|Anonymous | Login||2021-06-18 09:07 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001479||[1003.1(2016/18)/Issue7+TC2] Shell and Utilities||Objection||Clarification Requested||2021-05-28 09:14||2021-05-28 16:10|
|Organization||The Open Group|
|Final Accepted Text|
|Summary||0001479: Not clear what "achieve results" means for make defaults|
The description of the make utility says "The default rules for make shall achieve results that are the same as if the following were used" and then goes on to specify, among other things, default values for some macros.
It is not clear what is intended by "achieve results". In particular if these results include the output written to standard output by make when it executes a shell command, then the only way to achieve the same results would be for the defaults to be exactly those that are specified in the standard. However, just excluding that output would not fix the problem because a command such as "echo $(CFLAGS) > outfile" would produce different contents in outfile if CFLAGS does not have exactly the specified default value.
A quick check of the Solaris and GNU make implementations reveals the following differences from the defaults specified in the standard:
Both have ARFLAGS=rv (instead of ARFLAGS=-rv)
Both have CC=cc (instead of CC=c99)
Both have CFLAGS= (empty instead of CFLAGS=-O 1)
GNU has SCCSGETFLAGS= (empty instead of SCCSGETFLAGS=-s)
The proposed change would allow the first three but not the GNU SCCSGETFLAGS value, which hopefully the GNU make maintainer will not object to changing.
The default rules for make shall achieve results that are the same as if the following were used.to:
The default rules and macro values for make shall achieve results that are the same as if the following were used, except that where a result includes the literal value of a macro, this value may differ.
|Tags||No tags attached.|
I have no problem with changing SCCSGETFLAGS.
I would like to point out that "CFLAGS=-O 1" is (IMO) a bug in the standard and this should be "CFLAGS=-O1" (no space). Some compilers (GCC, for example) do not allow space between "-O" and its argument.
For portability, the standard should not require CFLAGS to be set to a non-portable value by default.
$ touch /tmp/foo.c
$ cc -O1 -c /tmp/foo.c
$ cc -O 1 -c /tmp/foo.c
cc: error: 1: No such file or directory
edited on: 2021-05-28 13:32
ARFLAGS= without a leading dash is historic practice that still works
on all ar implementations I am aware of.
I am not shure whether any compiler supports -O 1 with a space.
This seems to be a definite text formatting bug in the standard.
Regarding CC=c99, if everybody believes this is what should be used,
given that SunPro Make in it's current configuration decides how to
behave at runtime, when called as /usr/xpg4/bin/make, it would be
possible to let it read /usr/share/lib/make/posix.make.rules instead of
/usr/share/lib/make/make.rules and change that file to define CC=c99.
Should this be done? Reading posix.make.rules in that case would be
three additional lines of code.
I think the standard has -O 1 with a space because conforming applications are required to pass the -O and the 1 as separate arguments to c99 (see XBD 12.1 item 2a). The c99 utility is required to accept them either separately or together.
An implementation can of course set the default CFLAGS to -O1 without the space under the "shall achieve results that are the same" wording that is the subject of this bug.
Setting the default CC to cc instead of c99 is fine on a particular implementation provided a conforming application compiled with cc behaves the same as if it was compiled with c99. (Remember that a conforming application must define _POSIX_C_SOURCE=200809 or _XOPEN_SOURCE=700.)
Actually, GNU make already has conforming values of CC, SCCSGETFLAGS, and ARFLAGS if you set .POSIX:
$ cat > Makefile
all: ; @echo $(CC) / $(SCCSGETFLAGS) / $(ARFLAGS)
c99 / -s / -rv
I just checked Sun Studio c99 and you seem to be correct. -O 1 is
Re Note: 0005369 My bad for doing my checks without a .POSIX target.
I have re-checked Solaris with .POSIX, and ARFLAGS changes to -rv but CC and CFLAGS are still the same.
Yes, this is line 3029 from file main.cc...
I did not know that. It seems to overwrite things at runtime
and it may be the only way to do this since .POSIX may be seen
after /usr/share/lib/make/make.rules has been read.
That block could be enhanced to also overwrite CC and CFLAGS.
FWIW, GNU make won't change CFLAGS to "-O 1" even in POSIX mode. GCC (run as c99) will fail if that is done and in this case the real world must prevail over small conformance issues :).
Someone can mention this (not accepting "-O 1") to the GCC folks but I would be surprised if they felt that conformance in this situation was worth the effort I suspect would be involved with making it work (but I could be wrong, it could be easy). Nevertheless there are enough c99's out there where it fails today, that it's not feasible to change it in GNU make.
I understand that this is not being asked.
|2021-05-28 09:14||geoffclare||New Issue|
|2021-05-28 09:14||geoffclare||Name||=> Geoff Clare|
|2021-05-28 09:14||geoffclare||Organization||=> The Open Group|
|2021-05-28 09:14||geoffclare||Section||=> make|
|2021-05-28 09:14||geoffclare||Page Number||=> 2980|
|2021-05-28 09:14||geoffclare||Line Number||=> 98946|
|2021-05-28 09:14||geoffclare||Interp Status||=> ---|
|2021-05-28 12:56||psmith||Note Added: 0005366|
|2021-05-28 13:23||joerg||Note Added: 0005367|
|2021-05-28 13:24||joerg||Note Edited: 0005367|
|2021-05-28 13:32||joerg||Note Edited: 0005367|
|2021-05-28 13:33||geoffclare||Note Added: 0005368|
|2021-05-28 13:53||psmith||Note Added: 0005369|
|2021-05-28 13:57||joerg||Note Added: 0005370|
|2021-05-28 15:02||geoffclare||Note Added: 0005371|
|2021-05-28 15:14||joerg||Note Added: 0005372|
|2021-05-28 16:10||psmith||Note Added: 0005373|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|