[Bug driver/47330] New: libdecnumber/Makefile.in overrides CFLAGS set by sub make invocation

[Bug driver/47330] New: libdecnumber/Makefile.in overrides CFLAGS set by sub make invocation

[rsa at us dot ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47330

           Summary: libdecnumber/Makefile.in overrides CFLAGS set by sub
                    make invocation
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rsa@us.ibm.com


Apologies for not selecting the appropriate component, but there isn't one for
libdecnumber.

libdecnumber is pulled into libdfp as well as used in libgcc.

Due to lack of flexibility in autoconf, sub-invocations of configure only pass
the original CFLAGS from the parent configure to a sub invocation configure.
i.e. only those CFLAGS used to configure libdfp are passed to
libdecnumber/configure.  This means that if libdfp/configure updates CFLAGS
this update is only implicitly used in libdfp/configure and libdfp/Makefile.

Due to how libdecnumber/Makefile.in has defined CFLAGS the CFLAGS updated in
libdfp/Makefile will not normally propagate to libdecnumber/Makefile:

CFLAGS = @CFLAGS@

That is, unless the entire environment is passed in the libdecnumber/Makefile
invocation.  But doing this is a bad idea since it may pollute the makefile
namespace with outside variables (we've seen bugs from this).

Currently libdfp/Makefile invokes a submake in libdecnumber/Makefile with the
following:

DEFS="-D__STDC_DEC_FP__=200704L $(mzarch)" CFLAGS="$(CFLAGS)" $(MAKE)  -C
$(dfp_backend)

Due to how CFLAGS are set, libdecnumber/Makefile.in ($(dfp_backend) in this
case) ignores the passed in CFLAGS and uses the CFLAGS that were set during
libdecnumber/configure.  This means that if libdfp modified CFLAGS they won't
get passed to libdecnumber.

One place this has come up is when setting fPIC.  We'd like to append fPIC to
CFLAGS but currently we have to do the following to get libdecnumber to use it:

DEFS="-D__STDC_DEC_FP__=200704L $(mzarch) -fPIC" $(MAKE) -C $(dfp_backend)

We obviously want CFLAGS congruent between libdfp/Makefile and
libdecnumber/Makefile to avoid confusion and bugs.

This can all be solved by making the following change in
libdecnumber/Makefile.in:

CFLAGS ?= @CFLAGS@

This means: use the CFLAGS passed in from libdecnumber/configure if no other
CFLAGS were passed in during libdecnumber/Makefile invocation.  This should
continue to work as-is with GCC and will allow Libdfp to have congruent CFLAGS
with libdecnumber.

Thanks

[Bug c/47330] libdecnumber/Makefile.in overrides CFLAGS set by sub make invocation

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47330

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> 2011-01-17 16:13:37 UTC ---
You are not supposed to override CFLAGS in sub-makes.

[Bug c/47330] libdecnumber/Makefile.in overrides CFLAGS set by sub make invocation

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47330

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> 2011-01-17 16:25:25 UTC ---
Those who ignore libtool are forced to reimplement it.

[Bug c/47330] libdecnumber/Makefile.in overrides CFLAGS set by sub make invocation

[rsa at us dot ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47330

--- Comment #2 from Ryan S. Arnold <rsa at us dot ibm.com> 2011-01-17 16:16:55 UTC ---
(In reply to comment #1)
> You are not supposed to override CFLAGS in sub-makes.

What's the recommended procedure for making sure fPIC/fpic is used properly,
once again relying on the one configuring to pass it in as a CFLAG?

[Bug c/47330] libdecnumber/Makefile.in overrides CFLAGS set by sub make invocation

[rsa at us dot ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47330

Ryan S. Arnold <rsa at us dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #4 from Ryan S. Arnold <rsa at us dot ibm.com> 2011-01-17 18:00:05 UTC ---
libtool is a mighty big stick to fix this one issue.  I'll work around it for
the time being by passing it in -DEFS.

Closing the bugz.