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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/20140318215845.GA742@pegase
