Closed timotheecour closed 3 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.).
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
Regarding the latter, see https://github.com/ldc-developers/ldc/pull/2454.
Is this resolved now? See linking help output here: https://dlang.org/blog/2018/03/06/ldc-1-8-0-released/
I'd say it definitely is.
-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
perhaps add an example in cmd line for ldmd2: -defaultlib=
set default library to name
=>
set default library to name, eg: -defaultlib=phobos2-ldc-shared,druntime-ldc-shared
isn't loader_path deprecated in favor of rpath?
should -defaultlib=phobos2-ldc-shared imply druntime-ldc-shared or do we perhaps want flexibility of mixing -defaultlib=phobos2-ldc-shared with other libs, eg druntime-ldc-debug-shared ?
what's the point of -debuglib if we can specify -defaultlib=phobos2-ldc-shared vs -defaultlib=phobos2-ldc-debug-shared ? could that be clarified in cmd line or docs? http://forum.dlang.org/thread/2e239c97-811f-0d26-ed39-f44461adfc13@dicebot.lv wasn't super clear on this either