In gcc 4.7, both static and shared libstdc++ build: i686-w64-mingw32/lib/libstdc++.a x86_64-w64-mingw32/lib/libstdc++.a i686-w64-mingw32/lib/libstdc++-6.dll x86_64-w64-mingw32/lib/libstdc++-6.dll But in gcc 4.8, no shared libstdc++ build anymore, only got static build: lib/libstdc++.a
Kai, can you please help triaging this?
Hmm, I can't reproduce that. I just built things myself again for 4.8.1 gcc. I am a bit curious to read that due distributions like Fedora seem to be able to build stuff without isssues for 4.8.x gcc. First advice would be to look into libstdc++'s config.log to see why for you shared library isn't built. Second question is how you are actual configuring it, and what additional patches you might use on built?
Created attachment 29979 [details] x86_64-w64-mingw32/libstdc++-v3/config.log
Created attachment 29980 [details] gcc/config.log
(In reply to comment #2) > Hmm, I can't reproduce that. I just built things myself again for 4.8.1 gcc. > I am a bit curious to read that due distributions like Fedora seem to be able > to build stuff without isssues for 4.8.x gcc. > First advice would be to look into libstdc++'s config.log to see why for you > shared library isn't built. Second question is how you are actual configuring > it, and what additional patches you might use on built? No additional patches applied. Here is my build cfg: $ /home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/configure --prefix=/home/cauchy/cross/x86_64-windows --with-sysroot=/home/cauchy/cross/x86_64-windows --target=x86_64-w64-mingw32 --enable-targets=all --disable-nls --enable-checking=release --enable-languages=c,c++,fortran --with-arch=x86-64 --with-tune=generic --with-fpmath=sse Please see attachments for config.log
OOPS, not RESOLVED.
Hmm, only issue I see is the use of '--disable-nls' option, which is known to cause issue. See here PR 54659. Another question I have is, what mingw-w64 header-set,crt you are using? You will need for >= 4.8.x gcc version actual trunk version. I looked through the config.log and don't see anything showing that shared-version doesn't work, so I assume the underlying issue you see is PR 54659.
(In reply to comment #7) > Hmm, only issue I see is the use of '--disable-nls' option, which is known to > cause issue. See here PR 54659. > > Another question I have is, what mingw-w64 header-set,crt you are using? You > will need for >= 4.8.x gcc version actual trunk version. > Yes, I use mingw-w64 trunk. > I looked through the config.log and don't see anything showing that > shared-version doesn't work, so I assume the underlying issue you see is PR > 54659. OK, I will try without '--disable-nls' option.
Created attachment 29981 [details] gcc/config-v2.log
Created attachment 29982 [details] i686-w64-mingw32/libstdc++-v3/config-v2.log
Please see gcc/config-v2.log and i686-w64-mingw32/libstdc++-v3/config-v2.log, still not build libstdc++-6.dll
Hmm, I don't see in config.log any difference to the variant I have built on my box. Shared is actual enabled in you config.log for libstdc++-v3. So DLL should be built, if you don't have a build error. For me 32-bit and 64-bit w64 version builds OOTB without any issue. You are building multilib as I see, so do you have 32-bit and 64-bit setuped too? Could you check if there is for real no dll built by executing within your libstdc++-v3 build-directory the command 'find ./* -name "*.dll" -print'?
(In reply to comment #12) > Hmm, I don't see in config.log any difference to the variant I have built on my > box. Shared is actual enabled in you config.log for libstdc++-v3. So DLL > should be built, if you don't have a build error. > For me 32-bit and 64-bit w64 version builds OOTB without any issue. > You are building multilib as I see, so do you have 32-bit and 64-bit setuped > too? Could you check if there is for real no dll built by executing within > your libstdc++-v3 build-directory the command 'find ./* -name "*.dll" -print'? Yes, I build x86_64-w64-mingw32 with multilib, i686-w64-mingw32 without multilib (due to binutils trunk regress), both do not generate libstdc++-6.dll: ~/obj/i686-w64-mingw32/gcc$ find ./* -name "*.dll" -print ./gcc/home/cauchy/cross/i686-windows/i686-w64-mingw32/lib/libgcc_s_sjlj-1.dll ./i686-w64-mingw32/libgcc/shlib/libgcc_s_sjlj-1.dll ./i686-w64-mingw32/libssp/.libs/libssp-0.dll ./i686-w64-mingw32/libquadmath/.libs/libquadmath-0.dll ./i686-w64-mingw32/libgfortran/.libs/libgfortran-3.dll ~/obj/x86_64-w64-mingw32/gcc$ find ./* -name "*.dll" -print ./gcc/home/cauchy/cross/x86_64-windows/x86_64-w64-mingw32/lib/libgcc_s_seh-1.dll ./gcc/home/cauchy/cross/x86_64-windows/x86_64-w64-mingw32/lib32/libgcc_s_sjlj-1.dll ./x86_64-w64-mingw32/libgcc/shlib/libgcc_s_seh-1.dll ./x86_64-w64-mingw32/32/libgcc/32/shlib/libgcc_s_sjlj-1.dll ./x86_64-w64-mingw32/32/libssp/.libs/libssp-0.dll ./x86_64-w64-mingw32/32/libquadmath/.libs/libquadmath-0.dll ./x86_64-w64-mingw32/32/libgfortran/.libs/libgfortran-3.dll ./x86_64-w64-mingw32/libssp/.libs/libssp-0.dll ./x86_64-w64-mingw32/libquadmath/.libs/libquadmath-0.dll ./x86_64-w64-mingw32/libgfortran/.libs/libgfortran-3.dll
Does this problem still exists for you with current 4.7 branch? For me recent bootstrap multilib 64-bit, and 32-bit are working without issues on 4.7.x
gcc 4.7.x never have such issue. for gcc 4.8.x or trunk, I did not build multilib long ago. because I can not build multilib which x64 use SEH, and x86 use SJLJ. I must build with SJLJ for x64 and x86.
Hmm, this issue seems to be fixed. I close this bug. Please don't hesitate to open new bug for it, iff issue still exists.