When/why are libstdc++ and libc++ symbols incompatible?












-1















Setup:



test.cpp



#include <set>
#include <string>

void common_config_file_iterator(const std::set<std::string>& allowed_options) {}


include.cpp



#include <set>
#include <string>

void common_config_file_iterator(const std::set<std::string>&) noexcept;

int main() {
std::set<std::string> set;
common_config_file_iterator(set);
return 0;
}


test.sh



clang++-7 test.cpp -c -O3 -fno-rtti -fno-exceptions -o test.o
g++-8 test.o include.cpp -O3 -fno-rtti -fno-exceptions -o test


Output:



Undefined symbols for architecture x86_64:
"common_config_file_iterator(std::set<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)", referenced from:
_main in ccWoGgrX.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status


So I did nm -g test.o:



0000000000000000 T __Z27common_config_file_iteratorRKNSt3__13setINS_12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEENS_4lessIS6_EENS4_IS6_EEEE


According to demangler.com, it means:



common_config_file_iterator(std::__1::set<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&)


Libc++ says:




[Features and Goals:] ABI compatibility with gcc's libstdc++ for some low-level features such as exception objects, rtti and memory allocation.




So, is the problem std::allocator<char>?



Note that I use the macOS assembler.



Curiosity caused by this issue and boost/program-options.










share|improve this question























  • Goal may mean that they don't agree at this stage?

    – Matthieu Brucher
    Nov 21 '18 at 15:47











  • noexcept is missing, it is part of the function signature.

    – Hans Passant
    Nov 21 '18 at 16:31











  • @Hans but is noexcept also part of the ABI?

    – rubenvb
    Nov 22 '18 at 8:43











  • @MatthieuBrucher no, it means "some low-level features such as exception objects, rtti and memory allocation" not std::set and std::string.

    – Jonathan Wakely
    Nov 23 '18 at 11:24






  • 1





    Did you maybe read the goal as "except for" instead of just "for"? You disable RTTI and exceptions and worry about std::allocator as if you think that exception objects, rtti and memory allocation are the things that are not compatible, when in fact they are the only things that are.

    – Sebastian Redl
    Nov 23 '18 at 11:29
















-1















Setup:



test.cpp



#include <set>
#include <string>

void common_config_file_iterator(const std::set<std::string>& allowed_options) {}


include.cpp



#include <set>
#include <string>

void common_config_file_iterator(const std::set<std::string>&) noexcept;

int main() {
std::set<std::string> set;
common_config_file_iterator(set);
return 0;
}


test.sh



clang++-7 test.cpp -c -O3 -fno-rtti -fno-exceptions -o test.o
g++-8 test.o include.cpp -O3 -fno-rtti -fno-exceptions -o test


Output:



Undefined symbols for architecture x86_64:
"common_config_file_iterator(std::set<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)", referenced from:
_main in ccWoGgrX.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status


So I did nm -g test.o:



0000000000000000 T __Z27common_config_file_iteratorRKNSt3__13setINS_12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEENS_4lessIS6_EENS4_IS6_EEEE


According to demangler.com, it means:



common_config_file_iterator(std::__1::set<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&)


Libc++ says:




[Features and Goals:] ABI compatibility with gcc's libstdc++ for some low-level features such as exception objects, rtti and memory allocation.




So, is the problem std::allocator<char>?



Note that I use the macOS assembler.



Curiosity caused by this issue and boost/program-options.










share|improve this question























  • Goal may mean that they don't agree at this stage?

    – Matthieu Brucher
    Nov 21 '18 at 15:47











  • noexcept is missing, it is part of the function signature.

    – Hans Passant
    Nov 21 '18 at 16:31











  • @Hans but is noexcept also part of the ABI?

    – rubenvb
    Nov 22 '18 at 8:43











  • @MatthieuBrucher no, it means "some low-level features such as exception objects, rtti and memory allocation" not std::set and std::string.

    – Jonathan Wakely
    Nov 23 '18 at 11:24






  • 1





    Did you maybe read the goal as "except for" instead of just "for"? You disable RTTI and exceptions and worry about std::allocator as if you think that exception objects, rtti and memory allocation are the things that are not compatible, when in fact they are the only things that are.

    – Sebastian Redl
    Nov 23 '18 at 11:29














-1












-1








-1








Setup:



test.cpp



#include <set>
#include <string>

void common_config_file_iterator(const std::set<std::string>& allowed_options) {}


