[Xastir] CoverSplit symbol issue with rtree in Fedora

[Richard Polivka, N6NKO]

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 <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.
>
>