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

[Nikos Mavrogiannopoulos]

On Tue, 2017-03-14 at 20:12 +0100, Helmut Grohne wrote:

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

But is that complexity needed here? Could we skip compilation of this
tool completely on build host and ship tr46map_data.c?


regards,
Nikos