On 03/04/2012 09:58 PM, Andrew Benton wrote: > On Sun, 4 Mar 2012 13:58:02 +0000 > Ken Moffat<[email protected]> wrote: > >> Finally I'm building on 7.1, mostly using the packages I used for >> 7.0 - at this early stage (just got icewm built, now I'm in for the >> long haul to firefox) the only real change is to use Python-2.7.3rc1 >> (updating an installed Python is unknown territory for me, so I'll >> use the rc in this new build). So, nothing else really changed - I >> thought. >> >> But three times I've had build failures. None of these directly >> affect the book, but all had similar symptons. The packages were >> mesa-demos (I had been using that after the old patch didn't apply >> to newer Mesa - current patch in the book for MesaLib is fine so I >> went back to that), xclock-1.0.4 (I don't build all of X, didn't >> notice the book had started to use a newer version), and icewm-1.3.7. >> >> In each case, ld reported an undefined reference, and told me which >> library was needed, then said it couldn't read it. >> >> e.g. in xclock-1.0.4 (the lines from ld itself have been reformatted >> by pasting) - >> >> /usr/bin/ld: Clock.o: undefined reference to symbol >> 'XmuCvtStringToBackingStore' >> /usr/bin/ld: note: 'XmuCvtStringToBackingStore' is defined in DSO >> /usr/lib64/libXmu.so.6 so try adding it to the linker command line >> /usr/lib64/libXmu.so.6: could not read symbols: Invalid operation >> collect2: ld returned 1 exit status >> make[1]: *** [xclock] Error 1 >> >> What I don't understand is why this suddenly shows up. No changes >> in my xorg versions, so no likely changes in which headers get >> included. AFAICS the only glibc change since 7.0 is that we now >> always install the rpc headers, we're using 2.14.1 both times, but >> I had to install them anyway for nfs. So, a change in gcc-4.6.2 or >> binutils-2.22 ? >> >> For icewm, google in lynx was adequate (result!) - debian had this >> problem in March 2011 (almost a year ago) and fixed it by adding >> ' -lfontconfig' to the end of the 'LIB = ' line of src/Makefile.in >> (they patch, I managed a sed - I hope Andy's pleased ;) > > Way to go Ken! > >> - they also >> had a similar problem with fvwm, but only on their amd64 build farm, >> not on the package maintainer's machine. >> >> March 2011 appears to be before current gcc and binutils, even if >> debian were using prerelease or hjl binutils. So, I'm baffled by >> what has triggered this spate of build failures. Any ideas ? > > I think it was binutils-2.22 that broke it. Several packages now need > LIBS="-lX11 -lpthread" and such like and for me it happened when I > started using a pre release version, binutils-2.22.51. I've started > adding them to the pages in the book that need them (eg Pidgin needs > LIBS="-lm -lX11", Rox needs LIBS="-lm -ldl") but no doubt there are > more that need fixed. > > Andy
I experienced same issue too ... Mostly it was libm.so that was needed, then libX11, libgobject-2.0 .. etc. I usually solve it with make LDFLAGS=-lm for example. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
