------- 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
