I ran into some linking issue when building tsschecker for Linux in CI environment. Like this:
/usr/bin/ld: /usr/local/lib/libplist-2.0.a(xplist.o): relocation R_X86_64_32 against .rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: /usr/local/lib/libplist-2.0.a(plist.o): relocation R_X86_64_32 against.bss' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: /usr/local/lib/libplist-2.0.a(node.o): relocation R_X86_64_32 against .rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: /usr/local/lib/libplist-2.0.a(base64.o): relocation R_X86_64_32S against.rodata.str1.16' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: /usr/local/lib/libplist-2.0.a(time64.o): relocation R_X86_64_32S against .rodata.cst4' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: /usr/local/lib/libplist-2.0.a(bplist.o): relocation R_X86_64_32S against.rodata' can not be used when making a PIE object; recompile with -fPIE
collect2: error: ld returned 1 exit status
While the same building procedure in a clean docker container with minimal installed packages does not produce any error.
It blows my mind when I found the following output from ./configure
I ran into some linking issue when building tsschecker for Linux in CI environment. Like this:
While the same building procedure in a clean docker container with minimal installed packages does not produce any error.
It blows my mind when I found the following output from
./configure
And the following code
https://github.com/libimobiledevice/libplist/blob/ebf2fdb938c755026668c8418da290e6870c1987/configure.ac#L22-L26
So anything else is using gcc, while libplist decided to use clang.
If you prefer clang over gcc, feel free to specify
CC=clang
in your CI script. But please don't do that inconfigure.ac
.