Bug 17833 – compiling dmd on x86 linux fails

Status
RESOLVED
Resolution
DUPLICATE
Severity
normal
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Linux
Creation time
2017-09-17T15:19:36Z
Last change time
2020-03-21T03:56:42Z
Keywords
ice
Assigned to
No Owner
Creator
deep42thought

Attachments

IDFilenameSummaryContent-TypeSize
1658log.32log of build on i686text/plain29786
1708packagesinstalled packagestext/plain3707

Comments

Comment #0 by dlang — 2017-09-17T15:19:36Z
Created attachment 1658 log of build on i686 following the steps here: https://wiki.dlang.org/Building_under_Posix The build of dmd fails with a segfault at: > cd "$srcdir/druntime" > make -f posix.mak The full log is attached. The steps are: > git clones/checkouts > cd "$srcdir/dmd" > make -f posix.mak AUTO_BOOTSTRAP=1 MODEL=32 > cd "$srcdir/phobos" > make -f posix.mak MODEL=32
Comment #1 by abaumann — 2017-10-13T06:54:17Z
Comment #2 by thomas.mader — 2017-11-11T23:26:10Z
I am having the same problem when trying to build dmd 2.075.1 with the dmd-cxx branch version at commit 7f7dd837f1cf92e3fd51fabbb95868b4b297ad37 as bootstrap dmd. The error message is: gmake[2]: *** [posix.mak:147: import/core/sync/barrier.di] Segmentation fault Switching back to 2.067.1 as bootstrap compiler makes it work again. @ibuclaw: Do you happen to know what the problem might be?
Comment #3 by tyzoid — 2018-04-15T13:51:44Z
Bumping this issue, since this is triggering the removal of this package from the archlinux32 repos.
Comment #4 by greeenify — 2018-07-02T21:49:42Z
Hmm building DMD on Linux 32 works on our CIs (e.g. https://auto-tester.puremagic.com/platform-history.ghtml?projectid=1&os=Linux_32), so I'm not sure what this is related to. The dmd-cxx branch was just an experiment, but it was never fully finished. Do you still get a segfault when using AUTO_BOOTSTRAP=1? (since 2.081 at least 2.074 is required to build DMD)
Comment #5 by dlang — 2018-07-03T06:24:19Z
Created attachment 1708 installed packages
Comment #6 by dlang — 2018-07-03T06:25:54Z
still fails for me. I ran: > mkdir dlang > cd ~/dlang/ > git clone https://github.com/dlang/dmd > git clone https://github.com/dlang/druntime > git clone https://github.com/dlang/phobos > git clone https://github.com/dlang/tools > cd ~/dlang/dmd > make -f posix.mak -j8 AUTO_BOOTSTRAP=1 > cd ~/dlang/phobos > make -f posix.mak -j8 inside an archlinux32 virtual box. See above for a list of installed packages on that box.
Comment #7 by dlang — 2018-07-03T07:13:17Z
We have an archlinux32 image for vagrant which you can use to reproduce the issue. The commands are: > mkdir arch32-builder > cd arch32-builder > vagrant init archlinux32/archlinux32 > vagrant up > ssh [email protected] -p 2222 -o StrictHostKeyChecking=Off -o IdentityFile=.vag$ >> sudo pacman -Syu base-devel curl git make libcurl-gnutls >> sudo reboot > ssh [email protected] -p 2222 -o StrictHostKeyChecking=Off -o IdentityFile=.vag$ >> mkdir dlang >> cd dlang/ >> git clone https://github.com/dlang/dmd >> git clone https://github.com/dlang/druntime >> git clone https://github.com/dlang/phobos >> git clone https://github.com/dlang/tools >> cd ~/dlang/dmd >> make -f posix.mak -j8 AUTO_BOOTSTRAP=1 >> cd ~/dlang/phobos >> make -f posix.mak -j8 (fails with segfault)
Comment #8 by greeenify — 2018-07-03T07:45:52Z
Thanks that works in reproducing the segfault :/ Command Line: ../dmd/generated/linux/release/32/dmd -conf= -c -o- -Isrc -Iimport -Hfimport/core/sync/barrier.di src/core/sync/barrier.d (gdb) bt full #0 0x00861f61 in _d_dso_registry () No symbol table info available. #1 0x007b53cf in ?? () No symbol table info available. #2 0x0087d97b in __libc_csu_init () No symbol table info available. #3 0xb7aecfd3 in __libc_start_main () from /usr/lib/libc.so.6 No symbol table info available. #4 0x0065d601 in _start () No symbol table info available. However, there's a workaround: Instead of using AUTO_BOOTSTRAP=1, you can use make -f posix.mak -j8 HOST_DMD=ldmd to compile dmd. With this druntime and phobos compile fine. So I guess it's just an issue that the release binaries aren't fully working with 32-bit anymore?
Comment #9 by dlang — 2018-07-03T08:00:07Z
thanks for your prompt reply - the workaround works :-)
Comment #10 by b2.temp — 2019-03-02T14:11:44Z
Still ?
Comment #11 by dfj1esp02 — 2019-08-05T08:39:18Z
*** This issue has been marked as a duplicate of issue 19116 ***