El vie, 22 mar 2024 a las 11:23, Agustin Martin (<agmar...@debian.org>) escribió: > > On Fri, Dec 30, 2022 at 10:46:18PM +0100, Helmut Grohne wrote: > > > > regina-rexx fails to cross build from source, because it builds for the > > build architecture. Fixing this is not entirely trivial. The obvious fix > > of passing --build and --host to configure is insufficient. Beyond that, > > the C compiler must be forced via the CC environment variable. Even > > then, the build system fails to transfer this assignment over to make. > > To make matters worse, it skips checking for --version-script (and thus > > symbol versioning) unless the compiler is exactly gcc. I'm attaching a > > patch for your convenience. > > I am not regina-rexx maintainer, but I am preparing a fix proposal (or > a NMU if required) for regina-rexx because of #1066314 FTBFS, which > will include a newer upstream version. > > While I am with that, I would also like to address this cross > compilation problem, and looking at your patch I have some questions, > even if only to properly document changes.
HI, Helmut, I finally had time to learn how to test cross compilation from my amd64 box. I am using the usual pbuilder/cowbuilder chroot for that with apropriate options (and forcing my local pbuilderrc loaded last to have PBUILDERSATISFYDEPENDSCMD properly overriden) > About debian/rules changes, > > I wonder if passing CC compiler to configure is done just because > otherwise C compiler will not be found because of unusual name during > cross compilation, or there is another reason. > > Passing CC to 'make' may not be needed. Another patch changes > Makefile.in to no longer hardcode CC, CFLAGS, RANLIB and LDFLAGS. As a > matter of fact, I woud expect no problems if LDFLAGS is not passed. > CFLAGS is passed only to concat CPPFLAGS (may be CFLAGS += $(CPPFLAGS) > and export CFLAGS could make that useless). All this seems needed just because CC is not exported by the build system . Adding export CC in the right place in debian/rules seems to make that uneeded. With that changes I could cross compile i386 from my amd64 box. However, there is another problem with other arches (e.g. arm64). Some binary files containing compiled error messages are built with a locally built program (msgcmp). Because of incompatible arches, it cannot be run and files cannot be built, and then, build fails when trying to install them (error is disabled during build). The first idea was to have a separate arch:all pakage with those messages, but it would not be arch:all because those messages binary files depend on arch endianness. I would like to close this bug report with above changes, even if a more specific bug report is open afterwards for the remaining stuff. Better suggestions are welcome. Regards, -- Agustin
