970901 - cross problem with libio/gen-params

Ian Lance Taylor ian@cygnus.com
Wed Sep 3 10:16:00 GMT 1997


   Date: Wed, 3 Sep 1997 12:08:21 -0500 (CDT)
   From: Joel Sherrill <joel@OARcorp.com>

   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



More information about the Gcc mailing list