XPost: linux.debian.ports.hurd

Hello Guillem and Rapha�l,

I sat down with Samuel yesterday and we looked into bootstrapping
hurd-amd64 on amd64. Doing cross-kernel same-cpu bootstraps is something
that is not expected to just work as the resulting binaries are not
quite distinguishable from looking at ELF headers, yet we tried.

It failed installing the full gcc cross compiler, because
cpp-14-x86-64-gnu had an unsatisfiable dependency on libc0.3. This was
issued by dpkg-shlibdeps, because it considered libc0.3 for libm.so.6. I
note that cpp-14-x86-64-gnu is Architecture: amd64 and that libc0.3 was
not qualified :hurd-amd64, so that dependency is never satisfiable.

In Dpkg/Shlibs.pm in sub setup_library_paths, there is the following
code:

| # Adjust set of directories to consider when we're in a situation of a
| # cross-build or a build of a cross-compiler.
| my $multiarch;
|
| # Detect cross compiler builds.
| if ($ENV{DEB_TARGET_GNU_TYPE} and
| ($ENV{DEB_TARGET_GNU_TYPE} ne $ENV{DEB_BUILD_GNU_TYPE}))
| {
| $multiarch = gnutriplet_to_multiarch($ENV{DEB_TARGET_GNU_TYPE});
| }
| # Host for normal cross builds.
| if (get_build_arch() ne get_host_arch()) {
| $multiarch = debarch_to_multiarch(get_host_arch());
| }
| # Define list of directories containing crossbuilt libraries.
| if ($multiarch) {
| push @system_librarypaths, "/lib/$multiarch", "/usr/lib/$multiarch";
| }
|
| push @system_librarypaths, DEFAULT_LIBRARY_PATH;

It is not clear to us, why that first branch exists. It was originally
added by Rapha�l in support of cross compilation and later changed a
couple of times.

I attempted a full architecture cross bootstrap (for m68k as it is
quick) with that first branch deleted and it succeeded. I also attempted
a hurd-amd64 bootstrap on amd64 with it deleted and then
cpp-14-x86-64-gnu become installable.

Let me also point out that the gcc packaging prefixes invocations of dh_shlibdeps issued for its libraries with $(cross_shlibdeps) and also
passes library search paths. That variable is defined as

| cross_shlibdeps = DEB_HOST_ARCH=$(TARGET) ARCH=$(DEB_TARGET_ARCH) MAKEFLAGS="CC=something"

for cross toolchain builds. We may conclude that the relevant branch in Shlibs.pm never becomes relevant during a gcc build as the second branch
always overwrites $multiarch.

Remember that since target libraries are not target qualified in the
resulting Depends, they're never satisfied in the desired way.

We would like to better understand why we even consider them in
Shlibs.pm and if the reason is not convincing whether that branch could
be deleted as it appears to improve cross bootstrap.

Thanks for sharing what you know about this matter

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.ports.hurd

Hi Helmut,

On Wed, 09 Jul 2025, Helmut Grohne wrote:

In Dpkg/Shlibs.pm in sub setup_library_paths, there is the following
code:

[...]

It is not clear to us, why that first branch exists. It was originally
added by Raphaël in support of cross compilation and later changed a
couple of times.

So this part was added as part of the discussion in this bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453267

From what I remember, that first branch was specifically in support

of building cross compilers.

I don't have recent knowledge of cross-building and cross-compilers
so I have no idea whether that's still useful in some cases or not.

I attempted a full architecture cross bootstrap (for m68k as it is
quick) with that first branch deleted and it succeeded. I also attempted
a hurd-amd64 bootstrap on amd64 with it deleted and then
cpp-14-x86-64-gnu become installable.

The right thing to try to validate whether we can remove the code is
building a cross-compiler (and not cross-building a compiler).

Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.ports.hurd

Hi!

On Wed, 2025-07-09 at 12:39:12 +0200, Raphael Hertzog wrote:

On Wed, 09 Jul 2025, Helmut Grohne wrote:

In Dpkg/Shlibs.pm in sub setup_library_paths, there is the following
code:

[...]

It is not clear to us, why that first branch exists. It was originally added by Raphaël in support of cross compilation and later changed a couple of times.

So this part was added as part of the discussion in this bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453267

Right, was about to post the same reference. :)

From what I remember, that first branch was specifically in support

of building cross compilers.

I agree that this code does not look correct…

I don't have recent knowledge of cross-building and cross-compilers
so I have no idea whether that's still useful in some cases or not.

…and from a quick skim over that report, I think this might have been
needed to support old gcc versions that had not yet been fixed to
use the expected variables (see messages #73 and forward)? (But this
was really a quick skim, so might have read the details wrong, as the
report is quite long.) Will try to recheck later today.

