Opened 16 years ago

Closed 15 years ago

#2114 closed defect (invalid)

gcc -print-search-dirs gives directories outside /tools directory

Reported by: Marco Fonseca Owned by: lfs-book@…
Priority: normal Milestone: 7.0
Component: Book Version: 6.3
Severity: normal Keywords:
Cc:

Description

While creating a x86 toolchain using lfs as a guideline, I noticed that a "gcc -print-search-dirs" on my temporary toolchain printed out some undesirable results. It contained references to /usr/... and others that I had assumed was handled by the gcc 4.1.2 spec patch.

I dug in a little and found that gcc/gcc.c still had explicit hardcoded values for standard_exec_prefix_1 and standard_exec_prefix_2. Additionally STANDARD_STARTFILE_PREFIX_1 and STANDARD_STARTFILE_PREFIX_2 were also hardcoded although these were predicated on some conditional. I found changing these references to "" removed the references to outside the /tool directory.

Change History (9)

comment:2 by bdubbs@…, 16 years ago

Milestone: 7.06.4

comment:3 by DJ Lucas, 16 years ago

Owner: changed from lfs-book@… to DJ Lucas
Status: newassigned

root:/sources# /tools/bin/gcc --print-search-dirs install: /tools/lib/gcc/i686-pc-linux-gnu/4.3.2/ programs: =/tools/libexec/gcc/i686-pc-linux-gnu/4.3.2/:/tools/libexec/gcc/i686-pc-linux-gnu/4.3.2/:/tools/libexec/gcc/i686-pc-linux-gnu/:/tools/lib/gcc/i686-pc-linux-gnu/4.3.2/:/tools/lib/gcc/i686-pc-linux-gnu/:/usr/libexec/gcc/i686-pc-linux-gnu/4.3.2/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/:/usr/lib/gcc/i686-pc-linux-gnu/:/tools/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/bin/i686-pc-linux-gnu/4.3.2/:/tools/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/bin/ libraries: =/tools/lib/gcc/i686-pc-linux-gnu/4.3.2/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/:/tools/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/lib/i686-pc-linux-gnu/4.3.2/:/tools/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/lib/:/usr/lib/i686-pc-linux-gnu/4.3.2/:/usr/lib/ root:/sources#

Confirmed.

If the OP's analysis is correct, this will be the fix:

sed -i -e 's@/usr/libexec/gcc@@' \
       -e 's@/usr/lib/gcc@@' \
       gcc/gcc.c

I'll drop it in tonight and report back tomorrow.

comment:4 by DJ Lucas, 16 years ago

Okay..not enough.

[dj@name25 BOOK]# /tools/bin/gcc --print-search-dirs install: /media/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/ programs: =/media/lfs/tools/bin/../libexec/gcc/i686-pc-linux-gnu/4.3.2/:/media/lfs/tools/bin/../libexec/gcc/:/i686-pc-linux-gnu/4.3.2/:/i686-pc-linux-gnu/:/i686-pc-linux-gnu/4.3.2/:/i686-pc-linux-gnu/:/media/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/bin/i686-pc-linux-gnu/4.3.2/:/media/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/bin/ libraries: =/media/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/:/media/lfs/tools/bin/../lib/gcc/:/i686-pc-linux-gnu/4.3.2/:/media/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/lib/i686-pc-linux-gnu/4.3.2/:/media/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/lib/:/media/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/../../../i686-pc-linux-gnu/4.3.2/:/media/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/../../../:/lib/i686-pc-linux-gnu/4.3.2/:/lib/:/usr/lib/i686-pc-linux-gnu/4.3.2/:/usr/lib/

To 'fix' all is:

sed -i -e 's@/usr/libexec/gcc@/tools/libexec/gcc@' \
       -e 's@/usr/lib/gcc@/tools/lib/gcc@' \
       -e 's@"/usr/lib/"@"/tools/lib/"@' \
       -e 's@"/lib/"@"/tools/lib/"@' \
       gcc/gcc.c

comment:5 by DJ Lucas, 16 years ago

The above changes give this:

[dj@name25 source-archive]# /tools/bin/gcc --print-search-dirs install: /media/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/ programs: =/media/lfs/tools/bin/../libexec/gcc/i686-pc-linux-gnu/4.3.2/:/media/lfs/tools/bin/../libexec/gcc/:/i686-pc-linux-gnu/4.3.2/:/i686-pc-linux-gnu/:/i686-pc-linux-gnu/4.3.2/:/i686-pc-linux-gnu/:/media/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/bin/i686-pc-linux-gnu/4.3.2/:/media/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/bin/ libraries: =/media/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/:/media/lfs/tools/bin/../lib/gcc/:/i686-pc-linux-gnu/4.3.2/:/media/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/lib/i686-pc-linux-gnu/4.3.2/:/media/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/lib/:/usr/lib/i686-pc-linux-gnu/4.3.2/:/usr/lib/

It is not only coming from gcc/gcc.c.

comment:6 by DJ Lucas, 16 years ago

Milestone: 6.47.0
Owner: changed from DJ Lucas to lfs-book@…
Status: assignednew

I'm at a loss for the moment. I'm also concerned about changing too much in our temporary tools this close to release. Pushing it off for 7.0. I'm not sure what the impact is if we adopt the cross-tools method for 7.0. Ideally, it should never get that far, however...

