This is the mail archive of the libstdc++-prs@sourceware.cygnus.com mailing list for the libstdc++ project.


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

libstdc++/68: Makefile non-portability



>Number:         68
>Category:       libstdc++
>Synopsis:       Makefile non-portability
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jun 30 17:47:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     donnte@microsoft.com
>Release:        unknown-1.0
>Organization:
>Environment:
Interix
>Description:
I'm NOT quite sure that this qualifies as a bug because
it does work with gmake.  However, so far, it's the only
thing I've run across in building the whole compiler and
library suite that does:

On roughly line 130 of math/Makefile.in you'll find
libmath_la_LIBADD = \
        @LIBMATHOBJS@ \
        $(EXTRA_LONG_DOUBLE_$(USE_COMPLEX_LONG_DOUBLE))

At least the openbsd make I use normally use doesn't
support nested $(), and from reading POSIX.2, this (quite
arguably... the standard is fuzzy) is not standard.  
(POSIX, P673, L467).  (The unanswered question is
are macros evaluated inside-outward or left to right;
if the latter it's illegal, if the former, it's legal,
and the standard doesn't make it clear.)

Anyway... is this something that should be fixed in
the name of portability?

Donn Terry
Speaking only for myself.
>How-To-Repeat:
Use the appropriate make, configure, and make.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:

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