Re: Bug#857675: libidn2-0 FTCBFS: runs host arch code during build (gentr46map, help2man)

[Helmut Grohne]

Hi Tim,

Thank you for the instant review!

On Tue, Mar 14, 2017 at 11:30:48AM +0100, Tim Ruehsen wrote:
> Just removing 'include <config.h>' from gentr46map.c doesn't work out here.
> _GL_ATTRIBUTE_CONST and _GL_ATTRIBUTE_PURE are then not defined (used in 
> gentr46map.c and tr46map.h) and the compiler errors.

These weren't in use in the Debian version of libidn2, so it compiled
there. Given that gnulib has very little clue about cross compilation
and given that both attributes are an optimization mechanism, I suggest
to simply drop them (for these two files only). The code is only
executed during build, so optimizing seems unnecessary to me.
Alternatively, have the CC_FOR_BUILD invocation define them as empty
macros. In any case, using config.h in a file compiled for the build
architecture is an error, because its values are specific to the host
architecture. It must not be included here.

> Also, using -lunistring directly doesn't work out on systems without 
> libunistring. I guess it needs libtool and $(LTLIBUNISTRING) + 
> ../gl/libgnu.la 
> to do it portable. I can't test that for the Debian environment and know too 
> less about cross-compiling to test that myself.

I tried using $(LTLIBUNISTRING), but that doesn't work for two reasons:
* It contains libtool parameter such as -R, which are not understood by
  gcc.
* It contains parameters specific to the host architecture, but we need
  the libunitstring for the build architecture. Given that autoconf has
  no means to check for a build architecture library, I figured that we
  should skip checking it and link it directly.

Do you have any other ideas on how to fix this properly for everyone?

The only other way I see here (and I don't like that) is to implement
this twice, once portably for native builds and once less portably for
cross compilation.

Something (a README) should maybe note that libunistring is required
for both the build and host architecture.

> Added the changes for configure.ac and help2man into upstream.

Nice. I'd slightly favour not using help2man at all, because it is
something that breaks cross compilation by design and the utility of
manual pages produced by help2man tends to be limited. What do you
think?

Helmut