On Mon, Jul 02, 2007 at 12:50:33PM +1000, kala mazoo wrote: > > Now...this is the error glimpse threw at compile time; > > . > . > .<snip>... > > make[1]: Entering directory `/usr/local/glimpse-4.18.5/dynfilters' > gcc -O2 -fPIC -fomit-frame-pointer -fPIC -DSHARED_OBJECT -c lex.yy.c > gcc -shared -o htuml2txt.so lex.yy.o -lfl > /usr/bin/ld: > /usr/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../lib/libfl.a > (libyywrap.o): relocation R_X86_64_32 against `a local symbol' can not be > used when making a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../lib/libfl.a: could > not read symbols: Bad value > collect2: ld returned 1 exit status > make[1]: *** [htuml2txt.so] Error 1 > make[1]: Leaving directory `/usr/local/glimpse-4.18.5/dynfilters' > > .<snip>... > . > . > > Now...the culprit here is the 'libyywrap.o' object, compiled and linked > into libfl.* as part of the basic system install part of the CLFS-1.0 > book....to wit, the installation of 'flex'. > > Unpacking the flex-2.5.33 archive (again) and setting CFLAGS="-fPIC" > before the configure/compilation of flex fixes this problem. Perhaps this > should be done as a standard part of the CLFS book(s)? > > I don't know how many other packages in BLFS this would effect, in theory > everything that tries to link against libfl.* is going to bork... > Alternatively, glimpse is using -fPIC when it should not. I don't have a view on what is correct for x86_64 (and it almost certainly doesn't matter on other architectures), but I do have a different perspective: over the last two years I've built more than a dozen x86_64-64 desktop systems (and a handful of multilib) and not had any problems with flex.
But then, very little in my builds seems to be linking directly against libfl.a. Several things check for yywrap in -lfl during configure (e.g. xorg-server, twm, libIDL, bc, a2ps, gutenprint, gcalctool, gnumeric) but they don't all link against it (so, maybe it used to be needed, or is needed on another platform). The following do link against it, without obvious problems: bc-1.06: gcc -O2 -Wall -funsigned-char -o bc main.o bc.o scan.o execute.o load.o storage.o util.o global.o ../lib/libbc.a -lfl -lreadline -lncurses a2ps-4.2.13b using libtool: /bin/sh ../libtool --mode=link gcc -O2 -o a2ps main.o read.o sshread.o ssheet.o select.o generate.o delegate.o regex.o buffer.o versions.o ffaces.o version-etc.o long-options.o parsessh.o lexssh.o lexps.o sheets-map.o ../lib/liba2ps.la -lfl -lm No doubt you are used to using glimpse - for me, it looks like the proverbial sledgehammer to crack a nut in trying to work out why something won't build: find, grep, and view are my main tools for looking at build logs ;) I'm unclear if this is your first attempt at a non-x86 desktop, or if you have a new problem when building xorg. If you need to ask for help, please confirm which architecture you are building (pure64 or multilib). ĸen -- das eine Mal als Tragödie, das andere Mal als Farce _______________________________________________ Clfs-dev mailing list [email protected] http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev
