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