Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #82840 > unrolled thread

g++ and linking

Back to article view | Back to comp.lang.c++

Contents

  g++ and linking Joseph Hesse <joeh@gmail.com> - 2022-01-22 06:32 +0200
    Re: g++ and linking "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-01-22 09:39 +0100
      Re: g++ and linking Richard Damon <Richard@Damon-Family.org> - 2022-01-22 06:30 -0500
        Re: g++ and linking David Brown <david.brown@hesbynett.no> - 2022-01-22 12:53 +0100
        Re: g++ and linking Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-22 16:45 +0100
          Re: g++ and linking Richard Damon <Richard@Damon-Family.org> - 2022-01-22 11:13 -0500
            Re: g++ and linking Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-22 19:00 +0100
        Re: g++ and linking Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-01 07:17 -0800
          Re: g++ and linking "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-02-01 08:19 -0800
            Re: g++ and linking Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 07:19 -0700
              Re: g++ and linking "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-04-25 09:06 -0700
    Re: g++ and linking Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-22 10:24 -0800

#82840 — g++ and linking

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

[toc] | [next] | [standalone]

#82841

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

[toc] | [prev] | [next] | [standalone]

#82842

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

[toc] | [prev] | [next] | [standalone]

#82843

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.

[toc] | [prev] | [next] | [standalone]

#82844

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.

[toc] | [prev] | [next] | [standalone]

#82845

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

[toc] | [prev] | [next] | [standalone]

#82846

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.

[toc] | [prev] | [next] | [standalone]

#82893

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.

[toc] | [prev] | [next] | [standalone]

#82894

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.

[toc] | [prev] | [next] | [standalone]

#83725

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

[toc] | [prev] | [next] | [standalone]

#83736

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.

[toc] | [prev] | [next] | [standalone]

#82847

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web