Opened 17 years ago
Closed 16 years ago
#2114 closed defect (invalid)
gcc -print-search-dirs gives directories outside /tools directory
Reported by: | Marco Fonseca | Owned by: | |
---|---|---|---|
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 , 16 years ago
Milestone: | 7.0 → 6.4 |
---|
comment:3 by , 16 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 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 , 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 , 16 years ago
Milestone: | 6.4 → 7.0 |
---|---|
Owner: | changed from | to
Status: | assigned → new |
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 , 16 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 , 16 years ago
OK, I adjusted the above once more to do the following in gcc pass 2.
- 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/"
- 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/
follow-up: 10 comment:9 by , 16 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.
comment:10 by , 16 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
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.
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:
I'll drop it in tonight and report back tomorrow.