Fernando Rodriguez wrote:
Hi
Thanks for the tips, and sorry it took me a while to come back to this.
>> It means that the libxml2.so that you linked against had versioned symbols
> but
>> the one that's getting loaded doesn't.
>
> Actually it may be some other library that libxml.so linked against that has
> the versioned symbols. Running:
>
> # ldd /opt/local/bin/cmake
> # ldd /opt/local/bin/bsdtar
> # ldd /opt/local/lib/libxml2.so.2
>
> Will give you more info.
>
>>
>> Most likely the compiler wasn't compiled correctly and is linking against
> your
>> system libraries. You can see nm to list the symbols on the libraries, the
>> ones with versioned symbols will have an @VERSION suffix on all symbols. You
> can
>> use the LD_LIBRARY_PATH and LD_PRELOAD environment variables to load the
> right
>> libraries for troubleshooting.
Turns out there are 2 issues that are related, 1 of them probably responsible.
MacPorts base (portconfigure.tcl). It sets the -headerpad_max_install_names
linker option which is OS X specific (and ends up as a
"eaderpad_max_install_names" dependency in binaries). And it seems Linux really
should have `-Wl,-rpath,${prefix}/lib` in the LDFLAGS as its not the default to
generate binaries (shared libraries) with full rpath info on that platform.
Without that option, libraries only have their name (relative rpath without any
path info at all) stored, and that means the dynamic loader will fetch the 1st
library that matches the filename.
The alternative is adding ${prefix}/lib to the default LD_LIBRARY_PATH, but
that's not a good idea (trivial to set, less so to unset).
I'll upload a patch to trac for this. After rebuilding a few affected ports
with
it things now seem to function as expected/intended.
R.
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