comment:7 by Jeremy Huntwork, 15 years ago

The change to DIY's new build method already changed the definition for STANDARD_STARTFILE_PREFIX_1 and 2. Currently, in trunk for gcc pass 2, there are (roughly, it's part of a bigger loop) these commands:

echo '
#define STANDARD_STARTFILE_PREFIX_1 ""
#define STANDARD_STARTFILE_PREFIX_2 ""' >> gcc/config/linux.h

But there are still references to paths in /usr. If we just do as you mention in your first suggestion, we should be alright. A slightly modified suggestion would be:

sed -i 's@/usr/.*/gcc/@@' gcc/gcc.c

The only thing is, that for both areas (libraries and programs) when we just unset the values of the variables, we end up with broken paths in the search dirs, too. When I add the above line into my build, here is the result (on x86_64):

install: /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/
programs: =/mnt/lfs/tools/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.2/:/mnt/lfs/tools/bin/../libexec/gcc/:x86_64-unknown-linux-gnu/4.3.2/:x86_64-unknown-linux-gnu/:x86_64-unknown-linux-gnu/4.3.2/:x86_64-unknown-linux-gnu/:/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu/4.3.2/:/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../x86_64-unknown-linux-gnu/bin/
libraries: =/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/:/mnt/lfs/tools/bin/../lib/gcc/:x86_64-unknown-linux-gnu/4.3.2/:/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../x86_64-unknown-linux-gnu/lib/x86_64-unknown-linux-gnu/4.3.2/:/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../x86_64-unknown-linux-gnu/lib/:/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../x86_64-unknown-linux-gnu/4.3.2/:/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../:/tools/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../x86_64-unknown-linux-gnu/4.3.2/:/tools/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../

Let me put a line break after the colons, so it's easier to read:

install: /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/

programs: =/mnt/lfs/tools/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.2/:
/mnt/lfs/tools/bin/../libexec/gcc/:
x86_64-unknown-linux-gnu/4.3.2/:
x86_64-unknown-linux-gnu/:
x86_64-unknown-linux-gnu/4.3.2/:
x86_64-unknown-linux-gnu/:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu/4.3.2/:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../x86_64-unknown-linux-gnu/bin/

libraries: =/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/:
/mnt/lfs/tools/bin/../lib/gcc/:
x86_64-unknown-linux-gnu/4.3.2/:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../x86_64-unknown-linux-gnu/lib/x86_64-unknown-linux-gnu/4.3.2/:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../x86_64-unknown-linux-gnu/lib/:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../x86_64-unknown-linux-gnu/4.3.2/:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../:
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../x86_64-unknown-linux-gnu/4.3.2/:
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../

So, the main objective is achieved, there are no more references to /usr, but there are now definitely broken directories in the search paths, too. This doesn't seem to be a big deal, but I wonder if we can adjust those to be valid too...

comment:8 by Jeremy Huntwork, 15 years ago

OK, I adjusted the above once more to do the following in gcc pass 2.

  1. Adjust the current setting of STANDARD_STARTFILE_PREFIX_1 and 2 to be the following:
    #define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"
    #define STANDARD_STARTFILE_PREFIX_2 "/tools/lib/"
    
  2. Use the following sed to swap 'usr' for 'tools' on only the lines for the standard_exec_prefix_1 and 2 in gcc/gcc.c:
    sed -i '/usr\/li.*\/gcc/s@usr@tools@' gcc/gcc.c
    

When the gcc pass 2 build finishes, gcc -print-search-dirs outputs the following (line breaks inserted after colons for readability):

install: /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/

programs: =/mnt/lfs/tools/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.2/:
/mnt/lfs/tools/bin/../libexec/gcc/:
/tools/libexec/gcc/x86_64-unknown-linux-gnu/4.3.2/:
/tools/libexec/gcc/x86_64-unknown-linux-gnu/:
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/:
/tools/lib/gcc/x86_64-unknown-linux-gnu/:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu/4.3.2/:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../x86_64-unknown-linux-gnu/bin/

libraries: =/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/:
/mnt/lfs/tools/bin/../lib/gcc/:
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../x86_64-unknown-linux-gnu/lib/x86_64-unknown-linux-gnu/4.3.2/:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../x86_64-unknown-linux-gnu/lib/:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../x86_64-unknown-linux-gnu/4.3.2/:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../:
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../x86_64-unknown-linux-gnu/4.3.2/:
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../:
/tools/lib/x86_64-unknown-linux-gnu/4.3.2/:
/tools/lib/:
/tools/lib/x86_64-unknown-linux-gnu/4.3.2/:
/tools/lib/

comment:9 by Jeremy Huntwork, 15 years ago

One last note, I just noticed a reply Greg made to this ticket when it was first opened a year ago: http://linuxfromscratch.org/pipermail/lfs-book/2007-December/021637.html

Indeed, using the test he provides, even without changing anything, the gcc built in pass 2 does not appear to actually search /usr for anything. Adding in the above changes would appear to only make the output of -print-search-dirs more reassuring.

in reply to:  9 comment:10 by Matthew Burgess, 15 years ago

Resolution: invalid
Status: newclosed

Replying to jhuntwork@…:

Indeed, using the test he provides, even without changing anything, the gcc built in pass 2 does not appear to actually search /usr for anything.

In which case, I'm closing this as invalid.

Note: See TracTickets for help on using tickets.