[Bug c++/107998] New: [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

[Bug c++/107998] New: [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

[mckelvey at maskull dot com]

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

            Bug ID: 107998
           Summary: [13 Regression] gcc-13-20221204 failure to build on
                    Cygwin No dirname for option: m32
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mckelvey at maskull dot com
  Target Milestone: ---

Created attachment 54031
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54031&action=edit
Build log

This worked two snapshots ago.

make[3]: Entering directory
'/home/McKelvey/gcc-13-20221204/host-x86_64-pc-cygwin/gcc'
if test yes = yes \
   || test -n "../lib ../lib32"; then \
  /bin/sh ../.././gcc/genmultilib \
    "m64/m32" \
    "64" \
    "" \
    "" \
    "" \
    "" \
    "../lib ../lib32" \
    "" \
    "" \
    "" \
    "yes" \
    > tmp-mlib.h; \
else \
  /bin/sh ../.././gcc/genmultilib '' '' '' '' '' '' '' '' \
    "" '' no \
    > tmp-mlib.h; \
fi
Error calling ../.././gcc/genmultilib: No dirname for option: m32
make[3]: *** [Makefile:2241: s-mlib] Error 1
make[3]: Leaving directory
'/home/McKelvey/gcc-13-20221204/host-x86_64-pc-cygwin/gcc'
make[2]: *** [Makefile:4934: all-stage1-gcc] Error 2
make[2]: Leaving directory '/home/McKelvey/gcc-13-20221204'
make[1]: *** [Makefile:23894: stage1-bubble] Error 2
make[1]: Leaving directory '/home/McKelvey/gcc-13-20221204'
make: *** [Makefile:1063: all] Error 2

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-cygwin/13.0.0/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 13.0.0 20221118 (experimental) (GCC)


$ uname
CYGWIN_NT-10.0-19044

[Bug c++/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

[mckelvey at maskull dot com]

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

--- Comment #1 from James McKelvey <mckelvey at maskull dot com> ---
Created attachment 54032
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54032&action=edit
Config log

[Bug c++/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

[mckelvey at maskull dot com]

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

--- Comment #2 from James McKelvey <mckelvey at maskull dot com> ---
Configured with:

./configure --enable-languages=c,c++ --enable-threads=posix

[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
          Component|bootstrap                   |target
                 CC|                            |clyon at gcc dot gnu.org

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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

[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

[clyon at gcc dot gnu.org]

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

--- Comment #4 from Christophe Lyon <clyon at gcc dot gnu.org> ---
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

[mckelvey at maskull dot com]

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

--- Comment #5 from James McKelvey <mckelvey at maskull dot com> ---
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

[clyon at gcc dot gnu.org]

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

--- Comment #6 from Christophe Lyon <clyon at gcc dot gnu.org> ---
(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

[mckelvey at maskull dot com]

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

--- Comment #7 from James McKelvey <mckelvey at maskull dot com> ---
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

[mckelvey at maskull dot com]

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

--- Comment #8 from James McKelvey <mckelvey at maskull dot com> ---
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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> ---
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

[clyon at gcc dot gnu.org]

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

--- Comment #10 from Christophe Lyon <clyon at gcc dot gnu.org> ---
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

[mckelvey at maskull dot com]

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

--- Comment #11 from James McKelvey <mckelvey at maskull dot com> ---
(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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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-w64        2020-01-12 11:54:36.333414616 +0100
+++ gcc/config/i386/t-cygwin-w64        2023-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

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[mckelvey at maskull dot com]

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

--- Comment #14 from James McKelvey <mckelvey at maskull dot com> ---
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

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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

[mckelvey at maskull dot com]

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

--- Comment #16 from James McKelvey <mckelvey at maskull dot com> ---
$ 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

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[mckelvey at maskull dot com]

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

--- Comment #18 from James McKelvey <mckelvey at maskull dot com> ---
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

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[10walls at gmail dot com]

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

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54502&action=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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #23 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Yong <jyong@gcc.gnu.org>:

https://gcc.gnu.org/g:e3f8dfcd885d19d322b10fb4e36d50b60da2576b

commit r13-6578-ge3f8dfcd885d19d322b10fb4e36d50b60da2576b
Author: Jakub Jelinek <jakub@redhat.com>
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  <jakub@redhat.com>

    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 <10walls@gmail.com>

[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

[mckelvey at maskull dot com]

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

--- Comment #25 from James McKelvey <mckelvey at maskull dot com> ---
I just tried the latest snapshot and it works great, no need to specify
--disable-multilib.