FS#67857 - [gcc] Support new c99 options specified in POSIX 202x draft

Attached to Project: Arch Linux
Opened by Janis König (LeonardK) - Wednesday, 09 September 2020, 16:29 GMT
Last edited by freswa (frederik) - Saturday, 29 April 2023, 16:46 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Giancarlo Razzolini (grazzolini)
freswa (frederik)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description: POSIX 202x will add new options for the c99 executable, mainly -G, -B and -R for building shared libraries, dynamic executables and manipulating rpath respectively. These can be translated into options GCC understands by the already existing wrapper script.

I've attached an updated wrapper script that seems to at least work for my usages.

Additional info:

Relevant parts of the standard, for dynamic executables:

> −B mode : If *mode* is **dynamic**, produce a dynamically linked executable file. If the **−B** option is present with **−c**, **−E**, or **−G**, the result is unspecified.

For shared libraries:

> −G : Create a shared library or create object files suitable for inclusion in such a shared library. Compilations shall be performed in a manner suitable for the creation of shared libraries (for example, by producing position-independent code).
>
> If **−c** is also specified, create object files suitable for inclusion in a shared library.
>
> If **−c** is not specified, create a shared library. In this case the application shall ensure that the file named by the **−o** *outfile* option-argument includes an element named **so** or an implementation-defined element denoting a shared library, where elements in the last component of *outfile* are separated by `<period>` characters, for example **libx.so.1**; if no **−o** option is included in the options or the file named by the **−o** *outfile* option does not contain an element named **so** or an implementation-defined element denoting a shared library, the result is unspecified. If a *pathname* operand or **−l** option-argument names a shared library and that shared library defines an object used by the library being created, it shall become a dependency of the created shared library.
>
> If the **−G** option is present with **−B** or **−E**, the result is unspecified.

For the rpath:

> −R directory : If the object file format supports it, specify a directory to be searched for shared libraries when an executable file or shared library being created by *c99* is subsequently executed, or loaded using *dlopen()*. If *directory* contains any `<colon>` or `<dollar-sign>` characters, the behavior is unspecified. If an implementation provides a means for setting a default load time search location or locations, the **−R** option shall take precedence.
>
> The directory named by *directory* shall not be searched by a process performing dynamic loading if either of the following are true:
>
> * The real and effective user IDs of that process are different and the directory has write permission for a user ID outside the set of the effective user ID of that process and any implementation-specific user IDs used for directories containing system libraries.
> * The real and effective group IDs of that process are different and the directory has write permission for group IDs other than the effective group ID of that process.
>
> Directories named in **−R** options shall be searched in the order specified, before the default system library locations are searched.
>
> If a directory specified by a **−R** option contains files with names starting with any of the strings `"libc."`, `"libl."`, `"libpthread."`, `"libm."`, `"librt."`, `"libxnet."`, or `"liby."`, the result is unspecified.
>
> If the **−R** option is present with **−c** or **−E**, the result is unspecified.

And finally:

> Multiple instances of the **−D**, **−I**, **−L**, **−l**, **−R**, and **−U** options can be specified.



   c99 (1.4 KiB)
This task depends upon

Closed by  freswa (frederik)
Saturday, 29 April 2023, 16:46 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Sorry, I don't see "complex" scripts like these maintained downstream. A small wrapper is fine to me, but parsing and translating options is a bit too much to just put in a package.
Comment by Janis König (LeonardK) - Wednesday, 09 September 2020, 16:32 GMT
Accidentally attached my debugging version of the script.
   c99 (1.2 KiB)
   c99 (1.3 KiB)
Comment by Doug Newgard (Scimmia) - Wednesday, 09 September 2020, 19:52 GMT
Sounds like something that should be done upstream, not here.

Edit: My apologies, I didn't realize the script was only downstream.
Comment by Allan McRae (Allan) - Wednesday, 09 September 2020, 21:38 GMT
Why would c*99*, support 202x?
Comment by Janis König (LeonardK) - Wednesday, 09 September 2020, 21:51 GMT
I didn't realize this irony til now :)

But the reasoning is quite simply that c99 is simply the binary that compiles according to the ISO C99 standard, but it's frontend interface may change. The same way that modern versions of GCC can create dynamic executables written in/for C99 despite -std=c99.

In general though, POSIX just tries to standardize existing behavior or at least a common feature set and all compilers for C99 they could find supported the mentioned features, but with different flags. So this is just an adjustment to the interface and not to a 20 year old binary.

Although, in theory, one could go the Solaris route and provide a "old" c99 binary in /use/xpg4/bin/c99 and a "modern" POSIX 202x one in /usr/bin and the appropriate being selected via PATH=$(getconf -v MY_POSIX_VERSION PATH). But I doubt that this is what we want :)
Comment by Janis König (LeonardK) - Tuesday, 22 September 2020, 11:15 GMT
Scrolling through the issue regarding the addition of the mentioned options [1], there's also movement to switch to C17 or C2x [2], however I'm not sure whether this will happen with this standard or with another TC. Regardless, it may be advisable to also read the SunOS/Solaris manpage on c99 and cc as "reference implementation" [3], [4]


[1]: https://austingroupbugs.net/view.php?id=1294
[2]: https://austingroupbugs.net/view.php?id=1302
[3]: https://docs.oracle.com/cd/E37069_01/html/E54439/c99-1.html
[4]: https://docs.oracle.com/cd/E37069_01/html/E54439/cc-1.html
Comment by Allan McRae (Allan) - Tuesday, 22 September 2020, 11:43 GMT
Are any of these options not already in gcc? I checked a few and it looks like our current passthrough to gcc does just fine.
Comment by Janis König (LeonardK) - Tuesday, 22 September 2020, 13:05 GMT
Hm, I get e.g.:

gcc: error: unrecognized command-line option ‘-G’

They aren't documented as well. For me `command -v c99` gives `/usr/bin/c99` and `command -v gcc` gives `/usr/bin/gcc` and I'm on [testing] here.

Loading...