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

[Helmut Grohne]

Hi Tim,

On Tue, Mar 14, 2017 at 03:15:00PM +0100, Tim Ruehsen wrote:
> Hi Helmut,
> 
> On Tuesday, March 14, 2017 12:44:59 PM CET Helmut Grohne wrote:
> > 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.
> 
> Thanks for the good explanation, pushed upstream.

Great. One less thing to worry about.

> > > 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?
> 
> Not yet. I'll have a deeper look into libtool. If you are right and libtool 
> has no means for the build architecture, well then we have to use 
> libunistring 
> directly :-(

The issue with libtool is that autoconf configures it for the host
architecture. So any call to libtool becomes specific to the host
architecture. This can result in using architecture-specific paths (e.g.
/usr/lib/$host_triplet on Debian). Like one must not include config.h in
a build tool, one must not use libtool on build tools (if cross
compilation is supposed to work).

It seems to me that the first step here would be telling configure to
search for libunistring twice. Searching for a host architecture
libunistring is currently being done, but we'd also need the build
architecture libunistring.

So maybe we can do something else: Bite the bullet and do not use
libunistring for gentr46map? It seems that libunistring stuff generally
matches /\bu(8|16|32)_.*/ and I fail to find such symbols in
non-comments. Maybe we can skip it entirely (for these two files)? It
may be less convenient, but so is trying to libtoolize twice.

This may seem totally backwards, but when I am faced with "broken" (in
terms of cross compilation) build tools, I try to rewrite them as dumb
and portable as possible. realloc()ing an array at 1 increases, such
that it yields O(n^2)? Fine. All those inefficient practises are fine
here to avoid dependencies at all cost.

> > 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.
> 
> Using 'if !cross_compiling' makes the normal standard build more portable and 
> let's cross-compilation for Debian still succeed. I think about it.

Yeah, it works, but it is error prone. Whenever the native build and the
cross build diverts, the cross one will break sooner or later
(experience). Thus, I try to avoid such diversion.

> BTW, 'upstream' now is https://gitlab.com/libidn/libidn2.

Can 'upstream' be made accessible without having to log in? That'd help
a lot.

Please let me know if there is anything else I can help with.

Helmut