indirect dependencies in libraries
Follow-up for https://lists.debian.org/debian-ada/2014/03/msg00017.html.
I wrote:
> If libbar depends on libfoo, -lfoo must be given both when linking
> libbar and later when linking an executable with libbar.
and was proven wrong by Björn. In normal circumstances, if (dynamic)
libbar is linked with (dynamic) foo, executables linking with libbar
do not need to repeat -lfoo.
My misunderstanding was caused by the case of libbar importing a
libfoo C function. A direct dependency on libfoo appears whenever the
user actually calls the function. This probably also applies to other
situations like bar renaming a foo procedure.
In such situations, there is no way to predict whether the user will
actually call this specific function. I see three scenarios:
- it is called, -lfoo is mandatory.
- it is not called (--as-needed), -lfoo does not hurt.
- it is not called (--no-as-needed), -lfoo causes a fake dependency.
The third scenario is rare, --as-needed becoming the default. The
penalty is light and easily avoidable by setting --as-needed. I
suggest that we always append -lfoo.
For the record, there are two ways to achieve this:
- Linker.Linker_Options in the GNAT project,
- Linker_Options pragma in the source code.
Both have pros and contras, I think that we should support both. I
only mention it so that readers "grep -ir linker_options ." after
reading this. I was bitten once :-)
Back to the general case, I suggest that the Debian Ada Policy
requires two projects in the -dev package:
- LIBRARY_static.gpr, with a Linker package handling indirect
dependencies if any.
- LIBRARY_dynamic.gpr, without Linker package in normal circumstances.
If this is accepted, dh-ada-library should be updated. It currently
parses the (dynamic) project used to build a packaged library (say
build.gpr), then generates the (dynamic) LIBRARY.gpr. It copies -l
options from Build.Leading_Library_Options and Build.Library_Options
into LIBRARY.Linker.Linker_Options.
I intend to apply the following changes:
- build.gpr can be static or dynamic.
- install LIBRARY_[dynamic|static].gpr accordingly
- copy Build.Linker.Linker_Options into LIBRARY.Linker.Linker_Options.
- ignore Build.Leading_Library_Options and Build.Library_Options,
which are intended for build time only.
I believe that this would cover all concrete situations, as long as
build.gpr provides sensible Linker.Linker_Options.
> Of course, if the program itself uses libfoo directly, then it should
> be linked using -lfoo (but you can get away with omitting it if
> --copy-dt-needed-entries is on).
The --(no-)copy-dt-needed-entries (or --(no-)as-needed for that
matters) are useful when hand-crafting command lines, but in my
opinion projects should avoid hard-coding them because they affect
following -l options of the eventual "gcc -shared" command line.
Reply to: