Menu
▾
▴
Re: Heavy weight deps (was y scaling error)
|
From: <pl...@pi...> - 2007-11-07 10:52:32
|
On Wed, 07 Nov 2007 06:53:57 +0100, Ethan A Merritt = <merritt@u.washington.edu> wrote: > On Tuesday 06 November 2007 19:33, pl...@pi... wrote: >> On Tue, 06 Nov 2007 20:55:50 +0100, Ethan Merritt >> <merritt@u.washington.edu> wrote: >> >> > >> >> I'm using gnuplot on ARM embedded. At the moment it's running on a= = >> full >> >> debian image via nfs but when it goes onboard cruft will not be an= >> >> option. >> > The major consideration in building a lightweight gnuplot executabl= e >> > is which terminal drivers to include. But the LaTeX terminals are = = >> pretty >> > small, so disabling them isn't likely to save any space unless you >> > disable >> > PostScript support as well. I made a chart 2 years ago for version= = >> 4.0 >> > = >> http://skuld.bmsc.washington.edu/people/merritt/gnuplot/index.html#bl= oat >> > I should update it against current CVS. >> >> >> Thanks, that new info will be very useful. Sounds like my ./configure= = >> arg >> list is going to be rather long! >> >> Is there a more concise way to get a bare bones gnuplot >> --without-terminals and just add in the one that I need , svg? > > Interesting question. > I see that it's hard to turn off a lot of the auto-detected stuff. > For instance, doing > ./configure --disable-wxwidgets --disable-cairo > nevertheless detects and links against the cairo and pango libraries, = = > even > though it doesn't actually build the wxt or cairo terminals. Stupid. > And just removing the library references from the Makefile doesn't wor= k > either, because it still tries to compile gp_cairo.c. Not that = > gp_cairo.o > is very big, but it's annoying. > > > Here's my go at it: > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%% > ./configure --without-x --without-gd \ > --disable-wxwidgets --disable-cairo --disable-mouse > echo '#include "svg.trm"' > src/term.h > echo '#include "estimate.trm"' >> term.h > [Manually hack src/Makefile to remove all the cairo/pango related libr= ary > definitions, and the gp_cairo.o target] > make > > size gnuplot > text data bss dec hex filename > 631437 30580 14432 676449 a5261 gnuplot > > ldd gnuplot > linux-gate.so.1 =3D> (0xffffe000) > libreadline.so.5 =3D> /lib/libreadline.so.5 (0xb7f2d000) > libncurses.so.5 =3D> /lib/libncurses.so.5 (0xb7ee8000) > libz.so.1 =3D> /lib/libz.so.1 (0xb7ed5000) > libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0xb7cfb000) > libm.so.6 =3D> /lib/tls/libm.so.6 (0xb7cd6000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0xb7ccb000) > libc.so.6 =3D> /lib/tls/libc.so.6 (0xb7b9c000) > libdl.so.2 =3D> /lib/libdl.so.2 (0xb7b98000) > /lib/ld-linux.so.2 (0xb7f75000) > > ./gnuplot > gnuplot> set term > Available terminal types: > svg W3C Scalable Vector Graphics driver > unknown Unknown terminal type - not a plotting device > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%% > > Are you sure you don't want at least a few more output options? > > svg by itself is pretty horrible for pm3d or image plots. > Normally if you're creating svg pages, you would embed links to png > images instead. > > Adding libgd would get you png, jpeg and gif (including animated gif).= > Although if you want nice fonts then it'll drag in libfreetype, which > isn't so lightweight. By the time you have libgd, libpng, libfreetype= , > that's probably an additional hit equal in size to gnuplot itself. > Of course those are shared libraries, so if you're using them for > something else already they are essentially free. > > And it's probably worth including dumb.trm, if only for debugging. > > Will there be a user interface of any sort, or will it be entirely > script-driven? > > Thanks for all the detail, it looks like I should get quite close to wha= t = I want with all that. The application is a headless hardware monitoring system. My aim is to = provide continual realtime data viewing with svg and apache so in = principal that one terminal is enough. SVG seems ideally suited to plots= = since it allows zooming in for detail and is way lighter than png. Since svg rendering is getting pretty stable on Opera, konqueror and = Firefox I think this will do the job. Most of it will be automatic updates running off cron or triggered by th= e = monitoring software. I'm not too close to installing on the board yet, but I'm running native= = ARM over nfs during the development stage. I'll get back to this in deta= il = once I get to hone all this down to fit on the board. Many thanks for your help. Peter. |
