Re: libidn 1.28 .pc file does not record -lintl if -lidn requires the former

[Simon Josefsson]

Matthias Andree <address@hidden> writes:

> [Please CC: me on replies, I am not subscribed.]
>
> Greetings,
>
> I have just been debugging dnsmasq, a user of libidn, on a current
> FreeBSD 10 development version, and come across a linker problem.
>
> The issue is that dnsmasq need not necessarily be linked against libintl
> (gettext), but possibly only against libidn.  However, if libidn itself
> is then linked against gettext, it requires (per ELF NEEDED tag)
> libintl.  On some systems, among them the clang-based FreeBSD 10, but
> also others, this fails at link time.  The cause for that is that some
> systems require all symbols from shared libraries to be resolved at link
> time.
>
> Example errors:
>
> cc  -o dnsmasq cache.o [...] ipset.o -L/usr/local/lib -lidn
> /usr/bin/ld: 6: invalid DSO for symbol `libintl_bindtextdomain' definition
> /usr/local/lib/libintl.so.9: could not read symbols: Bad value
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> gmake[2]: *** [dnsmasq] Error 1
>
> Now, the -L/path and -lidn options are taken from libidn.pc[.in].
>
> Could the next release of libidn please make sure to record -lintl in
> libidn.pc, too, if libidn is linked against libintl, so that
>
> pkg-config --libs libidn   would, in this situation, print
>
> -L/usr/local/lib -lidn -lintl

Hi Matthias.  I must admit I'm not a pkg-config expert, but isn't doing
that against the idea of pkg-config?  Our pkg-config script contains:

Libs: -L${libdir} -lidn
Libs.private: @LTLIBICONV@

I thought the idea was that the first line would be just the library
itself, which would (through ELF) drag in its dependencies
automatically, and the second line would cover the cases where someone
really needs all dependent libraries as well (like you).

I'd be happy to change this, but I'd like to make sure that I'm doing
the right thing and not causing problems for others.  Some people are
quite sensitive about libfoo dragging in explicit "-lbar" parameters,
since it will result in tools that link to libfoo will also link to
libbar which they typically don't need, and it causes unneeded shared
library dependencies on systems.

/Simon