On 2012/10/08 23:07, Stuart Henderson wrote: > On 2012/10/08 21:54, Kirill Bychkov wrote: > > Hi. > > This is minor update for xmoto and its dependency - ode. Both tested for a > > long time on amd64 and i386. > > ode is okay with me (I had to hand-apply part of the patch as there > were trailing spaces in the original Makefile in the tree, but that shouldn't > affect things for committing, it just got broken in mailing), but I had a > problem building xmoto, gettext doesn't get detected (at least on my laptop > running amd64), > > configure:12230: checking for GNU gettext in libintl > configure:12258: cc -o conftest -O2 -pipe -I/usr/local/include/libxml2 > -I/usr/local/include -I/usr/local/include -DdSINGLE > -I/usr/local/include/libpng -I/usr/include -I/usr/local/include/SDL > -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/X11R6/include -DXTHREADS > -I/usr/local/include/lua-5.1 -DSVN_REV='"0.5.10"' > -I/usr/local/include/libxml2 -I/usr/local/include -L/usr/local/lib -pthread > -L/usr/X11R6/lib -R/usr/X11R6/lib -lpng -lz -lSDL -llua5.1 -lm -lGL > conftest.c -lcurl -lode -lSDL_ttf -lSDL_net -lSDL_mixer -lGLU -lxdg-basedir > -lbz2 -lpng -ljpeg -lz -lsqlite3 -L/usr/local/lib -lxml2 -lz > -L/usr/local/lib -liconv -lm /usr/local/lib/libintl.a >&5 > /usr/bin/ld: /usr/local/lib/libintl.a(bindtextdom.o): relocation R_X86_64_32 > can not be used when making a shared object; recompile with -fPIC > /usr/local/lib/libintl.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > configure:12258: $? = 1 > > so it goes on to try and use its internal version which breaks (though > that's not a problem as it shouldn't be using it anyway). > > Making all in intl > make: don't know how to make ../config.h (prerequisite of: bindtextdom.o) > > can anyone repeat this? my laptop might not be squeaky clean but other things > are building ok on it..
so following a suggestion, I removed old libiconv/gettext static libs and reinstalled them. (I didn't quite follow the suggestion and just removed the libs and /var/db/pkg/libiconv etc and forced a pkg_add repair, so *only* those files got changed). Both old and new packages were from snapshots so should be clean. It fixed things... so clearly some change in toolchain or libtool has resulted in different static libs, but because the package signature didn't change (in this case, that means that the package REVISION was not bumped, and libc was not bumped) the new packages didn't get considered by pkg_add -u. Anyone have an idea what change might have caused this? Hoping this will give a clue as to what ought to be bumped to get things back in sync properly after people have pkg_add -u'd.
