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

Groups > comp.lang.c++ > #82846

Re: g++ and linking

Show all headers | View raw

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.

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web