-   Linux From Scratch (
-   -   Problem with binutils first pass / bison & flex installation (

peristaltic 03-14-2005 03:17 PM

Problem with binutils first pass / bison & flex installation
Hello --

I am working on creating an LFS 6.0 system using Mandrake Official 10.1.

In " Binutils- - Pass 1", I encountered an error while executing 'make LDFLAGS="-all-static" ':


../../binutils- undefined reference to `yyparse'
collect2: ld returned 1 exit status
make[3]: *** [ar] Error 1
make[3]: Leaving directory `/lfs/tools/binutils-build/binutils'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/lfs/tools/binutils-build/binutils'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory `/lfs/tools/binutils-build/binutils'
make: *** [all-binutils] Error 2

Looking through the posts in this forum, I found that the reason for this error was because bison and/or flex were not installed on my host system.

I downloaded the bison and flex tarballs from the GNU website, compiled and installed them. I believe bison complained that it needed "m4", so I downloaded, compiled and installed that too.

I cleaned out the tools directory, wiped out my sources directory and started over. However, I received the same error when I got back to 'make LDFLAGS="-all-static" '!

As user lfs, I checked to see what "which bison" returns:

which: no bison in (/tools/bin:/bin:/usr/bin).
Same with "m4" and "flex".

I have checked and these files have indeed been installed on my system in /usr/local/bin. I can execute them when logged in as root or my usual account, but not as lfs.

What to do? I am stuck. Thank you.

slakmagik 03-14-2005 08:57 PM

/usr/local/bin isn't on lfs' path, as the 'which' command indicates. Add it to the path and log in and out as lfs, or re-source your bash configs. Not sure if that'll fix it, but it's necessary and is a start, either way.

peristaltic 03-15-2005 03:02 PM

Hi -- Thanks for your reply and suggested fix.

I also considered making links in /usr/bin/ to the files in /usr/local/bin/.

Which method of correcting this problem do you think is better -- or does it matter?

slakmagik 03-20-2005 10:17 AM

Sorry - fell off the net for a bit. If this is your host system, I'd add it to your path. While symlinks are mostly transparent, there are corner cases where they aren't, such as links to wrapper-scripts that check their current working directory and so on. And most additional software should be in /usr/local so you'd be symlinking a lot of stuff in general, if you wanted to run it from the console/xterm. Symlinks to binaries are generally just for historical reasons (hardlinked expectations and traditional locations and so on) and expanding your path would be the regular course to take.

All times are GMT -5. The time now is 07:54 AM.