Hi, On Mon, Jun 23, 2014 at 10:04:51AM +0200, Ludovic Courtès wrote: > b...@beuc.net skribis: > > On Sat, Jun 21, 2014 at 11:34:18PM +0200, Ludovic Courtès wrote: > >> b...@beuc.net skribis: > >> > On Fri, Jun 20, 2014 at 12:16:41PM +0200, Ludovic Courtès wrote: > >> >> b...@beuc.net skribis: > >> >> > First important note: I had to move "AC_CHECK_LIB(m, cos)" (which btw > >> >> > could be rewritten at LT_LIB_M()) before gl_INIT in configure.ac, > >> >> > otherwise libunistring would fail to be detected. > >> >> > >> >> Could you send the config.log of the failing thing? > >> > > >> > Selected bits: > >> > > >> > configure:14688: checking for libunistring > >> > configure:14710: arm-linux-androideabi-gcc -o conftest -g -O2 > >> > -I/usr/src/ndk-standalone-12/sysroot/usr/include conftest.c > >> > /usr/src/ndk-standalone-12/sysroot/usr/lib/libunistring.so -Wl,-rpath > >> > -Wl,/usr/src/ndk-standalone-12/sysroot/usr/lib >&5 > >> > > >> > /usr/src/ndk-standalone-12/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld: > >> > /usr/src/ndk-standalone-12/sysroot/usr/lib/libunistring.so: error: > >> > undefined reference to 'frexp' > >> > collect2: ld returned 1 exit status > >> > >> It looks like a libunistring issue no? Namely, libunistring assumed > >> frexp to be available in libc, and it isn’t. > > > > Incidentally, do you know why the test is referencing the .so directly? > > That comes from Gnulib’s AC_LIB_HAVE_LINKFLAGS, and I believe this > explanation is this comment (from lib-link.m4): > > dnl Using DIR/libNAME.so during linking hardcodes DIR into the > dnl resulting binary.
I mean I made a minimal project with gnulib's libunistring module, and it checks using '-lunistring'. I attach it. So there's a difference somewhere. -- Sylvain
testunistring.tar.gz
Description: Binary data
