[Xastir] CoverSplit symbol issue with rtree in Fedora

Tom Russo russo at bogodyn.org
Sat Jun 30 15:28:59 EDT 2007


On Fri, Jun 29, 2007 at 06:15:04PM -0700, we recorded a bogon-computron collision of the <jerutley at gmail.com> flavor, containing:
>  On 6/29/07, Richard Polivka, N6NKO <r.polivka at sbcglobal.net> 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.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick



More information about the Xastir mailing list