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

[Tim Ruehsen]

Hi Helmut,

On Tuesday, March 14, 2017 12:44:59 PM CET Helmut Grohne wrote:
> 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.

Thanks for the good explanation, pushed upstream.

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

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

New issue opened upstream.

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

Right, also added a new issue upstream.

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

Thanks for all your feedback !

Regards, Tim

signature.asc
Description: This is a digitally signed message part.