GCC_FOR_TARGET x linker scripts

GCC_FOR_TARGET x linker scripts

[Alexandre Oliva]

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

The top-level GCC_FOR_TARGET is set such that, if we're building GNU
ld, it contains -L$$r/ld, such that we find any linker scripts we
might need.

Unfortunately, the definition in gcc/Makefile.in doesn't ever search
that directory, so when running make bootstrap in the gcc
subdirectory, if we need linker scripts from the unified-build
directory, we don't find them.  There was also some condition that I
don't remember exactly that led me to conclude that we had to pass
GCC_FOR_TARGET down to sub-makes, otherwise the definition without
the ability to find linker scripts would supersede.  I wish I had
contributed this earlier, just when I found the need for it, but I had
forgotten about it.  My apologies.

Anyway, here's the patch, tested on mips-sgi-irix6.5 with GNU ld, only
to the point in which I verified that the right definition of
GCC_FOR_TARGET was being used for building target libraries in stage1
of a bootstrap, started from both the top level and from the gcc
sub-directory.  It was also fully tested in hundreds of bootstraps
that I ran after coming up with this patch.

I'm checking this in the 3.4-b-i-branch.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gcc-for-target.patch --]
[-- Type: text/x-patch, Size: 1756 bytes --]

Index: gcc/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	* Makefile.in (GCC_FOR_TARGET): Add -L$(objdir)/../ld.
	(STAGE2_FLAGS_TO_PASS): Pass GCC_FOR_TARGET.
	(stage1_build): Likewise.

Index: gcc/Makefile.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.939.2.10
diff -u -p -r1.939.2.10 Makefile.in
--- gcc/Makefile.in 21 Oct 2002 17:51:50 -0000 1.939.2.10
+++ gcc/Makefile.in 25 Oct 2002 03:04:57 -0000
@@ -182,7 +182,7 @@ USER_H = $(srcdir)/ginclude/float.h \
 # The GCC to use for compiling libgcc.a and crt*.o.
 # Usually the one we just built.
 # Don't use this as a dependency--use $(GCC_PASSES) or $(GCC_PARTS).
-GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./xgcc -B./ -B$(build_tooldir)/bin/ -isystem $(build_tooldir)/include -isystem $(build_tooldir)/sys-include
+GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./xgcc -B./ -B$(build_tooldir)/bin/ -isystem $(build_tooldir)/include -isystem $(build_tooldir)/sys-include -L$(objdir)/../ld
 
 # This is used instead of ALL_CFLAGS when compiling with GCC_FOR_TARGET.
 # It omits XCFLAGS, and specifies -B./.
@@ -3314,6 +3314,7 @@ VOL_FILES=`echo $(BACKEND) $(OBJS) $(C_O
 # the context of the stage_x rule.
 STAGE2_FLAGS_TO_PASS = \
 	ADAC="\$$(CC)" \
+	GCC_FOR_TARGET="$(GCC_FOR_TARGET)" \
 	CFLAGS="$(BOOT_CFLAGS)" \
 	LDFLAGS="$(BOOT_LDFLAGS)" \
 	WARN_CFLAGS="\$$(GCC_WARN_CFLAGS)" \
@@ -3331,6 +3332,7 @@ STAGE2_FLAGS_TO_PASS = \
 stage1_build:
 	$(MAKE) CC="$(CC)" libdir=$(libdir) LANGUAGES="$(BOOT_LANGUAGES)" \
 		CFLAGS="$(STAGE1_CFLAGS)" MAKEINFO="$(MAKEINFO)" \
+		GCC_FOR_TARGET="$(GCC_FOR_TARGET)" \
 		MAKEINFOFLAGS="$(MAKEINFOFLAGS)" COVERAGE_FLAGS=
 	$(STAMP) stage1_build
 	echo stage1_build > stage_last

[-- Attachment #3: Type: text/plain, Size: 289 bytes --]


-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: GCC_FOR_TARGET x linker scripts

[Daniel Jacobowitz]

On Fri, Oct 25, 2002 at 12:18:01AM -0300, Alexandre Oliva wrote:
> The top-level GCC_FOR_TARGET is set such that, if we're building GNU
> ld, it contains -L$$r/ld, such that we find any linker scripts we
> might need.
> 
> Unfortunately, the definition in gcc/Makefile.in doesn't ever search
> that directory, so when running make bootstrap in the gcc
> subdirectory, if we need linker scripts from the unified-build
> directory, we don't find them.  There was also some condition that I
> don't remember exactly that led me to conclude that we had to pass
> GCC_FOR_TARGET down to sub-makes, otherwise the definition without
> the ability to find linker scripts would supersede.  I wish I had
> contributed this earlier, just when I found the need for it, but I had
> forgotten about it.  My apologies.
> 
> Anyway, here's the patch, tested on mips-sgi-irix6.5 with GNU ld, only
> to the point in which I verified that the right definition of
> GCC_FOR_TARGET was being used for building target libraries in stage1
> of a bootstrap, started from both the top level and from the gcc
> sub-directory.  It was also fully tested in hundreds of bootstraps
> that I ran after coming up with this patch.
> 
> I'm checking this in the 3.4-b-i-branch.

Can I offer a suggestion?

I assume that the -L$$r/ld comes in via @FLAGS_FOR_TARGET@... yes, it
does.  Why should the definition in gcc/Makefile.in be any different? 
Is there any reason that the same FLAGS_FOR_TARGET and GCC_FOR_TARGET
won't work?

I have to override this in two places now because setting
FLAGS_FOR_TARGET affects the top level, and thus libstdc++-v3 (via
CC_FOR_TARGET), but not GCC.  It'd be nice if FLAGS_FOR_TARGET worked
consistently.

If you don't see anything wrong with this I'll put the patch together. 
I'd really like to cut down on gratuitous differences between GCC's
variables and the top level's.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GCC_FOR_TARGET x linker scripts

[Alexandre Oliva]

On Oct 25, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:

> I assume that the -L$$r/ld comes in via @FLAGS_FOR_TARGET@... yes, it
> does.  Why should the definition in gcc/Makefile.in be any different? 
> Is there any reason that the same FLAGS_FOR_TARGET and GCC_FOR_TARGET
> won't work?

Well, gcc/configure.in would have to duplicate the logic of
FLAGS_FOR_TARGET, no?

> I have to override this in two places now because setting
> FLAGS_FOR_TARGET affects the top level, and thus libstdc++-v3 (via
> CC_FOR_TARGET), but not GCC.  It'd be nice if FLAGS_FOR_TARGET worked
> consistently.

It should work consistently.  I think this patch actually fixes one of
the inconsistencies, which was that GCC_FOR_TARGET was not propagated
down to sub-bootstrap targets, so the definition gcc/Makefile, without
FLAGS_FOR_TARGET, prevailed.

The setting in GCC_FOR_TARGET should ideally be semantically (if not
syntactically) equivalent to that in the top-level, but we don't want
to duplicate the code to do that.

> If you don't see anything wrong with this I'll put the patch together. 

I'd be interested in seeing what you have in mind, yes.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Pass FLAGS_FOR_TARGET to subdirectories (was: Re: GCC_FOR_TARGET x linker scripts)

[Daniel Jacobowitz]

On Fri, Oct 25, 2002 at 01:22:58AM -0300, Alexandre Oliva wrote:
> On Oct 25, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> 
> > I assume that the -L$$r/ld comes in via @FLAGS_FOR_TARGET@... yes, it
> > does.  Why should the definition in gcc/Makefile.in be any different? 
> > Is there any reason that the same FLAGS_FOR_TARGET and GCC_FOR_TARGET
> > won't work?
> 
> Well, gcc/configure.in would have to duplicate the logic of
> FLAGS_FOR_TARGET, no?

Well, I was planning to pass the value down from the top level at
configure time.  Easiest would be in the environment, but FLAGS_TO_PASS
can get a little large, so that might be unwise.  I also could have
just picked it out of ../Makefile, but that's a little bit too magical
for my taste, so I wrote it to a new file.

Note that GCC_FOR_TARGET in gcc/Makefile.in includes "-isystem
$(build_tooldir)/sys-include".  In the top level it doesn't.  It's only
there because the compiler (if it's configured to look for
$(gcc_tooldir)/sys-include at all) won't necessarily find it at build
time when $(gcc_tooldir) doesn't exist... I left it alone for now, but
it should probably move to the top-level FLAGS_FOR_TARGET.

Here's what I came up with; what do you think?  The file can be
extended to pass up any other logic we want to be in the top level.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2002-10-28  Daniel Jacobowitz  <drow@mvista.com>

	* configure.in: Write FLAGS_FOR_TARGET to config.vars.
	* Makefile.in (local-distclean): Clean config.vars.

2002-10-28  Daniel Jacobowitz  <drow@mvista.com>

	* configure.in: Load ../config.vars.  Substitute FLAGS_FOR_TARGET.
	* configure: Regenerated.
	* Makefile.in (FLAGS_FOR_TARGET): Define.
	(GCC_FOR_TARGET): Use $(FLAGS_FOR_TARGET).

Index: configure.in
===================================================================
RCS file: /cvs/gcc/gcc/configure.in,v
retrieving revision 1.177.4.2
diff -u -p -r1.177.4.2 configure.in
--- configure.in	15 Oct 2002 01:32:20 -0000	1.177.4.2
+++ configure.in	28 Oct 2002 20:17:54 -0000
@@ -1536,6 +1536,12 @@ qCXX_FOR_TARGET=`echo "$CXX_FOR_TARGET" 
 # macros.
 qqCXX_FOR_TARGET=`echo "$qCXX_FOR_TARGET" | sed -e 's,[$][$],$$$$,g'`
 
+# Save FLAGS_FOR_TARGET for subdirectory configures.
+qFLAGS_FOR_TARGET=`echo "$FLAGS_FOR_TARGET" | sed -e "s/'/'\\\\''/g"`
+cat >config.vars <<EOF
+FLAGS_FOR_TARGET='${qFLAGS_FOR_TARGET}'
+EOF
+
 sedtemp=sed.$$
 cat >$sedtemp <<EOF
 s:@target_configdirs@:${target_configdirs}:
Index: gcc/Makefile.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.939.2.11
diff -u -p -r1.939.2.11 Makefile.in
--- gcc/Makefile.in	25 Oct 2002 03:18:37 -0000	1.939.2.11
+++ gcc/Makefile.in	28 Oct 2002 20:17:58 -0000
@@ -179,10 +179,12 @@ USER_H = $(srcdir)/ginclude/float.h \
 	 $(srcdir)/ginclude/varargs.h \
 	 $(EXTRA_HEADERS)
 
+FLAGS_FOR_TARGET = @FLAGS_FOR_TARGET@
+
 # The GCC to use for compiling libgcc.a and crt*.o.
 # Usually the one we just built.
 # Don't use this as a dependency--use $(GCC_PASSES) or $(GCC_PARTS).
-GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./xgcc -B./ -B$(build_tooldir)/bin/ -isystem $(build_tooldir)/include -isystem $(build_tooldir)/sys-include -L$(objdir)/../ld
+GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./xgcc -B./ $(FLAGS_FOR_TARGET) -isystem $(build_tooldir)/sys-include
 
 # This is used instead of ALL_CFLAGS when compiling with GCC_FOR_TARGET.
 # It omits XCFLAGS, and specifies -B./.
Index: gcc/configure.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/configure.in,v
retrieving revision 1.617.4.4
diff -u -p -r1.617.4.4 configure.in
--- gcc/configure.in	20 Oct 2002 01:03:49 -0000	1.617.4.4
+++ gcc/configure.in	28 Oct 2002 20:18:07 -0000
@@ -1177,6 +1177,15 @@ for f in $build_xm_file; do
   esac
 done
 
+# Pick up some definitions from the top level.
+if test -r ../config.vars; then
+  . ../config.vars
+else
+  echo '"config.vars" is missing; re-run configure at the top level to create it.' 1>&2
+  exit 1
+fi
+AC_SUBST(FLAGS_FOR_TARGET)
+
 # Define macro CROSS_COMPILE in compilation if this is a cross-compiler.
 # Also use all.cross instead of all.internal and adjust SYSTEM_HEADER_DIR.
 CROSS=						AC_SUBST(CROSS)
Index: Makefile.in
===================================================================
RCS file: /cvs/gcc/gcc/Makefile.in,v
retrieving revision 1.111.4.2
diff -u -p -r1.111.4.2 Makefile.in
--- Makefile.in	15 Oct 2002 01:32:20 -0000	1.111.4.2
+++ Makefile.in	28 Oct 2002 20:36:12 -0000
@@ -1000,6 +1000,7 @@ local-clean:
 
 local-distclean:
 	-rm -f Makefile config.status config.cache mh-frag mt-frag
+	-rm -f config.vars
 	-if [ "$(TARGET_SUBDIR)" != "." ]; then \
 	  rm -rf $(TARGET_SUBDIR); \
 	else true; fi

Re: Pass FLAGS_FOR_TARGET to subdirectories (was: Re: GCC_FOR_TARGET x linker scripts)

[Daniel Jacobowitz]

On Mon, Oct 28, 2002 at 03:37:38PM -0500, Daniel Jacobowitz wrote:
> On Fri, Oct 25, 2002 at 01:22:58AM -0300, Alexandre Oliva wrote:
> > On Oct 25, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> > 
> > > I assume that the -L$$r/ld comes in via @FLAGS_FOR_TARGET@... yes, it
> > > does.  Why should the definition in gcc/Makefile.in be any different? 
> > > Is there any reason that the same FLAGS_FOR_TARGET and GCC_FOR_TARGET
> > > won't work?
> > 
> > Well, gcc/configure.in would have to duplicate the logic of
> > FLAGS_FOR_TARGET, no?
> 
> Well, I was planning to pass the value down from the top level at
> configure time.  Easiest would be in the environment, but FLAGS_TO_PASS
> can get a little large, so that might be unwise.  I also could have
> just picked it out of ../Makefile, but that's a little bit too magical
> for my taste, so I wrote it to a new file.
> 
> Note that GCC_FOR_TARGET in gcc/Makefile.in includes "-isystem
> $(build_tooldir)/sys-include".  In the top level it doesn't.  It's only
> there because the compiler (if it's configured to look for
> $(gcc_tooldir)/sys-include at all) won't necessarily find it at build
> time when $(gcc_tooldir) doesn't exist... I left it alone for now, but
> it should probably move to the top-level FLAGS_FOR_TARGET.
> 
> Here's what I came up with; what do you think?  The file can be
> extended to pass up any other logic we want to be in the top level.

> 2002-10-28  Daniel Jacobowitz  <drow@mvista.com>
> 
> 	* configure.in: Write FLAGS_FOR_TARGET to config.vars.
> 	* Makefile.in (local-distclean): Clean config.vars.
> 
> 2002-10-28  Daniel Jacobowitz  <drow@mvista.com>
> 
> 	* configure.in: Load ../config.vars.  Substitute FLAGS_FOR_TARGET.
> 	* configure: Regenerated.
> 	* Makefile.in (FLAGS_FOR_TARGET): Define.
> 	(GCC_FOR_TARGET): Use $(FLAGS_FOR_TARGET).

I'm withdrawing this patch for now, per my discussion with Nathanael. 
I'll submit it again when we've autoconfed.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Pass FLAGS_FOR_TARGET to subdirectories (was: Re: GCC_FOR_TARGET x linker scripts)

[Alexandre Oliva]

On Oct 28, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:

> Note that GCC_FOR_TARGET in gcc/Makefile.in includes "-isystem
> $(build_tooldir)/sys-include".

I suppose this is no longer necessary, now that we warn or bail out when we
can't find ${SYSTEM_HEADER_DIR}.  We don't bail out when
SYSTEM_HEADER_DIR is ${gcc_tooldir}/sys-include, but we warn about the
problem, and `make install-gcc-tooldir' is the fix, so I think we can
lose this -isystem now.

> Here's what I came up with; what do you think?

I still find this a bit too magic.  Passing it in the environment
sounds ``more right´´ to me.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Pass FLAGS_FOR_TARGET to subdirectories (was: Re: GCC_FOR_TARGET x linker scripts)

[Daniel Jacobowitz]

On Wed, Nov 06, 2002 at 04:15:52PM -0200, Alexandre Oliva wrote:
> On Oct 28, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> 
> > Note that GCC_FOR_TARGET in gcc/Makefile.in includes "-isystem
> > $(build_tooldir)/sys-include".
> 
> I suppose this is no longer necessary, now that we warn or bail out when we
> can't find ${SYSTEM_HEADER_DIR}.  We don't bail out when
> SYSTEM_HEADER_DIR is ${gcc_tooldir}/sys-include, but we warn about the
> problem, and `make install-gcc-tooldir' is the fix, so I think we can
> lose this -isystem now.
> 
> > Here's what I came up with; what do you think?
> 
> I still find this a bit too magic.  Passing it in the environment
> sounds ``more right´´ to me.

I'm worried that this won't work, though.  Aren't there environment
size limits to consider?

(And I find passing arguments to sub-configures in the environment
mighty magical, too, since it doesn't show up in config.status that you
did so!)

In any case, I'm holding off on this patch until we autoconf so that I
won't just have to redo it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Pass FLAGS_FOR_TARGET to subdirectories (was: Re: GCC_FOR_TARGET x linker scripts)

[Alexandre Oliva]

On Nov  6, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:

> On Wed, Nov 06, 2002 at 04:15:52PM -0200, Alexandre Oliva wrote:
>> On Oct 28, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
>> 
>> > Note that GCC_FOR_TARGET in gcc/Makefile.in includes "-isystem
>> > $(build_tooldir)/sys-include".
>> 
>> I suppose this is no longer necessary, now that we warn or bail out when we
>> can't find ${SYSTEM_HEADER_DIR}.  We don't bail out when
>> SYSTEM_HEADER_DIR is ${gcc_tooldir}/sys-include, but we warn about the
>> problem, and `make install-gcc-tooldir' is the fix, so I think we can
>> lose this -isystem now.
>> 
>> > Here's what I came up with; what do you think?
>> 
>> I still find this a bit too magic.  Passing it in the environment
>> sounds ``more right´´ to me.

> I'm worried that this won't work, though.  Aren't there environment
> size limits to consider?

Perhaps.  It's not like it grows that big, anyway, and make will
export it to sub-makes anyway, so it's not like we're saving a lot
here.

> (And I find passing arguments to sub-configures in the environment
> mighty magical, too, since it doesn't show up in config.status that you
> did so!)

Good point, I hadn't thought of that.  I'd go with picking it from
../Makefile and, failing that, from the environment, then.

Or perhaps, after we upgrade gcc to autoconf 2.5x, we can take
advantage of the preservation of environment variables in the
configure command line and cache files.

> In any case, I'm holding off on this patch until we autoconf so that I
> won't just have to redo it.

Sounds good to me.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer