standalone gnuplot build with all libraries
Ingo Thies
Is there a possibility to make a local static built that includes *all*
the required libraries in the executable?
Background: After the recent update where something in the library
structure has changed, I cannot run gnuplot any longer on some of out
institute's machines. I get the following error message:
error while loading shared libraries: libreadline.so.6: cannot open
shared object file: No such file or directory
The binary and the local gp libs are located in a separate folder in the
home directory (which is the same for all machines in the network).
However, while gnuplot runs nicely it refuses to start on any other
machine of the network. It seems that some libs are not taken from the
raid system on which the home directory is located but rather on the
local machines.
As a workaround, it would be useful to have an executable that does not
dynamically link to some libs but does contain everything it needs, so I
can compile it on a machine that has all the libs (e.g. including the
very rare glibs needed for GIF, PNG and such stuff) and than copy it to
wherever I need it. I know that the resulting all-in-one binary file may
be huge compared to the standard gnuplot executable, but disc space is
not an issue to me.
Is there a way to do such thing to get independent of any shared or
locally installed libraries?
Ingo
sfeam
> Hi
>
> Is there a possibility to make a local static built that includes *all*
> the required libraries in the executable?
That would be hard, if by "all" you include the system's own runtime
C support libraries
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6d1d000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6d10000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb6cf9000)
libc.so.6 => /lib/i686/libc.so.6 (0xb6bb9000)
Also it is unusual to have statically linking copies of the X11 libraries.
But for the others...
When you issue the "make" command, eventually it issues a link command like
the following:
g++ -g -O2 -I/usr/lib/wx/include/ -I/usr/lib/wx/include/gtk2-ansi-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -L/usr/lib -L/usr/lib
-o gnuplot
[snip lots of *.o files]
-lreadline -lncurses -lz -lgd -lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm -ljpeg -lfreetype -lpng -llua -lm -pthread -L/usr/X11R6/lib -lwx_gtk2_aui-2.8 -lwx_gtk2_xrc-2.8 -lwx_gtk2_qa-2.8 -lwx_gtk2_html-2.8 -lwx_gtk2_adv-2.8 -lwx_gtk2_core-2.8 -lwx_base_xml-2.8 -lwx_base_net-2.8 -lwx_base-2.8 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lm -lz -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
To link against static libraries instead, you would revise this command by
adding the keyword "-static" before the list of libraries. This will cause
the linker to search for
libreadline.a libncurses.a libz.a libgd.a and so on rather than
libreadline.so libncurses.so ...
Most installation packages for shared libraries also include
a *.a version for static linking. In some cases they provide a *.la
(gnu libtool) library file, which you would have to convert to *.a
But I don't recommend doing this.
> Background: After the recent update where something in the library
> structure has changed, I cannot run gnuplot any longer on some of out
> institute's machines. I get the following error message:
>
> error while loading shared libraries: libreadline.so.6: cannot open
> shared object file: No such file or directory
>
> The binary and the local gp libs are located in a separate folder in the
> home directory (which is the same for all machines in the network).
> However, while gnuplot runs nicely it refuses to start on any other
> machine of the network. It seems that some libs are not taken from the
> raid system on which the home directory is located but rather on the
> local machines.
There are many ways to fix this. Several alternatives:
1) Explicitly link the shared executable against the same version
of libreadline.so that is installed on your individual client machines,
even though the machine you are building on has (it seems) a
newer version
2) Install the newer libreadline locally on the user machines
(probably a good thing to do anyhow)
3) Add the networked shared library directory to /etc/ld.so.conf
on the client machines so that it is included in the search path for
shared libraries
4) Define LD_LIBRARY_PATH on the client machines to include the shared
library directory on the server
Ingo Thies
finally, it came out, that the trouble was due to a Linux update which
had been performed on some machines but not on the others, so it didn't
have anything to do with the gnuplot update at all. The problems are
fixed now. Nevertheless I'll reserve the option of doing a static make.
I guess that the only problem with this might by a larger binary file
which is not really an issue on a 20 TB raid system ;-)
Ingo