Thread overview
Arch Linux ldc package can't use asan
Jan 09
Wild
Jan 09
Cym13
Jan 09
kinke
Jan 09
Wild
Jan 09
Wild
Jan 09
Wild
January 09
I don't know who's the current maintainer of the Arch Linux D packages. ldc1.7.0 from the Arch repositories doesn't work with -fsanitize=address right now, it fails to link. I originally filed an ldc bug here:

https://github.com/ldc-developers/ldc/issues/2488

But it turns out that the pre-built version from dlang.org works fine, so I opened an Arch bug here:

https://bugs.archlinux.org/task/57026

Atila
January 09
On Tuesday, 9 January 2018 at 15:19:37 UTC, Atila Neves wrote:
> I don't know who's the current maintainer of the Arch Linux D packages. ldc1.7.0 from the Arch repositories doesn't work with -fsanitize=address right now, it fails to link. I originally filed an ldc bug here:

I will look into this.

- Dan / The maintainer


January 09
On Tuesday, 9 January 2018 at 15:27:56 UTC, Wild wrote:
> On Tuesday, 9 January 2018 at 15:19:37 UTC, Atila Neves wrote:
>> I don't know who's the current maintainer of the Arch Linux D packages. ldc1.7.0 from the Arch repositories doesn't work with -fsanitize=address right now, it fails to link. I originally filed an ldc bug here:
>
> I will look into this.
>
> - Dan / The maintainer

Grasping the occasion to thank you for your work maintaining it.
January 09
On Tuesday, 9 January 2018 at 15:27:56 UTC, Wild wrote:
> On Tuesday, 9 January 2018 at 15:19:37 UTC, Atila Neves wrote:
>> I don't know who's the current maintainer of the Arch Linux D packages. ldc1.7.0 from the Arch repositories doesn't work with -fsanitize=address right now, it fails to link. I originally filed an ldc bug here:
>
> I will look into this.
>
> - Dan / The maintainer

Thanks. The official package ships with a renamed copy of the LLVM compiler-rt library (matching the LLVM version LDC was built with), libldc_rt.asan-x86_64.a. If a copy is out of the question, a dependency on the package containing that lib (original name: libclang_rt.asan-x86_64.a) and a symlink may do the job.
libFuzzer is handled like this as well. See https://github.com/ldc-developers/ldc/blob/v1.7.0/CMakeLists.txt#L742-L795.
January 09
On Tuesday, 9 January 2018 at 17:54:11 UTC, kinke wrote:
> Thanks. The official package ships with a renamed copy of the LLVM compiler-rt library (matching the LLVM version LDC was built with), libldc_rt.asan-x86_64.a. If a copy is out of the question, a dependency on the package containing that lib (original name: libclang_rt.asan-x86_64.a) and a symlink may do the job.
> libFuzzer is handled like this as well. See https://github.com/ldc-developers/ldc/blob/v1.7.0/CMakeLists.txt#L742-L795.

Thanks! Now I don't need track down what was missing.

Small question, is only *.a needed and not *.so?

- Dan
January 09
On Tuesday, 9 January 2018 at 17:54:11 UTC, kinke wrote:
> On Tuesday, 9 January 2018 at 15:27:56 UTC, Wild wrote:
>> On Tuesday, 9 January 2018 at 15:19:37 UTC, Atila Neves wrote:
>>> I don't know who's the current maintainer of the Arch Linux D packages. ldc1.7.0 from the Arch repositories doesn't work with -fsanitize=address right now, it fails to link. I originally filed an ldc bug here:
>>
>> I will look into this.
>>
>> - Dan / The maintainer
>
> Thanks. The official package ships with a renamed copy of the LLVM compiler-rt library (matching the LLVM version LDC was built with), libldc_rt.asan-x86_64.a. If a copy is out of the question, a dependency on the package containing that lib (original name: libclang_rt.asan-x86_64.a) and a symlink may do the job.
> libFuzzer is handled like this as well. See https://github.com/ldc-developers/ldc/blob/v1.7.0/CMakeLists.txt#L742-L795.

Extra info:
LDC should also recognize the libclang_rt.asan and libclang_rt.fuzzer libraries if they are in the same path where LDC would try to find the libldc copies. So the symlink is not even necessary in that case.

-Johan

January 09
On Tuesday, 9 January 2018 at 18:28:46 UTC, Johan Engelen wrote:
> Extra info:
> LDC should also recognize the libclang_rt.asan and libclang_rt.fuzzer libraries if they are in the same path where LDC would try to find the libldc copies. So the symlink is not even necessary in that case.
>
> -Johan

On Arch these files are stored in "/usr/lib/clang/5.0.1/lib/linux/",
and the archlinux package tool doesn't like symlinks that point
outside of the package. So a patch would be my only choice.

So my solution is:
sed -i "s/libclang_rt/clang\/$_llvmversion\/lib\/linux\/&/g" driver/linker-gcc.cpp

Would be nice if a future version of ldc checked this directory, or
if it would be possible to send in a constant to gnumake with this path.
January 09
On Tuesday, 9 January 2018 at 20:43:05 UTC, Wild wrote:
> On Arch these files are stored in "/usr/lib/clang/5.0.1/lib/linux/",
> and the archlinux package tool doesn't like symlinks that point
> outside of the package. So a patch would be my only choice.
>
> So my solution is:
> sed -i "s/libclang_rt/clang\/$_llvmversion\/lib\/linux\/&/g" driver/linker-gcc.cpp
>
> Would be nice if a future version of ldc checked this directory, or
> if it would be possible to send in a constant to gnumake with this path.

The ldc-1:1.7.0-2 is now pushed and -fsanitize=address works,
the -fsanitize=fuzzer option should work when this issue has been
fixed: https://bugs.archlinux.org/task/56023
January 09
On Tuesday, 9 January 2018 at 20:43:05 UTC, Wild wrote:
> On Tuesday, 9 January 2018 at 18:28:46 UTC, Johan Engelen wrote:
>> Extra info:
>> LDC should also recognize the libclang_rt.asan and libclang_rt.fuzzer libraries if they are in the same path where LDC would try to find the libldc copies. So the symlink is not even necessary in that case.
>>
>> -Johan
>
> On Arch these files are stored in "/usr/lib/clang/5.0.1/lib/linux/",
> and the archlinux package tool doesn't like symlinks that point
> outside of the package. So a patch would be my only choice.
>
> So my solution is:
> sed -i "s/libclang_rt/clang\/$_llvmversion\/lib\/linux\/&/g" driver/linker-gcc.cpp
>
> Would be nice if a future version of ldc checked this directory, or
> if it would be possible to send in a constant to gnumake with this path.

Yeah, I have this PR that I didn't look at for a while:
https://github.com/ldc-developers/ldc/pull/2345

-Johan