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 ;) - 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 ? ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
