• g++ and linking

    From Joseph Hesse@21:1/5 to All on Sat Jan 22 06:32:48 2022
    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)
  • From Alf P. Steinbach@21:1/5 to Joseph Hesse on Sat Jan 22 09:39:54 2022
    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)
  • From Richard Damon@21:1/5 to Alf P. Steinbach on Sat Jan 22 06:30:01 2022
    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)
  • From David Brown@21:1/5 to Richard Damon on Sat Jan 22 12:53:44 2022
    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)
  • From Bonita Montero@21:1/5 to All on Sat Jan 22 16:45:50 2022
    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)
  • From Richard Damon@21:1/5 to Bonita Montero on Sat Jan 22 11:13:52 2022
    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)
  • From Bonita Montero@21:1/5 to All on Sat Jan 22 19:00:56 2022
    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)
  • From Andrey Tarasevich@21:1/5 to Joseph Hesse on Sat Jan 22 10:24:34 2022
    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)
  • From Tim Rentsch@21:1/5 to Richard Damon on Tue Feb 1 07:17:31 2022
    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)
  • From jameskuyper@alumni.caltech.edu@21:1/5 to Tim Rentsch on Tue Feb 1 08:19:03 2022
    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)
  • From Tim Rentsch@21:1/5 to james...@alumni.caltech.edu on Mon Apr 25 07:19:47 2022
    "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)
  • From jameskuyper@alumni.caltech.edu@21:1/5 to Tim Rentsch on Mon Apr 25 09:06:24 2022
    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)