[Bug libstdc++/89044] libstdc++-6.dll is installed in the wrong directory cross-compiling with a multilib configuration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89044 --- Comment #4 from Andoni --- I am sorry for now explaining my self good enough. I am building a GCC toolchain for Windows: a cross-compiler one with Linux as host and a native one with Windows as host. Both toolchains are built in a Linux machine Host:Linux Target:Windows ../configure --prefix /home/andoni/mingw/linux/multilib --libdir /home/andoni/mingw/linux/multilib/lib --disable-maintainer-mode --disable-silent-rules --disable-gtk-doc --disable-introspection --with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm --disable-maintainer-mode--disable-shared --disable-libgomp --disable-libquadmath --disable-libquadmath-support --disable-libmudflap --disable-libmpx --disable-libssp --disable-nls --enable-threads=posix --enable-__cxa_atexit --enable-lto --enable-plugin --enable-multiarch --enable-languages=c,c++ --enable-long-long --with-sysroot=/home/andoni/mingw/linux/multilib/x86_64-w64-mingw32/sysroot --with-local-prefix=/home/andoni/mingw/linux/multilib/x86_64-w64-mingw32/sysroot --target=x86_64-w64-mingw32 --host=x86_64-pc-linux-gnu Host:Windows Target:Windows ../configure --prefix /home/andoni/mingw/windows/multilib --libdir /home/andoni/mingw/windows/multilib/lib --disable-maintainer-mode --disable-silent-rules --disable-gtk-doc --disable-introspection --with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm --disable-maintainer-mode--disable-shared --disable-libgomp --disable-libquadmath --disable-libquadmath-support --disable-libmudflap --disable-libmpx --disable-libssp --disable-nls --enable-threads=posix --enable-__cxa_atexit --enable-lto --enable-plugin --enable-multiarch --enable-languages=c,c++ --enable-long-long --with-sysroot=/home/andoni/mingw/windows/multilib/x86_64-w64-mingw32/sysroot --with-local-prefix=/home/andoni/mingw/windows/multilib/x86_64-w64-mingw32/sysroot --target=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 When cross-compiling the Windows toolchain, libstdc++-6.dll should be installed in lib/ and lib32/ instead of bin, in a similar fashion as the EH dll's, that are installed in lib/libgcc_s_seh-1.dll and lib32/libgcc_s_sjlj-1.dll. Being installed in bin, the x86_64 one is overridden during make install and there is a single dll for x86 installed in bin/
[Bug libstdc++/89044] libstdc++-6.dll is installed in the wrong directory cross-compiling with a multilib configuration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89044 --- Comment #2 from Andoni --- 8.2.0 I updated the version field too.
[Bug libstdc++/89044] New: libstdc++-6.dll is installed in the wrong directory cross-compiling with a multilib configuration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89044 Bug ID: 89044 Summary: libstdc++-6.dll is installed in the wrong directory cross-compiling with a multilib configuration Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ylatuya at gmail dot com Target Milestone: --- When compiling gcc with multilib support for Linux, libstdc++-6.dll ends ups installed correctly in lib and lib32: x86_64-w64-mingw32/lib/libstdc++-6.dll x86_64-w64-mingw32/lib/libstdc++-6.dll Instead, when cross-compilng for Windows a single libstdc++6.dll is installed in the bin dir: bin/libstdc++-6.dll Instead the EH library is correctly installed in lib and lib32: lib/libgcc_s_seh-1.dll lib32/libgcc_s_sjlj-1.dll This also happens for libatomic.
[Bug libgcc/88772] Exception handling configured mode does not match the one finally used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88772 --- Comment #6 from Andoni --- (In reply to Eric Botcazou from comment #5) > > But you said above that the result is "yes" for 32-bit, so how come the test: > > x$ac_cv_sjlj_exceptions = xyes; > > is false? Does it help to rewrite it into just: > > $ac_cv_sjlj_exceptions = yes; > > like in libgcc/configure.ac? I see what you mean. "config.log" do report for 32 bits "ac_cv_sjlj_exceptions=yes" I don't understand why this check fails than. It's either a problem with the order in which it's done (although I checked and it's correct) or an issue in how the value is checked. I will test several option, with quites, without prepending the x, etc... and I will report back.
[Bug libgcc/88772] Exception handling configured mode does not match the one finally used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88772
--- Comment #4 from Andoni ---
(In reply to Eric Botcazou from comment #3)
> > I just wiped the build to start a clean build from scratch, but I remember
> > checking this and it was "no". I can confirm it in ~1 hour
>
> Can you confirm that we're talking about the 32-bit multilib of libgcc here?
> Then, if the answer was "no", we need to understand why. The check is
> simple:
>
> dnl Check if the compiler is configured for setjmp/longjmp exceptions.
> AC_DEFUN([GCC_CHECK_SJLJ_EXCEPTIONS],
> [AC_CACHE_CHECK([whether the compiler is configured for setjmp/longjmp
> exceptions],
> ac_cv_sjlj_exceptions,
> [AC_COMPILE_IFELSE(
> [AC_LANG_PROGRAM(
> [[#ifdef __USING_SJLJ_EXCEPTIONS__
> this will fail
> #endif]],
> [[int i;]])],
> [ac_cv_sjlj_exceptions=no],
> [ac_cv_sjlj_exceptions=yes])])])
>
> Can you run it manually with -m32?
For 64bits the result is "no":
643 configure:4751: checking whether the compiler is configured for
setjmp/longjmp exceptions
644 configure:4769: x86_64-w64-mingw32-gcc
-L/home/andoni/mingw/windows/multilib/x86_64-w64-mingw32/lib
-L/home/andoni/mingw/windows/multilib/mingw/lib -isystem /home
/andoni/mingw/windows/multilib/x86_64-w64-mingw32/include -isystem
/home/andoni/mingw/windows/multilib/mingw/include-c -Wall -g -O2
-DWINVER=0x0600 -D_WIN32_ WINNT=0x0600 conftest.c >&5
645 conftest.c: In function 'main':
646 conftest.c:30:5: warning: unused variable 'i' [-Wunused-variable]
647 int i;
648 ^
649 configure:4769: $? = 0
650 configure:4776: result: no
for 32 bits the result is "yes":
631 configure:4751: checking whether the compiler is configured for
setjmp/longjmp exceptions
632 configure:4769: x86_64-w64-mingw32-gcc
-L/home/andoni/mingw/windows/multilib/x86_64-w64-mingw32/lib
-L/home/andoni/mingw/windows/multilib/mingw/lib -isystem /home
/andoni/mingw/windows/multilib/x86_64-w64-mingw32/include -isystem
/home/andoni/mingw/windows/multilib/mingw/include -m32 -c -Wall -g -O2
-DWINVER=0x0600 -D_WIN 32_WINNT=0x0600 conftest.c >&5
633 conftest.c:25:11: error: unknown type name 'this'
634this will fail
635^~~~
636 conftest.c:25:21: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'fail'
637this will fail
638 ^~~~
639 configure:4769: $? = 1
[...]
674 configure:4776: result: yes
For 32 bits the final EH model being used is Dwarf2:
340 # Additional sources to handle exceptions; overridden by targets as needed.
341 LIB2ADDEH = $(srcdir)/unwind-dw2.c $(srcdir)/unwind-dw2-fde.c \
342 $(srcdir)/unwind-sjlj.c $(srcdir)/unwind-c.c
What I understand is happening in a multilib build is that for 64 it chooses
SEH because ac_cv_sjlj_exceptions is not "yes" but for 32, it chooses dw2
instead of SJLJ for the same reason, because ac_cv_sjlj_exceptions is not
"yes":
if test x$ac_cv_sjlj_exceptions = xyes; then
tmake_eh_file="i386/t-sjlj-eh"
elif test "${host_address}" = 32; then
# biarch -m32 with --disable-sjlj-exceptions
tmake_eh_file="i386/t-dw2-eh"
md_unwind_header=i386/w32-unwind.h
else
tmake_eh_file="i386/t-seh-eh"
fi
What should happen in a mutilib build is that if the user configured without
passing any specific options for EH, the 32 bits target should be forced to be
configured with --enable-sjlj-exceptions.
[Bug libgcc/88772] Exception handling configured mode does not match the one finally used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88772 --- Comment #2 from Andoni --- (In reply to Eric Botcazou from comment #1) > What's the result of the configure check of libgcc for SJLJ? It should be > visible in the config.log file in the libgcc build directory: > > whether the compiler is configured for setjmp/longjmp exceptions... I just wiped the build to start a clean build from scratch, but I remember checking this and it was "no". I can confirm it in ~1 hour
[Bug libgcc/88772] New: Exception handling configured mode does not match the one finally used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88772
Bug ID: 88772
Summary: Exception handling configured mode does not match the
one finally used
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: ylatuya at gmail dot com
Target Milestone: ---
I am building a multilib GCC+MinGW toolchain targeting Windows. I have built
the cross toolchain, which compiled and works correctly and I am now trying to
build the native one.
The cross toolchain is configured with:
../configure --prefix /home/andoni/mingw/linux/w64 --libdir
/home/andoni/mingw/linux/w64/lib --enable-introspection
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--disable-shared --disable-libgomp --disable-libquadmath
--disable-libquadmath-support --disable-libmudflap --disable-libmpx
--disable-libssp --disable-nls --enable-threads=posix --enable-__cxa_atexit
--enable-lto --enable-plugin --enable-multiarch --enable-languages=c,c++
--enable-long-long
--with-sysroot=/home/andoni/mingw/linux/w64/x86_64-w64-mingw32/sysroot
--with-local-prefix=/home/andoni/mingw/linux/w64/x86_64-w64-mingw32/sysroot
--target=x86_64-w64-mingw32
The native toolchain is configured with the same settings, only changing the
host:
../configure --prefix /home/andoni/mingw/windows/w64 --libdir
/home/andoni/mingw/windows/w64/lib --disable-introspection
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--disable-shared --disable-libgomp --disable-libquadmath
--disable-libquadmath-support --disable-libmudflap --disable-libmpx
--disable-libssp --disable-nls --enable-threads=posix --enable-__cxa_atexit
--enable-lto --enable-plugin --enable-multiarch --enable-languages=c,c++
--enable-long-long
--with-sysroot=/home/andoni/mingw/windows/w64/x86_64-w64-mingw32/sysroot
--with-local-prefix=/home/andoni/mingw/windows/w64/x86_64-w64-mingw32/sysroot
--target=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
I none of them I force SJLJ or disable it, so from the documentation and the
headers it should be using SEH for 64 bits and SJLJ for 32 bits:
gcc/config/i386/cygming.h
369 /* If configured with --disable-sjlj-exceptions, use DWARF2 for 32-bit
370mode else default to SJLJ. 64-bit code uses SEH unless you request
371SJLJ. */
But what happens is that it ends up using i386/t-dw2-eh instead of
i386/t-seh-eh
and there is compilation error:
../../../../libgcc/unwind.inc: In function '_Unwind_RaiseException_Phase2':
../../../../libgcc/unwind.inc:53:62: error: 'struct _Unwind_Exception' has no
member named 'private_2'; did you mean 'private_'?
match_handler = (uw_identify_context (context) == exc->private_2
The error seems to be in the switch case for x86_64-mingw32 in
libgcc/config.host:
762 > # This has to match the logic for DWARF2_UNWIND_INFO in
gcc/config/i386/cygming.h
763 > if test x$ac_cv_sjlj_exceptions = xyes; then
764 > > tmake_eh_file="i386/t-sjlj-eh"
765 > elif test "${host_address}" = 32; then
766 > # biarch -m32 with --disable-sjlj-exceptions
767 >> tmake_eh_file="i386/t-dw2-eh"
768 > > md_unwind_header=i386/w32-unwind.h
769 > else
770 > > tmake_eh_file="i386/t-seh-eh"
771 > fi
^
private_
[Bug libstdc++/57212] New: Don't use pe-coff weak support with mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57212 Bug #: 57212 Summary: Don't use pe-coff weak support with mingw Classification: Unclassified Product: gcc Version: 4.7.4 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ylat...@gmail.com The issue was addressed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52300, but it's missing a replacement in the generated header in libstdc++. The generated gthr.h checks for _GLIBCXX___MINGW32_GLIBCXX___ instead of __MINGW32__ #if __GXX_WEAK__ /* The pe-coff weak support isn't fully compatible to ELF's weak. For static libraries it might would work, but as we need to deal with shared versions too, we disable it for mingw-targets. */ #ifdef _GLIBCXX___MINGW32_GLIBCXX___ #undef _GLIBCXX_GTHREAD_USE_WEAK #define _GLIBCXX_GTHREAD_USE_WEAK 0 #endif
[Bug libstdc++/57212] Don't use pe-coff weak support with mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57212 --- Comment #1 from Andoni ylatuya at gmail dot com 2013-05-08 13:40:46 UTC --- Created attachment 30056 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30056 Fix libstdc threads for mingw
[Bug libstdc++/57212] Don't use pe-coff weak support with mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57212 Andoni ylatuya at gmail dot com changed: What|Removed |Added Attachment #30056|0 |1 is obsolete|| --- Comment #2 from Andoni ylatuya at gmail dot com 2013-05-08 13:42:11 UTC --- Created attachment 30057 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30057 Fix define for mingw Sorry, I uploaded the wrong patch :)
