Bugfix for 'DSO not on commandline'

[cschlote]

On Ubuntu Linux 22.10 the attempt to compile adrdox with ldc2 failed with: BF71E424C08F3A6D4232856F69528B07401A46B683CB4F3FC3760DC6D5493338/adrdox.o: undefined reference to symbol 'inflateEnd' /usr/bin/ld: /lib/x86_64-linux-gnu/libz.so.1: error adding symbol: DSO missing from command line

$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.39

There is a workaround for this problem. See https://stackoverflow.com/questions/19901934/libpthread-so-0-error-adding-symbols-dso-missing-from-command-line

This workaround has been added and fixes the linker problem.

[Geod24]

That doesn't seem like the right solution to me, for many reasons.

First, in the link you post, the person mentioning --copy-dt-needed-entries says it's a workaround, and mention a proper way to fix things.

Second, I am not even sure this is a dub bug. And I can't verify if it is because there is no test. I think that adrdox might very well just lack an explicit reference to one of its dependency, the one defining inflateEnd (libz?). It might also come from one of adrdox's dependency.

Also, in case you didn't know this, or someone else finds this bug report, you should be able to work around this issue yourself by using:

"lflags": [ "--copy-dt-needed-entries" ]

In adrdox.

[cschlote]

@Geod24
The proplem happens with all compilers (dmd, dmd-beta, ldc2 and gdc). And it happens with several projects I tried on Ubuntu 22.10. It's a bit like the --no-as-needed workaround also found in the sources - instead of properly ordering the object file, the Linker accepts any order and accepts also backwards references.

So, having '--no-as-needed' as a workaround on Linux with all compilers also justifies to have this PR to allow LD to follow references to other DSOs. This was the default before someone changed that in LD.

Otherwise you can of argue to remove --no-as-needed as well and to expect all sources and objects are given in proper and without cyclic dependancies.

Also worthy to note, this is a Linux LD problem, only. Adding this PR together with --no-as-needed just makes LD to behave like the linkers on other platforms. And no special knowlegde in dub.json is needed to build the package on all platforms.

[cschlote]

BTW: The proper solution would be to add all referenced DSOs to the "libs" array of dub.json.

[cschlote]

I tested the proper fix - adding libz - to adrdox, and this works as expected. This should also work for other projects with the same problem.

However, when I urgently need to build a dub project with many dependancies and the 'DSO missing on commandline' problem pops up , then I won't have the time to fix all dependant packages first, bevor I can compile the dub project. Reporting bugs, posting PRs, reviews and arguing with the maintainer can take weeks...

So maybe, some extra option to dub to enable the workaround in this PR might be useful. It would allow to build now and fix the dependancies later/in parallel. Or at least tell the package maintainers about the problem. Most important - even Noobs can pass some extra option to dub and get their dub project linked.

I imagine that this new LD default setting becomes the common standard for most distros, and again D will suddenly fail to work just because of this lame reason, and that no working workaround exists to build affected projects with minimal effort. Just another good way to push away people from using D...

[adamdruppe]

I think that adrdox might very well just lack an explicit reference to one of its dependency, the one defining inflateEnd (libz?). It might also come from one of adrdox's dependency.

I import std.zlib;.... since Phobos is the one calling inflateEnd it seems like Phobos is the one with the -lz dependency.

Though on the other hand, just because one part of Phobos uses it doesn't mean every application uses that part....