g++ and linking

[Joseph Hesse]

Hello,

Suppose we compile two source files to object files with:
g++ -c -std=c++14 file1.cpp file2.cpp

Now we link them to an executable.
g++ -o prog -std=c++14 file1.o file2.o

Since the above is a linker command, do we need the -std=c++14?

Thank you,
Joe

[Alf P. Steinbach]

No.

At one time, probably in the 1990's? or so but I don't know, linking
changed from considering only 8 significant characters in a name, to
supporting effectively arbitrarily long names.

The standardized versions of the language have never had a restriction
to 8 significant characters, but the names in the iostreams stuff and in
the C library are typical of the kind of names programmers invented to
support that restriction.

Another area where linking could conceivably have had different
requirements for different versions of the language, is the use of weak
symbols for `inline` things. C++17 appeared to add the possibility of
`inline` variables. However, the wording for templates have had that as
a requirement that linkers had to be able to deal with, since C++98.

The only linker requirements change I know of for the standardized
language is for C++20 modules, and presumably there it's not the good
old common linker that deals with it (disclaimer: no experience).


- Alf

[Richard Damon]

The early versions of the standard, while not limiting identifier
length, does limit the 'significant' length for external identifiers,
allowing the implementation to truncate the name of the symbol in the
output to the linker.

In C99, 6.4.2.1p5 makes that length Implementation Defined. I would have
to search to see if somewhere there is a guarantee of a minimum value
for this length

[David Brown]

On 22/01/2022 12:30, Richard Damon wrote:
> On 1/22/22 3:39 AM, Alf P. Steinbach wrote:
>> On 22 Jan 2022 05:32, Joseph Hesse wrote:
>>> Hello,
>>>
>>> Suppose we compile two source files to object files with:
>>> g++ -c -std=c++14 file1.cpp file2.cpp
>>>
>>> Now we link them to an executable.
>>> g++ -o prog -std=c++14 file1.o file2.o
>>>
>>> Since the above is a linker command, do we need the -std=c++14?
>>
>> No.
>>
>> At one time, probably in the 1990's? or so but I don't know, linking
>> changed from considering only 8 significant characters in a name, to
>> supporting effectively arbitrarily long names.
>>
>> The standardized versions of the language have never had a restriction
>> to 8 significant characters, but the names in the iostreams stuff and
>> in the C library are typical of the kind of names programmers invented
>> to support that restriction.
>>
>> Another area where linking could conceivably have had different
>> requirements for different versions of the language, is the use of
>> weak symbols for `inline` things. C++17 appeared to add the
>> possibility of `inline` variables. However, the wording for templates
>> have had that as a requirement that linkers had to be able to deal
>> with, since C++98.

"weak" symbols are a different concept from inline and other merged
symbols (such as templates). Weak symbols are supported by elf format
object files, but not (IIRC) coff format. They are nothing to do with
C++, but can be used from any language.

Early C++ implementations used additional programs (typically called as
needed by driver programs such as "g++") to identify template usage and
ensure that only one copy of each shared function or object was made and
included in the linking.

For a long time, however, this has been done by smarter linkers.

>>
>> The only linker requirements change I know of for the standardized
>> language is for C++20 modules, and presumably there it's not the good
>> old common linker that deals with it (disclaimer: no experience).
>>
>>
>> - Alf
>
> The early versions of the standard, while not limiting identifier
> length, does limit the 'significant' length for external identifiers,
> allowing the implementation to truncate the name of the symbol in the
> output to the linker.
>
> In C99, 6.4.2.1p5 makes that length Implementation Defined. I would have
> to search to see if somewhere there is a guarantee of a minimum value
> for this length

In the specific case of gcc, since that is what the OP is asking about,
this kind of thing has always been "limited only by host computer
memory". In C18, implementations must support external identifiers of
at least 31 "significant initial characters". In C++14, "all characters
are significant". (I'm referring to these two, as I happen to have them
open on my desktop at the moment - not because I think they are
different relative to other versions.)

I remember vaguely that some old linkers had limits to the significant
characters in identifiers, but that was a /long/ time ago. And they
cannot have been used for C++ - name mangling for overloading functions
means that you are going to hit an 8 character limit /very/ quickly.

[Bonita Montero]

In C++ the mangled name includes the whole signature, so a limitation
would be a problem.

[Richard Damon]

Which is one reason about that time the common linkers started
supporting much longer names (and if they don't make it infinite, they
sometimes need to switch to a hash of the full name at some point).

[Bonita Montero]

That's stupid C programming-style to use static buffers.
If the linkers were written in C++ it would be easy to
support arbitrary symbol-lengths.

[Andrey Tarasevich]

No and yes.

The only conceivable practical reason to do this would be a potential
situation where different versions of the language standard required
linking in different versions of standard library binaries.

This is a reasonable possibility, but AFAIK GCC does not use different
libraries for different language standards.

Hence: no.

Considerations of name mangling or identifier length mentioned by other
posters are handled transparently by the linker, in a naturally
completely language-agnostic manner. The linker does not need to know
what name mangling scheme is used by the compiler proper.

So, again: no.

But, on the other hand, why do you even care? Who knows what compiler
switches `g++` executable uses to form the proper linker command line?
And if it doesn't use them today, who knows what compiler switches `g++`
executable will use tomorrow to form the proper linker command line?

For this reason it kinda makes good sense to just make sure that all
`g++` parameters are kept as consistent as possible between `g++`
invocations. Just pass'em all and let `g++` itself sort'em out.

For this reason: yes.

--
Best regards,
Andrey Tarasevich

[Tim Rentsch]

Richard Damon <Ric...@Damon-Family.org> writes:

[...]

> The early versions of the standard, while not limiting identifier
> length, does limit the 'significant' length for external identifiers,
> allowing the implementation to truncate the name of the symbol in the
> output to the linker.
>
> In C99, 6.4.2.1p5 makes that length Implementation Defined. I would
> have to search to see if somewhere there is a guarantee of a minimum
> value for this length

Section 5.2.4.1 paragraph 1 says

63 significant initial characters in an internal identifier
or a macro name

31 significant initial characters in an external identifier

By the way I think you mean requirement rather than guarantee.

[james...@alumni.caltech.edu]

On Tuesday, February 1, 2022 at 10:18:25 AM UTC-5, Tim Rentsch wrote:
> Richard Damon <Ric...@Damon-Family.org> writes:
>
> [...]
> > The early versions of the standard, while not limiting identifier
> > length, does limit the 'significant' length for external identifiers,
> > allowing the implementation to truncate the name of the symbol in the
> > output to the linker.
> >
> > In C99, 6.4.2.1p5 makes that length Implementation Defined. I would
> > have to search to see if somewhere there is a guarantee of a minimum
> > value for this length
> Section 5.2.4.1 paragraph 1 says

"The implementation shall be able to translate and execute at least one
program that contains at least one instance of every one of the following
limits:"

> 63 significant initial characters in an internal identifier
> or a macro name
>
> 31 significant initial characters in an external identifier

Keep in mind that these are NOT minimum permitted values for the
maximum number of significant characters in an identifier (the so-called
minimum maximum that I heard a lot about when C90 first came out).
Strictly speaking, the only requirement that they impose is on the "one
program". It is not a requirement that the implementation treat that many
characters as significant if they occur in any other program

> By the way I think you mean requirement rather than guarantee.

A requirement that must be met by an implementation of a language in
order to qualify as conforming to a given standard also serves as a
guarantee that anything that does qualify as conforming
implementation of that language meets that requirement.

[Tim Rentsch]

I think you're just wrong about that. Clearly the intended
reading of section 5.2.4, and how essentially everyone else
reads this section, is that 5.2.4.1 paragraph 1 gives minimum
translation limits, and also requires all conforming
implementations to be able to translate *and execute* a program
that has at least one instance of each of the minimums.
Conversely, any programming language standard that does not
give a requirement for minimum supported identifier length
would be grossly negligent. So it would be quite astonishing
to interpret 5.2.4.1 paragraph 1 as giving minimums that
apply to just the one program rather than stating minimum
requirements that apply to the implementation generally.

>> By the way I think you mean requirement rather than guarantee.
>
> A requirement that must be met by an implementation of a language in
> order to qualify as conforming to a given standard also serves as a
> guarantee that anything that does qualify as conforming
> implementation of that language meets that requirement.

It is not a guarantee in the usual sense of the word guarantee.
And even if it were, it's a pointless observation.

[james...@alumni.caltech.edu]

On Monday, April 25, 2022 at 10:20:07 AM UTC-4, Tim Rentsch wrote:
...

> I think you're just wrong about that. Clearly the intended
> reading of section 5.2.4, and how essentially everyone else
> reads this section, is that 5.2.4.1 paragraph 1 gives minimum
> translation limits, and also requires all conforming
> implementations to be able to translate *and execute* a program
> that has at least one instance of each of the minimums.

Yes, "a" program - a single program for which that is true is
sufficient to meet that requirement.

> Conversely, any programming language standard that does not
> give a requirement for minimum supported identifier length
> would be grossly negligent. So it would be quite astonishing
> to interpret 5.2.4.1 paragraph 1 as giving minimums that
> apply to just the one program rather than stating minimum
> requirements that apply to the implementation generally.

I think that the way 5.2.4.1 was written is indeed astonishingly
lax. I can understand why people feel a need to interpret in a
way that is more reasonable. But that is in fact the way it was
written. Saying that it was intended to be read in a way
inconsistent with the way it was written doesn't change the
fact that that interpretation is inconsistent with the way it was
written.

...

> > A requirement that must be met by an implementation of a language in
> > order to qualify as conforming to a given standard also serves as a
> > guarantee that anything that does qualify as conforming
> > implementation of that language meets that requirement.
> It is not a guarantee in the usual sense of the word guarantee.
> And even if it were, it's a pointless observation.

The standard doesn't make a single "guarantee" that is not conditional, in
precisely that sense, on the implementation qualifying as conforming. If
that doesn't qualify as "the usual sense of the word guarantee", then the
standard doesn't contain any usual guarantees. I can accept that you
don't consider this the "usual" sense, but that is not my experience.