When building dev-lang/ghc (version does not seem to matter) using sys-devel/gcc-4.9.2, it fails with the link errors in the build.log attachment. If I switch back to sys-devel/gcc-4.8.4 everything builds fine. Additionally, if I build ghc with 4.8.4, then use gcc-config to switch back to 4.9.2, even without recompiling ghc, I get similar link errors when building other Haskell software. Switching the C compiler back to 4.8.4 seems to resolve those issues. Reproducible: Always Steps to Reproduce: 1. gcc-config x86_64-pc-linux-gnu-4.9.2 2. emerge dev-lang/ghc 3. Actual Results: See the attached build.log for errors. Expected Results: A functional ghc should be installed. Output from emerge -pqv =dev-lang/ghc-7.8.4::gentoo [ebuild R ] dev-lang/ghc-7.8.4 USE="gmp -binary -doc -ghcbootstrap -ghcmakebinary"
Created attachment 402814 [details] build.log
Created attachment 402816 [details] emerge --info =dev-lang/ghc-7.8.4::gentoo
Interesting, i'm using gcc-4.9.2 for a long while and never seen such things before. Some questions for you: Did the error show-up only once or you dried some times to build it with 4.9.2? If you try CFLAGS without -march=native will it work?
Yes, I've done this over and over again. It took me a while to determine that gcc version made a difference. I've compiled with 4.8, then moved back to 4.9 and confirmed the same failure, and repeated that several times. I also just tried without -march="native" and it did not make any difference. I've even done an empty-tree on system and world and still have this issue.
Does it still happen for you?
Unfortunately, yes... It still errors on build with very similar looking errors, even though I'm running with gcc-5.3.0 now. I'm attaching a build log from the most recent attempt at building this.
Created attachment 434456 [details] build log with gcc-5.3.0 Tried again today with my currently installed compiler (gcc-5.3.0). Still fails with similar errors.
Interesting, never seen such failure before. Looks like object splitter gone mad. I need more details: - fresh 'emerge --info' - rerun failed command in '/var/tmp/portage/dev-lang/ghc-7.10.3/work/ghc-7.10.3' to see if it's easily reproducible: It's a: "/var/tmp/portage/dev-lang/ghc-7.10.3/work/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -optc-march=native -opta-march=native -optl-Wl,-O1 -optl-Wl,--as-needed -optc-fno-stack-protector -package-db libraries/bootstrapping.conf -this-package-key termi_6iVf4EBnOgfIaaOCLRs8jl -hide-all-packages -i -ilibraries/terminfo/. -ilibraries/terminfo/dist-boot/build -ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/dist-boot/build -Ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/. -optP-include -optPlibraries/terminfo/dist-boot/build/autogen/cabal_macros.h -package-key base_HQfYBxpPvuw8OunzQu6JGM -Wall -XHaskell2010 -no-user-package-db -rtsopts -odir libraries/terminfo/dist-boot/build -hidir libraries/terminfo/dist-boot/build -stubdir libraries/terminfo/dist-boot/build -c libraries/terminfo/./System/Console/Terminfo/Base.hs -o libraries/terminfo/dist-boot/build/System/Console/Terminfo/Base.o If it's still reproducible add 2 more options in the end of that command: ' -keep-tmp-files -v'. It will create a temporary directory with a random name like /tmp/ghc28697_0 (exact directory name will appear on screen as part of other commands). Archive that directory and attach to the bug.
Created attachment 434792 [details] new emerge --info Fresh emerge --info =dev-lang/ghc-7.10.3
Created attachment 434794 [details] /tmp/ghc5195_0 Re-running the command by hand also failed, so I added the "-keep-tmp-files -v" and have attached the /tmp/ghc* directory. Hope this helps.
I was not able to reproduce it locally yet. Having tried to play with it a bit more it seems to be a very specific ld.bfd linker bug. People occasionally stumble on it but don't get to the bottom: http://stackoverflow.com/questions/34654262/build-fails-because-of-multiple-definition-linker-errors-in-native-dependencie Let's try to prove the following hypothesis: ld manages to parse 'INPUT' .ldscript directives incorrectly and attempts to merge the same file twice. For that please try to add the following flags to your default values: CFLAGS+=" -v -Wl,--verbose" LDFLAGS+=" -Wl,--verbose" HCFLAGS+=" -v" It will add A Lot of logging. Try again to merge ghc and attach the build.log.
Created attachment 434838 [details] New build log with additional [C,LD,HC]FLAGS Thanks for the link. If it's the same problem, it doesn't sound like it's going to be an easy fix. Attached is the new highly-verbose build.log.
(In reply to signals42 from comment #12) > Created attachment 434838 [details] > New build log with additional [C,LD,HC]FLAGS > > Thanks for the link. If it's the same problem, it doesn't sound like it's > going to be an easy fix. > > Attached is the new highly-verbose build.log. attempt to open /var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc19353_0/ghc_8.ldscript succeeded opened script file /var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc19353_0/ghc_8.ldscript attempt to open /var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc19353_0/ghc_7.o succeeded /var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc19353_0/ghc_7.o attempt to open /var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc19353_0/ghc_6.o succeeded /var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc19353_0/ghc_6.o attempt to open /var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc19353_0/ghc_8.ldscript succeeded opened script file /var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc19353_0/ghc_8.ldscript attempt to open /var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc19353_0/ghc_7.o succeeded /var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc19353_0/ghc_7.o attempt to open /var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc19353_0/ghc_6.o succeeded Woohoo! Single ld invocation tries to read one ldscript twice and gets object file collision with itself. Let's try to do the same but build everything sequentially: MAKEOPTS=-j1
Created attachment 434860 [details] build.log with MAKEOPTS="-j1" Still doesn't build, but here's the build.log from a MAKEOPTS="-j1" run. Thanks!
(In reply to signals42 from comment #14) > Created attachment 434860 [details] > build.log with MAKEOPTS="-j1" > > Still doesn't build, but here's the build.log from a MAKEOPTS="-j1" run. > > Thanks! Yes, it should not change (bad) behaviour. It only makes log slightly more readable. Let's check what arguments are passed to ld executable. You'll need dev-util/strace for that. Run the following command (the last command before "/* Script for ld -r: link without relocation */" string): strace -s1024 -v -f -etrace=execve -o/tmp/strace.log x86_64-pc-linux-gnu-gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads -Wl,--no-as-needed -Wl,-O1 -Wl,--as-needed -Wl,--verbose -nostdlib -Wl,-r -nodefaultlibs '-Wl,--build-id=none' -o libraries/terminfo/dist-boot/build/System/Console/Terminfo/Base.o /var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc14351_0/ghc_8.ldscript from directory '/var/tmp/portage/dev-lang/ghc-7.10.3/work/ghc-7.10.3' and attach generated /tmp/strace.log
Created attachment 434862 [details] strace.log Oddly, I have no "/var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc14351_0" or anything similarly named in /var/tmp/portage/dev-lang/ghc-7.10.3/temp/. I ran it again with keepwork and keeptemp in my FEATURES, but I still see this near the end of the build: *** Deleting temp dirs: Deleting: /var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc3226_0 Consequently, all I get is: "x86_64-pc-linux-gnu-gcc: error: /var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc3226_0/ghc_8.ldscript: No such file or directory" Maybe that's expected? I'm attaching the strace.log from that, in case it is what you were looking for. Otherwise, I'll have to figure out how to keep it from deleting the temp dirs.
Created attachment 434886 [details] bad_reduced.tar.gz (In reply to signals42 from comment #16) > Created attachment 434862 [details] > strace.log > > Oddly, I have no "/var/tmp/portage/dev-lang/ghc-7.10.3/temp/ghc14351_0" or > anything similarly named in /var/tmp/portage/dev-lang/ghc-7.10.3/temp/. Yeah, you would need to reexecute 'ghc --make .. Base.o with -keep-tmp-files' first to get failed temps. It's a lot of steps. Let's give up on it for a while and try to focus on reducing what you've already got. I've tried to minimize (maybe too much) real example to bad_reduced.tar.gz. Try to run ./test.sh after unpacking the archive. We'll see if it's enough to trigger the same problem.
Looks like you nailed it: + cc=gcc + gcc -c foo.c -o ghc_6.o + gcc -c bar.c -o ghc_7.o + gcc @ghc_9.rsp ghc_7.o: In function `bar': bar.c:(.text+0x0): multiple definition of `bar' ghc_7.o:bar.c:(.text+0x0): first defined here ghc_6.o: In function `foo': foo.c:(.text+0x0): multiple definition of `foo' ghc_6.o:foo.c:(.text+0x0): first defined here collect2: error: ld returned 1 exit status
Just poking at it a bit: I removed the ldscript and compiled it with the .o files listed explicitly in the rsp file and it compiled just fine. So, apparently something's going wrong with the way it is parsing the ldscript.
> Looks like you nailed it: > + gcc @ghc_9.rsp > ghc_7.o: In function `bar': > bar.c:(.text+0x0): multiple definition of `bar' > ghc_7.o:bar.c:(.text+0x0): first defined here Woohoo! (In reply to signals42 from comment #19) > Just poking at it a bit: I removed the ldscript and compiled it with the .o > files listed explicitly in the rsp file and it compiled just fine. So, > apparently something's going wrong with the way it is parsing the ldscript. Maybe inker script is a problem, but linker scripts are frequently used thus they have some coverage. While response files are mostly used on windows. Let's strace the test.sh now: strace -s1024 -v -f -etrace=execve -o/tmp/strace.log ./test.sh
Created attachment 434902 [details] strace of test.sh Here you go. Hope there's something useful inside.
Created attachment 434904 [details] /tmp/ccVXjL1A as mentioned in the strace After looking through the strace log, I noticed that it's calling ld with "@/tmp/ccVXjL1A" so I'm attaching that, too. In case it's helpful.
(In reply to signals42 from comment #22) > Created attachment 434904 [details] > /tmp/ccVXjL1A as mentioned in the strace > > After looking through the strace log, I noticed that it's calling ld with > "@/tmp/ccVXjL1A" so I'm attaching that, too. In case it's helpful. Interesting. gcc passes seemingly sane arguments to ld. Does it fail or work if you run ld directly? ld.bfd @/tmp/ccVXjL1A If it still fails with duplicate symbols then attach output strace and ltrace: strace -v -s1024 -o/tmp/strace.log ld.bfd @/tmp/ccVXjL1A ltrace -s1024 -o/tmp/ltrace.log ld.bfd @/tmp/ccVXjL1A
Strangely, it does not fail when I run "ld.bfd @/tmp/ccVXjL1A" it generates a Base.o with no messages to stdout/stderr.
Aha, it might mean that we either lack a file from ld's response file -plugin-opt=-fresolution=/tmp/ccCUhwE7.res Or we don't pass env variables to linker plugin (seen in strace): "COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/5.3.0/gcc", "COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/lto-wrapper", "COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/", "LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../:/lib/:/usr/lib/", "COLLECT_GCC_OPTIONS='-fno-stack-protector' '-D' 'TABLES_NEXT_TO_CODE' '-nostdlib' '-nodefaultlibs' '-o' 'Base.o' '-mtune=generic' '-march=x86-64'" Or both :)
Out of curiosity if you change last line in test.sh from $cc @ghc_9.rsp to $cc @ghc_9.rsp -fno-use-linker-plugin Does it make thing work?
Or it could be even simpler than that... /usr/bin/ld.bfd and /usr/libexec/gcc/x86_64-pc-linux-gnu/ld might not be the same linker: $ readlink -f "/usr/libexec/gcc/x86_64-pc-linux-gnu/ld" /usr/x86_64-pc-linux-gnu/binutils-bin/2.22/ld $ readlink -f "/usr/bin/ld.bfd" /usr/x86_64-pc-linux-gnu/binutils-bin/2.25.1/ld.bfd No idea how this came to be, but I'm assuming it's the source of the problem...
Well, here's the problem. In 2012, someone or something created a bunch of links in /usr/libexec/gcc/x86_64-pc-linux-gnu: lrwxrwxrwx 1 root root 53 Sep 16 2012 addr2line -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/addr2line lrwxrwxrwx 1 root root 46 Sep 16 2012 ar -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/ar lrwxrwxrwx 1 root root 46 Sep 16 2012 as -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/as lrwxrwxrwx 1 root root 51 Sep 16 2012 c++filt -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/c++filt lrwxrwxrwx 1 root root 51 Sep 16 2012 elfedit -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/elfedit lrwxrwxrwx 1 root root 49 Sep 16 2012 gprof -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/gprof lrwxrwxrwx 1 root root 46 Sep 16 2012 ld -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/ld lrwxrwxrwx 1 root root 50 Sep 16 2012 ld.bfd -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/ld.bfd lrwxrwxrwx 1 root root 51 Sep 16 2012 ld.gold -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/ld.gold lrwxrwxrwx 1 root root 46 Sep 16 2012 nm -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/nm lrwxrwxrwx 1 root root 51 Sep 16 2012 objcopy -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/objcopy lrwxrwxrwx 1 root root 51 Sep 16 2012 objdump -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/objdump lrwxrwxrwx 1 root root 50 Sep 16 2012 ranlib -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/ranlib lrwxrwxrwx 1 root root 51 Sep 16 2012 readelf -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/readelf lrwxrwxrwx 1 root root 48 Sep 16 2012 size -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/size lrwxrwxrwx 1 root root 51 Sep 16 2012 strings -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/strings lrwxrwxrwx 1 root root 49 Sep 16 2012 strip -> /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/strip After removing them, all is well and I can emerge ghc. Sorry to bother you with a bug report that was clearly a mis-configuration on my system. Strikes me as odd that ghc (and other Haskell-related ebuilds) are the only things that seemed to have a problem with it, though. (And even stranger that gcc-4.8 didn't have a problem either.) I even did an "emerge -e @world" when I upgraded to gcc-5.3.0 and had no issues. What I'd really like to know is where those links came from in the first place. Sure hope *I* didn't manually create them, but who knows; it was years ago. Thanks for your time on this. I really appreciate it! I guess this bug can be closed as invalid.
(In reply to signals42 from comment #28) > Well, here's the problem. In 2012, someone or something created a bunch of > links in /usr/libexec/gcc/x86_64-pc-linux-gnu: > > lrwxrwxrwx 1 root root 53 Sep 16 2012 addr2line -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/addr2line > lrwxrwxrwx 1 root root 46 Sep 16 2012 ar -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/ar > lrwxrwxrwx 1 root root 46 Sep 16 2012 as -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/as > lrwxrwxrwx 1 root root 51 Sep 16 2012 c++filt -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/c++filt > lrwxrwxrwx 1 root root 51 Sep 16 2012 elfedit -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/elfedit > lrwxrwxrwx 1 root root 49 Sep 16 2012 gprof -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/gprof > lrwxrwxrwx 1 root root 46 Sep 16 2012 ld -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/ld > lrwxrwxrwx 1 root root 50 Sep 16 2012 ld.bfd -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/ld.bfd > lrwxrwxrwx 1 root root 51 Sep 16 2012 ld.gold -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/ld.gold > lrwxrwxrwx 1 root root 46 Sep 16 2012 nm -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/nm > lrwxrwxrwx 1 root root 51 Sep 16 2012 objcopy -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/objcopy > lrwxrwxrwx 1 root root 51 Sep 16 2012 objdump -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/objdump > lrwxrwxrwx 1 root root 50 Sep 16 2012 ranlib -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/ranlib > lrwxrwxrwx 1 root root 51 Sep 16 2012 readelf -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/readelf > lrwxrwxrwx 1 root root 48 Sep 16 2012 size -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/size > lrwxrwxrwx 1 root root 51 Sep 16 2012 strings -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/strings > lrwxrwxrwx 1 root root 49 Sep 16 2012 strip -> > /usr//x86_64-pc-linux-gnu/binutils-bin/2.22/strip > > After removing them, all is well and I can emerge ghc. > > Sorry to bother you with a bug report that was clearly a mis-configuration > on my system. Strikes me as odd that ghc (and other Haskell-related ebuilds) > are the only things that seemed to have a problem with it, though. (And even > stranger that gcc-4.8 didn't have a problem either.) I even did an "emerge > -e @world" when I upgraded to gcc-5.3.0 and had no issues. > > What I'd really like to know is where those links came from in the first > place. Sure hope *I* didn't manually create them, but who knows; it was > years ago. > > Thanks for your time on this. I really appreciate it! I guess this bug can > be closed as invalid. Oh, that makes more sense now! I wondered why i don't have "/usr/libexec/gcc/x86_64-pc-linux-gnu/ld" target at all and was about to ask. But you are ahead of me here :) Do you use (or happened to use?) USE=multislot for binutils (and maybe gcc)? Cruft might also be caused by recent rough changes in binutils/gcc slotting in gentoo. Glad we've fixed your system :)
