protobuf installed using brew but not found in build process - makefile

Background
Yesterday I built Caffe and had no problems with its dependencies.
Today I had problems building the Caffe Matlab wrappers due to protobuf dependencies not being found. So I rebuilt Caffe: make clean followed by a make all, hoping that would fix the problem.
Now the Caffe build is complaining about the protobuf dependency.
The error output is given at the bottom of this question.
Between the original (successful) build and the failed build, I needed to pip install protobuf to allow the Caffe python wrappers to import protobuf, as python complained about not being able to find the protobuf package. That was the only "change" involving protobuf prior to the failed Caffe rebuild.
I have tried reinstalling protobuf using brew, but this did not help.
So essentially the chronology of events relating to protobuf are as follows:
1. protobuf installed from source using brew:
brew install --build-from-source --with-python --fresh -vd protobuf
2. caffe built successfully
3. caffe python wrappers failed to build -- protobuf not found
4. pip install protobuf
5. caffe python wrappers built successfully
6. caffe matlab wrappers failed to build -- protobuf not found
7. tried to rebuild caffe -- failed -- protobuf not found
8. reinstalled protobuf from source using brew
9. tried again to rebuild caffe -- failed -- protobuf not found
Whenever protobuf was not found, brew list --versions showed that protobuf (2.6.1) was installed.
Question
Can someone please explain why protobuf is not being found when it is clearly installed?
What is particularly confusing is the fact that it was found initially (during the original, successful build) and now it is not being found despite following the same approach.
Here is the error output:
$ make clean
$ make all -j8
[... truncated ...]
CXX examples/mnist/convert_mnist_data.cpp
CXX examples/siamese/convert_mnist_siamese_data.cpp
CXX .build_release/src/caffe/proto/caffe.pb.cc
AR -o .build_release/lib/libcaffe.a
LD -o .build_release/lib/libcaffe.so
clang: warning: argument unused during compilation: '-pthread'
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .build_release/lib/libcaffe.a(cudnn_conv_layer.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .build_release/lib/libcaffe.a(cudnn_pooling_layer.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .build_release/lib/libcaffe.a(cudnn_relu_layer.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .build_release/lib/libcaffe.a(cudnn_sigmoid_layer.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .build_release/lib/libcaffe.a(cudnn_softmax_layer.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .build_release/lib/libcaffe.a(cudnn_tanh_layer.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .build_release/lib/libcaffe.a(cudnn.o) has no symbols
Undefined symbols for architecture x86_64:
"google::protobuf::io::CodedOutputStream::WriteStringWithSizeToArray(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned char*)", referenced from:
caffe::Datum::SerializeWithCachedSizesToArray(unsigned char*) const in caffe.pb.o
caffe::FillerParameter::SerializeWithCachedSizesToArray(unsigned char*) const in caffe.pb.o
caffe::NetParameter::SerializeWithCachedSizesToArray(unsigned char*) const in caffe.pb.o
caffe::SolverParameter::SerializeWithCachedSizesToArray(unsigned char*) const in caffe.pb.o
caffe::SolverState::SerializeWithCachedSizesToArray(unsigned char*) const in caffe.pb.o
caffe::NetState::SerializeWithCachedSizesToArray(unsigned char*) const in caffe.pb.o
caffe::NetStateRule::SerializeWithCachedSizesToArray(unsigned char*) const in caffe.pb.o
...
"google::protobuf::internal::empty_string_", referenced from:
caffe::Datum::SharedCtor() in caffe.pb.o
caffe::Datum::MergeFrom(caffe::Datum const&) in caffe.pb.o
caffe::Datum::~Datum() in caffe.pb.o
caffe::Datum::SharedDtor() in caffe.pb.o
caffe::Datum::Clear() in caffe.pb.o
caffe::Datum::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream*) in caffe.pb.o
caffe::NetParameter::SharedCtor() in caffe.pb.o
...
"google::protobuf::internal::WireFormatLite::WriteBytesMaybeAliased(int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, google::protobuf::io::CodedOutputStream*)", referenced from:
caffe::Datum::SerializeWithCachedSizes(google::protobuf::io::CodedOutputStream*) const in caffe.pb.o
"google::protobuf::internal::WireFormatLite::WriteStringMaybeAliased(int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, google::protobuf::io::CodedOutputStream*)", referenced from:
caffe::FillerParameter::SerializeWithCachedSizes(google::protobuf::io::CodedOutputStream*) const in caffe.pb.o
caffe::NetParameter::SerializeWithCachedSizes(google::protobuf::io::CodedOutputStream*) const in caffe.pb.o
caffe::SolverParameter::SerializeWithCachedSizes(google::protobuf::io::CodedOutputStream*) const in caffe.pb.o
caffe::SolverState::SerializeWithCachedSizes(google::protobuf::io::CodedOutputStream*) const in caffe.pb.o
caffe::ParamSpec::SerializeWithCachedSizes(google::protobuf::io::CodedOutputStream*) const in caffe.pb.o
caffe::LayerParameter::SerializeWithCachedSizes(google::protobuf::io::CodedOutputStream*) const in caffe.pb.o
caffe::TransformationParameter::SerializeWithCachedSizes(google::protobuf::io::CodedOutputStream*) const in caffe.pb.o
...
"google::protobuf::internal::InitEmptyString()", referenced from:
caffe::Datum::SharedCtor() in caffe.pb.o
caffe::FillerParameter::SharedCtor() in caffe.pb.o
caffe::NetParameter::SharedCtor() in caffe.pb.o
caffe::SolverParameter::SharedCtor() in caffe.pb.o
caffe::SolverState::SharedCtor() in caffe.pb.o
caffe::NetState::SharedCtor() in caffe.pb.o
caffe::NetStateRule::SharedCtor() in caffe.pb.o
...
"google::protobuf::internal::empty_string_once_init_", referenced from:
caffe::Datum::SharedCtor() in caffe.pb.o
caffe::FillerParameter::SharedCtor() in caffe.pb.o
caffe::NetParameter::SharedCtor() in caffe.pb.o
caffe::SolverParameter::SharedCtor() in caffe.pb.o
caffe::SolverState::SharedCtor() in caffe.pb.o
caffe::NetState::SharedCtor() in caffe.pb.o
caffe::NetStateRule::SharedCtor() in caffe.pb.o
...
"google::protobuf::io::CodedInputStream::BytesUntilTotalBytesLimit() const", referenced from:
bool google::protobuf::internal::WireFormatLite::ReadPackedPrimitive<float, (google::protobuf::internal::WireFormatLite::FieldType)2>(google::protobuf::io::CodedInputStream*, google::protobuf::RepeatedField<float>*) in caffe.pb.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [.build_release/lib/libcaffe.so] Error 1

Did you build protobuf from source? I had a similar problem due to compiling protobuf and my project with differing versions of libc++.
I solved it by adding c++11 to CXXFLAGS.

Related

Mac OS with M1 encounters with an error when using glfw glew [closed]

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 1 year ago.
Improve this question
error!
ld: warning: ignoring file /opt/homebrew/Cellar/glfw/3.3.2/lib/libglfw.3.dylib, building for macOS-x86_64 but attempting to link with file built for macOS-arm64
Undefined symbols for architecture x86_64:
"_glfwCreateWindow", referenced from:
GLWindow::GLWindow(int, int, char*) in MagicCubeLauncher.cpp.o
"_glfwDestroyWindow", referenced from:
GLWindow::~GLWindow() in MagicCubeLauncher.cpp.o
"_glfwGetKey", referenced from:
Render::processInput() in MagicCubeLauncher.cpp.o
"_glfwGetProcAddress", referenced from:
GLWindow::GLWindow(int, int, char*) in MagicCubeLauncher.cpp.o
"_glfwGetTime", referenced from:
Render::initRenderLayer() in MagicCubeLauncher.cpp.o
getTime() in MagicCubeLauncher.cpp.o
"_glfwInit", referenced from:
Shader::Shader(char const*, char const*) in MagicCubeLauncher.cpp.o
GLWindow::GLWindow(int, int, char*) in MagicCubeLauncher.cpp.o
"_glfwMakeContextCurrent", referenced from:
GLWindow::GLWindow(int, int, char*) in MagicCubeLauncher.cpp.o
"_glfwPollEvents", referenced from:
Render::initRenderLayer() in MagicCubeLauncher.cpp.o
"_glfwSetCursorPosCallback", referenced from:
Render::init() in MagicCubeLauncher.cpp.o
"_glfwSetFramebufferSizeCallback", referenced from:
Render::init() in MagicCubeLauncher.cpp.o
"_glfwSetInputMode", referenced from:
Render::processInput() in MagicCubeLauncher.cpp.o
"_glfwSetScrollCallback", referenced from:
Render::init() in MagicCubeLauncher.cpp.o
"_glfwSetWindowShouldClose", referenced from:
Render::processInput() in MagicCubeLauncher.cpp.o
"_glfwSwapBuffers", referenced from:
Render::initRenderLayer() in MagicCubeLauncher.cpp.o
"_glfwTerminate", referenced from:
GLWindow::GLWindow(int, int, char*) in MagicCubeLauncher.cpp.o
Render::clear() in MagicCubeLauncher.cpp.o
"_glfwWindowHint", referenced from:
GLWindow::GLWindow(int, int, char*) in MagicCubeLauncher.cpp.o
"_glfwWindowShouldClose", referenced from:
Render::initRenderLayer() in MagicCubeLauncher.cpp.o
ld: symbol(s) not found for architecture x86_64
Can i directly use Rosetta 2 to translate it into arm64 framework for using?
if NOT, is there any other methods i can use to run it on this framework
or i need to wait for glew and glfw to support it?
I ran into this issue previously and I finally found a fix for it. What's going on here is that your compiler is building for the wrong architecture. You need to specify that you would like to compile for apple silicon to make this work properly. Since you did not specify your build system, I'll go with what I used which, in this case, was CMake.
All you need to add is the CMAKE_APPLE_SILICON_PROCESSOR option, like so:
# Inside of your `build` directory
$ cmake -DCMAKE_APPLE_SILICON_PROCESSOR=arm64 ..
Without this, my code was explicitly specifying the x86_64 architecture and threw the error you posted. This might not be a silver bullet, but it's how I solved the above problem. You need to do whatever the equivalent of this is for your system, or explicitly specify the architecture if you're compiling manually.

Boost Linker Issues

I am using the Boost library and I am having some linker issues. Currently my code is outputting this:
Undefined symbols for architecture x86_64:
"boost::program_options::to_internal(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&)", referenced from:
std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > > boost::program_options::to_internal<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > >(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > > const&) in train_model_main.cc.o
"boost::program_options::variables_map::variables_map()", referenced from:
_main in train_model_main.cc.o (THE LIST CONTINUES)
At the bottom my code says this:
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I am trying to use the program_options library from Boost, but the linking step seems to be failing. Here is how I link in my CMake file:
find_package(Boost 1.73.0 COMPONENTS program_options REQUIRED)
if(Boost_FOUND)
include_directories(${Boost_INCLUDE_DIRS})
add_executable(main ./apps/something.cc)
target_link_libraries( main program_options)
endif()
I believe that I am correctly linking the library, so what could be causing this issue?
I'm gonna copy and paste the answer from the cmake discourse:
https://discourse.cmake.org/t/boost-linker-issues/2030
"I believe that I am correctly linking the libraryā€¯ unfortunately not. You need to reference the full target name including the namespace prefix with Boost::program_options. And you can omit adding the Boost_INCLUDE_DIRS explicitely as the target definition does include this information. So your lines would look like:" - Volker Enderlein
if(Boost_FOUND)
add_executable(main ./apps/something.cc)
target_link_libraries(main PUBLIC Boost::program_options)
endif()
Mismatch of architecture is the issue here. Match your compile of the application you are building with the boost program options
How do you build the x64 Boost libraries on Windows?
The address needs to be set to 64 in your case or use 64 bit binaries

How can I build LLVM and link it against libc++?

I am trying to build LLVM and link it against libc++, but I can't get it to work. I downloaded the latest version (LLVM 3.2).
$ CXXFLAGS=-stdlib=libc++ LDFLAGS=-stdlib=libc++ ../llvm-3.2.src/configure
$ make
llvm[0]: Constructing LLVMBuild project information.
llvm[1]: Compiling APFloat.cpp for Release+Asserts build
llvm[1]: Compiling APInt.cpp for Release+Asserts build
(etcetera)
llvm[1]: Building Release+Asserts Archive Library libLLVMTableGen.a
llvm[2]: Compiling FileCheck.cpp for Release+Asserts build
llvm[2]: Linking Release+Asserts executable FileCheck (without symbols)
Undefined symbols for architecture x86_64:
"std::string::find_last_not_of(char, unsigned long) const", referenced from:
llvm::SMDiagnostic::print(char const*, llvm::raw_ostream&, bool) const in libLLVMSupport.a(SourceMgr.o)
"std::string::copy(char*, unsigned long, unsigned long) const", referenced from:
llvm::sys::Path::makeUnique(bool, std::string*) in libLLVMSupport.a(Path.o)
"std::string::find(char const*, unsigned long, unsigned long) const", referenced from:
llvm::sys::getDefaultTargetTriple() in libLLVMSupport.a(Host.o)
"std::string::find(char, unsigned long) const", referenced from:
llvm::sys::Program::FindProgramByName(std::string const&) in libLLVMSupport.a(Program.o)
(followed by a bunch of other related linker errors)
Complete output on Gist.
LLVM compiles and links fine with libstdc++, but not with libc++. I have no idea why it won't link with libc++; other programs just link fine. I am running OS X Mountain Lion and libc++ is in /usr/lib/libc++.1.dylib. The compiler used is Apple clang version 4.0 (tags/Apple/clang-421.0.60) (based on LLVM 3.1svn).
Trust me, I'm not expert in this area. But try this:
../llvm/configure --enable-libcpp
And in general I've found:
../llvm/configure --help
quite helpful.

Qt4.8 + CMake 2.8.5 on OSX 10.5.8 can't link

I'm using Qt4.8 on OSX Leopard and instead of qmake+QtCreator I want to compile a very simple project using CMake on OSX to understand how to do a package.
While the very same project compiles and links smoothly under Linux, under my OSX box, this is the error message I always get in the linking phase:
ld warning: in /Library/Frameworks//QtGui.framework/QtGui, file is not of required architecture
ld warning: in /Library/Frameworks//QtCore.framework/QtCore, file is not of required architecture
Undefined symbols:
"QWidget::mousePressEvent(QMouseEvent*)", referenced from:
vtable for TestFormin moc_TestForm.cxx.o
"QObject::childEvent(QChildEvent*)", referenced from:
vtable for TestFormin moc_TestForm.cxx.o
"QWidget::actionEvent(QActionEvent*)", referenced from:
vtable for TestFormin moc_TestForm.cxx.o
"QCoreApplication::translate(char const*, char const*, char const*, QCoreApplication::Encoding)", referenced from:
etcetera etcetera.
This happens for every project I want to compile with cmake.
Any idea of what's going on?
Check what architecture (i386,x86_64) is being used by cmake (CMAKE_OSX_ARCHITECTURES). Try suggesting the architecture to cmake:
cmake -DCMAKE_OSX_ARCHITECTURES=x86_64

WxWidgets / GCC / MacOs X: How can I build and link the WxWidgets library properly?

I am trying to port a windows application based on WxWidgets 2.8.9 to MacOS X. I've gotten to the point where everything compiles successfully, except from a few missing symbols related to WxWidgets. I've tried compiling WxWidgets with the command line and with XCode and I've tried several different configuration options, but none of this has worked properly. The WxWidgets Wiki has a few articles about this here, but most of the information is outdated and none of it solved my problem.
The closest I got was by compiling WxWidgets at the command line with
./configure --enable-monolithic
make
Then I linked the library by adding "wxMac-2.8.9/lib/libwx_mac-2.8.a" to the "Other Linker Flags" in my XCode project settings.
But this gives me the following linking errors:
"wxOnAssert(char const*, int, char const*, char const*, char const*)", referenced from:
wxStringBase::wxStringBase(wxStringBase const&)in MyFrame.o
wxCloseEvent::Veto(bool) in MyFrame.o
wxStringBase::wxStringBase(wxStringBase const&)in TGameSettingsForm.o
wxCheckBoxBase::DoSet3StateValue(wxCheckBoxState) in TGameSettingsForm.o
wxCheckBoxBase::DoGet3StateValue() const in TGameSettingsForm.o
wxStringBase::wxStringBase(wxStringBase const&)in NonoGameStates.o
wxStringBase::wxStringBase(wxStringBase const&)in TWxInvalidRegCodeForm.o
"_iconv_close", referenced from:
wxMBConv_iconv::~wxMBConv_iconv()in libwx_mac-2.8.a(monolib_strconv.o)
wxMBConv_iconv::~wxMBConv_iconv()in libwx_mac-2.8.a(monolib_strconv.o)
wxMBConv_iconv::~wxMBConv_iconv()in libwx_mac-2.8.a(monolib_strconv.o)
wxMBConv_iconv::~wxMBConv_iconv()in libwx_mac-2.8.a(monolib_strconv.o)
"wxAppConsole::OnAssert(char const*, int, char const*, char const*)", referenced from:
vtable for CMyWxApp3_wxstaticAppin MyWxApp3-wxstaticApp.o
"_iconv", referenced from:
wxMBConv_iconv::GetMBNulLen() const in libwx_mac-2.8.a(monolib_strconv.o)
wxMBConv_iconv::WC2MB(char*, wchar_t const*, unsigned long) constin libwx_mac-2.8.a(monolib_strconv.o)
wxMBConv_iconv::WC2MB(char*, wchar_t const*, unsigned long) constin libwx_mac-2.8.a(monolib_strconv.o)
wxMBConv_iconv::MB2WC(wchar_t*, char const*, unsigned long) constin libwx_mac-2.8.a(monolib_strconv.o)
wxMBConv_iconv::MB2WC(wchar_t*, char const*, unsigned long) constin libwx_mac-2.8.a(monolib_strconv.o)
wxMBConv_iconv::wxMBConv_iconv(char const*)in libwx_mac-2.8.a(monolib_strconv.o)
"wxAppConsole::OnAssertFailure(char const*, int, char const*, char const*, char const*)", referenced from:
vtable for CMyWxApp3_wxstaticAppin MyWxApp3-wxstaticApp.o
"_iconv_open", referenced from:
wxMBConv_iconv::wxMBConv_iconv(char const*)in libwx_mac-2.8.a(monolib_strconv.o)
wxMBConv_iconv::wxMBConv_iconv(char const*)in libwx_mac-2.8.a(monolib_strconv.o)
wxMBConv_iconv::wxMBConv_iconv(char const*)in libwx_mac-2.8.a(monolib_strconv.o)
wxMBConv_iconv::wxMBConv_iconv(char const*)in libwx_mac-2.8.a(monolib_strconv.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
If possible, I would prefer dynamic linking, not static linking as used above. However, for the moment I would be happy to get it running at all. If anyone could give me (or point me to) a working step-by-step description on how to compile and link the WxWidgets library, I would be very thankful.
Thanks,
Adrian
I've not built wx under MacOS, but I do use it extensively under Windows and Linux. The instructions on the page you linked look very similar to those under Linux and it says:
Following make, you will find the
built library under your folder (eg,
build-release). This is also where the
corresponding wx-config is.
The wx-config script under Linux makes building projects a breeze, you simply use the command wx-config --cxxflags to get the compilation flags required for gcc and wx-config --libs to get all of the required libraries for linking. Under build environments such as Code::Blocks you can use those commands in the project settings, however I am not familiar with XCode - but worst case you just need to copy the compiler and linker options that the wx-config script lists.
wxOnAssert-related errors mean that you build your library in debug (__WXDEBUG__ defined, NDEBUG is not) while wxWidgets libraries were built in release build (__WXDEBUG__ not defined). The solution is simple: don't do this.
If you need to build a debug version, build wxWidgets in debug mode too using --enable-debug configure argument and use wx-config --debug ... to get the appropriate flags.

Resources