[Discuss] Compiling a binary

[Hans Oeste]

I want to thank you all for your help with this.  I certainly looks like a
daunting task if I proceed with it.
 
Again, thank-you.
 
I think I'll see if I can explore another avenue first for which I will
start another thread.  I will keep this information on the back burner as
insurance.
 
Hans
 
-------Original Message-------
 
From: Alan W. Irwin
Date: 09/27/06 17:01:59
To: discuss at vlug.org
Subject: Re: [Discuss] Compiling a binary
 
On 2006-09-27 15:38-0700 p.willis at telus.net wrote:
 
> use ldd to get a list of dependencies for
> your application, create a dependency tree,
> make sure you link all those libraries into
> your application.
 
Additional issues:
 
* Use the -r option on ldd.  That picks up additional symbols that have not
been resolved by the library dependencies that ldd knows about for badly
linked libraries where the list of dependent libraries is incomplete.
 
* Be careful of the order in which static libraries are mentioned on the
link line.  Linkers proceed down the list of libraries in a serial manner,
and if any library has symbols resolved by some library previous to it in
the list, then you will have to mention that previous library later in the
list as well.
 
* Even so, when I went through this exercise (making a statically linked
application) recently, there were still plenty of unresolved symbols (mostly
involving X-related libraries). There is probably a better way, but I found
I had to do several hours worth of google searching for the symbols to find
the associated library name I had to add to the link.  It was not at all
clear that I was going to win the battle until the last undefined symbol
finally disappeared after a good guess on my part.  Mass use of nm could be
your friend here, but unfortunately most/all Linux distros strip symbols
from their installed libraries.
 
* As Peter alluded to, the link command warned about plug-ins that were
dlopened by various libraries.  As I recall there were also plug-in warnings
when I ran the executable, but I seemed to get away with it, and the
executable actually worked.
 
The whole experience although ultimately successful was rather pain-filled.
Static linking of executables was routine for the 80's when you only had to
deal with a handful of libraries, but I am convinced its a pretty desperate
measure now when you could well be dealing with a list of 100 different
libraries all of which have to be in a particular order, and often where you
are guessing at the library name based on a google search for the missing
symbol.  Of course, static executables might be worthwhile for the case when
you are doing binary distribution of the executable, but otherwise I would
strongly advise staying away from them.  For example, I went through the
exercise because some PLplot user wanted to do such a binary distribution of
one of his executables, but so far he hasn't been even able to replicate my
static build success on his distribution following my cookbook of what
arcane X-related libraries I had to add to the link line, and I believe from
other things he has said that he is pretty experienced.
 
Alan
__________________________
Alan W. Irwin
 
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
 
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); 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
__________________________
_______________________________________________
Discuss mailing list
Discuss at vlug.org
http://ladybug.vlug.org/cgi-bin/mailman/listinfo/discuss