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.