include.cpp



#include <set>
#include <string>

void common_config_file_iterator(const std::set<std::string>&) noexcept;

int main() {
std::set<std::string> set;
common_config_file_iterator(set);
return 0;
}


test.sh



clang++-7 test.cpp -c -O3 -fno-rtti -fno-exceptions -o test.o
g++-8 test.o include.cpp -O3 -fno-rtti -fno-exceptions -o test


Output:



Undefined symbols for architecture x86_64:
"common_config_file_iterator(std::set<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)", referenced from:
_main in ccWoGgrX.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status


So I did nm -g test.o:



0000000000000000 T __Z27common_config_file_iteratorRKNSt3__13setINS_12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEENS_4lessIS6_EENS4_IS6_EEEE


According to demangler.com, it means:



common_config_file_iterator(std::__1::set<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&)


Libc++ says:




[Features and Goals:] ABI compatibility with gcc's libstdc++ for some low-level features such as exception objects, rtti and memory allocation.




So, is the problem std::allocator<char>?



Note that I use the macOS assembler.



Curiosity caused by this issue and boost/program-options.










share|improve this question














Setup:



test.cpp



#include <set>
#include <string>

void common_config_file_iterator(const std::set<std::string>& allowed_options) {}


include.cpp



#include <set>
#include <string>

void common_config_file_iterator(const std::set<std::string>&) noexcept;

int main() {
std::set<std::string> set;
common_config_file_iterator(set);
return 0;
}


test.sh



clang++-7 test.cpp -c -O3 -fno-rtti -fno-exceptions -o test.o
g++-8 test.o include.cpp -O3 -fno-rtti -fno-exceptions -o test


Output:



Undefined symbols for architecture x86_64:
"common_config_file_iterator(std::set<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)", referenced from:
_main in ccWoGgrX.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status


So I did nm -g test.o:



0000000000000000 T __Z27common_config_file_iteratorRKNSt3__13setINS_12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEENS_4lessIS6_EENS4_IS6_EEEE


According to demangler.com, it means:



common_config_file_iterator(std::__1::set<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&)


Libc++ says:




[Features and Goals:] ABI compatibility with gcc's libstdc++ for some low-level features such as exception objects, rtti and memory allocation.




So, is the problem std::allocator<char>?



Note that I use the macOS assembler.



Curiosity caused by this issue and boost/program-options.







c++ libstdc++ abi libc++ object-files






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 21 '18 at 15:37









MCCCSMCCCS

4371930




4371930













  • Goal may mean that they don't agree at this stage?

    – Matthieu Brucher
    Nov 21 '18 at 15:47











  • noexcept is missing, it is part of the function signature.

    – Hans Passant
    Nov 21 '18 at 16:31











  • @Hans but is noexcept also part of the ABI?

    – rubenvb
    Nov 22 '18 at 8:43











  • @MatthieuBrucher no, it means "some low-level features such as exception objects, rtti and memory allocation" not std::set and std::string.

    – Jonathan Wakely
    Nov 23 '18 at 11:24






  • 1





    Did you maybe read the goal as "except for" instead of just "for"? You disable RTTI and exceptions and worry about std::allocator as if you think that exception objects, rtti and memory allocation are the things that are not compatible, when in fact they are the only things that are.

    – Sebastian Redl
    Nov 23 '18 at 11:29



















  • Goal may mean that they don't agree at this stage?

    – Matthieu Brucher
    Nov 21 '18 at 15:47











  • noexcept is missing, it is part of the function signature.

    – Hans Passant
    Nov 21 '18 at 16:31











  • @Hans but is noexcept also part of the ABI?

    – rubenvb
    Nov 22 '18 at 8:43











  • @MatthieuBrucher no, it means "some low-level features such as exception objects, rtti and memory allocation" not std::set and std::string.

    – Jonathan Wakely
    Nov 23 '18 at 11:24






  • 1





    Did you maybe read the goal as "except for" instead of just "for"? You disable RTTI and exceptions and worry about std::allocator as if you think that exception objects, rtti and memory allocation are the things that are not compatible, when in fact they are the only things that are.

    – Sebastian Redl
    Nov 23 '18 at 11:29

















Goal may mean that they don't agree at this stage?

– Matthieu Brucher
Nov 21 '18 at 15:47





Goal may mean that they don't agree at this stage?

– Matthieu Brucher
Nov 21 '18 at 15:47













noexcept is missing, it is part of the function signature.

