public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: NM and AR not being used?
       [not found] <E1Bidol-0000cS-D4@mikro.physik.TU-Berlin.DE>
@ 2004-07-11  9:53 ` Jim Wilson
  2004-07-11 11:37   ` Andreas Schwab
  0 siblings, 1 reply; 3+ messages in thread
From: Jim Wilson @ 2004-07-11  9:53 UTC (permalink / raw)
  To: Georg Schwarz; +Cc: gcc, gcc-patches

[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]

On Thu, 2004-07-08 at 11:40, Georg Schwarz wrote:
> > Georg Schwarz wrote:
> > > env AR=/usr/local/mips-sgi-irix5.3/bin/AR
> > > NM=/usr/local/mips-sgi-irix5.3/bin/nm
> > > RANLIB=/usr/local/mips-sgi-irix5.3/bin/ranlib CONFIG_SHELL=/bin/ksh
> > > /usr/people/schwarz/gcc-3.4.0/configure --prefix=/usr/local
> > > --with-gnu-as --with-gnu-ld --with-as=/usr/local/mips-sgi-irix5.3/bin/as
> > > --with-ld=/usr/local/mips-sgi-irix5.3/bin/ld
> > > --enable-languages=c,c++,ada

I didn't get around to creating a bugzilla bug report, but I have done
quite a bit more investigation.

When you configure this way, the toplevel Makefile gets the new NM
values written into it.  The gcc Makefile does not.  When you do "make
all-gcc", the toplevel value of NM is passed down to the gcc Makefile,
and it works as expected.  When you do "make bootstrap", the toplevel
value of NM is passed down to the gcc Makefile, and then the gcc
Makefile does a recursive make without passing down any arguments and
this value gets lost.  We do export NM_FOR_TARGET which seems like it
should work, but the NM_FOR_TARGET value that gets exported is the value
defined in the gcc Makefile, not the value that was passed down from the
toplevel.  I don't know why exports are working this way.

Assuming this is the way things are supposed to work in make, then
solving this problem seems to require autoconf tests for AR and NM in
the gcc directory, so that we get the environment variable values
written into the gcc Makefile.  That attached patch does this, and with
this patch I get the expected result for your configure/make commands.

I'm not really a configure/make expert, so if someone could confirm that
this is the right approach I would appreciate that.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

