Austin Group Defect Tracker

Aardvark Mark III

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001294 [1003.1(2016)/Issue7+TC2] Shell and Utilities Comment Omission 2019-10-01 08:03 2019-11-06 08:27
Reporter Konrad_Schwarz View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Konrad Schwarz
Organization Siemens AG
User Reference
Section c99
Page Number [^]
Line Number [^]
Interp Status ---
Final Accepted Text
Summary 0001294: POSIX recognizes the existence of dynamically loadable, executable object files, but provides no way of producing them.
Description The interface specified in [^] allows run-time access to "executable object files", but I could not find
a conforming way to produce them.
Desired Action Add _POSIX_SHARED_OBJECT and _POSIX_V8_SHARED_OBJECT_{CFLAGS,LDFLAGS} options to getconf analogously to the "Threaded Programming Environment" table
in c99.

For the GCC toolchain, I would expect _POSIX_V8_SHARED_OBJECT_CFLAGS to be
-fpic and ..._LDFLAGS to be -shared.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
GarrettWollman (reporter)
2019-10-01 17:14

There is no portable way to generate dynamically loadable object files because some dynamic linker implementations require that an exhaustive list of exported symbols be provided by the programmer (distinct from the symbol table in the object files), or require other similar interface information that cannot be deduced from the object files alone.
shware_systems (reporter)
2019-10-01 20:05

From c99 Description:
"If there are no options that prevent link editing (such as -c or -E), and all input files compile and link without error, the resulting executable file shall be written according to the -o outfile option (if present) or to the file a.out."

When this is true, what makes such an executable file a program is the presence of main(), either from a provided object or static library, or the one in standard libraries libl or liby. If main() is not found the file is a library that is expected to be useable by dlopen() the same as dlopen(NULL, flags) references the current program file.

This is portable without needing any extra command line flag. The wording of dlfcn.h and interfaces could emphasize better that what is allowed there as implementation-defined is in addition to the above expectation, not a substitute.

Also, if an external linker is used, it is the responsibility of the compilation phase to synthesize from the input .o and .c sources the information that linker requires. If the compiler cannot do this, necessitating the maintenance of files like an exports list, they are disqualified from being considered conforming, and the object format is suspect for being insufficently sophisticated to begin with. The caveat in the Input Files section for c99 that additional formats may be defined I see as for optional data, not for any additional requirements for producing a valid executable.
alanc (reporter)
2019-10-01 22:22

For platforms which support multiple compilers, how would you specify to getconf which compiler you want the flags for? For instance, on Solaris, _POSIX_V8_SHARED_OBJECT_LDFLAGS would need to be -G for Studio compilers but -shared for GNU & LLVM compilers.
Konrad_Schwarz (reporter)
2019-10-02 07:38
edited on: 2019-10-17 16:13

Re Note: 0004586: are these dynamic linker implementations relevant to POSIX? (Can POSIX assume an "ELF-only" world at this point?).

But this is a fair point -- I recognize that any serious engineering
organization will invest in far more in-depth handling of toolchain
issues that the generic getconf interface offers. OTOH, this is
true for c99 in general, so conversely, should c99 (or any hypothetical
successors like c11) be retired?

I would argue no; I think it is beneficial to have a standardized
(fairly simple) interface to the compilation tool chain, which,
at the least, gives you a starting point for platform (or toolchain)
dependent optimizations.

Re Note: 0004589: You would use whatever non-standard mechanism
that platform offers -- if any -- to map the standard c99 utility
to one of the compilers the platform supposedly supports.

eblake (manager)
2019-10-17 16:07

Re: Note: 0004591 asking about ELF-only. The Cygwin platform tries to comply with POSIX (where possible) but uses PE-COFF not ELF (thanks to the underlying Windows OS). And yes, Cygwin has support for loadable libraries. Thus, POSIX cannot assume ELF-only.
Konrad_Schwarz (reporter)
2019-11-05 11:20
edited on: 2019-11-05 11:34

Re: Note: 0004625: on purely formal grounds, I think Cygwin doesn't count,
as it is not a POSIX system.

However, the GNU ld --export-all-symbols option would seem to do the right thing, even on Cygwin.

So Cygwin could probably support this proposal.

(Also, it is quite likely that any system supporting libtool could support
this extension).

shware_systems (reporter)
2019-11-05 17:05

Cygwin does count, as do the apps created for Windows POSIX add-on, as the internals of .o files and application or library files linked from these, as a.out modules, are left unspecified. As such, COFF and OMF are as valid as ELF in that these all maintain associations of symbolic names with object or function addresses that a dlsym() implementation can reference.

This said, the consensus in the phone call discussions is an option like --export-all-symbols is missing from the c99 utility that ensures all names from source .o files with extern scope are represented in an a.out module, whether a main() declaration is processed or not. Addition of this switch is seen as more forward compatible than the Desired Action, and is using the Solaris cc compiler's -G switch as example/model of existing practice. See etherpad for details.
joerg (reporter)
2019-11-05 17:10

From my understanding, the option --export-all-symbols is not relevant for us as long as we do not standardize linker map files.

My impression is that --export-all-symbols is a workaround, since on UNIX, all global symbols remain global unless there is a linker map file.
shware_systems (reporter)
2019-11-05 17:41

yes, map and listing files of any sort are unspecified, as are linker utilities to begin with as unnecessary. That many toolchains include a separate linker is their election, but only needed if a compiler other than c99 is provided that requires it's use. As an option name it is descriptive of functionality c99 is seen as lacking, that's all, not that it is the model for removing that lack.
Konrad_Schwarz (reporter)
2019-11-06 08:27
edited on: 2019-11-06 10:09

Re: Note: 0004636 and Note: 0004637

I think you are missing the point here: the key difference
in Windows PE-COFF DLLs vs. ELF shared objects is that
DLLs have an explicit symbol export list, whereas shared objects
export everything by default. Obviously, there are various ways
of changing this, but I am talking about the default case here.

Now with DLLs, you either use a separate file
(a module definition file---not an linker map file)
to specify which symbols
are exported, or you mark up your code with declspec(dllexport), etc.
POSIX does not want you to do that, because ELF shared objects don't
require it: by default they export all non-static symbols, just as
in the static linking case.

However, the GCC toolchain for PE-COFF targets provides the
--export-all-symbols flag
which basically replicates the shared object behavior for PE-COFF DLLs.
It also supports "direct linking to a DLL" (see the manual),
so the .lib import file used by Microsoft toolchains is not required.
So the toolchain flow for GCC for a PE-COFF-based target turns out
to be pretty much identical to the ELF case.

Hence, an implementation of getconf on Cygwin can return
-Xl,--export-all-symbols or similar in the proposed

Just to make this clear:
-Xl,--export-all-symbols is a compiler flag that gcc
and its POSIX-specified alter ego c99 understand.

Finally, note that GCC ld will automatically assume
if no symbols would otherwise be exported. This means that
the "best" solution would probably be for
-Xl,--export-all-symbols at all.

- Issue History
Date Modified Username Field Change
2019-10-01 08:03 Konrad_Schwarz New Issue
2019-10-01 08:03 Konrad_Schwarz Name => Konrad Schwarz
2019-10-01 08:03 Konrad_Schwarz Organization => Siemens AG
2019-10-01 08:03 Konrad_Schwarz Section => c99
2019-10-01 08:03 Konrad_Schwarz Page Number => [^]
2019-10-01 08:03 Konrad_Schwarz Line Number => [^]
2019-10-01 17:14 GarrettWollman Note Added: 0004586
2019-10-01 20:05 shware_systems Note Added: 0004587
2019-10-01 22:22 alanc Note Added: 0004589
2019-10-02 07:38 Konrad_Schwarz Note Added: 0004591
2019-10-17 16:07 eblake Note Added: 0004625
2019-10-17 16:13 Don Cragun Note Edited: 0004591
2019-11-05 11:20 Konrad_Schwarz Note Added: 0004634
2019-11-05 11:34 Konrad_Schwarz Note Edited: 0004634
2019-11-05 17:05 shware_systems Note Added: 0004635
2019-11-05 17:10 joerg Note Added: 0004636
2019-11-05 17:41 shware_systems Note Added: 0004637
2019-11-06 08:27 Konrad_Schwarz Note Added: 0004638
2019-11-06 08:28 Konrad_Schwarz Note Edited: 0004638
2019-11-06 10:09 Konrad_Schwarz Note Edited: 0004638

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker