When/why are libstdc++ and libc++ symbols incompatible?
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
|
show 1 more comment
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
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 isnoexcept
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" notstd::set
andstd::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 aboutstd::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
|
show 1 more comment
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
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
c++ libstdc++ abi libc++ object-files
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 isnoexcept
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" notstd::set
andstd::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 aboutstd::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
|
show 1 more comment
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 isnoexcept
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" notstd::set
andstd::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 aboutstd::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
|
show 1 more comment
1 Answer
1
active
oldest
votes
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.
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
add a comment |
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.
add a comment |
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.
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.
answered Nov 23 '18 at 11:23
Jonathan WakelyJonathan Wakely
132k17243412
132k17243412
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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
andstd::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