Re: minimum installation query

[<pl...@pi...>]

On Wed, 23 Jan 2008 12:43:14 +0100, <pl...@pi...> wrote:

> On Wed, 23 Jan 2008 07:10:52 +0100, Ethan A Merritt  
> <merritt@u.washington.edu> wrote:
>
>> On Tuesday 22 January 2008 20:30, you wrote:
>>> On Wed, 23 Jan 2008 02:16:20 +0100, Ethan Merritt
>>> <merritt@u.washington.edu> wrote:
>>>
>>> > Anyhow, FWIW last time I tried to build a minimally-configured  
>>> gnuplot
>>> > it came in at 0.75 MByte for a 32-bit x86 executable image.  If you
>>> > can share libraries with apache, it should be smaller than that for
>>> > an arm executable (I think).
>>>
>>> Thanks for that guide.
>>>
>>> I found that all I needed to bring in was libstdc++ at about 831 kB
>>>
>>> my gnuplot came down to very close to a meg with "-mcpu=arm9 -Os"
>>>
>>>   ./configure --without-x --without-tutorial --without-pdf  
>>> --without-cairo
>>> --disable-wxwidgets --without-gd --with-readline=builtin
>>> --without-documentation --prefix=/debsTS/usr --host=arm-linux
>>>
>>>
>>> Can you see anything I have left in or has it just grown quite a bit  
>>> since
>>> you tried your minimalist trip?
>>
>> You will still get the default set of terminals built with this command.
>> Instead of all the explicit --without-terminalXXX options,
>> just edit .../src/term.h so that it only includes the terminal[s] that  
>> you
>> want.  This procedure is described in the installation instructions.
>> Probably in your case you can strip it all the way down to:
>>
>> term.h:
>> #include "estimate.trm"       /* used for enhanced text processing */
>> #include "svg.trm"            /* my only terminal type */
>>
>>
>>> It's not really a problem now I'm under 2 megs additional but if I'm  
>>> still
>>> carrying cruft it would be nice to strip it out.
>>
>> Other thoughts:
>>
>> - do not assume that the compiler's -s option will produce a smaller  
>> executable.
>>   Yes I know that's its claimed reason for existence, but it doesn't  
>> always work
>>   that way.
>>
>> - stripping the resulting executable (if you haven't already done so)  
>> should
>>   make it considerably smaller at the cost of being harder to debug  
>> errors.
>>
>> - I suspect that the build system is not smart enough to detect that  
>> some of
>>   the component modules are no longer required at all once you have  
>> stripped
>>   out essentially all of the default terminals.  In particular I  
>> suspect that
>>   bitmap.o can be replaced by a null file.  I am certain that you don't  
>> need
>>   mouse.o either, but I think the build system is smart enough to catch  
>> that
>>   one.
>>
>
> Hi,
>
> thanks for pointing out term.h , I'd not wanted to get too far into  
> hacking unless it was really required, I did not realise the code was so  
> well set up for this sort of change. It was well worth the effort it  
> saved me about 250K ;)
>
> O2 came out about the same as Os in size.
>
> I now have 780k or 670k stripped.
>
> Fun as all this is I probably need to focus on actually using it now. My  
> feeling is it's unlikely to get down to <600k whatever I do.
>
> If I need more space I should probably look at reducing libstdc++,  
> that's the killer.
>
> Many thanks for all your help. This has been invaluable and lot less  
> effor than I expected.
>
> regards, Peter.
>

Hi Ethan ,

I've dug this one out again. I'm now working on gcc 4.3.4 gnueabi -  
maverick fpu. (I've made some progress on the segfaults ;) )

I have term.h down to bare svg and enh but I seem to have grown by about  
100k since last time. (This may of course be gcc producing larger code but  
I doubt it to that point).

My current stripped and unstripped sizes are:

13323865 -rwxr-xr-x 1 user users 843771 May  5 15:51 src/gnuplot
13323870 -rwxr-xr-x 1 user users 751432 May  5 15:52 src/gnuplot

One thing I don't seem to be able to get rid off is postscript. I took all  
mention of it out of term.h but I can still see it building , This is  
presumably quite large as well.

Is it a core requirement or can I hack it out somewhere.

Thanks again, Peter.