[Bug libstdc++/108027] New: mcf thread model causes build issues for x86_64-w64-mingw32 multilibs

[Bug libstdc++/108027] New: mcf thread model causes build issues for x86_64-w64-mingw32 multilibs

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027

            Bug ID: 108027
           Summary: mcf thread model causes build issues for
                    x86_64-w64-mingw32 multilibs
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 54051
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54051&action=edit
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

[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027

--- Comment #1 from LIU Hao <lh_mouse at 126 dot com> ---
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.

[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027

--- Comment #2 from cqwrteur <unlvsur at live dot com> ---
(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?

[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027

--- Comment #3 from cqwrteur <unlvsur at live dot com> ---
(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

[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027

--- Comment #4 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027

--- Comment #5 from cqwrteur <unlvsur at live dot com> ---
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

[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027

--- Comment #6 from LIU Hao <lh_mouse at 126 dot com> ---
That's not a GCC bug. That's because you have installed libraries to the
default but wrong location.

[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027

--- Comment #7 from LIU Hao <lh_mouse at 126 dot com> ---
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).

[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027

--- Comment #8 from cqwrteur <unlvsur at live dot com> ---
(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

[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027

--- Comment #9 from LIU Hao <lh_mouse at 126 dot com> ---
(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.

[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027

--- Comment #10 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027

--- Comment #11 from LIU Hao <lh_mouse at 126 dot com> ---
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.

[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027

--- Comment #12 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027

--- Comment #13 from cqwrteur <unlvsur at live dot com> ---
(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