Bug 5278 – gentoo's 'hardended' gcc doesn't work with dmd

My program is this: void main() {} My bash session looks like this: $ dmd main.d -v binary dmd version v2.050 config /usr/local/share/dcompilers/dmd/linux/bin/dmd.conf parse main importall main import object (/usr/local/share/dcompilers/dmd/linux/bin/../../src/druntime/import/object.di) semantic main semantic2 main semantic3 main code main function main gcc main.o -o main -m32 -Xlinker -L/usr/local/share/dcompilers/dmd/linux/bin/../lib -Xlinker --export-dynamic -lphobos2 -lpthread -lm /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. $ ./main Segmentation fault I'm on 64-bit Gentoo Linux, though I am creating 32-bit executables like normal. This is a problem for dmd v2.050 and v2.049. v2.048 runs just fine, though it also makes the linker complain about "creating a DT_TEXTREL in object."

Additional note: as far as I can tell this afflicts ALL programs I write with DMD, not just the trivial do-nothing program.

Something looks wrong with your 32 bit gcc installation. Notice that gcc is invoking the 64 bit linker. Can you successfully build any 32 bit C apps with gcc? I'm going to guess no.

(In reply to comment #2) > Something looks wrong with your 32 bit gcc installation. Notice that gcc is > invoking the 64 bit linker. Can you successfully build any 32 bit C apps with > gcc? I'm going to guess no. Good thought. I still seem to be able to build 32 bit C apps though: chad@Hugin ~/cprojects/ctesting $ gcc trivial.c -o trivial chad@Hugin ~/cprojects/ctesting $ file trivial trivial: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped chad@Hugin ~/cprojects/ctesting $ ./trivial chad@Hugin ~/cprojects/ctesting $ gcc trivial.c -m32 -o trivial chad@Hugin ~/cprojects/ctesting $ file trivial trivial: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped chad@Hugin ~/cprojects/ctesting $ ./trivial chad@Hugin ~/cprojects/ctesting $ cat trivial.c int main(int argc, char *argv[]) { return 0; } I checked dmd 2.050 at the same time just to make sure this isn't because I changed my system config. It still produces segfaulting executables. I have encountered another program that I didn't expect to segfault but did: the Gish demo (http://www.chroniclogic.com/gish_download.htm). I don't know if it's related because the segfault is such a terribly vague error and I don't feel like learning how to disassemble executables again right now :/ If someone wants to point me in the right directions to do that though, I wouldn't mind. So hey, maybe there is something special about my system that makes things crashy, but it'd be nice if the D executables could run on my system without crashing like all of the other executables on my system that don't crash.

Try "gcc -v trivial.c -m32 -o trivial" to see which linker is being invoked in the working 32 bit case. Also try "gcc -v trivial.c -o trivial -m32" to closer match the way dmd is invoking gcc. Which linker is being invoked now? I just tried those experiments on my box, and both forms correctly built 32 bit binaries. Another thing to do to try to gather more information, on the dmd command line, add: -L-v. That should be enough to show that collect2 is being invoked with -m elf_i386. For even more details, try running dmd with: -L-v -L-Wl,-v. That will add another -v down at the ld command which will give even more output, showing that ld is being invoked with -m elf_i386 as well. I assure you that dmd produces proper 32 bit executables on my linux x86_64 box. So, the exercise here is to figure out what's different, why, and how to resolve it.

Alright, here goes: chad@Hugin ~/cprojects/ctesting $ gcc -v trivial.c -m32 -o trivial Reading specs from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/specs Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --disable-libgomp --enable-checking=release --disable-libgcj --enable-languages=c,c++,treelang --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.3.2-r3 p1.6, pie-10.1.5' Thread model: posix gcc version 4.3.2 (Gentoo Hardened 4.3.2-r3 p1.6, pie-10.1.5) COLLECT_GCC_OPTIONS='-v' '-m32' '-o' 'trivial' '-mtune=generic' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/cc1 -quiet -v -imultilib 32 trivial.c -fPIE -fno-strict-overflow -quiet -dumpbase trivial.c -m32 -mtune=generic -auxbase trivial -version -o /tmp/cc4qEg6K.s ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include-fixed /usr/include End of search list. GNU C (Gentoo Hardened 4.3.2-r3 p1.6, pie-10.1.5) version 4.3.2 (x86_64-pc-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.3.2, MPFR version 2.4.2-p3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: e8faf928abdbcb1acb2166e18d14ae3d COLLECT_GCC_OPTIONS='-v' '-m32' '-o' 'trivial' '-mtune=generic' /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/as -V -Qy --32 -o /tmp/ccEd2Qcf.o /tmp/cc4qEg6K.s GNU assembler version 2.20.1 (x86_64-pc-linux-gnu) using BFD version (GNU Binutils) 2.20.1.20100303 COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/:/lib/../lib32/:/usr/lib/../lib32/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-m32' '-o' 'trivial' '-mtune=generic' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie -z now -o trivial /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32 -L/lib/../lib32 -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../.. /tmp/ccEd2Qcf.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crtn.o chad@Hugin ~/cprojects/ctesting $ ./trivial chad@Hugin ~/cprojects/ctesting $ chad@Hugin ~/cprojects/ctesting $ gcc -v trivial.c -o trivial -m32 Reading specs from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/specs Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --disable-libgomp --enable-checking=release --disable-libgcj --enable-languages=c,c++,treelang --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.3.2-r3 p1.6, pie-10.1.5' Thread model: posix gcc version 4.3.2 (Gentoo Hardened 4.3.2-r3 p1.6, pie-10.1.5) COLLECT_GCC_OPTIONS='-v' '-o' 'trivial' '-m32' '-mtune=generic' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/cc1 -quiet -v -imultilib 32 trivial.c -fPIE -fno-strict-overflow -quiet -dumpbase trivial.c -m32 -mtune=generic -auxbase trivial -version -o /tmp/cckuthAp.s ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include-fixed /usr/include End of search list. GNU C (Gentoo Hardened 4.3.2-r3 p1.6, pie-10.1.5) version 4.3.2 (x86_64-pc-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.3.2, MPFR version 2.4.2-p3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: e8faf928abdbcb1acb2166e18d14ae3d COLLECT_GCC_OPTIONS='-v' '-o' 'trivial' '-m32' '-mtune=generic' /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/as -V -Qy --32 -o /tmp/cceQ7W8N.o /tmp/cckuthAp.s GNU assembler version 2.20.1 (x86_64-pc-linux-gnu) using BFD version (GNU Binutils) 2.20.1.20100303 COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/:/lib/../lib32/:/usr/lib/../lib32/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-o' 'trivial' '-m32' '-mtune=generic' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie -z now -o trivial /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32 -L/lib/../lib32 -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../.. /tmp/cceQ7W8N.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crtn.o chad@Hugin ~/cprojects/ctesting $ ./trivial chad@Hugin ~/cprojects/ctesting $ chad@Hugin ~/dprojects/dtesting $ dmd trivial.d -L-v collect2 version 4.3.2 (x86-64 Linux/ELF) /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie -z now -o trivial /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32 -L/lib/../lib32 -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../.. trivial.o -v -L/usr/local/share/dcompilers/dmd/linux/bin/../lib --export-dynamic -lphobos2 -lpthread -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crtn.o GNU ld (GNU Binutils) 2.20.1.20100303 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. chad@Hugin ~/dprojects/dtesting $ ./trivial Segmentation fault The -L-Wl,-v flag doesn't seem to work: chad@Hugin ~/dprojects/dtesting $ dmd trivial.d -L-v -L-Wl,-v collect2 version 4.3.2 (x86-64 Linux/ELF) /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie -z now -o trivial /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32 -L/lib/../lib32 -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../.. trivial.o -v -Wl,-v -L/usr/local/share/dcompilers/dmd/linux/bin/../lib --export-dynamic -lphobos2 -lpthread -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crtn.o GNU ld (GNU Binutils) 2.20.1.20100303 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld: unrecognized option '-Wl,-v' /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status --- errorlevel 1

Does this bug report shed any light, specifically the part about changing the CHOST towards the bottom of the report? (I'm not a gentoo user, just using google to investigate similar issues). http://bugs.gentoo.org/show_bug.cgi?id=332663 If that's not it, then I'm running out of obvious things to check.

(In reply to comment #6) > Does this bug report shed any light, specifically the part about changing the > CHOST towards the bottom of the report? (I'm not a gentoo user, just using > google to investigate similar issues). > > http://bugs.gentoo.org/show_bug.cgi?id=332663 > > If that's not it, then I'm running out of obvious things to check. I'm afraid not. I haven't changed my CHOST; it's "x86_64-pc-linux-gnu" like always.

> I don't know if it's > related because the segfault is such a terribly vague error and I don't feel > like learning how to disassemble executables again right now If dmd can generate debug info, you shouldn't need to disassemble. At least you'll know, where it crashes. d2 is a sophisticated system, it can use nifty functions in trivial cases. AFAIK, Gentoo is compiled from the source, did you use any special options like strong optimization etc?

(In reply to comment #8) > > I don't know if it's > > related because the segfault is such a terribly vague error and I don't feel > > like learning how to disassemble executables again right now > > If dmd can generate debug info, you shouldn't need to disassemble. At least > you'll know, where it crashes. > > d2 is a sophisticated system, it can use nifty functions in trivial cases. > AFAIK, Gentoo is compiled from the source, did you use any special options like > strong optimization etc? For DMD I just grab the binary releases. I've never been very confident in the D-related ebuilds :( As for my system configuration and its optimization, I don't think I have anything too exotic. Here are my CFLAGS: CFLAGS="-march=nocona -O2 -finline-functions -fgcse-after-reload -pipe"

So I thought it'd be wise to try it with both the working compiler version and the not working compiler version and see what changed in the linker string. Here it is: chad@Hugin /mnt/sharedhd/dprojects/dtesting $ dmd trivial.d -L-v 2> dmd2048.link GNU ld (GNU Binutils) 2.20.1.20100303 chad@Hugin /mnt/sharedhd/dprojects/dtesting $ dmd trivial.d -L-v 2> dmd2050.link GNU ld (GNU Binutils) 2.20.1.20100303 chad@Hugin /mnt/sharedhd/dprojects/dtesting $ diff dmd2048.link dmd2050.link 2c2 < /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie -z now -o trivial /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32 -L/lib/../lib32 -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../.. trivial.o -v -L/usr/local/share/dcompilers/dmd/linux/bin/../lib -lphobos2 -lpthread -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crtn.o --- > /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie -z now -o trivial /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32 -L/lib/../lib32 -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../.. trivial.o -v -L/usr/local/share/dcompilers/dmd/linux/bin/../lib --export-dynamic -lphobos2 -lpthread -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crtn.o Note the that --export-dynamic is only present in the one that segfaults. I'm in a bit of a rush at the moment and I don't remember how to mess with --export-dynamic, so that's all for now.

(In reply to comment #10) > So I thought it'd be wise to try it with both the working compiler version and > the not working compiler version and see what changed in the linker string. > Here it is: > > ... Whoops, diff formatting messed things up on that second line. Here it is again, minus the angle brackets: -------------- dmd 2.048 -------------- /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie -z now -o trivial /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32 -L/lib/../lib32 -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../.. trivial.o -v -L/usr/local/share/dcompilers/dmd/linux/bin/../lib -lphobos2 -lpthread -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crtn.o -------------- dmd 2.050 -------------- /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie -z now -o trivial /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32 -L/lib/../lib32 -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../.. trivial.o -v -L/usr/local/share/dcompilers/dmd/linux/bin/../lib --export-dynamic -lphobos2 -lpthread -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crtn.o

I just thought I'd mention that I had some similar problems with DMD on Gentoo due to bad permissions of certain libraries. Do your programs run under root? If so, check permissions for libphobos and whatever 32-bit libraries your program / libphobos uses (glibc? libstdc++?).

I have taken another crack at this. After some compiling of D on a roommate's non-hardened Gentoo system I found that if I recompile my gcc without the hardened useflag and then compile my D programs, the D programs won't segfault. This round of testing was done with 64-bit DMD. In short: using hardened GCC will trigger this. I was pointed in this direction by observing the last line of the output of compiling with dmd -v: gcc main.o -o main -m64 -Xlinker -L/usr/local/share/dcompilers/dmd/linux/bin64/../lib64 -Xlinker -L/usr/local/share/dcompilers/dmd/linux/bin64/../lib32 -Xlinker --no-warn-search-mismatch -Xlinker --export-dynamic -lrt -lphobos2 -lpthread -lm Notably, it is using gcc for its linking step. After a bit of browsing in the DMD sources, a workaround presents itself. DMD just uses the CC environment variable to determine what to use for linking, so it is possible to build an isolated non-hardened GCC and then use that to compile D programs. It would look like this: CC=custom-gcc dmd -v main.d -ofmain At some point I may bisect the older changes in DMD to find out where this regression was introduced. I can see this ending up in the backend though, so I'm not sure I'll be able to understand the code I end up in.

(In reply to comment #12) > I just thought I'd mention that I had some similar problems with DMD on Gentoo > due to bad permissions of certain libraries. Do your programs run under root? > If so, check permissions for libphobos and whatever 32-bit libraries your > program / libphobos uses (glibc? libstdc++?). I almost forgot to mention this... My programs still segfault under root. Permissions are fine. Everything works if I use a non-hardened GCC. Thanks for the suggestions!

I recall some changes going in that addressed some hardening issues along the way. I don't have a gentoo based system to test this on. Please try the most recent beta to see if the problem still exists. http://ftp.digitalmars.com/dmd2beta.zip

I'm afraid it doesn't seem to be working. It went something like this: chad@Hugin /mnt/bulk/dprojects/helloD2 $ ls main.d chad@Hugin /mnt/bulk/dprojects/helloD2 $ cat main.d import std.stdio; void main() { writefln("hello world!"); } chad@Hugin /mnt/bulk/dprojects/helloD2 $ dmd DMD64 D Compiler v2.056 Copyright (c) 1999-2011 by Digital Mars written by Walter Bright Documentation: http://www.digitalmars.com/d/2.0/index.html Usage: dmd files.d ... { -switch } files.d D source files @cmdfile read arguments from cmdfile -c do not link -cov do code coverage analysis -D generate documentation -Dddocdir write documentation file to docdir directory -Dffilename write documentation file to filename -d allow deprecated features -debug compile in debug code -debug=level compile in debug code <= level -debug=ident compile in debug code identified by ident -debuglib=name set symbolic debug library to name -defaultlib=name set default library to name -deps=filename write module dependencies to filename -fPIC generate position independent code -g add symbolic debug info -gc add symbolic debug info, pretend to be C -gs always emit stack frame -H generate 'header' file -Hddirectory write 'header' file to directory -Hffilename write 'header' file to filename --help print help -Ipath where to look for imports -ignore ignore unsupported pragmas -inline do function inlining -Jpath where to look for string imports -Llinkerflag pass linkerflag to link -lib generate library rather than object files -man open web browser on manual page -map generate linker .map file -noboundscheck turns off array bounds checking for all functions -nofloat do not emit reference to floating point -O optimize -o- do not write object file -odobjdir write object & library files to directory objdir -offilename name output file to filename -op do not strip paths from source file -profile profile runtime performance of generated code -property enforce property syntax -quiet suppress unnecessary messages -release compile release version -run srcfile args... run resulting program, passing args -unittest compile in unit tests -v verbose -version=level compile in version code >= level -version=ident compile in version code identified by ident -vtls list all variables going into thread local storage -w enable warnings -wi enable informational warnings -X generate JSON file -Xffilename write JSON file to filename chad@Hugin /mnt/bulk/dprojects/helloD2 $ dmd main.d -ofmain /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: main.o: relocation R_X86_64_32 against `.data' can not be used when making a shared object; recompile with -fPIC main.o: could not read symbols: Bad value collect2: ld returned 1 exit status --- errorlevel 1 chad@Hugin /mnt/bulk/dprojects/helloD2 $ ls main.d main.o chad@Hugin /mnt/bulk/dprojects/helloD2 $ dmd main.d -ofmain -m32 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. chad@Hugin /mnt/bulk/dprojects/helloD2 $ ls main main.d main.o chad@Hugin /mnt/bulk/dprojects/helloD2 $ main main: error while loading shared libraries: cannot make segment writable for relocation: Permission denied chad@Hugin /mnt/bulk/dprojects/helloD2 $ sudo paxctl -m main chad@Hugin /mnt/bulk/dprojects/helloD2 $ main Segmentation fault chad@Hugin /mnt/bulk/dprojects/helloD2 $ ls main main.d main.o chad@Hugin /mnt/bulk/dprojects/helloD2 $ (I don't have any other 2.056 D compilers on my system; so the part where I ran dmd to get the help text should confirm that the correct compiler is in use.)

Created attachment 1043 More detailed info of dmd run on hardened gentoo 64-bit.

Here is the output of dmd -v for both 32-bit (-m32) and 64-bit runs, just in-case it helps.

Well, I tried bisecting dmd to find which change caused this. It didn't work because this problem does not care which version of dmd I am using, it cares which RELEASE I am using. I narrowed it down to the "-L--export-dynamic" flag in $DPATH/linux/bin64/dmd.conf If I remove that export-dynamic flag AND rebuild druntime/phobos from scratch, everything is fine. Of course, if I remove -L--export-dynamic AND I do NOT rebuild druntime/phobos from scratch, I get this: /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: main.o: relocation R_X86_64_32 against `.data' can not be used when making a shared object; recompile with -fPIC main.o: could not read symbols: Bad value collect2: ld returned 1 exit status --- errorlevel 1 I take it this means that the executable and the library must agree on whether or not to use -L--export-dynamic. I guess it makes sense. By removing -L--export-dynamic and building dmd/druntime/phobos all from git at v2.057, I was able to get the recent release of dmd to run on my machine without using a special GCC. Any chance we can remove -L--export-dynamic or fix it so that it does not do this? (I have no idea how to fix it, but removing it is easy enough!)

The core issue is that your gcc is linking PIE by default but PIC support for dmd still has some bug and probably would need more that -fPIC to support PIE. Currently you should pass -fno-pie to gcc for linking. Please help to find out why --export-dynamic is involved. Does it trigger alter the PIE behavior? What's the backtrace of your segfault core dumps? Please list any linker warnings you get (-Wl,--verbose for gcc or -L--verbose for dmd).

(In reply to comment #20) > The core issue is that your gcc is linking PIE by default but > PIC support for dmd still has some bug and probably would need > more that -fPIC to support PIE. Currently you should pass > -fno-pie to gcc for linking. > > Please help to find out why --export-dynamic is involved. > Does it trigger alter the PIE behavior? How do I find this out? > What's the backtrace of your segfault core dumps? Also, how do I find this out? Running the program just makes it print "Segmentation fault"; there is no backtrace for me to copy. Maybe I am missing something (where would I find a core dump for this?). > Please list any linker warnings you get > (-Wl,--verbose for gcc or -L--verbose for dmd). Stock DMD v2.057 64-bit: chad@Hugin /mnt/bulk/dprojects/helloD2 $ which dmd /usr/local/share/dcompilers/dmd/linux/bin64/dmd chad@Hugin /mnt/bulk/dprojects/helloD2 $ cat main.d import std.stdio; void main() { writefln("hello world!"); } Without -m32 it isn't able to compile my program: http://pastebin.com/GqP5JC3z With -m32 it does, but segfaults: http://pastebin.com/hd5zEtD2 32-bit dmd: chad@Hugin /mnt/bulk/dprojects/helloD2 $ which dmd /usr/local/share/dcompilers/dmd/linux/bin32/dmd Segfaults: http://pastebin.com/d7miSKtH

What's linker flags are passed by gcc if you use --export-dynamic vs. not using it? dmd -c main ---------- gcc main.o -o main -m32 -Xlinker -L/usr/local/share/dcompilers/dmd/linux/bin32/../lib32 -Xlinker -L/usr/local/share/dcompilers/dmd/linux/bin32/../lib64 -Xlinker --no-warn-search-mismatch -Xlinker --export-dynamic -lphobos2 -lpthread -lm -lrt -v ---------- vs. ---------- gcc main.o -o main -m32 -Xlinker -L/usr/local/share/dcompilers/dmd/linux/bin32/../lib32 -Xlinker -L/usr/local/share/dcompilers/dmd/linux/bin32/../lib64 -Xlinker --no-warn-search-mismatch -lphobos2 -lpthread -lm -lrt -v ---------- Also did passing -fno-pie to gcc resolve your problems?

(In reply to comment #22) Thank you for clarifying. > What's linker flags are passed by gcc if you use --export-dynamic vs. not using > it? > > dmd -c main > ---------- > gcc main.o -o main -m32 -Xlinker > -L/usr/local/share/dcompilers/dmd/linux/bin32/../lib32 -Xlinker > -L/usr/local/share/dcompilers/dmd/linux/bin32/../lib64 -Xlinker > --no-warn-search-mismatch -Xlinker --export-dynamic -lphobos2 -lpthread -lm > -lrt -v http://pastebin.com/BD52Kkp2 > ---------- > vs. > ---------- > gcc main.o -o main -m32 -Xlinker > -L/usr/local/share/dcompilers/dmd/linux/bin32/../lib32 -Xlinker > -L/usr/local/share/dcompilers/dmd/linux/bin32/../lib64 -Xlinker > --no-warn-search-mismatch -lphobos2 -lpthread -lm -lrt -v (no segfault) http://pastebin.com/0yA29by1 > ---------- > > Also did passing -fno-pie to gcc resolve your problems? Yes. http://pastebin.com/yLQacSuf Those were all 32-bit. I suppose the natural next thing to try is 64-bit: http://pastebin.com/utYgp7YA And yep, -fno-pie makes it run.

(In reply to comment #22) Additional info: I can get basic stack traces now. Yay! And I don't have to use paxctl -m anymore. Also yay! http://pastebin.com/tt784wYr More line numbers in the stack trace would be nice though. I suspect this -fno-pie thing will make shared libraries impossible on my setup until this gets resolved though, right?

>I suspect this -fno-pie thing will make shared libraries impossible on my setup >until this gets resolved though, right? No, it doesn't. PIE simply means randomized address space for the executable. I do even think that PIE should work out of the box if you compile phobos and you executables with -fPIC.

(In reply to comment #25) > >I suspect this -fno-pie thing will make shared libraries impossible on my setup > >until this gets resolved though, right? > No, it doesn't. > PIE simply means randomized address space for the executable. > I do even think that PIE should work out of the box if you > compile phobos and you executables with -fPIC. Oh, my bad. I confused PIE with PIC. So, just to be clear, -fpie is not passed by default on most systems, but it is on mine (a feature of the hardened GCC). DMD's binary release of phobos is then compiled WITHOUT -fpie because that's the usual course of things, thus causing it to complain when I link it with something that compiles WITH -fpie. Is there any chance that -fno-pie could make it into the list of things DMD passes to GCC by default? Assuming I understand this all correctly, then other systems won't care if -fno-pie gets passed because they don't use PIE anyways. On my system it will convert a dead-on-arrival binary release into something that works. If someone still wanted to build with PIE then the ideal, I suppose, would be to have portage (the package manager) build everything from source, adding -fpie and -fPIC as necessary and adjusting the dmd.conf file to reflect it. Also, is it even possible to get -fno-pie in there through dmd.conf? When I add -L-fno-pie in dmd.conf it adds "-Xlinker -fno-pie" instead of just "-fno-pie" to the GCC args and it seems to end up going to the wrong place. Then I get linker errors and stuff won't build: http://pastebin.com/wEcuyUqp

I'm reopening this because DMD won't work on my system unless -fno-pie is passed to GCC by DMD itself. I can't even fix this without recompiling DMD because if I add "-L-fno-pie" to dmd.conf then will put "-Xlinker" before that and GCC itself never sees the "-fno-pie". (See my previous comment for more detail.)

Yeah, it's a limitation that dmd doesn't let you pass flags to gcc. It's a different bug though. Have you actually tried to build PIE using dmd's -fPIC flag. You'd need to rebuild druntime and phobos with the fPIC too. I think PIE will work without further changes.

(In reply to comment #28) > Yeah, it's a limitation that dmd doesn't let you pass flags to gcc. It's a > different bug though. > > Have you actually tried to build PIE using dmd's -fPIC flag. > You'd need to rebuild druntime and phobos with the fPIC too. > I think PIE will work without further changes. It seemed like it was working before, but I did it again with more rigor to try and confirm that all of the flags are what I think they are. It didn't work too well. Here's what happened: druntime compile: http://pastebin.com/e5HjcVRb phobos compile: http://pastebin.com/4uATCBt1 executable compile: chad@Hugin /mnt/bulk/dprojects/helloD2 $ dmd -fPIC -c main.d chad@Hugin /mnt/bulk/dprojects/helloD2 $ gcc main.o -o main -m32 -Xlinker -L/usr/local/share/dcompilers/dmd/linux/bin/../lib -lphobos2 -lpthread -lm -lrt -fPIC -pie /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. chad@Hugin /mnt/bulk/dprojects/helloD2 $ main main: error while loading shared libraries: cannot make segment writable for relocation: Permission denied chad@Hugin /mnt/bulk/dprojects/helloD2 $ sudo paxctl -m main chad@Hugin /mnt/bulk/dprojects/helloD2 $ main Killed chad@Hugin /mnt/bulk/dprojects/helloD2 $ If I did something wrong, please let me know a better way. What's the issue# for the bug preventing DMD from forwarding arguments to GCC? It's actually really easy to write a patch for that. In fact, I did it so that I could continue working on my system. Otherwise there is no way for me to have DMD work on my system without hardcoding "-fno-pie" into dmd/src/link.c and compiling from git. Now, this is probably the wrong place for it, and I could stand to improve it slightly and make sure it works off of the latest git sources (I was working offline with this), but here is the patch for adding a -cflags parameter in DMD, just in case anyone wants it: http://pastebin.com/U6cTmryQ

Does this pull resolve the issue for you? https://github.com/D-Programming-Language/dmd/pull/794

(In reply to comment #30) > Does this pull resolve the issue for you? > > https://github.com/D-Programming-Language/dmd/pull/794 Hey, I didn't even realize this response was here. Yes it does. Or at least it gives me a reasonable workaround until the codegen issues are fixed.

This also affects Ubuntu 16.10 to some degree. [Hardened system tutorial/patch](http://forum.dlang.org/post/[email protected]) [Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10](http://forum.dlang.org/post/[email protected]) Using -fPIC -defaultlib=libphobos2.so (the normal shared flags) was reported to be a workaround for the missing -fPIE support on Ubuntu 16.10. https://github.com/rejectedsoftware/ddox/issues/134

I can confirm that putting `-fPIC -defaultlib=libphobos2.so` in dmd.conf makes DMD work correctly on hardened systems (tested on Ubuntu 16.10). Binaries built this way are PIE and have Phobos linked dynamically. I didn't manage to find a configuration that allows me to statically link Phobos, with or without PIE.

The only way I've found that works with statically-linked Phobos is to compile druntime and phobos with PIC=1 so that libphobos.a is PIC, in addition to putting -fPIC in dmd.conf (but not -defaultlib=libphobos.so, since that causes phobos to be linked dynamically). All other combinations seems to fail in one place or another. See: https://issues.dlang.org/show_bug.cgi?id=16794 Alternatively, it *may* be possible to get away with non-PIC libphobos.a if there's a way to coax dmd to invoke gcc (used as the linker) with -no-pie. I tried -L-no-pie but that didn't seem to do the trick either. Probably something else is needed to make it work.

Should work now that we ship phobos with PIC by default (at least on X64). Executables compiled with dmd's `-fPIC` do create PIEs.