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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 22.01.2022 um 12:30 schrieb Richard Damon:

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.

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 C++ the mangled name includes the whole signature, so a limitation
would be a problem.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/22/22 10:45 AM, Bonita Montero wrote:

Am 22.01.2022 um 12:30 schrieb Richard Damon:

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.

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 C++ the mangled name includes the whole signature, so a limitation
would be a problem.

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).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 22.01.2022 um 17:13 schrieb Richard Damon:

On 1/22/22 10:45 AM, Bonita Montero wrote:

Am 22.01.2022 um 12:30 schrieb Richard Damon:

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.

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 C++ the mangled name includes the whole signature, so a limitation
would be a problem.

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).

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/21/2022 8:32 PM, 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 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Damon <Richard@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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)