ldc-developers / ldc

The LLVM-based D Compiler.
http://wiki.dlang.org/LDC
Other
1.2k stars 259 forks source link

Comma-separated list arguments for -{default,debug}lib should be documented #2446

Closed timotheecour closed 3 years ago

timotheecour commented 6 years ago

-defaultlib=phobos2-ldc-shared doesn't work this works: -defaultlib=phobos2-ldc-shared,druntime-ldc-shared

this isn't obvious at all from the docs; especially given that: otool -L libphobos2-ldc-shared.dylib shows: @loader_path/libdruntime-ldc-shared.76.dylib

dnadlinger commented 6 years ago

-defaultlib=phobos2-ldc-shared doesn't work this works: -defaultlib=phobos2-ldc-shared,druntime-ldc-shared

This is expected.

this isn't obvious at all from the docs; especially given that: otool -L libphobos2-ldc-shared.dylib shows: @loader_path/libdruntime-ldc-shared.76.dylib

Nothing unusual here, that's how linking works on macOS (and Linux as well). If the main executable depends on a library, then that library also needs to be linked. A transitive dependency is not enough to establish that.

perhaps add an example in cmd line for ldmd2

Clarifying the comma-separated list functionality would indeed be a good idea. I've updated the issue title accordingly.

As for making it easier for the user to link against a shared runtime, this is clearly something that needs improvement, and we are working on it – you might be interested in https://github.com/ldc-developers/ldc/pull/2443.

isn't loader_path deprecated in favor of rpath?

A few points: First, I don't think we set this explicitly, CMake takes care of the dependency setup. Secondly, @loader_path is older, but is it really deprecated? It is definitely used heavily in the wild still. Thirdly, as fas as I know, @rpath is not a direct replacement for @loader_path – for the @rpath dependency to be found, wouldn't the main executable (or whatever happens to load Phobos) need to set up RPATH accordingly?

should -defaultlib=phobos2-ldc-shared imply druntime-ldc-shared

No – the -{default,debug}lib switches (which may or may not be replaced by a more comprehensive target configuration setup in the future) are precisely intended to override the default behaviour to accommodate custom toolchain setups. One wouldn't want a lot of magic in that.

what's the point of -debuglib if we can specify -defaultlib=phobos2-ldc-shared vs -defaultlib=phobos2-ldc-debug-shared ?

The libraries specified with -debuglib used to be linked in by default in -g builds for better debugging. On closer inspection, this turned out not to be a good idea (missing optimizations, and even some O(1) -> O(n) changes due to some pre-/postconditions in druntime), and they need to be explicitly requested by -link-debuglib now. But the idea of decoupling user intent from library details remains: The user/build system/… shouldn't need to know how to link the different components standard library (think about adding a third library in the future, or maybe some special cross-compilation setup with different library names, etc.).

timotheecour commented 6 years ago

also, before crashing with hardware instruction error when starting an executable that was linked against a dynamic library that linked against libphobos.a instead of libphobos.dylib, writing to stderr a relevant error message would help debugging. Especially useful when dealing with third party libraries over which you have less control/visibility

dnadlinger commented 6 years ago

Regarding the latter, see https://github.com/ldc-developers/ldc/pull/2454.

JohanEngelen commented 6 years ago

Is this resolved now? See linking help output here: https://dlang.org/blog/2018/03/06/ldc-1-8-0-released/

kinke commented 3 years ago

I'd say it definitely is.