Re: libstdc++/5095: broken $(MAKEFLAGS)

Re: libstdc++/5095: broken $(MAKEFLAGS)

[pme]

Synopsis: broken $(MAKEFLAGS)

State-Changed-From-To: open->feedback
State-Changed-By: pme
State-Changed-When: Wed Apr 10 10:07:58 2002
State-Changed-Why:
    
    I don't fully understand it either.  I think I see what's
    happening, but I don't see how it could.
    
    gin@mo.msk.ru, is this still happening for you?  Lots of
    changes have been made since 3.0.2.
    
    In particular, I don't see how this can happen with the
    default "gmake bootstrap-lean" and no other arguments
    or overrides.  Nobody else has experienced this with the
    default setup.
    
    The problem would seem to occur when trying to override
    a makefile variable on the command line; this gets tricky
    when recursing.  The construct $(foo) is simply a variable
    in makefiles, but in a POSIX Bourne shell it is the same as
    writing `foo` which means something very different.
    
    A cleaner makefile would use ${foo} in all cases, because
    brace-expansion means the same thing (variable expansion)
    in makefiles as it does in shells.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5095

Re: libstdc++/5095: broken $(MAKEFLAGS)

[pme]

Synopsis: broken $(MAKEFLAGS)

State-Changed-From-To: feedback->closed
State-Changed-By: pme
State-Changed-When: Fri May 31 17:58:42 2002
State-Changed-Why:
    (Feedback received in email only.)  Local problem.
    
    Note to maintainers:  please consider using braces
    instead of parenthesis in makefiles for this reason.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5095

Re: libstdc++/5095: broken $(MAKEFLAGS)

[Phil Edwards]

The following reply was made to PR libstdc++/5095; it has been noted by GNATS.

From: Phil Edwards <phil@jaj.com>
To: "Golubev I. N." <gin@mo.msk.ru>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: libstdc++/5095: broken $(MAKEFLAGS)
Date: Fri, 19 Apr 2002 01:17:23 -0400

 On Sun, Apr 14, 2002 at 03:41:28PM +0000, Golubev I. N. wrote:
 > On Thu, 13 Dec 2001 18:32:00 (GMT) I wrote to gcc-bugs@gcc.gnu.org in
 > <01e43c18f42036-gin@mo.msk.ru>:
 > 
 > > My apologies.  That happens only if
 > > 
 > > MAKEOVERRIDES = 
 > > 
 > > line is removed from `libstdc++-v3/Makefile', which does not normally
 > > happen with gcc.
 > 
 > It should be displayed in list archive as a followup to original
 > report, but it looks like it is not.  How do I ensure that in future?
 
 Make certain that gcc-gnats is in the To:/Cc: header, and that the PR
 number (libstdc++/5095) is in the Subject: header.  Then it will be
 appended automatically.
 
 
 > The real problem is that "trying to override a makefile variable gets
 > tricky when recursing".  Current gcc configuration scripts constantly
 > lack something essential for one's favorite system, and overriding
 > makefile variables is often required.  Documenting ways to do it is
 > absolutely necessary.
 
 Unfortunately no two libraries are the same.  Patches welcome.
 
 
 -- 
 If ye love wealth greater than liberty, the tranquility of servitude greater
 than the animating contest for freedom, go home and leave us in peace.  We seek
 not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
 and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: libstdc++/5095: broken $(MAKEFLAGS)

[bkoz]

Synopsis: broken $(MAKEFLAGS)

Responsible-Changed-From-To: unassigned->pme
Responsible-Changed-By: bkoz
Responsible-Changed-When: Tue Apr  9 14:23:06 2002
Responsible-Changed-Why:
    Phil, I'd appreciate it if you could look at this. I don't understand the problem report, or the suggestion.
    
    -benjamin

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5095

libstdc++/5095: broken $(MAKEFLAGS)

[Golubev I. N.]

>Number:         5095
>Category:       libstdc++
>Synopsis:       broken $(MAKEFLAGS)
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 12 09:16:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        3.0.2
>Organization:
>Environment:
System: SCO_SV d-fens 3.2 2 i386


GNU Make version 3.79.1	
host: i586-pc-sco3.2v5.0.2
build: i586-pc-sco3.2v5.0.2
target: i586-pc-sco3.2v5.0.2
configured with: configure --without-included-gettext --prefix=/usr --with-as=/usr/bin/gas --enable-multilib --disable-static --enable-shared --with-system-zlib --program-transform-name=s/cpp/gcpp/ --enable-languages=c,c++,f77
>Description:
	target libstdc++-v3 build fails
>How-To-Repeat:
	gmake bootstrap-lean

gmake[3]: Entering directory `$top_builddir/i586-pc-sco3.2v5.0.2/libstdc++-v3'
/bin/sh: syntax error at line 1: `(' unexpected
gmake[3]: *** [all-recursive] Error 2
gmake[3]: Leaving directory `$top_builddir/i586-pc-sco3.2v5.0.2/libstdc++-v3'
gmake[2]: *** [all-recursive-am] Error 2
gmake[2]: Target `all' not remade because of errors.
gmake[2]: Leaving directory `$top_builddir/i586-pc-sco3.2v5.0.2/libstdc++-v3'
gmake[1]: *** [all-target-libstdc++-v3] Error 2

When doing `$(MAKE) all-recursive' in leave gmake process,
$(MAKEFLAGS) expansion *in shell command* causes arguments like

LIBCXXFLAGS=$(LIBCXXFLAGS_FOR_TARGET)

to appear in `set' shell command.  Its expansion in upper level makes
yields

 'LIBCXXFLAGS=$(LIBCXXFLAGS_FOR_TARGET)'

Entries in MAKEFLAGS like this appear due to $(EXTRA_TARGET_FLAGS) in
top-level Makefile.  When passed through command line arguments to
sub-make once, they are ok.  But the next sub-make handles them as
described above.

>Fix:

Passing variable values containing references to other makefile
variables to sub-make that uses Makefile generated by automake is more
reliable when using AM_MAKEFLAGS environment variable.  Its value does
not get mangled by recursive makes.

That is, top-level makefile might call recursive make for target build
like this:

AM_MAKEFLAGS='AR=$$(AR_FOR_TARGET) AS=$$(AS_FOR_TARGET)' $(MAKE)

Unfortunately, it should be done only for modules using automake,
otherwise AM_MAKEFLAGS will affect nothing.
>Release-Note:
>Audit-Trail:
>Unformatted: