Bug#700525: unblock: sundials/2.5.0-2

[Julian Taylor]

On 02/27/2013 04:38 PM, Sébastien Villemot wrote:
> Le samedi 16 février 2013 à 16:47 +0100, Julian Taylor a écrit :
> 
>> also there are still undefined references remaining in a public library
>> in debian:
>>
>> root at ubuntu:/# ldd -r /usr/lib/libsundials_fnvecserial.so
>> ...
>> undefined symbol: N_VCloneVectorArrayEmpty_Serial
>> (/usr/lib/libsundials_fnvecserial.so)
>> undefined symbol: N_VNewEmpty_Serial	(/usr/lib/libsundials_fnvecserial.so)
> 
> I don’t think this specific issue is RC: the symbols are provided by
> libsundials_nvecserial, which is in the same package. So no dependency
> is missing. This just means that you have to link a program with
> "-lsundials_nvecserial -lsundials_fnvecserial" (as you would anyways
> have to do if doing static compilation).
> 
> Also, I tried to fix this by adding the "-lsundials_nvecserial" when
> linking libsundials_fnvecserial. Unfortunately, libtool ends up adding
> an incorrect rpath in the binary. I guess this is because the libtool
> embedded in sundials is very old, and updating libtool in this case
> seems non trivial and therefore not freeze policy-compliant.
> 


While it is not RC anymore, I disagree with closing the bug.
LDFLAGS is the wrong place for links, please fix it so derivatives do
not need to diverge from debian.


Please also add a pkg-config file that helps with this unusual type of
linking then (this is probably not appropriate for wheezy anymore).

such type of linking usually fails with ld --as-needed, as the symbols
are not needed by the application which does the link so gcc drops the
library, but if it works or not follows some rules not yet understood by
me (sometimes it works sometimes not).
But this again does not affect Debian.