– Hans Passant
Nov 21 '18 at 16:31





noexcept is missing, it is part of the function signature.

– Hans Passant
Nov 21 '18 at 16:31













@Hans but is noexcept also part of the ABI?

– rubenvb
Nov 22 '18 at 8:43





@Hans but is noexcept also part of the ABI?

– rubenvb
Nov 22 '18 at 8:43













@MatthieuBrucher no, it means "some low-level features such as exception objects, rtti and memory allocation" not std::set and std::string.

– Jonathan Wakely
Nov 23 '18 at 11:24





@MatthieuBrucher no, it means "some low-level features such as exception objects, rtti and memory allocation" not std::set and std::string.

– Jonathan Wakely
Nov 23 '18 at 11:24




1




1





Did you maybe read the goal as "except for" instead of just "for"? You disable RTTI and exceptions and worry about std::allocator as if you think that exception objects, rtti and memory allocation are the things that are not compatible, when in fact they are the only things that are.

– Sebastian Redl
Nov 23 '18 at 11:29





Did you maybe read the goal as "except for" instead of just "for"? You disable RTTI and exceptions and worry about std::allocator as if you think that exception objects, rtti and memory allocation are the things that are not compatible, when in fact they are the only things that are.

– Sebastian Redl
Nov 23 '18 at 11:29












1 Answer
1






active

oldest

votes


















2















So, is the problem std::allocator<char>?




What? No. It's everything in your example.



The doc you quoted clearly says the goal is compatibility for "low-level features such as exception objects, rtti and memory allocation".



std::set and std::string are not "low-level features such as exception objects, rtti and memory allocation". They are very definitely not compatible between libc++ and libstdc++, which are completely different libraries with completely different implementations.



The compatible pieces are things like std::type_info and std::exception (and the derived exception types in <stdexcept>) because those are part of the basic language runtime. Anything above that, such as containers, strings, algorithms, I/O, locales etc. is not compatible.