[-- Attachment #2: patch.ar.nm --]
[-- Type: text/plain, Size: 2910 bytes --]

2004-07-10  James E Wilson  <wilson@specifixinc.com>

	* Makefile.in (AR): Use @AR@ not ar.
	(NM): New.
	(AR_FOR_TARGET): Use $(AR) not ar for native.
	(NM_FOR_TARGET): Use $(NM) not nm for native.
	* configure.ac: Add AC_CHECK_PROG calls for NM and AR.
	* configure: Regenerate.
	
Index: Makefile.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.1320
diff -p -r1.1320 Makefile.in
*** Makefile.in	6 Jul 2004 16:28:29 -0000	1.1320
--- Makefile.in	11 Jul 2004 05:00:56 -0000
*************** BISON = @BISON@
*** 221,228 ****
  BISONFLAGS =
  FLEX = @FLEX@
  FLEXFLAGS =
! AR = ar
  AR_FLAGS = rc
  RANLIB = @RANLIB@
  RANLIB_FLAGS = @ranlib_flags@
  
--- 221,229 ----
  BISONFLAGS =
  FLEX = @FLEX@
  FLEXFLAGS =
! AR = @AR@
  AR_FLAGS = rc
+ NM = @NM@
  RANLIB = @RANLIB@
  RANLIB_FLAGS = @ranlib_flags@
  
*************** AR_FOR_TARGET := $(shell \
*** 326,332 ****
      echo $(objdir)/../binutils/ar ; \
    else \
      if [ "$(host)" = "$(target)" ] ; then \
!       echo ar; \
      else \
         t='$(program_transform_name)'; echo ar | sed -e $$t ; \
      fi; \
--- 327,333 ----
      echo $(objdir)/../binutils/ar ; \
    else \
      if [ "$(host)" = "$(target)" ] ; then \
!       echo $(AR); \
      else \
         t='$(program_transform_name)'; echo ar | sed -e $$t ; \
      fi; \
*************** NM_FOR_TARGET := $(shell \
*** 351,357 ****
      echo $(objdir)/../binutils/nm-new ; \
    else \
      if [ "$(host)" = "$(target)" ] ; then \
!       echo nm; \
      else \
         t='$(program_transform_name)'; echo nm | sed -e $$t ; \
      fi; \
--- 352,358 ----
      echo $(objdir)/../binutils/nm-new ; \
    else \
      if [ "$(host)" = "$(target)" ] ; then \
!       echo $(NM); \
      else \
         t='$(program_transform_name)'; echo nm | sed -e $$t ; \
      fi; \
Index: configure.ac
===================================================================
RCS file: /cvs/gcc/gcc/gcc/configure.ac,v
retrieving revision 2.44
diff -p -r2.44 configure.ac
*** configure.ac	4 Jul 2004 17:18:59 -0000	2.44
--- configure.ac	11 Jul 2004 05:00:57 -0000
*************** else
*** 799,804 ****
--- 799,819 ----
    AC_CHECK_PROG(BISON, bison, bison, ${CONFIG_SHELL-/bin/sh} ${srcdir}/../missing bison)
  fi
  
+ # NM
+ if test x${build} = x${host} && test -f $srcdir/../binutils/nm.c; then
+   NM='$(objdir)/../binutils/nm-new'
+ else
+   AC_CHECK_PROG(NM, nm, nm, ${CONFIG_SHELL-/bin/sh} ${srcdir}/../missing nm)
+ fi
+ 
+ # AR
+ if test x${build} = x${host} && test -f $srcdir/../binutils/ar.c; then
+   AR='$(objdir)/../binutils/ar'
+ else
+   AC_CHECK_PROG(AR, ar, ar, ${CONFIG_SHELL-/bin/sh} ${srcdir}/../missing ar)
+ fi
+ 
+ 
  # --------------------
  # Checks for C headers
  # --------------------

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: NM and AR not being used?
  2004-07-11  9:53 ` NM and AR not being used? Jim Wilson
@ 2004-07-11 11:37   ` Andreas Schwab
  2004-07-13 13:36     ` Jim Wilson
  0 siblings, 1 reply; 3+ messages in thread
From: Andreas Schwab @ 2004-07-11 11:37 UTC (permalink / raw)
  To: Jim Wilson; +Cc: Georg Schwarz, gcc, gcc-patches

Jim Wilson <wilson@specifixinc.com> writes:

> We do export NM_FOR_TARGET which seems like it should work, but the
> NM_FOR_TARGET value that gets exported is the value defined in the gcc
> Makefile, not the value that was passed down from the toplevel.  I don't
> know why exports are working this way.

Local makefile assignments always override values from the environment
(unless -e).  And since we null out MAKEOVERRIDES there are no implicit
command-line overrides passed down to recursive invocations.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: NM and AR not being used?
  2004-07-11 11:37   ` Andreas Schwab
@ 2004-07-13 13:36     ` Jim Wilson
  0 siblings, 0 replies; 3+ messages in thread
From: Jim Wilson @ 2004-07-13 13:36 UTC (permalink / raw)
  To: gcc-patches; +Cc: Andreas Schwab, Georg Schwarz

Andreas Schwab wrote:
> Local makefile assignments always override values from the environment
> (unless -e).  And since we null out MAKEOVERRIDES there are no implicit
> command-line overrides passed down to recursive invocations.

Thanks for the explanation.  I understand what is going on now.

I believe my suggested patch was the right approach given that 
explanation.  I have tested it with an x86-linux bootstrap and make 
check.  There was one libjava regression, but it appears to be a memory 
corruption problem with mainline.  The testcase worked correctly when I 
ran it by hand.

Here is the one error I got:
pr83.java:0: internal compiler error: virtual array basic_block_info[6]: 
element 2947526575 out of bounds in set_up_bb_rts_numbers, at global.c:2118
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-07-13  2:27 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <E1Bidol-0000cS-D4@mikro.physik.TU-Berlin.DE>
2004-07-11  9:53 ` NM and AR not being used? Jim Wilson
2004-07-11 11:37   ` Andreas Schwab
2004-07-13 13:36     ` Jim Wilson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).