Tom,

I will run an "ldd" on non-cvs binary compiling with just -lrtree in a bit. I am trying to finish up some pesky yardwork. I am in just now because the pager went off for a completely useless call.

73 from 807,

Richard, N6NKO


Tom Russo wrote:
On Fri, Jun 29, 2007 at 06:15:04PM -0700, we recorded a bogon-computron collision of 
the <[EMAIL PROTECTED]> flavor, containing:
 On 6/29/07, Richard Polivka, N6NKO <[EMAIL PROTECTED]> wrote:

I will send the -v from gcc and the output from both runs under a
separate email. I don't think that there is a problem with xastir. I am
beginning to believe that there is an issue between the -l and the -L
calls in gcc.
 Those 2 flags do completely different things:

 -L - specifies directories to be searched for library files
 -l - specifies libraries to be linked in, without the "lib" in the name

 So, -Lrtree -lrtree flags will attempt to link in the librtree.{so,a}
 file, and include the directory "rtree" in the search path used to
 find libraries.  Since xastir includes the functionality of rtree in
 the main executable, it's probably looking for librtree.a to compile
 in static (am I right Curt?), and it will probably be inside the
 directory "rtree" included with the xasitr source code.

 The order of these two flags do not matter at all, since they indicate
 completely different things.

Yes, absolutely.  The order is not supposed to matter, and if all were right
and proper with F7, both the -L (to tell where to look) and the -l (to tell
what to look for) would have been essential.

What is very telling, though, is that Richard did not get a linker failure
from unresolved symbols when he removed the -lrtree.  This suggests rather
strongly that some other library that's being included is providing
a duplicate of the rtree stuff.  That is scary.

Without the -lrtree, the loader should have complained about unresolved
symbols "RTreeSearch", "RTreeDestroyNode", RTreeNewIndex, and RTreeInsertRect. That it linked at all says that these are present elsewhere.
Now the trick is to find them.

Richard:  You'll need to look through all the libraries that *are* still being
linked in (all those "-l" flags in the final link line) using "nm" to see which
one has RTreeSearch, for example.  You might also need to look through
shared libraries that are being pulled in, so do an "ldd" on your final
xastir binary to find out what those are.

I'm astonished that any other library on the system has that stuff, and that
it is quietly being used.  I'm also astonished that the linker didn't just
complain about duplicate symbols instead of that obscure bit about relocation.

_______________________________________________
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

Reply via email to