share|improve this answer
























    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53415544%2fwhen-why-are-libstdc-and-libc-symbols-incompatible%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    2















    So, is the problem std::allocator<char>?




    What? No. It's everything in your example.



    The doc you quoted clearly says the goal is compatibility for "low-level features such as exception objects, rtti and memory allocation".



    std::set and std::string are not "low-level features such as exception objects, rtti and memory allocation". They are very definitely not compatible between libc++ and libstdc++, which are completely different libraries with completely different implementations.



    The compatible pieces are things like std::type_info and std::exception (and the derived exception types in <stdexcept>) because those are part of the basic language runtime. Anything above that, such as containers, strings, algorithms, I/O, locales etc. is not compatible.






    share|improve this answer




























      2















      So, is the problem std::allocator<char>?




      What? No. It's everything in your example.



      The doc you quoted clearly says the goal is compatibility for "low-level features such as exception objects, rtti and memory allocation".



      std::set and std::string are not "low-level features such as exception objects, rtti and memory allocation". They are very definitely not compatible between libc++ and libstdc++, which are completely different libraries with completely different implementations.



      The compatible pieces are things like std::type_info and std::exception (and the derived exception types in <stdexcept>) because those are part of the basic language runtime. Anything above that, such as containers, strings, algorithms, I/O, locales etc. is not compatible.






      share|improve this answer


























        2












        2








        2








        So, is the problem std::allocator<char>?




        What? No. It's everything in your example.



        The doc you quoted clearly says the goal is compatibility for "low-level features such as exception objects, rtti and memory allocation".



        std::set and std::string are not "low-level features such as exception objects, rtti and memory allocation". They are very definitely not compatible between libc++ and libstdc++, which are completely different libraries with completely different implementations.



        The compatible pieces are things like std::type_info and std::exception (and the derived exception types in <stdexcept>) because those are part of the basic language runtime. Anything above that, such as containers, strings, algorithms, I/O, locales etc. is not compatible.






        share|improve this answer














        So, is the problem std::allocator<char>?




        What? No. It's everything in your example.



        The doc you quoted clearly says the goal is compatibility for "low-level features such as exception objects, rtti and memory allocation".



        std::set and std::string are not "low-level features such as exception objects, rtti and memory allocation". They are very definitely not compatible between libc++ and libstdc++, which are completely different libraries with completely different implementations.



        The compatible pieces are things like std::type_info and std::exception (and the derived exception types in <stdexcept>) because those are part of the basic language runtime. Anything above that, such as containers, strings, algorithms, I/O, locales etc. is not compatible.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 23 '18 at 11:23









        Jonathan WakelyJonathan Wakely

        132k17243412




        132k17243412
































            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53415544%2fwhen-why-are-libstdc-and-libc-symbols-incompatible%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            鏡平學校

            ꓛꓣだゔៀៅຸ໢ທຮ໕໒ ,ໂ'໥໓າ໼ឨឲ៵៭ៈゎゔit''䖳𥁄卿' ☨₤₨こゎもょの;ꜹꟚꞖꞵꟅꞛေၦေɯ,ɨɡ𛃵𛁹ޝ޳ޠ޾,ޤޒޯ޾𫝒𫠁သ𛅤チョ'サノބޘދ𛁐ᶿᶇᶀᶋᶠ㨑㽹⻮ꧬ꧹؍۩وَؠ㇕㇃㇪ ㇦㇋㇋ṜẰᵡᴠ 軌ᵕ搜۳ٰޗޮ޷ސޯ𫖾𫅀ल, ꙭ꙰ꚅꙁꚊꞻꝔ꟠Ꝭㄤﺟޱސꧨꧼ꧴ꧯꧽ꧲ꧯ'⽹⽭⾁⿞⼳⽋២៩ញណើꩯꩤ꩸ꩮᶻᶺᶧᶂ𫳲𫪭𬸄𫵰𬖩𬫣𬊉ၲ𛅬㕦䬺𫝌𫝼,,𫟖𫞽ហៅ஫㆔ాఆఅꙒꚞꙍ,Ꙟ꙱エ ,ポテ,フࢰࢯ𫟠𫞶 𫝤𫟠ﺕﹱﻜﻣ𪵕𪭸𪻆𪾩𫔷ġ,ŧآꞪ꟥,ꞔꝻ♚☹⛵𛀌ꬷꭞȄƁƪƬșƦǙǗdžƝǯǧⱦⱰꓕꓢႋ神 ဴ၀க௭எ௫ឫោ ' េㇷㇴㇼ神ㇸㇲㇽㇴㇼㇻㇸ'ㇸㇿㇸㇹㇰㆣꓚꓤ₡₧ ㄨㄟ㄂ㄖㄎ໗ツڒذ₶।ऩछएोञयूटक़कयँृी,冬'𛅢𛅥ㇱㇵㇶ𥄥𦒽𠣧𠊓𧢖𥞘𩔋цѰㄠſtʯʭɿʆʗʍʩɷɛ,əʏダヵㄐㄘR{gỚṖḺờṠṫảḙḭᴮᵏᴘᵀᵷᵕᴜᴏᵾq﮲ﲿﴽﭙ軌ﰬﶚﶧ﫲Ҝжюїкӈㇴffצּ﬘﭅﬈軌'ffistfflſtffतभफɳɰʊɲʎ𛁱𛁖𛁮𛀉 𛂯𛀞నఋŀŲ 𫟲𫠖𫞺ຆຆ ໹້໕໗ๆทԊꧢꧠ꧰ꓱ⿝⼑ŎḬẃẖỐẅ ,ờỰỈỗﮊDžȩꭏꭎꬻ꭮ꬿꭖꭥꭅ㇭神 ⾈ꓵꓑ⺄㄄ㄪㄙㄅㄇstA۵䞽ॶ𫞑𫝄㇉㇇゜軌𩜛𩳠Jﻺ‚Üမ႕ႌႊၐၸဓၞၞၡ៸wyvtᶎᶪᶹစဎ꣡꣰꣢꣤ٗ؋لㇳㇾㇻㇱ㆐㆔,,㆟Ⱶヤマފ޼ޝަݿݞݠݷݐ',ݘ,ݪݙݵ𬝉𬜁𫝨𫞘くせぉて¼óû×ó£…𛅑הㄙくԗԀ5606神45,神796'𪤻𫞧ꓐ㄁ㄘɥɺꓵꓲ3''7034׉ⱦⱠˆ“𫝋ȍ,ꩲ軌꩷ꩶꩧꩫఞ۔فڱێظペサ神ナᴦᵑ47 9238їﻂ䐊䔉㠸﬎ffiﬣ,לּᴷᴦᵛᵽ,ᴨᵤ ᵸᵥᴗᵈꚏꚉꚟ⻆rtǟƴ𬎎

            Why https connections are so slow when debugging (stepping over) in Java?