[Bug driver/19353] New: Faulty handling of startfile_prefix_spec

[Bug driver/19353] New: Faulty handling of startfile_prefix_spec

[gschafer at zip dot com dot au]

This test case is about the spec `startfile_prefix_spec', tho' I suspect the
problem might actually be a generic specs problem, but am not sure.

Scenario:
Say you want to link executables with startfiles different from those in the
default location on your system. Sure, I can use -B, but there are times when
you want this hardwired into the compiler's specs, so this bug is about specs
handling.

To reproduce the problem, follow these steps:

1. Copy some startfiles to /tmp
     cp /usr/lib/{crt1.o,crti.o,crtn.o} /tmp

2. GCC-4 no longer installs a specs file so we'll create a temporary one:
     gcc -dumpspecs > /tmp/specs

3. Now edit /tmp/specs so that startfile_prefix_spec points at /tmp/

4. Compile a dummy binary with -v and note that it DOES NOT pick up our start
files in /tmp:

$ echo 'main(){}' | cc -x c -specs=/tmp/specs -v -
Using built-in specs.
Reading specs from /tmp/specs
Configured with: ../gcc-20050106T052249/configure --libexecdir=/usr/lib
--enable-shared --enable-languages=c,c++ --enable-clocale=gnu
--enable-threads=posix --enable-__cxa_atexit --disable-checking
Thread model: posix
gcc version 4.0.0 20050106 (experimental)
 /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/cc1 -quiet -v - -quiet -dumpbase -
-mtune=pentiumpro -auxbase - -version -o /tmp/ccsb8sUR.s
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/include
 /usr/include
End of search list.
GNU C version 4.0.0 20050106 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 4.0.0 20050106 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -V -Qy -o /tmp/ccQlh4py.o /tmp/ccsb8sUR.s
GNU assembler version 2.15.94.0.2 (i686-pc-linux-gnu) using BFD version
2.15.94.0.2 20041220
 /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../crt1.o
/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/crtbegin.o
-L/usr/lib/gcc/i686-pc-linux-gnu/4.0.0 -L/usr/lib/gcc/i686-pc-linux-gnu/4.0.0
-L/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../.. /tmp/ccQlh4py.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/crtend.o
/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../crtn.o


5. This time we'll try again, with the difference being that we'll place a specs
file in GCC's default location:

gcc -dumpspecs > `gcc -print-search-dirs | head -n 1 | awk '{ print $2 }'`specs

6. Now edit this one as above ie: place /tmp/ into the startfile_prefix_spec

7. Again, compile a dummy binary with -v and note that this time it DOES pick up
our start files in /tmp:

$ echo 'main(){}' | cc -x c -v -
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc-20050106T052249/configure --libexecdir=/usr/lib
--enable-shared --enable-languages=c,c++ --enable-clocale=gnu
--enable-threads=posix --enable-__cxa_atexit --disable-checking
Thread model: posix
gcc version 4.0.0 20050106 (experimental)
 /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/cc1 -quiet -v - -quiet -dumpbase -
-mtune=pentiumpro -auxbase - -version -o /tmp/cchIqhHa.s
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/include
 /usr/include
End of search list.
GNU C version 4.0.0 20050106 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 4.0.0 20050106 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -V -Qy -o /tmp/ccevdSNe.o /tmp/cchIqhHa.s
GNU assembler version 2.15.94.0.2 (i686-pc-linux-gnu) using BFD version
2.15.94.0.2 20041220
 /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 /tmp/crt1.o /tmp/crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/crtbegin.o
-L/usr/lib/gcc/i686-pc-linux-gnu/4.0.0 -L/usr/lib/gcc/i686-pc-linux-gnu/4.0.0
-L/tmp /tmp/ccevdSNe.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/crtend.o
/tmp/crtn.o


The bug is that startfile_prefix_spec is not being used when I specify another
specs file using -specs=/tmp/specs. I can modify other specs (eg:
dynamic_linker) using the above technique and it works fine.

I tried 3.4.3 and 4.0 and this bug is present in both.

Thankyou

-- 
           Summary: Faulty handling of startfile_prefix_spec
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: driver
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: gschafer at zip dot com dot au
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353

[Bug driver/19353] Faulty handling of startfile_prefix_spec

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-10 02:36 -------
Hmm, this SPEC should be removed from the mainline, it is unused in GCC at all.
Most of the use of this was removed when this patch was applied:
<http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01218.html>.

In fact it was added only for Multi-lib places:
<http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01660.html>.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353

[Bug driver/19353] Faulty handling of startfile_prefix_spec

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-10 02:52 -------
Patch to remove STARTFILE_PREFIX_SPEC support:
<http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00507.html>.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353

[Bug driver/19353] Faulty handling of startfile_prefix_spec

[gschafer at zip dot com dot au]

------- Additional Comments From gschafer at zip dot com dot au  2005-01-12 05:46 -------
(In reply to comment #1)
> Hmm, this SPEC should be removed from the mainline, it is unused in GCC at all.

Ok, good. I suppose removing faulty code is better then leaving it there for
folks to (ab)use.

BTW, at first glance, the patch you posted cannot possibly be correct. An "if"
statement was removed but the following "else if" statement was left in place.
Then again, I could be wrong coz I haven't tested the patch.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353

[Bug driver/19353] Faulty handling of startfile_prefix_spec

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-12 05:49 -------
(In reply to comment #3)
> BTW, at first glance, the patch you posted cannot possibly be correct. An "if"
> statement was removed but the following "else if" statement was left in place.
> Then again, I could be wrong coz I haven't tested the patch.
oh, it only compiles because there is an if before but you are right, that "else if" should have been 
changed to an if. thanks.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353

[Bug driver/19353] Faulty handling of startfile_prefix_spec

[gschafer at zip dot com dot au]

------- Additional Comments From gschafer at zip dot com dot au  2005-01-27 21:39 -------
The patch was approved by the RM here:

  http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00850.html

but it is still not applied. It would be great if you could pls commit this
patch then close the BZ.

Many thanks.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353

[Bug driver/19353] Faulty handling of startfile_prefix_spec

[ryan dot oliver at pha dot com dot au]

------- Additional Comments From ryan dot oliver at pha dot com dot au  2005-02-08 07:22 -------
(In reply to comment #5)
> The patch was approved by the RM here:
> 
>   http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00850.html
> 
> but it is still not applied. It would be great if you could pls commit this
> patch then close the BZ.
> 
> Many thanks.

Greetings, coming in a bit late here...

I have noticed that startfile_prefix_spec is still handled by the driver as of
20050208.

I would personally not like to see this feature go, as it is incredibly useful
when building multilib toolchains (be it native or cross) where the startfiles
and libraries are not located in standard locations, and not located under the
prefix the compiler was installed to. Fair enough nothing internal to the gcc
build still uses it, but it still has a use...

Main thing it facilitates is building a multilib gcc linked against c-libraries
in a non standard location (te create a self hosted toolchain)
 
Use of -B/target/lib to specify the location of startfiles will not fly, you end
up linking in 32bit startfiles into your 64bit libgcc. Unless there is another
mechanism for specifying the location, and have it get adjusted by the multilib
spec, multilib gcc builds in this scenario aren't possible (without much hackery
and pain).

Here the simple adjustment of startfile_prefix_spec to /target/lib/ ensures
everything will build correctly.

It also proves invaluable when cross-compiling a self-hosted toolchain for a
multilib target w/o using --with-sysroot (which isn't appropriate in all
circumstances)

I do hope that you will reconsider the full application of this patch, true it
wont take a lot to maintain a patch which reverts these changes, but I surely
would prefer to not have to do so...

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353