I had a look at the libmad.a library in /libmad/.libs/ and it is only 103K so all the extra size must be comming from minimad and the mp3 data. Since the mp3 is only 20k minimad is adding 258k to the final binary. This seems like a lot?
Here is how i have changed minimad so far :
# include <stdio.h> # include "music.h" # include "mad.h"
static int decode(unsigned char const *, unsigned long);
int main (void) { unsigned char *fdm = &music[0]; decode(fdm, sizeof(music)); return 0; }
The rest is the same.
On Mon, 3 Jun 2002 13:55:03 +0100 "Gareth" G.C.Bransby-99@student.lboro.ac.uk wrote:
I have got mad running on an ARM development board with no operating system using an arm-elf compiler and newlib that i built from source. I have modified minimad.c slightly to suit the application. It no longer takes command line arguments. The mp3 is compiled into the binary in an array so decode() is just passed the start address of this array. The output is still sent to stdout for now. mman.h is no longer needed.
My problem is the compiled binary is 381K. The mp3 array is only 21K so this is not what is making it big. Are there any options i can pass to configure to optimise the code for size? This is what i passs to configure :
--enable-speed --disable-debugging --enable-fpm=arm --disable-nls --disable-mmap --host=arm-elf
The onnoying thing is a week ago the binary was compiling to about 220K. Now when i come back to it a week later after changing nothing it suddenly increases by 160K.
Lastly, I am still not certain what this 'stat' struct is for. If I am passing the array to decode() can i replace stat.st_size with the size of the array? This is my main finction :
{ struct stat stat; unsigned char *fdm = &music[0];
//printf("Started :\n"); decode(fdm, stat.st_size);
return 0; }
Thanks