Re: [Plplot-general] C++ problem in cvs 20031004

[Alan W. I. <ai...@us...>]

On 2003-10-15 09:37-0500 Herng-Jeng Jou wrote:

> After I install PLplot into "/usr/local/plplot" directory,
> then I was trying to compile a standalone x01 without dynamic linkage at
> all to PLplot, and
> this is what I did:
> $ g++ -I/usr/local/plplot/include/plplot -c x01.cc
> $ g++ -g -O2 -o x01 x01.o  /usr/local/plplot/lib/libplplotcxxd.a
> /usr/local/plplot/lib/libplplotd.a /usr/lib/libfreetype.so
> /usr/local/plplot/lib/libcsirocsa.a -ldl

You should use plplot_libtool to solve the problem of making statically
linked versions of executables.

Here is what to do:

Adjust the line below for your prefix, but if I build
plplot-5.2.1.cvs.20031004 using

--prefix=/usr/local/plplot_at --disable-dyndrivers

Note the --disable-dyndrivers is essential because the combination of static
libraries (what you are ultimately trying to use) and dyndrivers does not
currently work.

plplot_libtool --mode=link g++ -all-static x01.cc \
-I/usr/local/plplot_at/include/plplot -L/usr/local/plplot_at/lib \
-lplplotcxxd -o x01 -ldl

then I get good results.

Herng-Jeng and Andrew, will you please confirm this also works well on your
systems?

Note the resulting executable is statically linked:

file x01
x01: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically
linked, not stripped

Also, the size of the executable is enormous

ls -l x01
-rwxr-xr-x    1 software software  4760851 Oct 15 11:36 x01*

But ./x01 -dev xwin, for example, works fine.

I tried the same thing in the c directory, and again no problems.

Also, I tried ordinary builds using make (which invokes plplot_libtool
without the -all-static and -ldl options) and they worked fine as well.

So plplot_libtool is your friend for sorting out various linking cases.
(Rafael is working on a replacement to plplot_libtool which should be
able to do the same thing in a simpler way, but until that works,
use plplot_libtool.)

What is going on here is that by default, both dynamic and static versions
of the plplot library are built.  And the plplot_libtool -all-static flag
(see info libtool for documentation on how to invoke libtool, and therefore
its locally configured copy for your system, plplot_libtool) forces use of
the static libraries.  On my system, the above plplot_libtool command
generates the following good compile/build commmand and executes it:

g++ -static x01.cc -I/usr/local/plplot_at/include/plplot -o x01
-L/usr/local/plplot_at/lib /usr/local/plplot_at/lib/libplplotcxxd.a
/usr/local/plplot_at/lib/libplplotd.a /usr/local/plplot_at/lib/libcsirocsa.a
/usr/local/plplot_at/lib/libcsironn.a -lqhull -lcd -lgd -lpng
/usr/lib/libjpeg.a -lz -litk3.1 -ltk8.3 -litcl3.1 -ltcl8.3
/usr/lib/libfreetype.a -L/usr/X11R6/lib -lX11 -ldl

So you could adjust your own g++ invocation to mimic this, but I think it is
much better to use plplot_libtool directly.

BTW, the reason I knew what to do with plplot_libtool was I pretty much
(except for the -all-static option and -ldl on the end) followed what was
done for the examples to build them.  I have already discussed why
-all-static is necessary.  I found that the -ldl flag was necessary for the
--all-static case because /usr/lib/libtcl8.3.a refers to dlopen and friends,
and you have to resolve those reference with an explicit -ldl option.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________