Allow BDWGC to be linked dynamically #112
Conversation
This is useful for debugging, where profilers intercept and override dynamically linked symbols (e.g. `malloc` and `free`). As of this commit, there is no way to build a custom BDWGC fork and have that dynamically link to a program compiled with Alloy automatically. This is because `cargo` does not support bubbling up linker args to the final linked binary, so there is no way to programmatically set the rpath for BDWGC to the OUT directory in `library/bdwgc` [1]. Alloy programs must therefore set the `LD_PRELOAD` environment variable to prevent it from linking against the system libgc. [1]: rust-lang/cargo#9554
|
Could we make use of rust-lang/cargo#9554 (comment) |
I agree. This is really less than ideal. Fortunately though dynamic linking should never really be used unless you're trying to debug the collector.
The problem with this as I see it is that it must also be transitive, I've even tried using Personally I think this is the least worst option. |
|
OK let's revisit this at another point and see if we can improve things. This will have to do for now. |
|
@jacob-hughes I think we should have added docs to the |
This is useful for debugging, where profilers intercept and override dynamically linked symbols (e.g.
mallocandfree).As of this commit, there is no way to build a custom BDWGC fork and have that dynamically link to a program compiled with Alloy automatically. This is because
cargodoes not support bubbling up linker args to the final linked binary, so there is no way to programmatically set the rpath for BDWGC to the OUT directory inlibrary/bdwgc1.Alloy programs must therefore set the
LD_PRELOADenvironment variable to prevent it from linking against the system libgc.