Control: tags -1 + confirmed pending Hi!
On Wed, 27 Aug 2025 04:19:35 +0300, Guillem Jover wrote: > X-Debbugs-Cc: [email protected] I kept that in CC. > The libgnustep-base1.31 binary package has a run-time dependency on > dpkg-dev, because its shared library has been patched to use > dpkg-architecture to fetch the DEB_HOST_MULTIARCH variable. Right. > Given that this is shared library package, the run-time dependency on > dpkg-dev ends up pulling the entire build-essential, and I think the > current reason for the dependency is problematic in any case. I agree this is a problem and I've always felt the solution that I've chosen back then is not entirely correct. > The patch with those changes is supposedly to support the multiarch > layout and cross building, but it's not clear whether the cross > building changes could be restricted to the cross.config file, Yes, changes for cross bulding are in cross.config plus few tiny changes in configure.ac (hard-coded pkg-config and an override for sparc64 due to alignment requirement). > and the changes to the Objective C file could be done by hardcoding > the value computed at configure time? Thanks, that's way better and I wonder why such an obvious thing hasn't crossed my mind. It simplifies the patch a lot and avoids the performance penalty of spawning dpkg-architecture (plus the benefit of avoiding the dpkg-dev dependency). > Otherwise the shared library might potentially end up returning the > wrong pathname not matching its own architecture (because > dpkg-architecture will honor the already set environment variables). That's already the case -- the current version of the patch checks if the variable is set in the environment (so dpkg-architecture is not involved here): $ dpkg --print-architecture amd64 $ dpkg --print-foreign-architectures i386 x32 $ AClock (program starts successfully) $ DEB_HOST_MULTIARCH=armhf-linux-gnu AClock 2025-09-07 19:25:06.059 AClock[2583241:2583241] Did not find correct version of backend (libgnustep-back-032.bundle), falling back to std (libgnustep-back.bundle). 2025-09-07 19:25:06.059 AClock[2583241:2583241] NSApplication.m:306 Assertion failed in initialize_gnustep_backend. Unable to find backend back AClock: Uncaught exception NSInternalInconsistencyException, reason: NSApplication.m:306 Assertion failed in initialize_gnustep_backend. Unable to find backend back The new version of the patch (not yet pushed) will ignore it and use only the hard-coded value determined at configure time. > I just noticed this on a recently upgraded system (to Debian trixie), > which has otherwise no use for development files, and where > build-essential got pulled in. Many thanks for the report, will upload after some testing.
