[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Confusion with gcc on 'specs' file...



	I think I have hit a strange bug in the potato version of gcc
(which does not exist in slink's gcc). I was attempting to build a cross
compiler for a m68k-aout target on my Debian 2.2 (Potato) x86 machine. The
Debian machine was updated to the Potato archive on Sat, 2/26/00. 
	The build process creates a 'specs' file in different directories
for the xgcc (cross compiling gcc being built) to use. But the potato
version of gcc (the system gcc) is also reading these specs files and
getting (understandably) confused. Here is an example of what I mean:

Debian 2.2:

$ rm ./specs
$ gcc -v 
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
gcc version 2.95.2 20000220 (Debian GNU/Linux)
$ touch specs
$ gcc -v 
Reading specs from ./specs
gcc version 2.95.2 20000220 (Debian GNU/Linux)

Debian 2.1r4

$ rm ./specs
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.3/specs
gcc version 2.7.2.3
$ touch specs
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.3/specs
gcc version 2.7.2.3

	The end result is that the build process for the cross compiler
fails unless these xgcc specs file are remove at certain points (which is
tedious to get right). 
	There is no metion of this anywhere in the debian-devel mailing
list archives, in the bug list on the gcc package, or in the gcc package
change log. So, am I (and the cross-gcc build process) misunderstanding
something, or is this a bug? If it is, I will file a bug report against
it (probably serverity normal or important).

	PS. A RH6 machine with gcc 2.91.66 behaves as the slink machine
did, i.e. did not listen to the local specs file.

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------




Reply to: