Looking at Information for RPM mingw64-zlib-1.2.13-2.fc38.noarch.rpm <https://koji.fedoraproject.org/koji/rpminfo?rpmID=33118048> sysroot paths look like this: /usr/x86_64-w64-mingw32/sys-root/mingw/bin/zlib1.dll /usr/x86_64-w64-mingw32/sys-root/mingw/include/zconf.h /usr/x86_64-w64-mingw32/sys-root/mingw/include/zlib.h /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libz.dll.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/zlib.pc Is the /mingw/ part of the sysroot path, or is it within the sysroot? Would I use --sysroot=/usr/x86_64-w64-mingw32/sys-root or --sysroot=/usr/x86_64-w64-mingw32/sys-root/mingw to build against the sysroot? I assumed the latter, but now I wonder if /mingw in the sysroot is the analogue of /usr in GNU/Linux sysroots.

Eventually, we want to produce some GNU/Linux sysroots. I picked /usr/%{_arch}-redhat-linux/sys-root/fc%{fedora} or (depending on the operating system) /usr/%{_arch}-redhat-linux/sys-root/el%{rhel} or (as the fallback) /usr/%{_arch}-redhat-linux/sys-root/root and we have /usr inside the sysroot, e.g. <stdio.h> is /usr/x86_64-redhat-linux/sys-root/fc35/usr/include/stdio.h in a Fedora 35 sysroot on x86-64 (although the Fedora 35 update with this never actually went out). We essentially use the /mingw/ part as an OS ABI version indicator, to make the different versions co-installable. I want to pick this up again and would like to solicit comments if that OS ABI variant thing is the right approach, or if we should drop it. Sysroot packages are by nature relocatable, and do not have to be installed in /, so it's perhaps not a great loss if their version variants are not co-installable. We need something like this before we can drop i686 on ELN; it's only way to enable -m32 in GCC in a sustainable fashion. But we don't need OS ABI variants for that. Thanks, Florian

On Fri, Apr 28, 2023 at 01:41:05PM +0100, Richard W.M. Jones wrote: > On Fri, Apr 28, 2023 at 02:22:40PM +0200, Florian Weimer wrote: > > Looking at > > > > Information for RPM mingw64-zlib-1.2.13-2.fc38.noarch.rpm > > <https://koji.fedoraproject.org/koji/rpminfo?rpmID=33118048> > > > > sysroot paths look like this: > > > > /usr/x86_64-w64-mingw32/sys-root/mingw/bin/zlib1.dll > > /usr/x86_64-w64-mingw32/sys-root/mingw/include/zconf.h > > /usr/x86_64-w64-mingw32/sys-root/mingw/include/zlib.h > > /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libz.dll.a > > /usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/zlib.pc > > > > Is the /mingw/ part of the sysroot path, or is it within the sysroot? > > Would I use --sysroot=/usr/x86_64-w64-mingw32/sys-root or > > --sysroot=/usr/x86_64-w64-mingw32/sys-root/mingw to build against the > > sysroot? > > > > I assumed the latter, but now I wonder if /mingw in the sysroot is the > > analogue of /usr in GNU/Linux sysroots. > > FWIW: > > $ x86_64-w64-mingw32-gcc -print-sysroot > /usr/x86_64-w64-mingw32/sys-root > > which would indicate that you are correct that /mingw is somehow > "inside" the sysroot. Then on the Meson side we define root = '/usr/i686-w64-mingw32/sys-root/mingw' in the /usr/share/mingw/toolchain-mingw32.meson spec, while with configure we invoke configure \ --host=i686-w64-mingw32 \ --build=x86_64-redhat-linux-gnu \ --target=i686-w64-mingw32 \ --prefix=/usr/i686-w64-mingw32/sys-root/mingw \ --exec-prefix=/usr/i686-w64-mingw32/sys-root/mingw \ --bindir=/usr/i686-w64-mingw32/sys-root/mingw/bin \ --sbindir=/usr/i686-w64-mingw32/sys-root/mingw/sbin \ --sysconfdir=/usr/i686-w64-mingw32/sys-root/mingw/etc \ --datadir=/usr/i686-w64-mingw32/sys-root/mingw/share \ --includedir=/usr/i686-w64-mingw32/sys-root/mingw/include \ --libdir=/usr/i686-w64-mingw32/sys-root/mingw/lib \ --libexecdir=/usr/i686-w64-mingw32/sys-root/mingw/libexec \ --localstatedir=/usr/i686-w64-mingw32/sys-root/mingw/var \ --sharedstatedir=/usr/i686-w64-mingw32/sys-root/mingw/com \ --mandir=/usr/i686-w64-mingw32/sys-root/mingw/share/man \ --infodir=/usr/i686-w64-mingw32/sys-root/mingw/share/info \ is there any difference between the notion of the 'sysroot' vs the install 'prefix' ?

Looking at Information for RPM mingw64-zlib-1.2.13-2.fc38.noarch.rpm <https://koji.fedoraproject.org/koji/rpminfo?rpmID=33118048> sysroot paths look like this: /usr/x86_64-w64-mingw32/sys-root/mingw/bin/zlib1.dll /usr/x86_64-w64-mingw32/sys-root/mingw/include/zconf.h /usr/x86_64-w64-mingw32/sys-root/mingw/include/zlib.h /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libz.dll.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/zlib.pc Is the /mingw/ part of the sysroot path, or is it within the sysroot? Would I use --sysroot=/usr/x86_64-w64-mingw32/sys-root or --sysroot=/usr/x86_64-w64-mingw32/sys-root/mingw to build against the sysroot? I assumed the latter, but now I wonder if /mingw in the sysroot is the analogue of /usr in GNU/Linux sysroots. Eventually, we want to produce some GNU/Linux sysroots. I picked /usr/%{_arch}-redhat-linux/sys-root/fc%{fedora} or (depending on the operating system) /usr/%{_arch}-redhat-linux/sys-root/el%{rhel} or (as the fallback) /usr/%{_arch}-redhat-linux/sys-root/root and we have /usr inside the sysroot, e.g. <stdio.h> is /usr/x86_64-redhat-linux/sys-root/fc35/usr/include/stdio.h in a Fedora 35 sysroot on x86-64 (although the Fedora 35 update with this never actually went out). We essentially use the /mingw/ part as an OS ABI version indicator, to make the different versions co-installable. I want to pick this up again and would like to solicit comments if that OS ABI variant thing is the right approach, or if we should drop it. Sysroot packages are by nature relocatable, and do not have to be installed in /, so it's perhaps not a great loss if their version variants are not co-installable. We need something like this before we can drop i686 on ELN; it's only way to enable -m32 in GCC in a sustainable fashion. But we don't need OS ABI variants for that.

Parallel install of different versions of mingw has never been something we needed to consider. We only need parallel install the different ABIs, which is handled by the higher level dir in the path. So from that POV, I don't think mingw particularly cares what semantics are attached to the 4th path component 'mingw'. As long as we don't have to change our paths currently used in Fedora, I think it'd be OK for you to define the 4th component as the OS version indicator.