Problem with binutils first pass / bison & flex installation

peristaltic · 03-14-2005, 03:17 PM

Hello --

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

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

Code:

../../binutils-2.15.91.0.2/binutils/ar.c:148: 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:

Code:

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.