This is the mail archive of the
libstdc++-prs@sourceware.cygnus.com
mailing list for the libstdc++ project.
libstdc++/68: Makefile non-portability
- To: libstdc++-gnats at sourceware dot cygnus dot com
- Subject: libstdc++/68: Makefile non-portability
- From: donnte at microsoft dot com
- Date: 1 Jul 2000 00:44:04 -0000
- Reply-To: donnte at microsoft dot com
- Resent-Cc: libstdc++-prs at sourceware dot cygnus dot com
- Resent-Reply-To: libstdc++-gnats@sourceware.cygnus.com, donnte@microsoft.com
>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: