Menu
▾
▴
gnuplot-beta
|
From: <pl...@pi...> - 2008-01-21 15:26:02
|
Hi, I am trying to build a minimum sized installation for use on an arm SBC = = using crosstools on debian 3.1 Mostly it seems to be going perfectly but I have a couple of hitches. Firstly gnuplot.gih is about half a meg that I could do without. It's = addind about 25% to the foot print and will be totally useless on the = headless target. Is there (or should there be) a means to take this out = of = the build options? I could of course just delete it but that's a hack and I dont know if it= = will cause a failure at runtime. Also it appears not to get built by `make` but during `make install` it = = seems to be detected as missing and an attempt is made to build it. This= = suggests an error in the make files. prof@debbox:~/tmp/gnuplot$ ./configure --without-x --without-tutorial = --without-pdf --without-cairo --disable-wxwidgets --without-gd --with-readline=3Dbuiltin --prefix=3D/debsTS/usr --host=3Darm-linux su make install .... make[3]: Leaving directory `/home/prof/tmp/gnuplot/src/wxterminal' make[2]: Leaving directory `/home/prof/tmp/gnuplot/src/wxterminal' make[2]: Entering directory `/home/prof/tmp/gnuplot/src' arm-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I../term -I../term -DBINDIR=3D\"/debsTS/usr/bin\" -DX11_DRIVER_DIR=3D\"/debsTS/usr/libexec/gnuplot/4.3\" -DGNUPLOT_PS_DIR=3D\"/debsTS/usr/share/gnuplot/4.3/PostScript\" -DCONTACT=3D\"gnu...@li...\" -DHELPFILE=3D\"/debsTS/usr/share/gnuplot/4.3/gnuplot.gih\" -DGNUPLOT_X11=3D\"`echo gnuplot_x11 | sed 's,x,x,'`\" -g -O2 -MT alloc= .o -MD -MP -MF .deps/alloc.Tpo -c -o alloc.o alloc.c /bin/sh: line 1: arm-linux-gcc: command not found make[2]: *** [alloc.o] Error 127 make[2]: Leaving directory `/home/prof/tmp/gnuplot/src' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/prof/tmp/gnuplot/src' make: *** [install-recursive] Error 1 This error is coming to light since root does not have the cross compile= r = in its path. If I try install as user (which it does not have write perm= s = for) it creates the gih and then root can install it. Again it seems wro= ng = that it only gets build by make install rather than make. Root should no= t = need to build anything to run install and finally, as I said I do not wa= nt = the gih file anyway. ./configure tells me that help is always build . This seems to be half = correct. I would be best for this installation if I could be opted out. What is the best way to clean this up? Thanks in advance, Peter. |
|
From: Ethan A M. <merritt@u.washington.edu> - 2008-01-21 20:52:06
|
On Monday 21 January 2008 07:25, pl...@pi... wrote: > Hi, > > I am trying to build a minimum sized installation for use on an arm SBC > using crosstools on debian 3.1 > > Mostly it seems to be going perfectly but I have a couple of hitches. > > Firstly gnuplot.gih is about half a meg that I could do without. It's > addind about 25% to the foot print and will be totally useless on the > headless target. Is there (or should there be) a means to take this out of > the build options? > > I could of course just delete it but that's a hack and I dont know if it > will cause a failure at runtime. You can test the effect for yourself easily. Just delete the file. It causes a non-fatal error message at runtime if you type "help": /usr/local/share/gnuplot/4.3/gnuplot.gih: No such file or directory gnuplot.gih compresses by about a factor of about 4X using gzip. Perhaps it would be worth tweaking the code to uncompress dynamically? > Also it appears not to get built by `make` It is normally. I don't know what you may have tweaked in the Makefile. > but during `make install` it > seems to be detected as missing and an attempt is made to build it. This > suggests an error in the make files. No. That is correct behavior. "make install" is a superset of "make all". If it detects that a component hasn't been made, it will do that first. > /bin/sh: line 1: arm-linux-gcc: command not found > make[2]: *** [alloc.o] Error 127 > make[2]: Leaving directory `/home/prof/tmp/gnuplot/src' > make[1]: *** [install-recursive] Error 1 > make[1]: Leaving directory `/home/prof/tmp/gnuplot/src' > make: *** [install-recursive] Error 1 > > > This error is coming to light since root does not have the cross compiler > in its path. [shrug] If you don't want to have it in the path permanently, you could still put the full path in the environmental variable CC before doing "make". > If I try install as user (which it does not have write perms > for) it creates the gih and then root can install it. Again it seems wrong > that it only gets build by make install rather than make. Root should not > need to build anything to run install and finally, as I said I do not want > the gih file anyway. FWIW, I have the same problem with the emacs support files. No matter what I tell gnuplot's ./configure script, "make install" always tries to write into /usr/local/share/emacs/site-lisp/ and fails if it doesn't have root permission. This drives me bats, but I've never figured out how to fix it. > ./configure tells me that help is always build . This seems to be half > correct. I would be best for this installation if I could be opted out. > > What is the best way to clean this up? In the Makefile there is a line SUBDIRS = config m4 term src docs $(LISPDIR) man demo tutorial share Remove the "docs" entry and any others that you do not care about. If you are willing to sacrifice the help subsystem in order to make the footprint smaller, then logically you would also want to omit help.c from the list of source files and comment out the calls to its routines. You used to be able to accomplish this by adding -DNO_GIH to the CFLAGS, but that option seems to have suffered from bit rot in a couple of places. I'll see about whiping up a patch to restore that as a viable option unless you beat me to it. -- Ethan A Merritt |
|
From: <pl...@pi...> - 2008-01-21 21:50:34
|
On Mon, 21 Jan 2008 21:52:07 +0100, Ethan A Merritt = <merritt@u.washington.edu> wrote: > In the Makefile there is a line > SUBDIRS =3D config m4 term src docs $(LISPDIR) man demo tutorial share= > Remove the "docs" entry and any others that you do not care about. That the simplest solution. It did the trick. After a closer look I realised I was confusing two similar fs clones I'd= = been working on. The true problem was the trimmed down fs was lacking = doc2gih and indeed make was failing as well, so that is all consistant. What this does bring out is that there is no check for doc2gih in the = preamble. Since this fails to compile and hence fails to install even th= e = executable this is a fatal error and probably should be checked for in t= he = preamble. Sorry I did not spot this earlier. regards. |
|
From: <HBB...@t-...> - 2008-01-21 22:33:50
|
pl...@pi... wrote: > What this does bring out is that there is no check for doc2gih in the > preamble. Since this fails to compile and hence fails to install even the > executable this is a fatal error doc2gih is not meant to be installed anywhere. It's compiled inside the build tree and used to create gnuplot.gih, and that's the end of its usefulness. This will most probably fail to work in a cross build. |
|
From: <pl...@pi...> - 2008-01-21 21:30:38
|
On Mon, 21 Jan 2008 21:52:07 +0100, Ethan A Merritt = <merritt@u.washington.edu> wrote: > On Monday 21 January 2008 07:25, pl...@pi... wrote: >> Hi, >> >> I am trying to build a minimum sized installation for use on an arm S= BC >> using crosstools on debian 3.1 >> >> Mostly it seems to be going perfectly but I have a couple of hitches.= >> >> Firstly gnuplot.gih is about half a meg that I could do without. It's= >> addind about 25% to the foot print and will be totally useless on the= >> headless target. Is there (or should there be) a means to take this o= ut = >> of >> the build options? >> >> I could of course just delete it but that's a hack and I dont know if= it >> will cause a failure at runtime. > > You can test the effect for yourself easily. Just delete the file. > It causes a non-fatal error message at runtime if you type "help": > /usr/local/share/gnuplot/4.3/gnuplot.gih: No such file or directory > > gnuplot.gih compresses by about a factor of about 4X using gzip. > Perhaps it would be worth tweaking the code to uncompress dynamically?= > >> Also it appears not to get built by `make` > > It is normally. I don't know what you may have tweaked in the Makefile= . No, I have not touched the makefile . I'll update to cvs and check again= . > >> but during `make install` it >> seems to be detected as missing and an attempt is made to build it. T= his >> suggests an error in the make files. > > No. That is correct behavior. "make install" is a superset of "make = > all". > If it detects that a component hasn't been made, it will do that first= . > I realise that , I was meaning it seemed there was an error in that it w= as = not getting caught my make itself. This have been missed if it got picke= d = up by make install. I'll report back if it still does on clean cvs. >> /bin/sh: line 1: arm-linux-gcc: command not found >> make[2]: *** [alloc.o] Error 127 >> make[2]: Leaving directory `/home/prof/tmp/gnuplot/src' >> make[1]: *** [install-recursive] Error 1 >> make[1]: Leaving directory `/home/prof/tmp/gnuplot/src' >> make: *** [install-recursive] Error 1 >> >> >> This error is coming to light since root does not have the cross = >> compiler >> in its path. > > [shrug] If you don't want to have it in the path permanently, you coul= d > still put the full path in the environmental variable CC before doing = = > "make". Again this is not an issue, I was just explaining my rather odd set up = which caused it to show up in this way. > >> If I try install as user (which it does not have write perms >> for) it creates the gih and then root can install it. Again it seems = = >> wrong >> that it only gets build by make install rather than make. Root should= = >> not >> need to build anything to run install and finally, as I said I do not= = >> want >> the gih file anyway. > > FWIW, I have the same problem with the emacs support files. No matter= = > what > I tell gnuplot's ./configure script, "make install" always tries to = > write > into /usr/local/share/emacs/site-lisp/ and fails if it doesn't have r= oot > permission. This drives me bats, but I've never figured out how to fi= x = > it. > LOL >> ./configure tells me that help is always build . This seems to be hal= f >> correct. I would be best for this installation if I could be opted ou= t. >> >> What is the best way to clean this up? > > In the Makefile there is a line > SUBDIRS =3D config m4 term src docs $(LISPDIR) man demo tutorial share= > > Remove the "docs" entry and any others that you do not care about. > > If you are willing to sacrifice the help subsystem in order to make th= e > footprint smaller, then logically you would also want to omit help.c f= rom > the list of source files and comment out the calls to its routines. I'm not that tight I need to byte pinch at this stage but saving 500k + = is = relevant. > You used to be able to accomplish this by adding -DNO_GIH to the CFLAG= S, > but that option seems to have suffered from bit rot in a couple of = > places. > I'll see about whiping up a patch to restore that as a viable option > unless you beat me to it. > Thanks, I would have thought that the most consistant way would be = --without-help , like --without-doc . That would keep everything tidy in= = one ./configure command . I wanted to make sure I was not over looking some option. Many thanks for such a detailed reply. regards. Peter. |
|
From: Ethan M. <merritt@u.washington.edu> - 2008-01-21 23:02:56
|
On Monday 21 January 2008 13:16, pl...@pi... wrote: > > If you are willing to sacrifice the help subsystem in order to make the > > footprint smaller, then logically you would also want to omit help.c from > > the list of source files and comment out the calls to its routines. > > I'm not that tight I need to byte pinch at this stage but saving 500k + is > relevant. So now I'm curious as to how small you managed to make the executable. What drivers have you decided to include? Did you link to shared libraries, or is it static? What sort of display is present on the device you are building for? Can you suggest alternative mechanisms for help access that would be reasonable? Maybe the "help" command could trigger a web browser pointed to on-line documentation hosted elsewhere. -- Ethan A Merritt |
|
From: <pl...@pi...> - 2008-01-22 00:04:45
|
On Tue, 22 Jan 2008 00:02:57 +0100, Ethan Merritt <merritt@u.washington.edu> wrote: > On Monday 21 January 2008 13:16, pl...@pi... wrote: >> > If you are willing to sacrifice the help subsystem in order to make >> the >> > footprint smaller, then logically you would also want to omit help.c >> from >> > the list of source files and comment out the calls to its routines. >> >> I'm not that tight I need to byte pinch at this stage but saving 500k >> + is >> relevant. > > So now I'm curious as to how small you managed to make the executable. > > What drivers have you decided to include? > Did you link to shared libraries, or is it static? > What sort of display is present on the device you are building for? > > Can you suggest alternative mechanisms for help access that would be > reasonable? Maybe the "help" command could trigger a web browser > pointed to on-line documentation hosted elsewhere. > well I haven't really tried to optimise the footprint , just lighten it a bit. I may need to dig further later. It's mainly a case of removing as many deps as possible. I really do not require gnuplot help in the current context. I am using gnuplot on an SBC that does some simple control and data logging. The idea is to use gnuplot to preprocess the live data and provide graphical output in svg format that can be served up by apache. There will probably be some simple user interface via javascript so all calls to gnuplot will be scripts not user. This means I can dump most of the baggage like x11 , png ,gd etc since svg is one of the std terminals. It looks like about 2MB for gnuplot itself but I still have -g at this stage and not -Os. I expect I can drop that a lot if needed. I'm currently trying to determine exactly what deps I do need to cross-build so if you have any hints on determining the list it would be helpful. eg is zlib reqd if I'm not using gd/png ? Hans: >> doc2gih is not meant to be installed anywhere. It's compiled inside >> the build treeand used to create gnuplot.gih, and that's the end of its >> usefulness. This will mostprobably fail to work in a cross build. thanks for explaining what that was about. Luckily I have got around the problem as Ethan suggested by hacking the SUBDIRS line. Thank you both for your help ;) |
|
From: <pl...@pi...> - 2010-05-05 13:59:43
|
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. |