I attempted a full architecture cross bootstrap (for m68k as it is
quick) with that first branch deleted and it succeeded. I also attempted
a hurd-amd64 bootstrap on amd64 with it deleted and then
cpp-14-x86-64-gnu become installable.

The right thing to try to validate whether we can remove the code is
building a cross-compiler (and not cross-building a compiler).

Yes, I don't see rebootstrap using dpkg-buildpackage --target-arch for
anything except GNU mig?

Ideally, we'd test both a cross-compiler build (build == host != target)
and a canadian cross-compiler build (build != host != target).

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.ports.hurd

Hi Guillem and Raphaël,

thank you two for jumping into it right away.

On Wed, Jul 09, 2025 at 01:26:27PM +0200, Guillem Jover wrote:

On Wed, 2025-07-09 at 12:39:12 +0200, Raphael Hertzog wrote:

On Wed, 09 Jul 2025, Helmut Grohne wrote:
So this part was added as part of the discussion in this bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453267

Right, was about to post the same reference. :)

Thank you. Right in message #73 and later message #93 Raphaël questions precisely the code in question. In the later conversation, and message
#78 in particular, we see that gcc did not override DEB_HOST_ARCH for dpkg-shlibdeps back then. There was a bit back and forth
whether gcc could be updated to convey the architecture it is interested
in more sanely, but the original approach ended up being merged.

The -$DEB_TARGET_ARCH-cross packages that were mentioned there are still being built (unless applying the with_deps_on_target_arch_pkgs patchset and
then they become :$DEB_TARGET_ARCH). Either way, gcc precisely tells
apart what packages are meant to be target ones and for each of those it
now (but now back then) changes DEB_HOST_ARCH to target for the
dh_shlibdeps invocation.

…and from a quick skim over that report, I think this might have been needed to support old gcc versions that had not yet been fixed to
use the expected variables (see messages #73 and forward)? (But this
was really a quick skim, so might have read the details wrong, as the
report is quite long.) Will try to recheck later today.

I concur. This fully matches my understanding (see above).

The right thing to try to validate whether we can remove the code is building a cross-compiler (and not cross-building a compiler).

Running rebootstrap starts out with building a stage1 cross compiler,
glibc stage2 and then a stage3 gcc cross compiler. Admittedly, it limits
the amount of frontends to C, C++ and Fortran leaving out most other
frontends. So building a full gcc-14-cross with that patch applied is
something I likely should do still. Thankfully, we now have Debusine. :)

https://debusine.debian.net/debian/developers/work-request/119889/ is a
dpkg workflow and a gcc one shall go later.

Yes, I don't see rebootstrap using dpkg-buildpackage --target-arch for anything except GNU mig?

That is correct. The gcc source packages refuse to support
DEB_TARGET_ARCH and you have to convey the target architecture via debian/target. In the end, it internally sets DEB_TARGET_*
appropriately.

Ideally, we'd test both a cross-compiler build (build == host != target)
and a canadian cross-compiler build (build != host != target).

I'm not sure canadian builds are supported at all. Do note that the
canadian build should be unaffected. If build != host, $multiarch is overwritten and it no longer matters whether we set it when build !=
target. I argue that the proposed change does not affect canadian
builds.

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.ports.hurd

Hi Guillem (and Rapha�l),

On Wed, Jul 09, 2025 at 02:11:06PM +0200, Helmut Grohne wrote:

https://debusine.debian.net/debian/developers/work-request/119889/ is a
dpkg workflow and a gcc one shall go later.

The gcc-14-cross workflow is:

https://debusine.debian.net/debian/developers/work-request/120241/

It succeeded and I checked the build log to see it actually used the
rebuilt dpkg-dev.

From my point of view, this means we're good to move forward with the

patch (in forky).

If you end up staging it into some git tree, I appreciate being able to reference it from rebootstrap for the benefit of hurd.

Thank you

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.ports.hurd

Hi!

On Fri, 2025-07-11 at 23:58:45 +0200, Helmut Grohne wrote:

Hi Guillem (and Raphaël),

On Wed, Jul 09, 2025 at 02:11:06PM +0200, Helmut Grohne wrote:

https://debusine.debian.net/debian/developers/work-request/119889/ is a dpkg workflow and a gcc one shall go later.

The gcc-14-cross workflow is:

https://debusine.debian.net/debian/developers/work-request/120241/

It succeeded and I checked the build log to see it actually used the
rebuilt dpkg-dev.

From my point of view, this means we're good to move forward with the

patch (in forky).

If you end up staging it into some git tree, I appreciate being able to reference it from rebootstrap for the benefit of hurd.

Thanks for the testing! (As I think I mentioned off-list) I'm going to
be queueing it for dpkg git main in the coming days, can provide the
reference off-list then once it gets pushed.

Regards,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)