From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Lance Taylor To: joel@OARcorp.com Cc: egcs@cygnus.com Subject: Re: 970901 - cross problem with libio/gen-params Date: Wed, 03 Sep 1997 10:16:00 -0000 Message-id: <199709031716.NAA16865@subrogation.cygnus.com> References: X-SW-Source: 1997-09/msg00099.html Date: Wed, 3 Sep 1997 12:08:21 -0500 (CDT) From: Joel Sherrill I tried to build egcs-970901 to target sparc-rtems. This was a buidl from scratch and I did not have another sparc-rtems toolset in my path. The script libio/gen-params wanted to use an installed sparc-rtems-nm not the one which is still in the build tree. It does not look like gen-params has changed since the 970825 snapshot, so I do not know what broke. I don't know if this is the problem, but here is a potential problem which might cause the symptoms you are reporting. The current development sources of the binutils generate nm-new rather than nm.new. This is for easier use on Windows systems, so that we can generate nm-new.exe without worrying about the multiple extensions in nm.new.exe (it's true that nm.new.exe will work on new MS file systems, but it's easier to sidestep the whole issue for the benefit of old 8.3 file systems). The top level Makefile.in in the egcs release looks for nm-new. If you are using this with, e.g., binutils 2.8.1, which produces nm.new, then the top level Makefile.in won't find the nm program in the build directory. That will cause it to use nm from your path instead. The fix is to change the top level Makefile.in to look for nm.new rather than nm-new. Similar cases arise for some other programs; search for `-new' in Makefile.in. I don't know if this is really an egcs problem; the problem will only arise if you try to mix egcs with the binutils 2.8.1 release in the same directory tree. When the egcs CVS server is up and running, I hope to start putting the development binutils releases on it as well. At that time, it will be possible to get a single consistent tree. Ian