Issue 449 in protobuf: Link error while using clang++ with -stdlib=libc++ flag in OSX
3,867 views
Skip to first unread message
prot...@googlecode.com
Dec 31, 2012, 3:29:15 AM12/31/12
to prot...@googlegroups.com
Status: New
Owner: liu...@google.com
Labels: Type-Defect Priority-Medium
New issue 449 by yayj...@gmail.com: Link error while using clang++ with
-stdlib=libc++ flag in OSX
http://code.google.com/p/protobuf/issues/detail?id=449
What steps will reproduce the problem?
1. To avoid the affection of my other code, I wrote down this short snippet:
packet.proto:
message packet {
required uint32 var = 1;
}
And pb.cc:
#include "packet.pb.h"
int main()
{
GOOGLE_PROTOBUF_VERIFY_VERSION;
google::protobuf::ShutdownProtobufLibrary();
return 0;
}
2. If I try to link with libc++, clang++ will complain like this error:
$ clang++ -stdlib=libc++ -o pb pb.cc packet.pb.cc -lprotobuf
Undefined symbols for architecture x86_64:
"google::protobuf::MessageFactory::InternalRegisterGeneratedFile(char
const*, void (*)(std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > const&))", referenced from:
protobuf_AddDesc_packet_2eproto() in packet-q8y2hq.o
"google::protobuf::DescriptorPool::FindFileByName(std::__1::basic_string<char,
std::__1::char_traits<char>,
std::__1::allocator<char> > const&) const",
referenced from:
protobuf_AssignDesc_packet_2eproto() in packet-q8y2hq.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
3. But everything seems OK without libc++:
$ clang++ -o pb pb.cc packet.pb.cc -lprotobuf
$ otool -L pb
pb:
/usr/local/lib/libprotobuf.7.dylib (compatibility version 8.0.0,
current version 8.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 169.3.0)
What is the expected output? What do you see instead?
Linking stage passed for sure.
What version of the product are you using? On what operating system?
OS: OS X 10.8.2
Here are the versions of clang and protobuf:
$ clang -v
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix
$ brew info protobuf
protobuf: stable 2.4.1
http://code.google.com/p/protobuf/
/usr/local/Cellar/protobuf/2.4.1 (62 files, 5.9M) *
https://github.com/mxcl/homebrew/commits/master/Library/Formula/protobuf.rb
Please provide any additional information below.
And I also compiled the snippet on a Linux workstation on which clang and
libc++ were installed. But no error was raised with libc++.
$ /opt/llvm/bin/clang++ -stdlib=libc++ -o pb pb.cc packet.pb.cc -lprotobuf
$ ldd pb
linux-gate.so.1 => (0x005dd000)
libprotobuf.so.7 => /usr/local/lib/libprotobuf.so.7 (0x0035c000)
libc++.so.1 => /usr/lib/libc++.so.1 (0x00113000)
libm.so.6 => /lib/libm.so.6 (0x0072d000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x006ea000)
libc.so.6 => /lib/libc.so.6 (0x00a6c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x001b1000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x001cc000)
librt.so.1 => /lib/librt.so.1 (0x002b7000)
/lib/ld-linux.so.2 (0x008c3000)
As you can see above, I built libc++ on Linux by using libstdc++ as the ABI
layer.
$ clang++ -v
clang version 3.1 (tags/RELEASE_31/final 170526)
Target: i386-pc-linux-gnu
Thread model: posix
libcxx$ svn info
Path: .
URL: http://llvm.org/svn/llvm-project/libcxx/trunk
Repository Root: http://llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 170542
Node Kind: directory
Schedule: normal
Last Changed Author: marshall
Last Changed Rev: 170435
Last Changed Date: 2012-12-19 00:46:30 +0800 (Wed, 19 Dec 2012)
Because I didn't know whether it is the root cause or not that my protobuf
library is built by libstdc++ instead of libc++, I also tried to build it
with libc++ instead of homebrew.
$ ./configure CC=clang CXX=clang++ CXXFLAGS='-stdlib=libc++'
$ make
...
/bin/sh ../libtool --tag=CXX --mode=compile clang++ -DHAVE_CONFIG_H -I.
-I.. -D_THREAD_SAFE -pthread -Wall -Wwrite-strings -Woverloaded-virtual
-Wno-sign-compare -O2 -pipe -stdlib=libc++ -MT message.lo -MD -MP
-MF .deps/message.Tpo -c -o message.lo `test
-f 'google/protobuf/message.cc' || echo './'`google/protobuf/message.cc
libtool: compile: clang++ -DHAVE_CONFIG_H -I. -I.. -D_THREAD_SAFE -pthread
-Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -O2 -pipe
-stdlib=libc++ -MT message.lo -MD -MP -MF .deps/message.Tpo -c
google/protobuf/message.cc -fPIC -DPIC -o .libs/message.o
google/protobuf/message.cc:130:60: error: implicit instantiation of
undefined
template 'std::__1::basic_istream<char, std::__1::char_traits<char> >'
return ParseFromZeroCopyStream(&zero_copy_input) && input->eof();
^
/usr/include/c++/v1/iosfwd:108:27: note: template is declared here
class _LIBCPP_VISIBLE basic_istream;
^
google/protobuf/message.cc:135:67: error: implicit instantiation of
undefined
template 'std::__1::basic_istream<char, std::__1::char_traits<char> >'
return ParsePartialFromZeroCopyStream(&zero_copy_input) && input->eof();
^
/usr/include/c++/v1/iosfwd:108:27: note: template is declared here
class _LIBCPP_VISIBLE basic_istream;
^
google/protobuf/message.cc:175:16: error: implicit instantiation of
undefined
template 'std::__1::basic_ostream<char, std::__1::char_traits<char> >'
return output->good();
^
/usr/include/c++/v1/iosfwd:110:27: note: template is declared here
class _LIBCPP_VISIBLE basic_ostream;
^
3 errors generated.
gmake[2]: *** [message.lo] Error 1
Then, I followed this
link(http://freebsd.1045724.n5.nabble.com/ports-166011-patch-devel-protobuf-unbreak-with-libc-td5561262.html)
and patched it. These errors disappeared, but a lot of link errors came up.
All of them are shown in attachment build.log.
Attachments:
build.log 41.3 KB
Owner: liu...@google.com
Labels: Type-Defect Priority-Medium
New issue 449 by yayj...@gmail.com: Link error while using clang++ with
-stdlib=libc++ flag in OSX
http://code.google.com/p/protobuf/issues/detail?id=449
What steps will reproduce the problem?
1. To avoid the affection of my other code, I wrote down this short snippet:
packet.proto:
message packet {
required uint32 var = 1;
}
And pb.cc:
#include "packet.pb.h"
int main()
{
GOOGLE_PROTOBUF_VERIFY_VERSION;
google::protobuf::ShutdownProtobufLibrary();
return 0;
}
2. If I try to link with libc++, clang++ will complain like this error:
$ clang++ -stdlib=libc++ -o pb pb.cc packet.pb.cc -lprotobuf
Undefined symbols for architecture x86_64:
"google::protobuf::MessageFactory::InternalRegisterGeneratedFile(char
const*, void (*)(std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > const&))", referenced from:
protobuf_AddDesc_packet_2eproto() in packet-q8y2hq.o
"google::protobuf::DescriptorPool::FindFileByName(std::__1::basic_string<char,
std::__1::char_traits<char>,
std::__1::allocator<char> > const&) const",
referenced from:
protobuf_AssignDesc_packet_2eproto() in packet-q8y2hq.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
3. But everything seems OK without libc++:
$ clang++ -o pb pb.cc packet.pb.cc -lprotobuf
$ otool -L pb
pb:
/usr/local/lib/libprotobuf.7.dylib (compatibility version 8.0.0,
current version 8.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 169.3.0)
What is the expected output? What do you see instead?
Linking stage passed for sure.
What version of the product are you using? On what operating system?
OS: OS X 10.8.2
Here are the versions of clang and protobuf:
$ clang -v
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix
$ brew info protobuf
protobuf: stable 2.4.1
http://code.google.com/p/protobuf/
/usr/local/Cellar/protobuf/2.4.1 (62 files, 5.9M) *
https://github.com/mxcl/homebrew/commits/master/Library/Formula/protobuf.rb
Please provide any additional information below.
And I also compiled the snippet on a Linux workstation on which clang and
libc++ were installed. But no error was raised with libc++.
$ /opt/llvm/bin/clang++ -stdlib=libc++ -o pb pb.cc packet.pb.cc -lprotobuf
$ ldd pb
linux-gate.so.1 => (0x005dd000)
libprotobuf.so.7 => /usr/local/lib/libprotobuf.so.7 (0x0035c000)
libc++.so.1 => /usr/lib/libc++.so.1 (0x00113000)
libm.so.6 => /lib/libm.so.6 (0x0072d000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x006ea000)
libc.so.6 => /lib/libc.so.6 (0x00a6c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x001b1000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x001cc000)
librt.so.1 => /lib/librt.so.1 (0x002b7000)
/lib/ld-linux.so.2 (0x008c3000)
As you can see above, I built libc++ on Linux by using libstdc++ as the ABI
layer.
$ clang++ -v
clang version 3.1 (tags/RELEASE_31/final 170526)
Target: i386-pc-linux-gnu
Thread model: posix
libcxx$ svn info
Path: .
URL: http://llvm.org/svn/llvm-project/libcxx/trunk
Repository Root: http://llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 170542
Node Kind: directory
Schedule: normal
Last Changed Author: marshall
Last Changed Rev: 170435
Last Changed Date: 2012-12-19 00:46:30 +0800 (Wed, 19 Dec 2012)
Because I didn't know whether it is the root cause or not that my protobuf
library is built by libstdc++ instead of libc++, I also tried to build it
with libc++ instead of homebrew.
$ ./configure CC=clang CXX=clang++ CXXFLAGS='-stdlib=libc++'
$ make
...
/bin/sh ../libtool --tag=CXX --mode=compile clang++ -DHAVE_CONFIG_H -I.
-I.. -D_THREAD_SAFE -pthread -Wall -Wwrite-strings -Woverloaded-virtual
-Wno-sign-compare -O2 -pipe -stdlib=libc++ -MT message.lo -MD -MP
-MF .deps/message.Tpo -c -o message.lo `test
-f 'google/protobuf/message.cc' || echo './'`google/protobuf/message.cc
libtool: compile: clang++ -DHAVE_CONFIG_H -I. -I.. -D_THREAD_SAFE -pthread
-Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -O2 -pipe
-stdlib=libc++ -MT message.lo -MD -MP -MF .deps/message.Tpo -c
google/protobuf/message.cc -fPIC -DPIC -o .libs/message.o
google/protobuf/message.cc:130:60: error: implicit instantiation of
undefined
template 'std::__1::basic_istream<char, std::__1::char_traits<char> >'
return ParseFromZeroCopyStream(&zero_copy_input) && input->eof();
^
/usr/include/c++/v1/iosfwd:108:27: note: template is declared here
class _LIBCPP_VISIBLE basic_istream;
^
google/protobuf/message.cc:135:67: error: implicit instantiation of
undefined
template 'std::__1::basic_istream<char, std::__1::char_traits<char> >'
return ParsePartialFromZeroCopyStream(&zero_copy_input) && input->eof();
^
/usr/include/c++/v1/iosfwd:108:27: note: template is declared here
class _LIBCPP_VISIBLE basic_istream;
^
google/protobuf/message.cc:175:16: error: implicit instantiation of
undefined
template 'std::__1::basic_ostream<char, std::__1::char_traits<char> >'
return output->good();
^
/usr/include/c++/v1/iosfwd:110:27: note: template is declared here
class _LIBCPP_VISIBLE basic_ostream;
^
3 errors generated.
gmake[2]: *** [message.lo] Error 1
Then, I followed this
link(http://freebsd.1045724.n5.nabble.com/ports-166011-patch-devel-protobuf-unbreak-with-libc-td5561262.html)
and patched it. These errors disappeared, but a lot of link errors came up.
All of them are shown in attachment build.log.
Attachments:
build.log 41.3 KB
prot...@googlecode.com
Jan 5, 2013, 7:12:02 PM1/5/13
to prot...@googlegroups.com
Comment #1 on issue 449 by ltwar...@gmail.com: Link error while using
Index: src/google/protobuf/message.cc
===================================================================
--- src/google/protobuf/message.cc (revision 463)
+++ src/google/protobuf/message.cc (working copy)
@@ -32,6 +32,7 @@
// Based on original Protocol Buffers design by
// Sanjay Ghemawat, Jeff Dean, and others.
+#include <iostream>
#include <stack>
#include <google/protobuf/stubs/hash.h>
And the problem is gone, i saw this first time here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=166011
I'm willing to see this go upstream.
prot...@googlecode.com
Jan 5, 2013, 7:19:23 PM1/5/13
to prot...@googlegroups.com
Comment #2 on issue 449 by ltwar...@gmail.com: Link error while using
Ps. this solves the problem of building protobuf with libc++ and clang++ :)
Your problem with the link errors comes from that You are trying to mix
libs compiled with libstdc++ and libc++, this can't be as for example
string implementations in those two differ so those libs are not binary
compatible (except for some low lebel stuff), see this post:
http://stackoverflow.com/questions/8454329/why-cant-clang-with-libc-in-c0x-mode-link-this-boostprogram-options-examp
prot...@googlecode.com
Jan 5, 2013, 10:19:39 PM1/5/13
to prot...@googlegroups.com
Updates:
Status: Accepted
Owner: xiaof...@google.com
Comment #3 on issue 449 by xiaof...@google.com: Link error while using
Thanks for the patch.
Status: Accepted
Owner: xiaof...@google.com
Comment #3 on issue 449 by xiaof...@google.com: Link error while using
Thanks for the patch.
prot...@googlecode.com
Jan 6, 2013, 12:06:20 AM1/6/13
to prot...@googlegroups.com
Comment #4 on issue 449 by yayj...@gmail.com: Link error while using
Yep, it seems that my assumption was correct.
As a result, I tried to rebuild protobuf library with libc++ but failed.
According to the description in your stackoverflow link, libc++ uses
std::__1 namespace while libstdc++ uses std directly.
So, that means -stdlib=libc++ flags makes compilation with libc++, but
without libc++ when linking. It's very strange. Then I try to add it
manually:
protobuf-2.4.1$ ./configure CC=clang CXX=clang++ CXXFLAGS='-stdlib=libc++'
LIBS='-lc++'
protobuf-2.4.1$ make
Everything seems OK and libprotobuf.dylib is generated. Now checking its
dependency:
protobuf-2.4.1$ otool -L src/.libs/libprotobuf.dylib
src/.libs/libprotobuf.7.dylib:
/usr/lib/libprotobuf.7.dylib (compatibility version 8.0.0, current
version 8.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
version 65.1.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version
1.2.5)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 169.3.0)
Why it still contains libstdc++?
version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 169.3.0)
prot...@googlecode.com
Jan 6, 2013, 7:37:31 AM1/6/13
to prot...@googlegroups.com
Comment #5 on issue 449 by ltwar...@gmail.com: Link error while using
Im doing this in Linux.
My configure:
./configure --prefix=/usr CC=clang CXX=clang++ CXXFLAGS="-O2
-stdlib=libc++" LIBS="-lc++ -lc++abi"
After compilation and installation:
ldd /usr/lib/libprotobuf.so
linux-vdso.so.1 (0x00007fffe4505000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fe3199ea000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007fe3197d4000)
libc++abi.so.1 => /usr/lib/libc++abi.so.1 (0x00007fe319785000)
libc++.so.1 => /usr/lib/libc++.so.1 (0x00007fe3195f6000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fe3192f8000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fe318f4b000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fe318d35000)
/usr/lib/ld-linux-x86-64.so.2 (0x00007fe319d63000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007fe318b2d000)
There is not libstdc++
Note: libc++ does not come with the ABI layer, that is why i'm linking also
libc++abi. This may be the cause that in Your case libstdc++ is still
pulled as a fallback to unresolved symbols, i think that this is the way
that FreeBSD guys did it or maybe You linker has some defaults.
Ps. The "string" case is the way to version libraries, in this case C++11
inline namespace feature is used.
prot...@googlecode.com
Jan 6, 2013, 11:47:55 PM1/6/13
to prot...@googlegroups.com
Comment #6 on issue 449 by yayj...@gmail.com: Link error while using
On OSX, libc++ takes libc++abi as the ABI layer by default I think. And
otool command doesn't print the indirect dependency libraries. Let's see:
protobuf-2.4.1$ otool -L src/.libs/libprotobuf.dylib
src/.libs/libprotobuf.dylib:
/usr/lib/libprotobuf.7.dylib (compatibility version 8.0.0, current
version 8.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version
1.2.5)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
version 65.1.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 169.3.0)
protobuf-2.4.1$ otool -L /usr/lib/libc++.1.dylib
version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 169.3.0)
/usr/lib/libc++.1.dylib:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
version 65.1.0)
/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current
version 24.2.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 169.3.0)
I also tried to use your configure parameters, but it still contains
version 169.3.0)
libstdc++:
protobuf-2.4.1$ otool -L src/.libs/libprotobuf.dylib
src/.libs/libprotobuf.dylib:
/usr/lib/libprotobuf.7.dylib (compatibility version 8.0.0, current
version 8.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version
1.2.5)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
version 65.1.0)
/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current
version 24.4.0)
prot...@googlecode.com
Jan 7, 2013, 12:11:19 PM1/7/13
to prot...@googlegroups.com
Comment #7 on issue 449 by ltwar...@gmail.com: Link error while using
Link in verbose mode and check what things is Your linker pulling in, maybe
it is some default.
prot...@googlecode.com
Feb 4, 2013, 12:17:44 PM2/4/13
to prot...@googlegroups.com
Comment #10 on issue 449 by ltwar...@gmail.com: Link error while using
When this will hit the trunk ? :)
prot...@googlecode.com
Feb 5, 2013, 2:14:48 PM2/5/13
to prot...@googlegroups.com
Comment #11 on issue 449 by rhl...@comcast.net: Link error while using
Is google planning a fix and re-release? thank you
prot...@googlecode.com
Feb 7, 2013, 2:07:14 AM2/7/13
to prot...@googlegroups.com
Updates:
Status: Fixed
Comment #12 on issue 449 by xiaof...@google.com: Link error while using
Fixed in r475
Status: Fixed
Comment #12 on issue 449 by xiaof...@google.com: Link error while using
Fixed in r475
prot...@googlecode.com
Apr 5, 2013, 9:46:36 AM4/5/13
to prot...@googlegroups.com
Comment #13 on issue 449 by yayj...@gmail.com: Link error while using
Here's the linking command line:
clang++ -dynamiclib
-o .libs/libprotobuf.8.dylib .libs/atomicops_internals_x86_gcc.o .libs/atomicops_internals_x86_msvc.o .libs/common.o .libs/once.o .libs/stringprintf.o .libs/extension_set.o .libs/generated_message_util.o .libs/message_lite.o .libs/repeated_field.o .libs/wire_format_lite.o .libs/coded_stream.o .libs/zero_copy_stream.o .libs/zero_copy_stream_impl_lite.o .libs/strutil.o .libs/substitute.o .libs/structurally_valid.o .libs/descriptor.o .libs/descriptor.pb.o .libs/descriptor_database.o .libs/dynamic_message.o .libs/extension_set_heavy.o .libs/generated_message_reflection.o .libs/message.o .libs/reflection_ops.o .libs/service.o .libs/text_format.o .libs/unknown_field_set.o .libs/wire_format.o .libs/gzip_stream.o .libs/printer.o .libs/tokenizer.o .libs/zero_copy_stream_impl.o .libs/importer.o .libs/parser.o
-lz -lc++ -install_name /usr/local/lib/libprotobuf.8.dylib
-compatibility_version 9 -current_version 9.0 -Wl,-single_module
I didn't find why linking libstdc++. And, by the way, now I'm using 2.5.0.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
prot...@googlecode.com
Apr 8, 2013, 1:30:36 PM4/8/13
to prot...@googlegroups.com
Comment #14 on issue 449 by cvet...@gmail.com: Link error while using
I have been bumping HARD into this one too.
The default one within clang is libstdc++, so providing -lc++ results in
that being linked to as well. Only -stdlib=libc++ option should be used if
you don't want a library linked to both stdc++ and c++ libs.
For me the problem seems to be that somehow LDFLAGS is somehow ignored when
I do make (I provide LDFLAGS=-stdlib=libc++ on ./configure). This is the
command called:
/bin/sh ../libtool --tag=CXX --mode=link /usr/bin/clang++ -D_THREAD_SAFE
-Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare
-stdlib=libc++ -version-info 7:0:0 -export-dynamic -no-undefined -o
libprotobuf.la -rpath
/Users/cvetan/workspace/tundra/deps/osx-64/protobuf/lib common.lo once.lo
extension_set.lo generated_message_util.lo message_lite.lo
repeated_field.lo wire_format_lite.lo coded_stream.lo zero_copy_stream.lo
zero_copy_stream_impl_lite.lo strutil.lo substitute.lo
structurally_valid.lo descriptor.lo descriptor.pb.lo descriptor_database.lo
dynamic_message.lo extension_set_heavy.lo generated_message_reflection.lo
message.lo reflection_ops.lo service.lo text_format.lo unknown_field_set.lo
wire_format.lo gzip_stream.lo printer.lo tokenizer.lo
zero_copy_stream_impl.lo importer.lo parser.lo -lz -stdlib=libc++
and this is actually executed (notice that there is no mentioning of libc++
here) :
libtool: link: /usr/bin/clang++ -dynamiclib
-o .libs/libprotobuf.7.dylib .libs/common.o .libs/once.o .libs/extension_set.o .libs/generated_message_util.o .libs/message_lite.o .libs/repeated_field.o .libs/wire_format_lite.o .libs/coded_stream.o .libs/zero_copy_stream.o .libs/zero_copy_stream_impl_lite.o .libs/strutil.o .libs/substitute.o .libs/structurally_valid.o .libs/descriptor.o .libs/descriptor.pb.o .libs/descriptor_database.o .libs/dynamic_message.o .libs/extension_set_heavy.o .libs/generated_message_reflection.o .libs/message.o .libs/reflection_ops.o .libs/service.o .libs/text_format.o .libs/unknown_field_set.o .libs/wire_format.o .libs/gzip_stream.o .libs/printer.o .libs/tokenizer.o .libs/zero_copy_stream_impl.o .libs/importer.o .libs/parser.o
-lz -install_name
/Users/cvetan/workspace/tundra/deps/osx-64/protobuf/lib/libprotobuf.7.dylib
-compatibility_version 8 -current_version 8.0 -Wl,-single_module
which will result into the following:
Undefined symbols for architecture x86_64:
"std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::find_first_of(char const*, unsigned long,
unsigned long) const", referenced from:
void
google::protobuf::SplitStringToIteratorUsing<std::__1::back_insert_iterator<std::__1::vector<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> > > > >
>(std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > const&, char const*,
>(std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::back_insert_iterator<std::__1::vector<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> > > > >&) in
strutil.o
"std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::find_first_not_of(char const*, unsigned long,
unsigned long) const", referenced from:
void
google::protobuf::SplitStringToIteratorUsing<std::__1::back_insert_iterator<std::__1::vector<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> > > > >
>(std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > const&, char const*,
>(std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::back_insert_iterator<std::__1::vector<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> > > > >&) in
strutil.o
"std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::find(char const*, unsigned long, unsigned
long) const", referenced from:
google::protobuf::StringReplace(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&,
std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > const&, std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool,
std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >*) in strutil.o
google::protobuf::compiler::ContainsParentReference(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&) in
importer.o
"std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::find(char, unsigned long) const", referenced
from:
google::protobuf::DescriptorBuilder::LookupSymbolNoPlaceholder(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&,
std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > const&,
google::protobuf::DescriptorBuilder::ResolveMode) in descriptor.o
"std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::rfind(char, unsigned long) const", referenced
from:
google::protobuf::DescriptorBuilder::AddPackage(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&,
google::protobuf::Message const&, google::protobuf::FileDescriptor const*)
in descriptor.o
google::protobuf::DescriptorBuilder::AddSymbol(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&, void
const*, std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > const&, google::protobuf::Message const&,
google::protobuf::(anonymous namespace)::Symbol) in descriptor.o
google::protobuf::DescriptorBuilder::LookupSymbolNoPlaceholder(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&,
std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > const&,
google::protobuf::DescriptorBuilder::ResolveMode) in descriptor.o
google::protobuf::DescriptorBuilder::NewPlaceholder(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&,
google::protobuf::DescriptorBuilder::PlaceholderType) in descriptor.o
So one workaround is (which is the one I used) to "lie" that the CXX
compiler is actually "/usr/bin/clang++ -stdlib=libc++" instead of
plain "/usr/bin/clang++" to make sure your -stdlib=libc++ is not ignored.
And there you go
libprotobuf.7.dylib:
@executable_path/../lib/libprotobuf.7.dylib (compatibility version 8.0.0,
current version 8.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
65.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
169.3.0)
169.3.0)
prot...@googlecode.com
Apr 9, 2013, 1:46:05 PM4/9/13
to prot...@googlegroups.com
Comment #15 on issue 449 by ltwar...@gmail.com: Link error while using
I'm using 2.5.x too. This is not the linking command line, this is compiler
invocation which is passing some things to the linker, You need to know
what exactly is being called, for e.g ld.gold etc. Pass "--verbose" to the
clang and see what things clang is exactly doing, this will also show You
the linker invocation.
prot...@googlecode.com
Apr 10, 2013, 6:40:04 AM4/10/13
to prot...@googlegroups.com
Comment #16 on issue 449 by yayj...@gmail.com: Link error while using
I must say sorry for the mistake I made. I didn't notice that
-stdlib=libc++ argument acts as a switch to decide whether libc++ to be
used at linking time. It means, if using our previous configuration command
line, -lc++ is useless while linking, because -lstdc++ will be passed to
linker since -stdlib=libc++ is not specified.
So, I think configuration command line should be ./configure CC=clang
CXX=clang++ CXXFLAGS='-stdlib=libc++' LDFLAGS='-stdlib=libc++'.
But, it still failed while linking. I checked the linker command line:
/bin/sh ../libtool --tag=CXX --mode=link clang++ -D_THREAD_SAFE -Wall
-Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -stdlib=libc++
-version-info 8:0:0 -export-dynamic -no-undefined -stdlib=libc++ -o
libprotobuf.la -rpath /usr/local/lib atomicops_internals_x86_gcc.lo
atomicops_internals_x86_msvc.lo common.lo once.lo stringprintf.lo
extension_set.lo generated_message_util.lo message_lite.lo
repeated_field.lo wire_format_lite.lo coded_stream.lo zero_copy_stream.lo
zero_copy_stream_impl_lite.lo strutil.lo substitute.lo
structurally_valid.lo descriptor.lo descriptor.pb.lo descriptor_database.lo
dynamic_message.lo extension_set_heavy.lo generated_message_reflection.lo
message.lo reflection_ops.lo service.lo text_format.lo unknown_field_set.lo
wire_format.lo gzip_stream.lo printer.lo tokenizer.lo
zero_copy_stream_impl.lo importer.lo parser.lo -lz
libtool: link: clang++ -dynamiclib
repeated_field.lo wire_format_lite.lo coded_stream.lo zero_copy_stream.lo
zero_copy_stream_impl_lite.lo strutil.lo substitute.lo
structurally_valid.lo descriptor.lo descriptor.pb.lo descriptor_database.lo
dynamic_message.lo extension_set_heavy.lo generated_message_reflection.lo
message.lo reflection_ops.lo service.lo text_format.lo unknown_field_set.lo
wire_format.lo gzip_stream.lo printer.lo tokenizer.lo
zero_copy_stream_impl.lo importer.lo parser.lo -lz
-o .libs/libprotobuf.8.dylib .libs/atomicops_internals_x86_gcc.o .libs/atomicops_internals_x86_msvc.o .libs/common.o .libs/once.o .libs/stringprintf.o .libs/extension_set.o .libs/generated_message_util.o .libs/message_lite.o .libs/repeated_field.o .libs/wire_format_lite.o .libs/coded_stream.o .libs/zero_copy_stream.o .libs/zero_copy_stream_impl_lite.o .libs/strutil.o .libs/substitute.o .libs/structurally_valid.o .libs/descriptor.o .libs/descriptor.pb.o .libs/descriptor_database.o .libs/dynamic_message.o .libs/extension_set_heavy.o .libs/generated_message_reflection.o .libs/message.o .libs/reflection_ops.o .libs/service.o .libs/text_format.o .libs/unknown_field_set.o .libs/wire_format.o .libs/gzip_stream.o .libs/printer.o .libs/tokenizer.o .libs/zero_copy_stream_impl.o .libs/importer.o .libs/parser.o
-lz -install_name /usr/local/lib/libprotobuf.8.dylib
-compatibility_version 9 -current_version 9.0 -Wl,-single_module
2 files were linked, libprotobuf.la and libprotobuf.8.dylib. For
libprotobuf.la, CXXFLAGS and LDFLAGS were both passed to clang++. But the 2
flags were missing while linking libprotobuf.8.dylib. Then I tried to add
-stdlib=libc++ manually, everything was ok.
$ otool -L .libs/libprotobuf.8.dylib
.libs/libprotobuf.8.dylib:
/usr/local/lib/libprotobuf.8.dylib (compatibility version 9.0.0,
current version 9.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version
1.2.5)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
version 65.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 169.3.0)
I guess that might be caused by configure script or autoconf or something
version 169.3.0)
else to generate Makefile.
So is that a problem?
prot...@googlecode.com
Apr 10, 2013, 11:36:12 AM4/10/13
to prot...@googlegroups.com
Comment #17 on issue 449 by ltwar...@gmail.com: Link error while using
Hard to tell because i only need to do:
./configure --prefix=/usr CC=clang CXX=clang++ CXXFLAGS="-O2
-stdlib=libc++" LIBS="-lc++ -lc++abi" but You are closer than further to
the solution :)
prot...@googlecode.com
Jul 25, 2013, 6:10:31 AM7/25/13
to prot...@googlegroups.com
Comment #18 on issue 449 by trojan...@gmail.com: Link error while using
This appears to be resolved in 2.5.1-pre.
When building protobuf under OSX 10.8.4 with:
./configure CC=clang CXX=clang++ CXXFLAGS='-stdlib=libc++ -O3 -g'
LDFLAGS='-stdlib=libc++' --prefix=/opt/local
and a test project with:
kraken:~/Source/Test/protobuf $ make
/opt/local/bin/protoc --cpp_out=. addressbook.proto
clang++ -stdlib=libc++ -O3 -g -I/opt/local/include -c -o readab.o
readab.cpp
clang++ -stdlib=libc++ -O3 -g -I/opt/local/include -c -o addressbook.pb.o
addressbook.pb.cc
clang++ -stdlib=libc++ -L/opt/local/lib -o readab readab.o addressbook.pb.o
-lprotobuf
clang++ -stdlib=libc++ -O3 -g -I/opt/local/include -c -o writeab.o
writeab.cpp
clang++ -stdlib=libc++ -L/opt/local/lib -o writeab writeab.o
addressbook.pb.o -lprotobuf
I get:
kraken:~/Source/Test/protobuf $ otool -L readab
readab:
/opt/local/lib/libprotobuf.9.dylib (compatibility version 10.0.0,
current version 10.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
version 65.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 169.3.0)
kraken:~/Source/Test/protobuf $ otool -L /opt/local/lib/libprotobuf.9.dylib
version 169.3.0)
/opt/local/lib/libprotobuf.9.dylib:
/opt/local/lib/libprotobuf.9.dylib (compatibility version 10.0.0,
current version 10.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version
1.2.5)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
version 65.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 169.3.0)
version 169.3.0)
prot...@googlecode.com
Aug 8, 2013, 3:11:02 PM8/8/13
to prot...@googlegroups.com
Comment #19 on issue 449 by spacecad...@gmail.com: Link error while using
Use the CXX compiler variable to make libtool use the flags for linking too:
./configure CC=clang CXX="clang++ -std=c++11 -stdlib=libc++" CXXFLAGS="-O3"
Tried with 2.5.0
protobuf-2.5.0 $ otool -L build/lib/libprotobuf.8.dylib
build/lib/libprotobuf.8.dylib:
/Users/spacecadet/src/protobuf-2.5.0/build/lib/libprotobuf.8.dylib
(compatibility version 9.0.0, current version 9.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
28.4.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
159.1.0)
prot...@googlecode.com
Aug 9, 2013, 7:53:07 AM8/9/13
to prot...@googlegroups.com
Comment #20 on issue 449 by kuznetsov.alexey: Link error while using
Oh thanks @spacecad It is actually working. So I made XCodeProject from
2.5.0 referrencing to the source files.
https://github.com/axet/protobuf-ios
Reply all
Reply to author
Forward
0 new messages