On Fri, Dec 30, 2022 at 10:46:18PM +0100, Helmut Grohne wrote:

Source: regina-rexx
Version: 3.6-2.4
Tags: patch
User: debian-cross@lists.debian.org
Usertags: ftcbfs

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.

Hi, Helmut,

First thanks a lot for the analysis and the fix proposals.

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.

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).

Other changes in debian/rules are clear and very useful, thanks.

About changes in configure{,.in} I would leave a check for GCC, I
guess upstream wants other compilers supported. I would like to have a
change that might be sent upstream, so for portability I would use a
case statement, now written in a very generic way (see attached diff
for that). Which kind of strings are expected as C compiler during
cross compilation?

Thanks again for everything,

Regards,

--
Agustin

RGVzY3JpcHRpb246IEFsbG93IGEgbW9yZSBwZXJtaXNzaXZlIGdjY3xnKysgY2hlY2sgZm9yIGNy b3NzIGNvbXBpbGF0aW9uLgogQ29tcGlsZXIgbmFtZSBtYXkgaGF2ZSBwcmVmaXh8c3VmZml4IHdo ZW4gY3Jvc3MgY29tcGlsaW5nLgpCdWctRGViaWFuOiBodHRwOi8vYnVncy5kZWJpYW4ub3JnLzEw Mjc0MDUKRm9yd2FyZGVkOgoKLS0tIGEvY29uZmlndXJlLmluCisrKyBiL2NvbmZpZ3VyZS5pbgpA QCAtNDE2LDkgKzQxNiwxMSBAQCBmaQogQUNfU1VCU1QoTVlfR0VUT1BUX08pCiBBQ19TVUJTVChN WV9HRVRPUFRfU09fTykKIAotaWYgdGVzdCAiJGFjX2N2X3Byb2dfQ0MiID0gImdjYyIgLW8gIiRh Y19jdl9wcm9nX0NDIiA9ICJnKysiOyB0aGVuCi0gICBSRUdfQ0hFQ0tfR0NDX1ZFUlNJT05fU0NS SVBUCi1maQorY2FzZSAiJGFjX2N2X3Byb2dfQ0MiIGluCisgICAqZ2NjKnwqZysrKikKKwlSRUdf Q0hFQ0tfR0NDX1ZFUlNJT05fU0NSSVBUCisJOzsKK2VzYWMKIAogZG5sIGVuYWJsZV9wb3NpeF90 aHJlYWRzPSJ5ZXMiCiBSRUdfQ0hFQ0tfUE9TSVhfVEhSRUFEUwotLS0gYS9jb25maWd1cmUKKysr IGIvY29uZmlndXJlCkBAIC02MzQyLDcgKzYzNDIsOCBAQCBmaQogCiAKIAotaWYgdGVzdCAiJGFj X2N2X3Byb2dfQ0MiID0gImdjYyIgLW8gIiRhY19jdl9wcm9nX0NDIiA9ICJnKysiOyB0aGVuCitj YXNlICIkYWNfY3ZfcHJvZ19DQyIgaW4KKyAgICpnY2MqfCpnKysqKQogCiB7ICRhc19lY2hvICIk YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIHdoZXRoZXIgZ2NjIHVuZGVyc3Rh bmRzIC0tdmVyc2lvbi1zY3JpcHQiID4mNQogJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBn Y2MgdW5kZXJzdGFuZHMgLS12ZXJzaW9uLXNjcmlwdC4uLiAiID4mNjsgfQpAQCAtNjM5MCw3ICs2 MzkxLDggQEAgZmkKIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz dWx0OiAkbWhfY3ZfdmVyc2lvbl9zY3JpcHQiID4mNQogJGFzX2VjaG8gIiRtaF9jdl92ZXJzaW9u X3NjcmlwdCIgPiY2OyB9CiAKLWZpCisJOzsKK2VzYWMKIAogCiBNSF9NVF9MSUJTPSIiCg==

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

El vie, 22 mar 2024 a las 11:23, Agustin Martin
(<agmartin@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

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

El mar, 2 abr 2024 a las 13:49, Helmut Grohne (<helmut@subdivi.de>) escribió:

On Fri, Mar 29, 2024 at 01:29:04PM +0100, Agustin Martin wrote:

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.

Does that mean that it vendors a gettext rather than using the system gettext? There is a msgcmp in the gettext package and it is Multi-Arch: foreign. If this is something different from gettext, you should likely
use CC_FOR_BUILD as set by dpkg's buildtools.mk for compiling msgcmp.c.
I don't think it is installed into any binary package so there likely is
no need to compile it twice in a cross build.

HI, Helmut,

Thanks for the testing and for the info. Yes, a completely different
system is used for internationalization, not gettext.

By the way, upstream is active and responsive. I have recently opened
a couple of tickets about different things

https://sourceforge.net/p/regina-rexx/support-requests/56/ https://sourceforge.net/p/regina-rexx/support-requests/57/

and reply to first one was more than quick. The other has just been opened.

--
Agustin

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