[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #25 from James McKelvey --- I just tried the latest snapshot and it works great, no need to specify --disable-multilib.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #24 from Jakub Jelinek --- Fixed.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #23 from CVS Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:e3f8dfcd885d19d322b10fb4e36d50b60da2576b
commit r13-6578-ge3f8dfcd885d19d322b10fb4e36d50b60da2576b
Author: Jakub Jelinek
Date: Wed Feb 22 10:25:04 2023 +0100
cygwin: Don't try to support multilibs [PR107998]
As discussed in the PR, t-cygwin-w64 file has been introduced in 2013
and has one important problem, two different multilib options -m64 and
-m32,
but MULTILIB_DIRNAMES with just one word in it.
Before the genmultilib sanity checking was added, my understanding is that
this essentially resulted in effective --disable-multilib,
$ gcc -print-multi-lib
.;
;@m32
$ gcc -print-multi-directory
.
$ gcc -print-multi-directory -m64
.
$ gcc -print-multi-directory -m32
$ gcc -print-multi-os-directory
../lib
$ gcc -print-multi-os-directory -m64
../lib
$ gcc -print-multi-os-directory -m32
../lib32
and because of the way e.g. config-ml.in operates
multidirs=
for i in `${CC-gcc} --print-multi-lib 2>/dev/null`; do
dir=`echo $i | sed -e 's/;.*$//'`
if [ "${dir}" = "." ]; then
true
else
if [ -z "${multidirs}" ]; then
multidirs="${dir}"
else
multidirs="${multidirs} ${dir}"
fi
fi
done
dir was . first time (and so nothing was done) and empty
second time, multidirs empty too, so multidirs was set to empty
like it would be with --disable-multilib.
With the added sanity checking the build fails unless --disable-multilib
is used in configure (dunno whether people usually configure that way
on cygwin).
>From what has been said in the PR, multilibs were not meant to be
supported
and e.g. cygwin headers probably aren't ready for it.
So the following patch just removes the file with the (incorrect) multilib
stuff instead of fixing it (say by setting MULTILIB_DIRNAMES to 64 32).
I have no way to test this though, no Windows around, can anyone please
test this? I just would like to get some progress on the P1s we have...
2023-02-22 Jakub Jelinek
gcc/ChangeLog:
PR target/107998
* config.gcc (x86_64-*-cygwin*): Don't add i386/t-cygwin-w64 into
$tmake_file.
* config/i386/t-cygwin-w64: Remove.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #22 from Jakub Jelinek --- Created attachment 54502 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54502=edit gcc13-pr107998.patch Let's go with this patch then? Note, I can't really test it.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #21 from Jakub Jelinek --- If so, then I don't understand why does t-cygwin-w64 exist.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #20 from jon_y <10walls at gmail dot com> --- No, Cygwin does not use fat objects/archives. As far as I know, Cygwin never shipped multilib capable gcc.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #19 from Jakub Jelinek ---
I don't know either. Maybe objdump would print something.
Anyway, looking at config-ml.in, it seems like the empty directory name would
basically
disable that multilib:
multidirs=
for i in `${CC-gcc} --print-multi-lib 2>/dev/null`; do
dir=`echo $i | sed -e 's/;.*$//'`
if [ "${dir}" = "." ]; then
true
else
if [ -z "${multidirs}" ]; then
multidirs="${dir}"
else
multidirs="${multidirs} ${dir}"
fi
fi
done
I think for
.;
;@m32
the above first sets dir to "." and doesn't do anything, in the second
iteration
dir is empty string and as multidirs is empty as well, it is set to the same
empty
string.
So I think previously x86_64-pc-cygwin just didn't build multilibs at all, but
supported -m32 for compilation and would do weird things when trying to link
something.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #18 from James McKelvey --- I don't know. How do I tell? I'm pretty sure they are just 64-bit.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #17 from Jakub Jelinek --- And those are libraries containing 64-bit objects, 32-bit objects, mixture of that (FAT objects)?
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #16 from James McKelvey --- $ find /usr/local/lib/gcc -name libgcc_s\*.dll -o -name libgcc.a /usr/local/lib/gcc/x86_64-pc-cygwin/11.3.1/libgcc.a /usr/local/lib/gcc/x86_64-pc-cygwin/12.1.1/libgcc.a /usr/local/lib/gcc/x86_64-pc-cygwin/12.2.0/libgcc.a /usr/local/lib/gcc/x86_64-pc-cygwin/12.2.1/libgcc.a /usr/local/lib/gcc/x86_64-pc-cygwin/13.0.0/libgcc.a /usr/local/lib/gcc/x86_64-pc-cygwin/13.0.1/libgcc.a
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #15 from Jakub Jelinek --- (In reply to James McKelvey from comment #14) > Okay I installed gcc-12, built about 10/29/2022: > > $ g++ -v > Using built-in specs. > COLLECT_GCC=g++ > COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-cygwin/12.2.1/lto- > wrapper.exe > Target: x86_64-pc-cygwin > Configured with: ./configure --enable-languages=c,c++ --enable-threads=posix > Thread model: posix > Supported LTO compression algorithms: zlib zstd > gcc version 12.2.1 20221029 (GCC) > > $ cat gcc/config/i386/t-cygwin-w64 > MULTILIB_OPTIONS = m64/m32 > MULTILIB_DIRNAMES = 64 > MULTILIB_OSDIRNAMES = ../lib ../lib32 > > $ gcc -print-multi-lib > .; > ;@m32 > > $ gcc -print-multi-directory > . > > $ gcc -print-multi-directory -m64 > . > > $ gcc -print-multi-directory -m32 > > > $ gcc -print-multi-os-directory > ../lib > > $ gcc -print-multi-os-directory -m64 > ../lib > > $ gcc -print-multi-os-directory -m32 > ../lib32 That matches what I got from a cross-compiler. I think what is more interesting is where e.g. the libraries in the build or installed tree are. Say on x86_64-linux in the build directory I have find gcc -name libgcc_s.so.\* -o -name libgcc.a gcc/libgcc.a gcc/32/libgcc.a gcc/32/libgcc_s.so.1 gcc/libgcc_s.so.1 What do you get with find gcc -name libgcc_s\*.dll -o -name libgcc.a ?
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #14 from James McKelvey --- Okay I installed gcc-12, built about 10/29/2022: $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-cygwin/12.2.1/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: ./configure --enable-languages=c,c++ --enable-threads=posix Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.1 20221029 (GCC) $ cat gcc/config/i386/t-cygwin-w64 MULTILIB_OPTIONS = m64/m32 MULTILIB_DIRNAMES = 64 MULTILIB_OSDIRNAMES = ../lib ../lib32 $ gcc -print-multi-lib .; ;@m32 $ gcc -print-multi-directory . $ gcc -print-multi-directory -m64 . $ gcc -print-multi-directory -m32 $ gcc -print-multi-os-directory ../lib $ gcc -print-multi-os-directory -m64 ../lib $ gcc -print-multi-os-directory -m32 ../lib32
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #13 from Jakub Jelinek ---
I have tried a cross with the genmultilib exit 1 commented out, and the
difference between the previous state of just MULTILIB_DIRNAMES = 64 and 64 32
is
--- multilib.h 2023-02-01 18:41:31.013661359 +0100
+++ multilib.h 2023-02-01 18:43:33.950857507 +0100
@@ -1,7 +1,7 @@
static const char *const multilib_raw[] = {
". !m64 !m32;",
"64:../lib m64 !m32;",
-":../lib32 !m64 m32;",
+"32:../lib32 !m64 m32;",
NULL
};
With the former, ./xgcc -B -print-multi-lib prints
.;
;@m32
and
-print-multi-directory
-print-multi-directory -m64
print
.
and
-print-multi-directory -m32
prints just an empty line.
I can't see how that could have every worked. So, I think the 64 32 patch is
right
and I assume everybody who was configuring for x86_64-w64-cygwin had to be
using --disable-multilib, otherwise I really wonder how it could actually work.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- Any progress here? It would be nice to know where did cygwin without --disable-multilib install the 64-bit and 32-bit libraries, say in gcc 12 or before Christophe's changes on the trunk see what gcc -print-multi-lib and gcc -print-multi-directory and gcc -print-multi-directory -m64 and gcc -print-multi-directory -m32 and gcc -print-multi-os-directory and gcc -print-multi-os-directory -m64 and gcc -print-multi-os-directory -m32 printed, what does trunk with the --- gcc/config/i386/t-cygwin-w642020-01-12 11:54:36.333414616 +0100 +++ gcc/config/i386/t-cygwin-w642023-02-01 18:24:34.771591906 +0100 @@ -1,3 +1,3 @@ MULTILIB_OPTIONS = m64/m32 -MULTILIB_DIRNAMES = 64 +MULTILIB_DIRNAMES = 64 32 MULTILIB_OSDIRNAMES = ../lib ../lib32 patch do.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #11 from James McKelvey --- (In reply to Christophe Lyon from comment #10) > Can you try to revert my patches: > f0d3b6e384a68f8b58bc750f240a15cad92600cd > ccb9c7b129206209cfc315ab1a0432b5f517bdd9 > and remove your patch at comment #5 ? > You should still see the problem you reported in bug #108011 > > > However, I don't understand why you had to do what you describe in comment > #8. When multilibs are disabled, the build shouldn't try to use > MULTILIB_OPTIONS etc... Sorry, I don't use git. I just build from the weekly snapshots. I double-checked by removing the fix, make distclean, and ./configure --enable-languages=c,c++ --enable-threads=posix --disable-multilib and got the same error.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #10 from Christophe Lyon --- Can you try to revert my patches: f0d3b6e384a68f8b58bc750f240a15cad92600cd ccb9c7b129206209cfc315ab1a0432b5f517bdd9 and remove your patch at comment #5 ? You should still see the problem you reported in bug #108011 However, I don't understand why you had to do what you describe in comment #8. When multilibs are disabled, the build shouldn't try to use MULTILIB_OPTIONS etc...
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||10walls at gmail dot com Last reconfirmed||2022-12-21 Priority|P3 |P1 Ever confirmed|0 |1 --- Comment #9 from Richard Biener --- Please try to work together to fix the build issue.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #8 from James McKelvey --- Okay I backed out the fix to t-cygwin-w64 and tried to build again with --disable-multilib and stil got the "no dirname" error. So that fix is definitely needed.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #7 from James McKelvey --- That fix let the build proceed until it hit a #error much later. See 108011. Cygwin seems to be removing support for 32-bit, so although multilib has built for years, it won't anymore. That's my take. I'm not an expert on Cygwin or g++, I just build gcc-13 every snapshot and report bugs.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #6 from Christophe Lyon --- (In reply to James McKelvey from comment #5) > This works: > > $ diff gcc/config/i386/t-cygwin-w64~ gcc/config/i386/t-cygwin-w64 > 2c2 > < MULTILIB_DIRNAMES = 64 > --- > > MULTILIB_DIRNAMES = 64 32 I guess this has an impact on the multilib layout (dirnames changes), is that OK? Did you understand how the build succeeded previously? Is there a risk to break other packages depending on this one?
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #5 from James McKelvey --- This works: $ diff gcc/config/i386/t-cygwin-w64~ gcc/config/i386/t-cygwin-w64 2c2 < MULTILIB_DIRNAMES = 64 --- > MULTILIB_DIRNAMES = 64 32
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #4 from Christophe Lyon --- Indeed my patch aimed at catching such inconsistencies. I guess before that the build had a 'strange' behavior? (with a missing dirname, some parts of the shell genmultilib shell script would expand into empty values, probably leading to unintended behaviour)
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Component|bootstrap |target CC||clyon at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- MULTILIB_OPTIONS = m64/m32 MULTILIB_DIRNAMES = 64 MULTILIB_OSDIRNAMES = ../lib ../lib32 Hmmm, the fix is obviously just add 32 to MULTILIB_DIRNAMES . https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606887.html
