> Le 7 mai 2017 à 08:16, Michael Matz <matz....@frakked.de> a écrit : > > On debain, if you have libc6-dev and musl-dev installed you get a strange mix > of glibc and musl objects and shared libraries linked into the exe. E.g. in > the above it picks up /usr/lib/x86_64-linux-gnu/libc.a (from glibc), which > has TPOFF32 relocs and those aren't handled by TCC. > > Removing libc6-dev, installing musl-tools, and using musl-gcc for compilation > ensures that there's no mixture at least. But that then fails because TCC > itself isn't prepared to look into e.g. /usr/include/x86_64-linux-musl for > standard headers like e.g. stdio.h, neither does it look into > /usr/lib/x86_64-linux-musl/ for startup files like crt1.o. So, yeah, the > detection/support of musl is early and doesn't work with the split-mind > approach that debian is using. > > It does work for the setup of musl as the main libc, like with alpine linux; > so I'm not sure the detection should be disabled or rather be improved (or > there should perhaps be a configure option to override the detection by > users).
To address that, I committed a first patch on mob to improve musl or uclibc detection: Now, configure does not enable musl or uclibc native support if a GNU linker is already present. This avoids interference for example on a Debian platform with musl-dev installed. More work is required to select musl libc in that case, with additional configure flags, i.e. --enable-musl and further code in tcc.h etc. Thanks, Marc _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel