This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, libgfortran] Remove AM_MAKEFLAGS.


Steve Ellcey <sje@cup.hp.com> writes:

> The problem I had on ia64 was that when AM_MAKEFLAGS was not set then
> CC_FOR_TARGET was undefined during the libgfortran build.  Attached is
> the tail end of a makelog from before I made the change.  It looks like
> CFLAGS_FOR_TARGET was not being set either.

I was able to successfully cross-build libgfortran on Fedora Core 1
(targetting xscale-elf) after reverting your patch.

> gmake[2]: Entering directory `/CLO/Products/OPENSOURCE/cvs/obj_ia_gcc/ia64-hp-hpux11.00/libgfortran'
> /bin/sh ./libtool --mode=compile (CC_FOR_TARGET) -DHAVE_CONFIG_H -I. -I/CLO/Products/OPENSOURCE/cvs/gcc/libgfortran -I.  -I/CLO/Products/OPENSOURCE/cvs/gcc/libgfortran/io -O2 -g -std=gnu99 (CFLAGS_FOR_TARGET) -c -o environ.lo `test -f 'runtime/environ.c' || echo '/CLO/Products/OPENSOURCE/cvs/gcc/libgfortran/'`runtime/environ.c
> /bin/sh: Syntax error at line 1 : `(' is not expected.
> gmake[2]: *** [environ.lo] Error 2
> gmake[2]: Leaving directory `/CLO/Products/OPENSOURCE/cvs/obj_ia_gcc/ia64-hp-hpux11.00/libgfortran'
> gmake[1]: *** [all] Error 2
> gmake[1]: Leaving directory `/CLO/Products/OPENSOURCE/cvs/obj_ia_gcc/ia64-hp-hpux11.00/libgfortran'

The corresponding line in my make log is:

/bin/sh ./libtool --mode=compile /home/ian/gcc/xscale-elf/gcc/xgcc -B/home/ian/gcc/xscale-elf/gcc/ -B/home/ian/gcc/xscale-elf-install/xscale-elf/bin/ -B/home/ian/gcc/xscale-elf-install/xscale-elf/lib/ -isystem /home/ian/gcc/xscale-elf-install/xscale-elf/include -isystem /home/ian/gcc/xscale-elf-install/xscale-elf/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libgfortran -I.  -iquote../../../gcc/libgfortran/io -O2 -g -O2 -std=gnu99 -O2 -g -O2 -c -o environ.lo `test -f 'runtime/environ.c' || echo '../../../gcc/libgfortran/'`runtime/environ.c

The line in the Makefile is

	$(LIBTOOL) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o environ.lo `test -f 'runtime/environ.c' || echo '$(srcdir)/'`runtime/environ.c

So evidently in your case $(CC) expanded to "(CC_FOR_TARGET)" and in
my case it expanded to

/home/ian/gcc/xscale-elf/gcc/xgcc -B/home/ian/gcc/xscale-elf/gcc/ -B/home/ian/gcc/xscale-elf-install/xscale-elf/bin/ -B/home/ian/gcc/xscale-elf-install/xscale-elf/lib/ -isystem /home/ian/gcc/xscale-elf-install/xscale-elf/include -isystem /home/ian/gcc/xscale-elf-install/xscale-elf/sys-include

The top level Makefile recurs into libgfortran using
    (cd $(TARGET_SUBDIR)/libgfortran && \
     $(MAKE) $(TARGET_FLAGS_TO_PASS)   $(TARGET-target-libgfortran))
TARGET_FLAGS_TO_PASS includes these lines:
    "CC_FOR_TARGET=$(CC_FOR_TARGET)"
    'CC=$$(CC_FOR_TARGET)'

Note the double dollar sign, which make (which ignores all quoting)
will convert to a single dollar sign.  For me this was correctly
passed as CC=$(CC_FOR_TARGET).  For you it was somehow passed as
CC=(CC_FOR_TARGET).

libgfortran/Makefile starts out doing a recursive make.  The first
thing it does is
    $(MAKE) $(AM_MAKEFLAGS) all-am

Your definition of AM_MAKEFLAGS included this definition:
    "CC=$(CC)"
The fact that the recursively invoked make received a correct
definition of CC strongly suggests that the libgfortran Makefile
received a correct definition of CC from the top level Makefile.  This
suggests that the problem occurs in the recursive make when variable
definitions are not passed explicitly.

In a recursive make, at least with GNU make, variable definitions are
passed via the environment variable MAKEFLAGS.  These definitions may
be overridden by command line arguments, but otherwise take effect as
usual.  When I add a printenv statement to the all: target in the
libgfortran Makefile, I see this in MAKEFLAGS:
    CC=$$(CC_FOR_TARGET)
Note that the dollar sign has been double quoted again.  This is
required because the recursively invoked make is going to parse this
string.

I took a look at the make source code.  make 3.76.1 does not double
the dollar sign when setting up MAKEFLAGS.  This was fixed in the make
sources with this ChangeLog entry:

1999-09-29  Paul Eggert  <eggert@twinsun.com>

	* main.c (quote_as_word): Always quote for decode_env_switches
        instead of for the shell, so that arguments with strange
        characters are are passed to submakes correctly.  Remove
        double_dollars arg; we always double dollars now.  All callers
        changed.
        (decode_env_switches): Don't run off the end of an environment
        variable whose contents ends in a unescaped backslash.

This happened between the make 3.78.1 release and the make 3.79
release.

I downloaded make 3.78.1 and tested both it and make 3.79.1 with this
simple Makefile:

X = foo

all:
	$(MAKE) 'Y=bar' 'X=$$(Y)' sub1

sub1:
	$(MAKE) sub2

sub2:
	echo $X

make 3.79.1 prints 'bar' as I expect.  make 3.78.1 tries to run "echo
(Y)", and gets a syntax error from the shell.

The gcc installation instructions require make 3.79 or above.
Therefore my conclusion is that your patch to the libgfortran Makefile
was required to work around a bug in older versions of GNU make, but
should not be required today.

In a different message, you said:

> Woops, forgot to include that information.  I updated to 3.80 gnu make and
> it didn't help any.  I still needed to set AM_MAKEFLAGS.

Please retest with make 3.80.  To avoid any possible confusion, be
sure that the new version of make is first on your PATH, that you do
not have MAKE set in your environment, etc.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]