[Bug driver/19353] Faulty handling of (some) user specified specs

[Bug driver/19353] Faulty handling of (some) user specified specs

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-11 12:46:11 UTC ---
User-defined specs are not really supposed to exist (and the situation with
them intentionally gets worse).

[Bug driver/19353] Faulty handling of (some) user specified specs

[gschafer at zip dot com dot au]

------- Comment #7 from gschafer at zip dot com dot au  2006-10-11 06:18 -------
The root cause of this bug is obvious after studying gcc.c.  Essentially, the
user specified specs are read _way_ too late in the process.  The sequence is
roughly this:

 1 - search for default specs file, if found load it
 2 - set up the standard search paths "Look for executables and startfiles in
the standard places"
 3 - process any user specified specs from the command line

It never used to be like this!  The user specified specs used to be processed
immediately after the default specs were loaded (which was much saner).  The
behavior was changed back in 1999 for the benefit of the Java front end which
wants to use "-specs=libgcj.spec" and have the specs file found automatically:

http://gcc.gnu.org/ml/gcc-patches/1999-06n/msg00511.html

gcc.c has evolved much since then so currently it's impossible for the user to
override on the command line a few specs that appear in step (2) above, namely:
"sysroot_suffix_spec", "sysroot_hdrs_suffix_spec", "startfile_prefix_spec",
"md_startfile_prefix" and "md_startfile_prefix_1".

Reverting the 1999 patch fixes the bug but of course breaks linking of Java
user programs.  In retrospect, Java should probably have implemented something
a bit less fragile than this "solution" IMHO.

Just removing "startfile_prefix_spec" is not the correct action because as
mentioned above, other specs are also affected.  Not only that, some folks (LFS
in particular) have latched onto that spec and rely on it for their build
procedures, even tho' it is completely *undocumented* and its usefulness is
questionable.

Re-titling bug to reflect reality.


-- 

gschafer at zip dot com dot au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Faulty handling of          |Faulty handling of (some)
                   |startfile_prefix_spec       |user specified specs


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