[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: how to add an indirect library linker dependency

Nicolas Boulenguez writes:
> As far as I know, the current practice for a package providing a
> library depending on another library is to mention the linker options
> in the *build* project, say for example
>   for Library_Options use ("-Wl,--as-needed", "-lgmp", "-lmpfr");
> but not to mention them in the *installed* project. I guess that they
> are embedded in the dynamic library, as I can compile a program using
> that installed project: ld finds the symbols when linking, then when
> running. Please look at the attached files for concrete examples.
> This scheme is used by many packages with any version of gnat, and
> used to work as well for gtkada-2.18/gnat-4.4. Since
> gtkada-2.24/gnat-4.6, the package builds fine, but the test fails with
> ld complaining about unresolved symbols. The user needs to add "-gnatl
> -lgtk and other -l options" to the gnatmake command line.
> I am interested in any explanation. Just in case, I tried removing
> --as-needed, this does not change anything.

I think the explanation is that ld no longer links an executable

* with --no-as-needed (the default on Debian), ld links the executable
  against all shared libraries specified on its command line.  In the
  case of GNAT Project files, this normally means only the shared library
  defined by the project file.

* with --as-needed (the default on Ubuntu), ld links the executable
  against a *subset* of the shared libraries specified on its command
  line; this subset contains only the libraries providing symbols
  actually needed by the executable.

* ld no longer links the executable transitively with shared libraries
  needed by shared libraries specified on the command line.

> Anyway, Adacore's documentation seems to say that the right solution
> is to set
>   for Library_Options use (blah);
> in the *build* project and
>   package Linker is
>      for Linker_Options use (blah);
>   end Linker;
> in the *installed* project. Maybe we should recommend this second
> scheme in the policy.

Yes, I just got confirmation from an Ubuntu porter that this solves the
problem, even with --as-needed.  I think an update to the Debian Policy
for Ada is in order.

Ludovic Brenta.

Reply to: