Created attachment 54051 [details] config.log and build logs undefined reference to `__MCF_cxa_thread_atexit' collect2: error: ld returned 1 exit status make[9]: *** [Makefile:751: libstdc++.la] Error 1 make[8]: *** [Makefile:784: all-recursive] Error 1 make[7]: *** [Makefile:576: all-recursive] Error 1 make[6]: *** [Makefile:501: all] Error 2 make[5]: *** [Makefile:870: multi-do] Error 1 make[4]: *** [Makefile:840: all-multi] Error 2 make[3]: *** [Makefile:576: all-recursive] Error 1 make[2]: *** [Makefile:501: all] Error 2 make[1]: *** [Makefile:13906: all-target-libstdc++-v3] Error 2 make: *** [Makefile:1029: all] Error 2
I need some information about this though: When multilib is enabled, does GCC still link programs with `-lmsvcrt`? There seems to be only reference to msvcrt: gcc/config/i386/mingw32.h:187: -lmoldname -lmingwex -lmsvcrt -lkernel32 " MCFGTHREAD_SPEC which is followed by `MCFGTHREAD_SPEC`. If GCC links against libmcfgthread in both m32 and m64, then I suspect there is only one issue: You forgot to install mcfgthread. I don't know whether libtool has builtin macros for multilib builds; by default libraries are installed into `<prefix>/lib` and you have to copy them into `<prefix>/lib32` and `<prefix>/lib64`, respectively.
(In reply to LIU Hao from comment #1) > I need some information about this though: > > > When multilib is enabled, does GCC still link programs with `-lmsvcrt`? > There seems to be only reference to msvcrt: > > gcc/config/i386/mingw32.h:187: -lmoldname -lmingwex -lmsvcrt -lkernel32 > " MCFGTHREAD_SPEC > > which is followed by `MCFGTHREAD_SPEC`. > > > If GCC links against libmcfgthread in both m32 and m64, then I suspect there > is only one issue: You forgot to install mcfgthread. I don't know whether > libtool has builtin macros for multilib builds; by default libraries are > installed into `<prefix>/lib` and you have to copy them into > `<prefix>/lib32` and `<prefix>/lib64`, respectively. I do install mcfgthread. Yes. I do both of them. The problem is that libtool will incorrectly link to lib/libmcfgthread.la even lib32/libmcfgthread.la and lib/32/libmcfgthread.la exist. Can you just remove the .la file?
(In reply to cqwrteur from comment #2) > (In reply to LIU Hao from comment #1) > > I need some information about this though: > > > > > > When multilib is enabled, does GCC still link programs with `-lmsvcrt`? > > There seems to be only reference to msvcrt: > > > > gcc/config/i386/mingw32.h:187: -lmoldname -lmingwex -lmsvcrt -lkernel32 > > " MCFGTHREAD_SPEC > > > > which is followed by `MCFGTHREAD_SPEC`. > > > > > > If GCC links against libmcfgthread in both m32 and m64, then I suspect there > > is only one issue: You forgot to install mcfgthread. I don't know whether > > libtool has builtin macros for multilib builds; by default libraries are > > installed into `<prefix>/lib` and you have to copy them into > > `<prefix>/lib32` and `<prefix>/lib64`, respectively. > > I do install mcfgthread. Yes. I do both of them. The problem is that libtool > will incorrectly link to lib/libmcfgthread.la even lib32/libmcfgthread.la > and lib/32/libmcfgthread.la exist. > Can you just remove the .la file? It finally gets to work by manually replacing all lib/libmcfgthread.la to lib32/libmcfgthread.la in 32 multilibs. I do not even think you ever tried how to build multilibs. If you want details, you can join QQ group 801441303
(In reply to cqwrteur from comment #3) > (In reply to cqwrteur from comment #2) > > (In reply to LIU Hao from comment #1) > > > I need some information about this though: > > > > > > > > > When multilib is enabled, does GCC still link programs with `-lmsvcrt`? > > > There seems to be only reference to msvcrt: > > > > > > gcc/config/i386/mingw32.h:187: -lmoldname -lmingwex -lmsvcrt -lkernel32 > > > " MCFGTHREAD_SPEC > > > > > > which is followed by `MCFGTHREAD_SPEC`. > > > > > > > > > If GCC links against libmcfgthread in both m32 and m64, then I suspect there > > > is only one issue: You forgot to install mcfgthread. I don't know whether > > > libtool has builtin macros for multilib builds; by default libraries are > > > installed into `<prefix>/lib` and you have to copy them into > > > `<prefix>/lib32` and `<prefix>/lib64`, respectively. > > > > I do install mcfgthread. Yes. I do both of them. The problem is that libtool > > will incorrectly link to lib/libmcfgthread.la even lib32/libmcfgthread.la > > and lib/32/libmcfgthread.la exist. > > Can you just remove the .la file? > > It finally gets to work by manually replacing all lib/libmcfgthread.la to > lib32/libmcfgthread.la in 32 multilibs. > > I do not even think you ever tried how to build multilibs. If you want > details, you can join QQ group 801441303 I do not think it is the problem of libstdc++ itself. It is probably your code has issues.
built toolchain demo. (this is canadian compilation. What I showed was cross one.) https://github.com/trcrsired/x86_64-w64-mingw32-with-mcf-thread-model-native-toolchain
That's not a GCC bug. That's because you have installed libraries to the default but wrong location.
The .la files generated by libtool are usually nonsense (https://fedoraproject.org/wiki/Changes/RemoveLaFiles). If you run `make install` by hand then you may delete them by hand. Some packagers (e.g. makepkg on Arch Linux and MSYS2) purge them before packaging so they can never get installed, but some don't (e.g. dpkg-deb on Debian).
(In reply to LIU Hao from comment #7) > The .la files generated by libtool are usually nonsense > (https://fedoraproject.org/wiki/Changes/RemoveLaFiles). If you run `make > install` by hand then you may delete them by hand. Some packagers (e.g. > makepkg on Arch Linux and MSYS2) purge them before packaging so they can > never get installed, but some don't (e.g. dpkg-deb on Debian). if I delete them by hand, then gcc could not build anymore since build scripts of libstdc++ would complain .la do not exist
(In reply to cqwrteur from comment #8) > if I delete them by hand, then gcc could not build anymore since build > scripts of libstdc++ would complain .la do not exist No library in MSYS2 has been installed with .la files because they are never necessary.
(In reply to LIU Hao from comment #9) > (In reply to cqwrteur from comment #8) > > if I delete them by hand, then gcc could not build anymore since build > > scripts of libstdc++ would complain .la do not exist > > No library in MSYS2 has been installed with .la files because they are never > necessary. i do not even understand why you are talking about msys2. I do Canadian compilation on linux. Cross compiling mcfgthread on Linux. This has nothing to do with msys2. I do not use msys2.
It has nothing to do with MSYS2. MSYS2 is merely an example to show that .la files are not necessary and should not be installed.
(In reply to LIU Hao from comment #11) > It has nothing to do with MSYS2. MSYS2 is merely an example to show that .la > files are not necessary and should not be installed. but your build scripts do that.
(In reply to cqwrteur from comment #12) > (In reply to LIU Hao from comment #11) > > It has nothing to do with MSYS2. MSYS2 is merely an example to show that .la > > files are not necessary and should not be installed. > > but your build scripts do that. I would even argue cmake would be better than autotool for you mcfgthread