[Bug bootstrap/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427 --- Comment #13 from cqwrteur --- (In reply to cqwrteur from comment #12) > (In reply to nightstrike from comment #10) > > (In reply to cqwrteur from comment #5) > > > I think the copy to bin behavior should be removed. It should be just like > > > normal linux distribution. 64 bit dlls in lib. 32 bit dlls in lib32. > > > > This is a feature of Windows. Windows will find dlls in PATH, not in lib > > directories. > > > > Multilib toolchains do face issues with versioned runtime libraries. You > > can try configuring with --enable-version-specific-runtime-libs. Generally > > speaking, it's easier to just build two separate toolchains than to try > > getting multilib to work. I made the mistake of pushing for multilib to be > > enabled by default, and we never got it working quite well. > > > > Anyway, I don't think this is a bug as stated. > > yes this is a bug. because I can fix it easily. > > You are wrong. Because cross toolchain for multilib would put DLLs in the > lib and lib32, not bin https://github.com/cppfastio/fast_io/blob/master/examples/0009.filesystem/gccx86canadianfix.cc
[Bug bootstrap/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427 --- Comment #12 from cqwrteur --- (In reply to nightstrike from comment #10) > (In reply to cqwrteur from comment #5) > > I think the copy to bin behavior should be removed. It should be just like > > normal linux distribution. 64 bit dlls in lib. 32 bit dlls in lib32. > > This is a feature of Windows. Windows will find dlls in PATH, not in lib > directories. > > Multilib toolchains do face issues with versioned runtime libraries. You > can try configuring with --enable-version-specific-runtime-libs. Generally > speaking, it's easier to just build two separate toolchains than to try > getting multilib to work. I made the mistake of pushing for multilib to be > enabled by default, and we never got it working quite well. > > Anyway, I don't think this is a bug as stated. yes this is a bug. because I can fix it easily. You are wrong. Because cross toolchain for multilib would put DLLs in the lib and lib32, not bin
[Bug bootstrap/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427 --- Comment #11 from nightstrike --- Possible duplicate of PR39947
[Bug bootstrap/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #10 from nightstrike --- (In reply to cqwrteur from comment #5) > I think the copy to bin behavior should be removed. It should be just like > normal linux distribution. 64 bit dlls in lib. 32 bit dlls in lib32. This is a feature of Windows. Windows will find dlls in PATH, not in lib directories. Multilib toolchains do face issues with versioned runtime libraries. You can try configuring with --enable-version-specific-runtime-libs. Generally speaking, it's easier to just build two separate toolchains than to try getting multilib to work. I made the mistake of pushing for multilib to be enabled by default, and we never got it working quite well. Anyway, I don't think this is a bug as stated.
[Bug bootstrap/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427 --- Comment #9 from Jonathan Wakely --- (In reply to cqwrteur from comment #8) > LOL. it bloats my mind. WHY WHY WHY are > > # DLL is installed to $(libdir)/../bin by postinstall_cmds > > Twice in libstdc++'s configure? Because it includes other .m4 files which include libtool.m4 twice. Why is it a problem? > We need a full-on cleanup on GCC source, please. That isn't going to happen unless somebody volunteers to do it.
