[Xastir] CoverSplit symbol issue with rtree in Fedora

[Tom Russo]

On Sat, Jun 30, 2007 at 03:15:10PM -0500, we recorded a bogon-computron collision of the <r.polivka at sbcglobal.net> flavor, containing:
>  Tom,
> 
>  I will run an "ldd" on non-cvs binary compiling with just -lrtree in a bit. 

No, please use a binary that does *not* have "-lrtree" (i.e., that has not
got the rtree library explicitly linked in).  Use of a "-Lrtree" without
the "-lrtree" to go with it is a no-op, by the way.  

Don't just post the ldd output, though --- what you need to do is go through
all the libraries that it lists and use "nm" to search for the one that
has RTreeSearch (or any of the other Rtree functions that xastir needs and
which are apparently getting to it from some other library than librtree.a).

>  Tom Russo wrote:
> > 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.  
[...]
> >>
> >>  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