Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Dave Korn wrote: Might move to 4.3.3 while I'm doing it, and should I make -4 the default? Oh, yes, yes! Thanks, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Dave Korn wrote: 1.5 or 1.7? I do not use 1.7. uname -a CYGWIN_NT-5.1 mypc 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin cygcheck ./test_program.exe .\test_program.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\cyggcc_s-1.dll C:\cygwin\bin\cyggfortran-3.dll -shared is not (surprisingly) the opposite of -static! -static means link your app against static libs, not DLLs. -shared means build your app as a DLL, not an EXE! If you want to link against shared DLLs, you need add no options at all; that's the default for all the languages (except plain C). In this case gfortran-4.3.2-2 works fine on 1.5 and, perhaps, we have another problem on 1.7! Cheers, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
--- Sab 14/3/09, Dave Korn ha scritto: > Da: Dave Korn > Oggetto: Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2 > A: > Data: Sabato 14 marzo 2009, 07:56 > Marco Atzeri wrote: > > > it seems a 1.7 specific fault. On cygwin 1.5 it works; > I never checked > > before :-( > > Odd! It fails for me on both. (You did > update gcc-4 on *both* your > installations, right?) > yes $ uname -a CYGWIN_NT-5.1 ITQMOZCAS2NB007 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin $ cygcheck -c -d |grep fortran gcc4-fortran 4.3.2-2 libgfortran3 4.3.2-2 $cygcheck ./conftest-15.exe .\conftest-15.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\cygwin\bin\cyggcc_s-1.dll C:\cygwin\bin\cyggfortran-3.dll $ ./conftest-15.exe > conftest.out ; cat conftest.out SUCCESS $ uname -a CYGWIN_NT-5.1 ITQMOZCAS2NB007 1.7.0(0.206/5/3) 2009-03-11 14:08 i686 Cygwin cygcheck -c -d |grep fortran gcc4-fortran 4.3.2-2 libgfortran3 4.3.2-2 $ cygcheck ./conftest-17.exe C:\cygwin2\pub\programs\fortran\conftest-17.exe C:\cygwin2\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\cygwin2\bin\cyggcc_s-1.dll C:\cygwin2\bin\cyggfortran-3.dll $ ./conftest-17.exe > conftest.out ; cat conftest.out So I can reproduce it only on cygwin-1.7. > > is it possible that Cygwin-1.7 is fooled by the not > like-C standard output > > ? > > > > "GFORTRAN_STDOUT_UNIT—Unit number for standard > output > > > > This environment variable can be used to select the > unit number > > preconnected to standard output. This must be a > positive integer. The > > default value is 6. " > > I'm not sure. From what I've studied so far of > libgfortran/io, I think the > fortran "unit" numbers are mapped to, rather than directly > equivalent to, unix > fds. It might be a libgfortran bug, or it may even > not; there could be some > interaction in the cygwin dll between DLL unload and stdio > shutdown during the > exit sequence that fails to flush the stream properly, for > example. Still > investigating. > > cheers, > DaveK > Regards Marco -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Marco Atzeri wrote: > it seems a 1.7 specific fault. On cygwin 1.5 it works; I never checked > before :-( Odd! It fails for me on both. (You did update gcc-4 on *both* your installations, right?) > is it possible that Cygwin-1.7 is fooled by the not like-C standard output > ? > > "GFORTRAN_STDOUT_UNIT—Unit number for standard output > > This environment variable can be used to select the unit number > preconnected to standard output. This must be a positive integer. The > default value is 6. " I'm not sure. From what I've studied so far of libgfortran/io, I think the fortran "unit" numbers are mapped to, rather than directly equivalent to, unix fds. It might be a libgfortran bug, or it may even not; there could be some interaction in the cygwin dll between DLL unload and stdio shutdown during the exit sequence that fails to flush the stream properly, for example. Still investigating. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
--- Sab 14/3/09, Dave Korn ha scritto: > Da: Dave Korn > Oggetto: Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2 > A: [email protected] > Data: Sabato 14 marzo 2009, 04:04 > Angelo Graziosi wrote: > > Still continuing to test... > > > > Marco Atzeri wrote: > >> if I had ./test_program I see the output on the > screen but > >> > >> ./test_program > test_output > >> leave test_output empty. > > > > If I build that tst case with: > > > > gfortran-4 test_program.F -o test_program > > > > then > > > > $ ./test_program.exe > > SUCCESS > > > > $ ./test_program.exe > test_output > > > > $ cat test_output > > SUCCESS > > Hmm, doesn't work here. 1.5 or 1.7? This > is 1.7: > > ad...@ubik /tmp/fortran/hw > $ cat hw.F > program main > WRITE(*,*) > 'SUCCESS' > end > > ad...@ubik /tmp/fortran/hw > $ gfortran-4 hw.F -o test_program > > ad...@ubik /tmp/fortran/hw > $ ./test_program.exe > test_output > > ad...@ubik /tmp/fortran/hw > $ cat test_output it seems a 1.7 specific fault. On cygwin 1.5 it works; I never checked before :-( is it possible that Cygwin-1.7 is fooled by the not like-C standard output ? "GFORTRAN_STDOUT_UNIT—Unit number for standard output This environment variable can be used to select the unit number preconnected to standard output. This must be a positive integer. The default value is 6. " http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gfortran/GFORTRAN_005fSTDOUT_005fUNIT.html#GFORTRAN_005fSTDOUT_005fUNIT > > cheers, > DaveK > Regards Marco -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Angelo Graziosi wrote: > Still continuing to test... > > Marco Atzeri wrote: >> if I had ./test_program I see the output on the screen but >> >> ./test_program > test_output >> leave test_output empty. > > If I build that tst case with: > > gfortran-4 test_program.F -o test_program > > then > > $ ./test_program.exe > SUCCESS > > $ ./test_program.exe > test_output > > $ cat test_output > SUCCESS Hmm, doesn't work here. 1.5 or 1.7? This is 1.7: ad...@ubik /tmp/fortran/hw $ cat hw.F program main WRITE(*,*) 'SUCCESS' end ad...@ubik /tmp/fortran/hw $ gfortran-4 hw.F -o test_program ad...@ubik /tmp/fortran/hw $ ./test_program.exe > test_output ad...@ubik /tmp/fortran/hw $ cat test_output ad...@ubik /tmp/fortran/hw $ cygcheck ./test_program.exe F:\cygwin-1.7\tmp\fortran\hw\test_program.exe F:\cygwin-1.7\bin\cygwin1.dll C:\WINNT\system32\ADVAPI32.DLL C:\WINNT\system32\NTDLL.DLL C:\WINNT\system32\KERNEL32.DLL C:\WINNT\system32\RPCRT4.DLL F:\cygwin-1.7\bin\cyggcc_s-1.dll F:\cygwin-1.7\bin\cyggfortran-3.dll ad...@ubik /tmp/fortran/hw > But if I build with: > > gfortran-4 -shared test_program.F -o test_program > > then > > $ ./test_program.exe > bash: ./test_program.exe: Permission denied > > i.e. it does not work at all! > > What am I missing? -shared is not (surprisingly) the opposite of -static! -static means link your app against static libs, not DLLs. -shared means build your app as a DLL, not an EXE! In particular, if you have '-shared', gcc adds '-e __cygwin_dll_en...@12' to the linker flags, which means that it gets a DllMain function for its entrypoint instead of your standard main(argc, argv). If you want to link against shared DLLs, you need add no options at all; that's the default for all the languages (except plain C). cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Still continuing to test... Marco Atzeri wrote: if I had ./test_program I see the output on the screen but ./test_program > test_output leave test_output empty. If I build that tst case with: gfortran-4 test_program.F -o test_program then $ ./test_program.exe SUCCESS $ ./test_program.exe > test_output $ cat test_output SUCCESS But if I build with: gfortran-4 -shared test_program.F -o test_program then $ ./test_program.exe bash: ./test_program.exe: Permission denied i.e. it does not work at all! What am I missing? Cheers, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Dave Korn wrote: So I think you should check for a bug in the --disable-debug configure option. ...it seems that the actual overall size of the stripped exes should be pretty much the same betwen the two compilers Indeed! I have flagged the thing to the Mrxvt guys. Thanks a lot, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Charles Wilson wrote: > It looks like CC='gcc -static-libgcc' (or, in our case for now, > -shared-libgcc and CXX='g++ -shared-libgcc -shared-libstdc++' etc) is the > "solution". Shouldn't need anything for CXX, as the default shared libstdc++ implies shared libgcc: dkad...@ubik /tmp/hw $ g++ -g -O0 h.cpp -o a -v Using built-in specs. Target: i686-pc-cygwin Configured with: /gnu/gcc/package/gcc4-4.3.2-2/src/gcc-4.3.2/configure --srcdir= /gnu/gcc/package/gcc4-4.3.2-2/src/gcc-4.3.2 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/sbin --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --infodir=/usr/share/info --mandir=/usr/share/man --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --with-slibdir=/usr/bin --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --enable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --disable-symvers --enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada --enable-threads=posix AS=/opt/gcc-tools/bin/as.exe AS_FOR_TARGET=/opt/gcc-tools/bin/as.exe LD=/opt/gcc-tools/bin/ld.exe LD_FOR_TARGET=/opt/gcc-tools/bin/ld.exe Thread model: posix gcc version 4.3.2 20080827 (beta) 2 (GCC) COLLECT_GCC_OPTIONS='-g' '-O0' '-o' 'a.exe' '-v' '-shared-libgcc' '-mtune=generic' cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Yaakov (Cygwin/X) wrote: > Dave Korn wrote: >> Can you take this one upstream for us? LT really ought to know about these >> two options, they're not even Cygwin-specific at all. > > Chuck would probably be a better candidate for that, as he works with > them already. No, not really. I've had a number of patches sitting in the queue since November. I think ANYONE else might get better responsiveness upstream. Bitter? ME? Nah... Frankly, Ralf W. is overworked. There are four maintainers, but Peter O'G, and Gary V. are MIA, and Bob F. never reviews patches. However, about this specific issue: it has been reported before: http://www.mail-archive.com/[email protected]/msg08402.html even though it was considered a bug: http://www.opensubscriber.com/message/[email protected]/3395177.html the last line states: "I don't see a coherent solution to this mess ATM." It looks like CC='gcc -static-libgcc' (or, in our case for now, -shared-libgcc and CXX='g++ -shared-libgcc -shared-libstdc++' etc) is the "solution". -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dave Korn wrote: > Can you take this one upstream for us? LT really ought to know about these > two options, they're not even Cygwin-specific at all. Chuck would probably be a better candidate for that, as he works with them already. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkm6h8AACgkQpiWmPGlmQSNvwwCdFjrFGKTjuoD03hkg21kAXjKn 3tMAn2Ez5VDyoMDqGb2hg+rkljikLntd =awWG -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Dave Korn wrote: > Tim Prince wrote: >> >> http://sites.google.com/site/tprincesite/levine-callahan-dongarra-vectors > > gcc: f90_cputime.c: No such file or directory > I notice you're compiling with -fopenmp; does removing it help any? Sorry, all these months and no one ever missed those .c files. Added them. Yes, I remove -fopenmp, and, when necessary, -ffast-math, from Makefile.gfortran, for various Windows hosted builds. I have tried just once this year to build gcc for cygwin with --enable-libgomp. Back when it used to pass a reasonable portion of the testsuite tests, it performed poorly. I wondered whether recent comments indicated someone tried to help that. > >> [ generic testsuite flakiness ] > Do you have > your heap_chunk_in_mb turned right up? I find it helps. > Set it for future efforts with testsuite. Thanks, Tim -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Angelo Graziosi wrote: > Dave Korn wrote: > >> Can you show me the "objdump -h" output for both? > > It seems that here there is a problem. I have build with the same build > script and without debug info, but, for what I can understand, with gcc4 > the debug info are still there. To reproduce: From what I understand, with gcc3 the debug info are also still there: > GGG 3.4.4-999 > > ./configure --enable-everything --disable-debug > 5 .stab 0004e2c4 00447000 00447000 00044000 2**2 > CONTENTS, READONLY, DEBUGGING, EXCLUDE > 6 .stabstr 0002db31 00496000 00496000 00092400 2**0 > CONTENTS, READONLY, DEBUGGING, EXCLUDE ... just a whole lot smaller than with gcc4: > GGG 4.3.2-2 > > CC='gcc-4' CXX='g++-4' CPP='cpp-4' ./configure --enable-everything > --disable-debug > 5 .debug_aranges 03c0 00448000 00448000 00043c00 2**3 > CONTENTS, READONLY, DEBUGGING > 6 .debug_pubnames 2c7f 00449000 00449000 00044000 2**0 > CONTENTS, READONLY, DEBUGGING > 7 .debug_info 00106f9e 0044c000 0044c000 00046e00 2**0 > CONTENTS, READONLY, DEBUGGING > 8 .debug_abbrev 5bbe 00553000 00553000 0014de00 2**0 > CONTENTS, READONLY, DEBUGGING > 9 .debug_line ae50 00559000 00559000 00153a00 2**0 > CONTENTS, READONLY, DEBUGGING > 10 .debug_frame 378c 00564000 00564000 0015ea00 2**2 > CONTENTS, READONLY, DEBUGGING > 11 .debug_str5371 00568000 00568000 00162200 2**0 > CONTENTS, READONLY, DEBUGGING > 12 .debug_loc00020b56 0056e000 0056e000 00167600 2**0 > CONTENTS, READONLY, DEBUGGING > 13 .debug_ranges 23a0 0058f000 0058f000 00188200 2**0 > CONTENTS, READONLY, DEBUGGING So I think you should check for a bug in the --disable-debug configure option. Running strip on the exe as a separate step should work around the problem too. Taking a look at the actual content: > GGG 3.4.4-999 > 0 .text 00035230 00401000 00401000 0400 2**4 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 1 .data 1f40 00437000 00437000 00035800 2**5 > CONTENTS, ALLOC, LOAD, DATA > 2 .rdata9f80 00439000 00439000 00037800 2**5 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 3 .bss 0410 00443000 00443000 2**3 > ALLOC > 4 .idata27cc 00444000 00444000 00041800 2**2 > CONTENTS, ALLOC, LOAD, DATA > GGG 4.3.2-2 > 0 .text 00036138 00401000 00401000 0400 2**4 > CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA > 1 .data 17c0 00438000 00438000 00036600 2**5 > CONTENTS, ALLOC, LOAD, DATA > 2 .rdata9484 0043a000 0043a000 00037e00 2**5 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 3 .bss 0430 00444000 00444000 2**3 > ALLOC > 4 .idata27ec 00445000 00445000 00041400 2**2 > CONTENTS, ALLOC, LOAD, DATA ... it seems that the actual overall size of the stripped exes should be pretty much the same betwen the two compilers. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Dave Korn wrote: Can you show me the "objdump -h" output for both? It seems that here there is a problem. I have build with the same build script and without debug info, but, for what I can understand, with gcc4 the debug info are still there. To reproduce: svn checkout https://materm.svn.sourceforge.net/svnroot/materm/mrxvt05b cd mrxvt05b ./bootstrap.sh GGG 3.4.4-999 ./configure --enable-everything --disable-debug make ls -lrt src/mrxvt.exe -rwxr-xr-x 1 graziosi Users 873388 Mar 13 16:09 src/mrxvt.exe objdump -h src/mrxvt.exe src/mrxvt.exe: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00035230 00401000 00401000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 1f40 00437000 00437000 00035800 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .rdata9f80 00439000 00439000 00037800 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .bss 0410 00443000 00443000 2**3 ALLOC 4 .idata27cc 00444000 00444000 00041800 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .stab 0004e2c4 00447000 00447000 00044000 2**2 CONTENTS, READONLY, DEBUGGING, EXCLUDE 6 .stabstr 0002db31 00496000 00496000 00092400 2**0 CONTENTS, READONLY, DEBUGGING, EXCLUDE GGG 4.3.2-2 svn checkout https://materm.svn.sourceforge.net/svnroot/materm/mrxvt05b cd mrxvt05b ./bootstrap.sh CC='gcc-4' CXX='g++-4' CPP='cpp-4' ./configure --enable-everything --disable-debug make ls -lrt src/mrxvt.exe -rwxr-xr-x 1 graziosi Users 1712670 Mar 13 16:16 src/mrxvt.exe objdump -h src/mrxvt.exe src/mrxvt.exe: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00036138 00401000 00401000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 17c0 00438000 00438000 00036600 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .rdata9484 0043a000 0043a000 00037e00 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .bss 0430 00444000 00444000 2**3 ALLOC 4 .idata27ec 00445000 00445000 00041400 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .debug_aranges 03c0 00448000 00448000 00043c00 2**3 CONTENTS, READONLY, DEBUGGING 6 .debug_pubnames 2c7f 00449000 00449000 00044000 2**0 CONTENTS, READONLY, DEBUGGING 7 .debug_info 00106f9e 0044c000 0044c000 00046e00 2**0 CONTENTS, READONLY, DEBUGGING 8 .debug_abbrev 5bbe 00553000 00553000 0014de00 2**0 CONTENTS, READONLY, DEBUGGING 9 .debug_line ae50 00559000 00559000 00153a00 2**0 CONTENTS, READONLY, DEBUGGING 10 .debug_frame 378c 00564000 00564000 0015ea00 2**2 CONTENTS, READONLY, DEBUGGING 11 .debug_str5371 00568000 00568000 00162200 2**0 CONTENTS, READONLY, DEBUGGING 12 .debug_loc00020b56 0056e000 0056e000 00167600 2**0 CONTENTS, READONLY, DEBUGGING 13 .debug_ranges 23a0 0058f000 0058f000 00188200 2**0 CONTENTS, READONLY, DEBUGGING Cheers, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Dave Korn wrote: > Marco Atzeri wrote: > >> It seems a problem of output redirection with dynamic >> fortran library Oh, another clue: it only affects stdout, not stderr- ad...@ubik /tmp/fortran/hw $ ./hw 1>&2 | cat SUCCESS ad...@ubik /tmp/fortran/hw $ ./hw 2>&1 | cat ad...@ubik /tmp/fortran/hw $ I'll start digging in the library code. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Marco Atzeri wrote: > It seems a problem of output redirection with dynamic > fortran library > This did not happened with static linked fortran library. I agree. If anyone has problems with this issue when using fortran, the workaround for now will be to use "-static" when compiling. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
--- Ven 13/3/09, Dave Korn ha scritto: > Da: Dave Korn > Oggetto: Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2 > A: > Data: Venerdì 13 marzo 2009, 07:41 > Tim Prince wrote: > > This doesn't seem to be a magically fully working > gfortran, such as we > > had fleetingly with the 20090227 snapshot of > 4.4. I'd agree it's likely > > an "upstream" problem, even if it shows up only on > cygwin. > > Hi Tim, can you give me a bit of context here? > I don't know what sort of > problems you're seeing or what "fully" working means > here. And of course it's > not going to reflect anything that happened after 4.3 > branched. > > I noticed a few regressions in the testsuite, where > the expected output > doesn't show up - in fact no output showed up at all from > the testcases. But > when I tried to reproduce a few of them manually, they > worked fine and > generated the correct output, so I put it down to an > artifact of the testsuite > framework, maybe an interaction with tcl/expect and > cygwin/win32 pipes, and > figured I'd try and solve it before the next release. > Hi Dave I also noted such issue playing with the previous 4.3.2-1 and my own built cygfortran.dll, but I thought was my fault. It seems a problem of output redirection with dynamic fortran library if I had ./test_program I see the output on the screen but ./test_program > test_output leave test_output empty. This did not happened with static linked fortran library. test case: -- program main WRITE(*,*) 'SUCCESS' end -- > I don't know much about Fortran, so I can't > necessarily solve problems in > the front-end, but if the issues relate to generic compiler > infrastructure > such as stdio or exception handling I should be able to fix > bugs. > > cheers, > DaveK > Regards Marco -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Tim Prince wrote: > Dave Korn wrote: >> Tim Prince wrote: >>> This doesn't seem to be a magically fully working gfortran, such as we >>> had fleetingly with the 20090227 snapshot of 4.4. >> Hi Tim, can you give me a bit of context here? > I may not have known what to look for, Most 4.3 and 4.4 snapshot cygwin > builds of gfortran, including all those I have tried from gfortran wiki or > cygwin setup, have acted as if there is a memory or stack leak which kills > the run after 40 or so Fortran subroutine calls and returns. I haven't > actually known how to check if this is a leak. This was never a problem > until the 4.3 era, and there have been a very few snapshots, including the > 4.4 20090227, which could run my tests perfectly at > http://sites.google.com/site/tprincesite/levine-callahan-dongarra-vectors gcc: f90_cputime.c: No such file or directory gcc: no input files make: *** [f90_cputime.o] Error 1 Hmm, I'm going to need a little more to go on than that! (Feel free to send me any missing files off-list if it's convenient and they're redistributable.) I notice you're compiling with -fopenmp; does removing it help any? > [ generic testsuite flakiness ] Hmmm, I get a couple of mutex-related testcases here and there which sometimes-pass-sometimes-fail (must look into this, it possibly indicates a race condition in the cygwin dll), and there are a few java testcases that get stuck and don't time out and I have to manually kill before the run will continue, but I don't get nearly that much general flakiness. Do you have your heap_chunk_in_mb turned right up? I find it helps. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Yaakov (Cygwin/X) wrote: >> Also, some 3PPs will get warm fuzzies from having one less DLL to >> distribute, though it hardly makes the resulting executables any more >> "standalone" ;-) > > Since when exactly do we care about 3PPs here? :-) We don't, hence my smiley! > Doesn't sound like > much of a reason not to have -shared-libgcc the default for gcc as well > (unless, of course, -static is specified, as you did with the other > languages). Would you consider changing this for -3? I'm fully in favour of changing the default once we've had a little running in period, along with the change to gcc4 as the system default compiler. But I'd really like to have the libstdc/weak problem fixed before making that switch, so that our default mode of operation isn't non-conformant. >> Errr, dunno. It's a standard GCC command-line option, libtool ought to be >> taught to understand it - surprised it doesn't already. > > No, it just seems to ignore it entirely. The only way I've found so far > is to define CC="gcc-4 -shared-libgcc" for configure. Not pretty. :-( Can you take this one upstream for us? LT really ought to know about these two options, they're not even Cygwin-specific at all. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Dave Korn wrote: > Tim Prince wrote: >> This doesn't seem to be a magically fully working gfortran, such as we >> had fleetingly with the 20090227 snapshot of 4.4. I'd agree it's likely >> an "upstream" problem, even if it shows up only on cygwin. > > Hi Tim, can you give me a bit of context here? I don't know what sort of > problems you're seeing or what "fully" working means here. And of course it's > not going to reflect anything that happened after 4.3 branched. > Dave, I may not have known what to look for, Most 4.3 and 4.4 snapshot cygwin builds of gfortran, including all those I have tried from gfortran wiki or cygwin setup, have acted as if there is a memory or stack leak which kills the run after 40 or so Fortran subroutine calls and returns. I haven't actually known how to check if this is a leak. This was never a problem until the 4.3 era, and there have been a very few snapshots, including the 4.4 20090227, which could run my tests perfectly at http://sites.google.com/site/tprincesite/levine-callahan-dongarra-vectors The problem does not show up in the version where Fortran calls a series of C++ functions (extern "C"), but it does show up when Fortran calls Fortran or C. Each of those versions has a function which is a direct translation of another, in fact the C and C++ versions have a number of identical functions (except for the extern "C"), as do the Fortran versions, one being as much f95 as possible, and the other using f77 where it is faster. I'm not referring here to the flaky behavior I see when running gcc testsuite on cygwin. As no one but me ever posts cygwin tests to gcc-testresults, I can't judge how my results compare to others. For months, the testsuite has repeated the gcc, gfortran, g++, and libstdc++ tests several times, but the objc testsuite runs just once, as it used to do. Most of those repeated test runs die or hang short of completion. I have tried several installations of cygwin, all behave this way. I have been using cygwin 1.7 for testsuite since it came out, as it seemed to work better than 1.5, but it always acts this way. Lately, the testresults for 4.4 on cygwin have improved greatly, I suppose from the work of some of the cygwin people. cygwin g77 used to be capable of running real applications of several thousand source lines. gfortran linux is capable of running applications of millions of source lines. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 First, I must say, many thanks for all your hard work on gcc4! Dave Korn wrote: > No reason that I can think of in general. The only case would be when you > really need to override intra-libstdc++ calls to operators new and delete, in > which case you need to link the whole thing statically. > > Also, some 3PPs will get warm fuzzies from having one less DLL to > distribute, though it hardly makes the resulting executables any more > "standalone" ;-) Since when exactly do we care about 3PPs here? :-) Doesn't sound like much of a reason not to have -shared-libgcc the default for gcc as well (unless, of course, -static is specified, as you did with the other languages). Would you consider changing this for -3? > Errr, dunno. It's a standard GCC command-line option, libtool ought to be > taught to understand it - surprised it doesn't already. No, it just seems to ignore it entirely. The only way I've found so far is to define CC="gcc-4 -shared-libgcc" for configure. Not pretty. :-( Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkm6BBIACgkQpiWmPGlmQSOOcQCfa+TZoh+bYFa6nrFP2dCda2F0 cL0AnAlAGFgBw0HM3EGvIuB3GbTgD7Rf =8T4t -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Yaakov (Cygwin/X) wrote: > Dave Korn wrote: >> Plain C applications will, by default, be linked statically against libgcc as >> previously. To link against the shared libgcc DLL, '-shared-libgcc' must be >> manually specified on the command-line. > > 1) What exactly are the pros and cons of this? IOW, why should we *not* > want to use shared libgcc? No reason that I can think of in general. The only case would be when you really need to override intra-libstdc++ calls to operators new and delete, in which case you need to link the whole thing statically. Also, some 3PPs will get warm fuzzies from having one less DLL to distribute, though it hardly makes the resulting executables any more "standalone" ;-) > 2) How can -shared-libgcc (or -static-libgcc, for that matter) be passed > when building with libtool so that it actually gets passed on to gcc? Errr, dunno. It's a standard GCC command-line option, libtool ought to be taught to understand it - surprised it doesn't already. >> The to-do list for the first fully stable release currently stands at: >> >> - Implement improved weak symbol handling in Win32 PE binutils, to resolve >> C++ >> operator new/delete interposition problem with shared libstdc++. >> - Add support scripts for default compiler switching. > > std::wstring for cygwin-1.7? Please?? Oh, sorry! Forgot. Adding it to the list now give us: The to-do list for the first fully stable release currently stands at: - Implement improved weak symbol handling in Win32 PE binutils, to resolve C++ operator new/delete interposition problem with shared libstdc++. - Add support scripts for default compiler switching. - std::wstring for cygwin-1.7! - investigate fortran testsuite problems. - investigate java testsuite run test failures. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Tim Prince wrote: > This doesn't seem to be a magically fully working gfortran, such as we > had fleetingly with the 20090227 snapshot of 4.4. I'd agree it's likely > an "upstream" problem, even if it shows up only on cygwin. Hi Tim, can you give me a bit of context here? I don't know what sort of problems you're seeing or what "fully" working means here. And of course it's not going to reflect anything that happened after 4.3 branched. I noticed a few regressions in the testsuite, where the expected output doesn't show up - in fact no output showed up at all from the testcases. But when I tried to reproduce a few of them manually, they worked fine and generated the correct output, so I put it down to an artifact of the testsuite framework, maybe an interaction with tcl/expect and cygwin/win32 pipes, and figured I'd try and solve it before the next release. I don't know much about Fortran, so I can't necessarily solve problems in the front-end, but if the issues relate to generic compiler infrastructure such as stdio or exception handling I should be able to fix bugs. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Angelo Graziosi wrote: > For completeness I want to flag that, for mrxvt, mrxvt.exe has a size > which is double respect with the case when Mrxvt is build with GCC-3.4.4. Stripped or unstripped? Can you show me the "objdump -h" output for both? DW2 debug (now default over stabs) is pretty big; here's a freshly built copy of 'ld': ad...@ubik /usr/build/obj-binutils/ld/.libs $ cp ld-new.exe ld-n.exe ad...@ubik /usr/build/obj-binutils/ld/.libs $ strip ld-n.exe ad...@ubik /usr/build/obj-binutils/ld/.libs $ du -h ld-new.exe ld-n.exe 5.2Mld-new.exe 768Kld-n.exe ad...@ubik /usr/build/obj-binutils/ld/.libs cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
On Thu, 12 Mar 2009, Dave Korn wrote: > > Indeed it did. With the attached patch, build and test both ran to > completion without any errors. Indeed! Now ROOT and its tests build fine... and also the following applications build fine: Cernlib 2006, TeXLive-SVN, Emacs-CVS, Mrxvt-398-svn. For completeness I want to flag that, for mrxvt, mrxvt.exe has a size which is double respect with the case when Mrxvt is build with GCC-3.4.4. Thanks a lot, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
This doesn't seem to be a magically fully working gfortran, such as we had fleetingly with the 20090227 snapshot of 4.4. I'd agree it's likely an "upstream" problem, even if it shows up only on cygwin. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dave Korn wrote: > Plain C applications will, by default, be linked statically against libgcc as > previously. To link against the shared libgcc DLL, '-shared-libgcc' must be > manually specified on the command-line. 1) What exactly are the pros and cons of this? IOW, why should we *not* want to use shared libgcc? 2) How can -shared-libgcc (or -static-libgcc, for that matter) be passed when building with libtool so that it actually gets passed on to gcc? > The to-do list for the first fully stable release currently stands at: > > - Implement improved weak symbol handling in Win32 PE binutils, to resolve C++ > operator new/delete interposition problem with shared libstdc++. > - Add support scripts for default compiler switching. std::wstring for cygwin-1.7? Please?? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkm5VbAACgkQpiWmPGlmQSO8+QCg8Etp2BF5O/JoJAL/L5UQPhyu GdwAoKvgtJ1+waD7Yl4Uf20tSQoLSiHH =ZQME -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Dave Korn wrote: > [the same post twice] Oops, sorry all, MTA glitch. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
[Bcc's sent to interested third parties] Dave Korn wrote: > And the immediate reason for this is the way that TSystem.o is built: > > build.log > g++-4 -O2 -pipe -Wall -Woverloaded-virtual -D_DLL -Iinclude > -I/usr/X11R6/include -o core/base/src/TSystem.o -c > core/base/src/TSystem.cxx > build.log > > Why is a -D for _DLL present? That is a reserved definition in the > implementation's namespace, and in particular it used when compiling > libstdc++ itself, where it alters the effect of the library headers to > declare all the library APIs as dllexport - they are dllimport by default, > which is what user applications want to see. > > I manually re-ran the compile command without "-D_DLL" and got a good > object file: > So I'll now try rebuilding and retesting without _DLL defined anywhere and > see if it solves the problem. Indeed it did. With the attached patch, build and test both ran to completion without any errors. As far as I can see (thanks, Peter R.) the _DLL definition conveys information from compiler to linker to tell it which multilib variant to link against. We have the -shared-libgcc/-static-libgcc option in the gcc driver and the related specs to serve the same purpose on GNU. One disclaimer: this could have side-effects on MinGW, and should be verified there to make sure, if it's a supported platform. (Hopefully it'll be equally correct there, though). cheers, DaveK diff -pru -x '*.o' -x '*.log' 1st.root/config/Makefile.win32gcc root/config/Makefile.win32gcc --- 1st.root/config/Makefile.win32gcc 2009-02-26 14:07:32.0 + +++ root/config/Makefile.win32gcc 2009-03-12 16:51:25.65625 + @@ -17,14 +17,14 @@ endif # Compiler: CXX = g++ CC= gcc -CXXFLAGS = -pipe -Wall -Woverloaded-virtual -D_DLL $(EXTRA_CXXFLAGS) \ +CXXFLAGS = -pipe -Wall -Woverloaded-virtual $(EXTRA_CXXFLAGS) \ -I/usr/X11R6/include -CFLAGS= -pipe -Wall -D_DLL $(EXTRA_CFLAGS) -I/usr/X11R6/include -CINTCXXFLAGS = -pipe -Wall -Woverloaded-virtual -D_DLL $(EXTRA_CXXFLAGS) \ +CFLAGS= -pipe -Wall $(EXTRA_CFLAGS) -I/usr/X11R6/include +CINTCXXFLAGS = -pipe -Wall -Woverloaded-virtual $(EXTRA_CXXFLAGS) \ -DG__REGEXP -DG__UNIX -DG__SHAREDLIB \ -DG__OSFDLL -DG__ROOT -DG__REDIRECTIO -DG__CYGWIN \ -DG__NEWSTDHEADER -CINTCFLAGS= -pipe -Wall -D_DLL $(EXTRA_CFLAGS) \ +CINTCFLAGS= -pipe -Wall $(EXTRA_CFLAGS) \ -DG__REGEXP -DG__UNIX -DG__SHAREDLIB \ -DG__OSFDLL -DG__ROOT -DG__REDIRECTIO -DG__CYGWIN \ -DG__NEWSTDHEADER diff -pru -x '*.o' -x '*.log' 1st.root/test/Makefile.arch root/test/Makefile.arch --- 1st.root/test/Makefile.arch 2009-02-26 14:07:26.0 + +++ root/test/Makefile.arch 2009-03-12 16:51:16.59375 + @@ -542,7 +542,7 @@ LD= g++ LDFLAGS = $(OPT) -Wl,--enable-auto-import \ -Wl,--enable-runtime-pseudo-reloc \ -L/usr/X11R6/lib -SOFLAGS = -shared -D_DLL -Wl,--enable-auto-image-base \ +SOFLAGS = -shared -Wl,--enable-auto-image-base \ -Wl,--export-all-symbols EXPLLINKLIBS = $(ROOTLIBS) $(ROOTGLIBS) endif -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Peter Rosin wrote: > Den 2009-03-12 18:01 skrev Dave Korn: >> Hmmm, I may have misunderstood that. Does -D_DLL mean something >> special to MSVC, does anyone know? > > When you compile with shared libc on MSVC (e.g. -MD), it defines _DLL > for you. Ah, thanks. So it's used for internal communication between compiler and linker in the MSVC toolchain. That does make it seem unlikely it should be needed here in a GNU build. And I assume that even an MSVC build should be using -MD rather than defining the macro directly? cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Den 2009-03-12 18:01 skrev Dave Korn: Dave Korn wrote: Why is a -D for _DLL present? That is a reserved definition in the implementation's namespace, Hmmm, I may have misunderstood that. Does -D_DLL mean something special to MSVC, does anyone know? When you compile with shared libc on MSVC (e.g. -MD), it defines _DLL for you. $ cat << EOF > dll.c #ifdef _DLL choke me #endif int foo; EOF $ cl -MD -c dll.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. dll.c dll.c(2) : error C2061: syntax error : identifier 'me' dll.c(2) : error C2059: syntax error : ';' $ cl -c dll.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. dll.c $ Cheers, Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Dave Korn wrote: > Why is a -D for _DLL present? That is a reserved definition in the > implementation's namespace, Hmmm, I may have misunderstood that. Does -D_DLL mean something special to MSVC, does anyone know? cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Dave Korn wrote: > Ok, for some reason it appears that libCore.dll.a exports symbols from > libstdc++: > > dkad...@ubik /work/root/test $ nm /work/root/lib/libCore.dll.a |grep > St9exception 71d6b958 d .rdata$_ZTISt9exception 71d6ff40 d > .rdata$_ZTSSt9exception 71d6b958 D __ZTISt9exception 71d6ff40 D > __ZTSSt9exception > > > Looks like the DLL got linked against static libstdc++, while the app links > against shared libstdc++? Nope, it uses -shared correctly. Nor is the problem down to the auto-export routines failing to recognize libstdc++ and inadvertently re-exporting its symbols (cf. libnamencmp). In fact, the re-exported symbols come from one of the .o files from which the DLL is composed: dkad...@ubik /work/root $ nm core/base/src/TSystem.o | grep St9exception r .rdata$_ZTISt9exception r .rdata$_ZTSSt9exception R __ZTISt9exception R __ZTSSt9exception dkad...@ubik /work/root And the immediate reason for this is the way that TSystem.o is built: build.log g++-4 -O2 -pipe -Wall -Woverloaded-virtual -D_DLL -Iinclude -I/usr/X11R6/include -o core/base/src/TSystem.o -c core/base/src/TSystem.cxx build.log Why is a -D for _DLL present? That is a reserved definition in the implementation's namespace, and in particular it used when compiling libstdc++ itself, where it alters the effect of the library headers to declare all the library APIs as dllexport - they are dllimport by default, which is what user applications want to see. I manually re-ran the compile command without "-D_DLL" and got a good object file: dkad...@ubik /work/root $ g++-4 -O2 -pipe -Wall -Woverloaded-virtual -Iinclude -I/usr/X11R6/include -o ./TSystem.2.o -c core/base/src/TSystem.cxx dkad...@ubik /work/root $ nm ./TSystem.2.o | grep St9exception rtua U __ZTISt9exception dkad...@ubik /work/root $ So I'll now try rebuilding and retesting without _DLL defined anywhere and see if it solves the problem. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Angelo Graziosi wrote: > To test this new version of the compiler I have rebuild ROOT [1]. It > builds fine, but when I try to build its tests, at least one fails in > linking: > d37.o:(.idata$5+0x0): multiple definition of `__imp___ZTISt9exception' > /usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.dll.a(d002074.o):(.idata$5+0x0): > first defined here > d37.o:(.idata$6+0x0): multiple definition of `__nm___ZTISt9exception' > /usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.dll.a(d002074.o):(.idata$6+0x0): > first defined here > d73.o:(.idata$5+0x0): multiple definition of `__imp___ZTISt9exception' > /usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.dll.a(d002074.o):(.idata$5+0x0): > first defined here > d73.o:(.idata$6+0x0): multiple definition of `__nm___ZTISt9exception' > /usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.dll.a(d002074.o):(.idata$6+0x0): > first defined here Ok, for some reason it appears that libCore.dll.a exports symbols from libstdc++: dkad...@ubik /work/root/test $ nm /work/root/lib/libCore.dll.a |grep St9exception 71d6b958 d .rdata$_ZTISt9exception 71d6ff40 d .rdata$_ZTSSt9exception 71d6b958 D __ZTISt9exception 71d6ff40 D __ZTSSt9exception Looks like the DLL got linked against static libstdc++, while the app links against shared libstdc++? That certainly wouldn't be expected to work. I'll take a little look at how ROOT builds its DLLs, hopefully we just need to tweak an LDFLAGS or similar somewhere. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
Angelo Graziosi wrote: > To test this new version of the compiler I have rebuild ROOT [1]. It > builds fine, but when I try to build its tests, at least one fails in > linking: Thanks for the report, I'm looking into it. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
To test this new version of the compiler I have rebuild ROOT [1]. It
builds fine, but when I try to build its tests, at least one fails in
linking:
---
[... many build fine ...]
g++-4 -O -pipe -Wall -Woverloaded-virtual -I/usr/X11R6/include
-D_REENTRANT -I/work/root/include -c stressMathMore.cxx
g++-4 -O -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc
-L/usr/X11R6/lib stressMathMore.o -L/work/root/lib
-Wl,-u,_G__cpp_setupG__Net -Wl,-u,_G__cpp_setupG__IO
-Wl,-u,_G__cpp_setupG__Hist -Wl,-u,_G__cpp_setupG__Graf
-Wl,-u,_G__cpp_setupG__G3D -Wl,-u,_G__cpp_setupG__GPad
-Wl,-u,_G__cpp_setupG__Tree -Wl,-u,_G__cpp_setupG__Thread
-Wl,-u,_G__cpp_setupG__Rint -Wl,-u,_G__cpp_setupG__PostScript
-Wl,-u,_G__cpp_setupG__Matrix -Wl,-u,_G__cpp_setupG__Physics -lCore
-lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint
-lPostscript -lMatrix -lPhysics -lMathCore -lThread -lpthread
-lMathMore -o stressMathMore.exe
stressMathMore.exe done
g++-4 -O -pipe -Wall -Woverloaded-virtual -I/usr/X11R6/include
-D_REENTRANT -I/work/root/include -c stressIterators.cxx
g++-4 -O -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc
-L/usr/X11R6/lib stressIterators.o -L/work/root/lib
-Wl,-u,_G__cpp_setupG__Net -Wl,-u,_G__cpp_setupG__IO
-Wl,-u,_G__cpp_setupG__Hist -Wl,-u,_G__cpp_setupG__Graf
-Wl,-u,_G__cpp_setupG__G3D -Wl,-u,_G__cpp_setupG__GPad
-Wl,-u,_G__cpp_setupG__Tree -Wl,-u,_G__cpp_setupG__Thread
-Wl,-u,_G__cpp_setupG__Rint -Wl,-u,_G__cpp_setupG__PostScript
-Wl,-u,_G__cpp_setupG__Matrix -Wl,-u,_G__cpp_setupG__Physics -lCore
-lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint
-lPostscript -lMatrix -lPhysics -lMathCore -lThread -lpthread -o
stressIterators.exe
d37.o:(.idata$5+0x0): multiple definition of `__imp___ZTISt9exception'
/usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.dll.a(d002074.o):(.idata$5+0x0):
first defined here
d37.o:(.idata$6+0x0): multiple definition of `__nm___ZTISt9exception'
/usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.dll.a(d002074.o):(.idata$6+0x0):
first defined here
d73.o:(.idata$5+0x0): multiple definition of `__imp___ZTISt9exception'
/usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.dll.a(d002074.o):(.idata$5+0x0):
first defined here
d73.o:(.idata$6+0x0): multiple definition of `__nm___ZTISt9exception'
/usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.dll.a(d002074.o):(.idata$6+0x0):
first defined here
collect2: ld returned 1 exit status
make: *** [stressIterators.exe] Error 1
---
To reproduce:
--
cd /
mkdir work
cd work/
wget -N ftp://root.cern.ch/root/root_v5.23.02.source.tar.gz
tar -xzf root_v5.23.02.source.tar.gz
export TMP=/tmp
export TMPDIR=/tmp
export TEMP=/tmp
export ROOTSYS=/work/root
cd root
./configure win32gcc --with-cc=gcc-4 --with-cxx=g++-4 --with-f77=gfortran-4
make -j4
export PATH="${PATH}:/work/root/bin"
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/work/root/lib"
cd test/
make LD='g++-4' all clean
---
It take about 40 minutes on AMD Athlon 2C.
With GCC-4.3.2-1 all worked fine (apart the binaries not completely
stripped, as, perhaps you remember...)
Cheers,
Angelo.
---
[1] http://root.cern.ch
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
