Re: Segmentation fault whew cross-compiling with included dll-s
On Sun, Jan 23, 2011 at 04:38, Alan Modra wrote: > On Fri, Jan 21, 2011 at 05:56:09PM +0100, Mojca Miklavec wrote: >> I have put the files and make-osx.sh/make-win.bat to a temporary location >> http://ol.ijs.si/~mojca/osciloskop/linker.zip > > You would probably be better off asking these questions on a mingw > support list. I suspect not many people read the bug-binutils list, > and the ones that do, don't have mingw compilers available. Thanks a lot for the suggestion. I already started wondering that it will probably be better to ask on some other list, but before I give up ... > If you want binutils hackers to look at your problem, then a linker > testcase should consist of object files and libraries (all system > libraries needed by the link too!), linker scripts and the linker > command line. ie. all the input to the linker. ... here are the libraries for 64-bit linux http://ol.ijs.si/~mojca/osciloskop/linker-with-libs.tar.gz I added collect2 and "runme.sh" which should run the basic command. However I'm not sure if what I attached is everything that is needed to reproduce the problem ... Please let me know if I missed something. (I'm just a basic user who has never dealt with any compiler issues at all.) Here is the output of my failed compilation with verbose flag (I just learnt about its existance): $ i586-mingw32msvc-c++ -v picoscope.cpp main.cpp -o main.exe -lps4000 -L. Using built-in specs. Target: i586-mingw32msvc Configured with: /build/buildd/mingw32-4.2.1.dfsg/build_dir/src/gcc-4.2.1-2-dfsg/configure -v --prefix=/usr --target=i586-mingw32msvc --enable-languages=c,c++ --enable-threads --enable-sjlj-exceptions --disable-multilib --enable-version-specific-runtime-libs Thread model: win32 gcc version 4.2.1-sjlj (mingw32-2) /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/cc1plus -quiet -v picoscope.cpp -quiet -dumpbase picoscope.cpp -mtune=pentium -auxbase picoscope -version -o /tmp/ccp4RiKp.s ignoring nonexistent directory "/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/sys-include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++ /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/i586-mingw32msvc /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/backward /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/include End of search list. GNU C++ version 4.2.1-sjlj (mingw32-2) (i586-mingw32msvc) compiled by GNU C version 4.2.3 20071210 (prerelease) (Ubuntu 4.2.2-4ubuntu1). GGC heuristics: --param ggc-min-expand=72 --param ggc-min-heapsize=80480 Compiler executable checksum: 154b8a53992189755305fccd99087270 /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/bin/as -o /tmp/ccDm0qY9.o /tmp/ccp4RiKp.s /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/cc1plus -quiet -v main.cpp -quiet -dumpbase main.cpp -mtune=pentium -auxbase main -version -o /tmp/ccp4RiKp.s ignoring nonexistent directory "/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/sys-include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++ /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/i586-mingw32msvc /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/backward /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/include End of search list. GNU C++ version 4.2.1-sjlj (mingw32-2) (i586-mingw32msvc) compiled by GNU C version 4.2.3 20071210 (prerelease) (Ubuntu 4.2.2-4ubuntu1). GGC heuristics: --param ggc-min-expand=72 --param ggc-min-heapsize=80480 Compiler executable checksum: 154b8a53992189755305fccd99087270 /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/bin/as -o /tmp/cc0NneNj.o /tmp/ccp4RiKp.s /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/collect2 -Bdynamic -o main.exe /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/lib/crt2.o /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/crtbegin.o -L. -L/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj -L/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj -L/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/lib /tmp/ccDm0qY9.o /tmp/cc0NneNj.o -lps4000 -lstdc++ -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/crtend.o collect2: ld terminated with signal 11 [Segmentation fault] Thanks again, Mojca ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Segmentation fault whew cross-compiling with included dll-s
On Sun, Jan 23, 2011 at 10:55:49AM +0100, Mojca Miklavec wrote: > http://ol.ijs.si/~mojca/osciloskop/linker-with-libs.tar.gz $ ~/build/gas/i586-mingw32/ld/ld-new -Bdynamic -o main.exe crt2.o crtbegin.o -L. ccDm0qY9.o cc0NneNj.o -lps4000 -lstdc++ -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt crtend.o $ echo $? 0 $ ~/build/gas/i586-mingw32/ld/ld-new -v GNU ld (GNU Binutils) 2.21.51.20110123 -- Alan Modra Australia Development Lab, IBM ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Segmentation fault whew cross-compiling with included dll-s
On Sun, Jan 23, 2011 at 14:58, Alan Modra wrote: > On Sun, Jan 23, 2011 at 10:55:49AM +0100, Mojca Miklavec wrote: >> http://ol.ijs.si/~mojca/osciloskop/linker-with-libs.tar.gz > > $ ~/build/gas/i586-mingw32/ld/ld-new -Bdynamic -o main.exe crt2.o crtbegin.o > -L. ccDm0qY9.o cc0NneNj.o -lps4000 -lstdc++ -lmingw32 -lgcc -lmoldname > -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc > -lmoldname -lmingwex -lmsvcrt crtend.o > $ echo $? > 0 > $ ~/build/gas/i586-mingw32/ld/ld-new -v > GNU ld (GNU Binutils) 2.21.51.20110123 Dear Alan, Do you want to say that the latest version of ld doesn't crash and generates a valid binary main.exe? If yes - may I ask for some link to instructions how to build a newer version of ld that would be suitable for cross-compiling? (I would be even more happy if somebody would be willing to send me just the binary for 64-bit Mac OS X, but I'm not sure if any developer is using Mac.) Thanks a lot, Mojca ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12248] Linker plugin failed to preserve linking order
http://sourceware.org/bugzilla/show_bug.cgi?id=12248 --- Comment #12 from H.J. Lu 2011-01-23 18:36:38 UTC --- (In reply to comment #10) > (In reply to comment #9) > > When there are "IR-object non-IR-archive IR-object" on command line, > > LTO makes it equivalent to "IR-object IR-object non-IR-archive". > > It seems this behavior isn't documented. It is fixed by commit 5ec86f21a2370249ae49ffb3dc0e438d67a39522 on hjl/lto-mixed branch. > > When there are "IR-object non-IR-archive IR-object" on command line, > > LTO makes it equivalent to "IR-object IR-object non-IR-archive". > > It also happens with IR-archive (though IR is not used: "ld.hjl: LTO IR > sections in libdiv.a(div.o) aren't used in stage 2 linking"). > I will try to change linker to ignore libdiv.a(div.o) in this case. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12314] No LTO, LD silently links to non-IR code
http://sourceware.org/bugzilla/show_bug.cgi?id=12314 --- Comment #3 from H.J. Lu 2011-01-23 19:12:29 UTC --- I checked in a different fix with commit baf9b44566e088687f28f9fe476122876c1d2f4d. Now you will get /usr/gcc-4.6/bin/gcc -B./ -O -flto -c -o bar.o bar.c ar cr libbar.a bar.o /usr/gcc-4.6/bin/gcc -B./ -O -flto -fuse-linker-plugin -o prog1 -L. main.c -lbar foo.c /tmp/cc9q7ek9.ltrans0.ltrans.o: In function `main': cc9q7ek9.ltrans0.o:(.text+0x5): undefined reference to `bar' collect2: ld returned 1 exit status make: *** [prog1] Error 1 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12248] Linker plugin failed to preserve linking order
http://sourceware.org/bugzilla/show_bug.cgi?id=12248 --- Comment #13 from H.J. Lu 2011-01-23 19:13:20 UTC --- (In reply to comment #10) > It also happens with IR-archive (though IR is not used: "ld.hjl: LTO IR > sections in libdiv.a(div.o) aren't used in stage 2 linking"). > Fixed by commit baf9b44566e088687f28f9fe476122876c1d2f4d on hjl/lto-mixed branch. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Segmentation fault whew cross-compiling with included dll-s
On Sun, Jan 23, 2011 at 05:30:50PM +0100, Mojca Miklavec wrote: > Do you want to say that the latest version of ld doesn't crash Yes. > and > generates a valid binary main.exe? That I don't know. I don't have a mingw system to run it on. > If yes - may I ask for some link to instructions how to build a newer > version of ld that would be suitable for cross-compiling? (I would be > even more happy if somebody would be willing to send me just the > binary for 64-bit Mac OS X, but I'm not sure if any developer is using > Mac.) Please ask for help on a mingw list. How you configure depends on where your current cross-tools are. -- Alan Modra Australia Development Lab, IBM ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12248] Linker plugin failed to preserve linking order
http://sourceware.org/bugzilla/show_bug.cgi?id=12248 --- Comment #14 from Dmitry Gorbachev 2011-01-23 23:14:20 UTC --- Now `gcc -B./ -o foo -O2 -fwhole-program -flto=jobserver -fuse-linker-plugin x.o libdiv.a y.o' uses __udivdi3 from libgcc. Plain non-LTO link takes it from libdiv.a. Inconsistency, again... -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12248] Linker plugin failed to preserve linking order
http://sourceware.org/bugzilla/show_bug.cgi?id=12248 --- Comment #15 from H.J. Lu 2011-01-23 23:38:41 UTC --- (In reply to comment #14) > Now `gcc -B./ -o foo -O2 -fwhole-program -flto=jobserver -fuse-linker-plugin > x.o > libdiv.a y.o' uses __udivdi3 from libgcc. Plain non-LTO link takes it from > libdiv.a. Inconsistency, again... It is consistent since LTO in x.o doesn't reference __udivdi3 while non-LTO in x.o references __udivdi3. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12248] Linker plugin failed to preserve linking order
http://sourceware.org/bugzilla/show_bug.cgi?id=12248 Dmitry Gorbachev changed: What|Removed |Added CC||d.g.gorbachev at gmail dot ||com --- Comment #16 from Dmitry Gorbachev 2011-01-24 00:37:53 UTC --- It looks counterintuitive to me. > LTO in x.o doesn't reference __udivdi3 But a reference to __udivdi3 from bar is generated on LTO step: /tmp/cczLpgd5.ltrans0.ltrans.o: reference to __udivdi3 BTW, behavior of `gcc -B./ -o foo -O2 -fwhole-program -flto=jobserver -fuse-linker-plugin y.o x.o libdiv.a' depends on the presence / absence of IR sections in libdiv.a (links with libgcc / libdiv.a). I think it's a bug. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12248] Linker plugin failed to preserve linking order
http://sourceware.org/bugzilla/show_bug.cgi?id=12248 --- Comment #17 from H.J. Lu 2011-01-24 01:24:01 UTC --- (In reply to comment #16) > It looks counterintuitive to me. > > > LTO in x.o doesn't reference __udivdi3 > > But a reference to __udivdi3 from bar is generated on LTO step: > /tmp/cczLpgd5.ltrans0.ltrans.o: reference to __udivdi3 This is internal implementation of LTO, which calls __udivdi3 in libgcc. LTO may also choose to inline it. > BTW, behavior of `gcc -B./ -o foo -O2 -fwhole-program -flto=jobserver > -fuse-linker-plugin y.o x.o libdiv.a' depends on the presence / absence of IR > sections in libdiv.a (links with libgcc / libdiv.a). I think it's a bug. This is intentional. Since libdiv.a with IR isn't used by LTO in stage 1 linking, it can't be used in stage 2 either. Otherwise, stage 2 linking may lead to undefined symbols if libdiv uses some external variables, which are defined in some IR inputs and optimized out by LTO since LTO didn't see their references in libdiv.a. I checked some LTO testcases into hjl/lto-mixed branch to verify it. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
