I am trying to compile an X11 application on Mac OS X using XQuartz (i.e. XQuartz provides an X11 implementation, so the code should compile directly).
The X11 code, however, is sophisticated enough to require OpenGL extensions through GLEW. This almost works, but a few symbols remain undefined. Here's the relevant, cleaned-up output of the verbose link:
"/usr/bin/ld" [flags] -o [out] [lib-dirs] [obj-file] [CustomLib2 CustomLib1] -lX11.6 -lGLEW -lGLEW.1.10 -lc++ -lstdc++ -lSystem /usr/bin/../lib/clang/4.2/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture x86_64:
"___glewXChooseFBConfig", referenced from: [place in CustomLib2]
"___glewXCreateContextAttribsARB", referenced from: [place in CustomLib2]
"___glewXSwapIntervalEXT", referenced from: [place in CustomLib2]
I checked the libraries, and they don't have any __glewX* symbols (though they have lots of __glew* symbols), despite this suggesting they should be there. I.e., these commands both come up empty:
nm /usr/lib/libGLEW.a | grep __glewX
nm /usr/lib/libGLEW.1.10.0.dylib | grep __glewX
My question: where are the __glewX* symbols located?
N.B. I am not using XCode or CMake. This is a simple makefile build.
Related
I'm mystified by why a large subset of symbols is apparently missing from OpenSSL libs I built on Mac.
In a CMake-based project, I'm compiling a lib (Restbed) that links statically with OpenSSL (both libssl and libcrypto). The Restbed lib appears to build fine, but if I try to link an application with it, it fails with lots of errors like:
Undefined symbols for architecture arm64:
"_BIO_ctrl", referenced from:
asio::ssl::detail::engine::map_error_code(std::__1::error_code&) const
in librestbed.a(service_impl.cpp.o)
asio::ssl::detail::engine::map_error_code(std::__1::error_code&) const
in librestbed.a(socket_impl.cpp.o)
"_BIO_ctrl_pending", referenced from:
asio::ssl::detail::engine::perform(int (asio::ssl::detail::engine::*)(void*, unsigned long), void*, unsigned long, std::__1::error_code&, unsigned long*) in
librestbed.a(service_impl.cpp.o)
The architecture isn't the problem; everything is built on M1 Mac.
To sum up, step 1 was build the static Restbed lib:
librestbed.a
libssl.a
libcrypto.a
All the output from that is here.
Then I tried to compile an app, linking statically with Restbed:
app
librestbed.a
Here's the build command for the app, which triggers the errors:
/usr/bin/clang++ -g -arch arm64 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/Series2Server.dir/main.cpp.o -o Series2Server -L/Users/me/data/series2server/restbed/library -Wl,-rpath,/Users/me/data/series2server/restbed/library -lrestbed -pthread
libssl and libcrypto are built from source using the configure tool provided in the OpenSSL source tree.
So I examined both libssl and libcrypto with nm -u, to see if the complained-about symbols were in there. Well, they aren't. Such symbols as BIO_ctrl are listed as undefined in both libssl and libcrypto.
I don't know what this means. How are symbols known about by nm, and yet "undefined" in the file under inspection? More importantly, how do I fix this problem so the application will build?
When you build a static lib, it does not involving linking at all -- you just run a tool (ar or libtool or some such) that collects the compiled object files into a static library and does not link any of them.
This means that when you link with a static library, you also need to link with any other libraries (static or dynamic) that it depends on.
I'm trying to compile camera_calibration on OSX 10.11 and after a few hurdles with a few X11 related dependencies I find myself still stuck with a few linking errors:
Undefined symbols for architecture x86_64:
"_glXChooseVisual", referenced from:
vis::OpenGLContextGLX::InitializeWindowless(vis::OpenGLContextImpl*) in opengl_context_glx.cc.o
"_glXCreateContext", referenced from:
vis::OpenGLContextGLX::InitializeWindowless(vis::OpenGLContextImpl*) in opengl_context_glx.cc.o
"_glXDestroyContext", referenced from:
vis::OpenGLContextGLX::Deinitialize() in opengl_context_glx.cc.o
"_glXGetCurrentContext", referenced from:
vis::IsOpenGLContextAvailable() in opengl.cc.o
vis::OpenGLContextGLX::AttachToCurrent() in opengl_context_glx.cc.o
"_glXGetCurrentDisplay", referenced from:
vis::OpenGLContextGLX::AttachToCurrent() in opengl_context_glx.cc.o
"_glXGetCurrentDrawable", referenced from:
vis::OpenGLContextGLX::AttachToCurrent() in opengl_context_glx.cc.o
"_glXMakeCurrent", referenced from:
vis::OpenGLContextGLX::MakeCurrent() in opengl_context_glx.cc.o
ld: symbol(s) not found for architecture x86_64
I found libGL.dylib has these symbols:
for lib in /usr/X11R6/lib/*.dylib;do nm -gU $lib | grep _glXChooseVisual;done
000000000000307f T _glXChooseVisual
000000000000307f T _glXChooseVisual
gp:src George$ for lib in /usr/X11R6/lib/*.dylib;do echo $lib && nm -gU $lib | grep _glXChooseVisual;done
/usr/X11R6/lib/libAppleWM.7.dylib
/usr/X11R6/lib/libAppleWM.dylib
/usr/X11R6/lib/libFS.6.dylib
/usr/X11R6/lib/libFS.dylib
/usr/X11R6/lib/libGL.1.dylib
000000000000307f T _glXChooseVisual
/usr/X11R6/lib/libGL.dylib
000000000000307f T _glXChooseVisual
However I can't seem to tweak CMakeLists.txt to take this into account.
I've tried adding:
set(X11R6_INCLUDE_DIRS "/usr/X11R6/include")
set(X11R6_LIBRARIES "/usr/X11R6/lib")
which I later use when calling target_include_directories and target_link_libraries for libvis, but doesn't seem to do the trick.
Hackily adding -lGL in target_link_libraries results in ld: library not found for -lGL
I've also looked at CMake's FindOpenGL reference and tried using find_package(OpenGL REQUIRED COMPONENTS OpenGL GLX) but didn't get very far:
CMake Error at /usr/local/Cellar/cmake/3.18.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
Could NOT find OpenGL (missing: GLX)
Any tips on correctly linking against GLX via CMake on OSX ?
On macOS do not(!) develop against X11 / GLX. They are not natively supported! The X11 server for macOS supports only indirect GLX with limited functionality. You will get only sub par performance. And CUDA (used by libvis) is not supported.
On macOS all OpenGL development should use the native OpenGL framework: https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_contexts/opengl_contexts.html
However take note that OpenGL has been declared deprecated by Apple.
In short: You'll at least have to modify your program to use the macOS OpenGL framework, or even bite the bullet and accept that macOS is not a well supported platform for your application.
I am very new with using GNU. I am trying to start using the boost filesystem library, and I keep getting these errors. I am trying to get the current working directory, by using boost::filesystem.
My code:
boost::filesystem::path full_path( boost::filesystem::detail::current_path() );
cout << "Current path is : " << full_path << endl;
My command:
g++ -I boost_1_58_0 main.cpp -o example
Result:
Undefined symbols for architecture x86_64:
"boost::filesystem::detail::current_path(boost::system::error_code*)", referenced from:
_main in main-1c56eb.o
"boost::system::system_category()", referenced from:
___cxx_global_var_init2 in main-1c56eb.o
"boost::system::generic_category()", referenced from:
___cxx_global_var_init in main-1c56eb.o
___cxx_global_var_init1 in main-1c56eb.o
ld: symbol(s) not found for architecture x86_64
Can someone please explain what the error is asking for? What did I do wrong?
boost.filesystem is not a header-only library. You have to link to the library using -L and -l flags. (And make sure the library is already properly built). You need to link to both boost_system and boost_filesystem libraries.
The command line could look like:
g++ -Iboost_1_58_0 -Lboost_1_58_0/lib/ -lboost-filesystem -lboost_system main.cpp -o example
(replace the -L argument with the path where the libboost-filesystem.so file resides)
Then, before you are able run the executable, you have to let the loader know where to look for the libraries. You shell be able do that using the following command:
export DYLD_LIBRARY_PATH=/path/to/boost/bib:$DYLD_LIBRARY_PATH
To make it automatic, I would recommend using a build system like cmake instead of just a command line.
I faced with the same issue for this question: Undefine symbols for architecture x86_64 using FFTW
And I tried to use flag -L and -l for C++ in xcode, but it doesn't work
Here is the error log:
clang: warning: -lsndfile: 'linker' input unused
clang: warning: -lfftw3: 'linker' input unused
clang: warning: argument unused during compilation: '-L/usr/local/lib'
Undefined symbols for architecture x86_64:
"_fftw_destroy_plan", referenced from:
_main in main.o
"_fftw_execute", referenced from:
_main in main.o
"_fftw_plan_dft_r2c_1d", referenced from:
_main in main.o
"_sf_close", referenced from:
_main in main.o
"_sf_open", referenced from:
_main in main.o
"_sf_read_double", referenced from:
_main in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
But if I compile with gcc in command line, it works well.
gcc -I/Users/sr2/Documents/Soft/fftw-3.3.4 -I/usr/local/include
-L/usr/local/lib -lfftw3 -lsndfile main.c -o fft_sample
where am I wrong?
Instead of putting these under "Other C/C++ Flags", they should go under "Other Linker Flags" (in the Linking section).
(Note that my XCode is old, so it may be slightly different for your version.)
You might wonder, why is this necessary?
Well, when you build your project, there are several stages to go through. The most basic breakdown is into compiling and linking. (They could perhaps be broken down further, but that's the important distinction here.)
The compiler takes a source file (eg, example.cpp) and outputs an object file (such as example.o). An object file is not executable. When compiling, the compiler generally only knows about the one source file that it's currently processing. Thus the compiler doesn't need to know which libraries you're using - all it needs to know is where the header files are.
The linker takes one or more object files and combines them together to create an executable binary. At this point, it must also resolve any external symbols not defined in your code - for example, symbols defined in an external library. For that reason, the linker needs to know about any libraries you're using.
The compiler does not know what to do with an -l or -L flag - they're not relevant to the process of compiling your code into an object file.
When you invoke gcc from the command-line like you demonstrated, it automatically invokes the linker for you and forwards those -l and -L flags to it. Because of this, no object file is produced on disk, and you get an executable file.
However, when you build through XCode, it does things a little differently. It invokes the compiler once for each of your source files, producing an object file like I described above. (This is the reason why you can specify extra compiler flags for specific source files in the Build Phases -> Compile Sources section.) Because the compiler has been asked to produce an object file, it does not invoke the linker, and since you're trying to pass it flags that should be forwarded to the linker, you get that warning that the flags are not used.
Once all the source files have successfully compiled, XCode next invokes the linker directly to combine them all into a single executable binary. This is the stage that needs to know about your libraries. (Incidentally, in any large project, this method is generally preferable even if you're not using XCode.)
You need probably add
-lstdc++
to the Other Linker Flags in Build Settings of your Project.
I'm having a compilation issue which I'm unable to solve. I'm developing a cross platform C++ project coding on both Mac Os X 10.8 and Windows. The code compiles and run fine on Windows and on Mac Os X Leopard as well.
Since Apple pushes the developers to stick to the latest platform for various reasons I'm forced to develop on Mountain Lion and I'm trying to get the project to work again.
I compiled correctly all the libraries I needed (wxWidgets, etc) and I imported the project in the latest version of Eclipse. When I try to build the project it tries to compile the firts .cpp file and at the end it (why?) tries to invoke the linker resulting on a series of missing symbols for my own defined classes. None of the other .cpp files is being compiled, so it's pretty understendable why the whole process is failing.
I also tried to invoke make from CLI, with the same result. I went into the makefile and everything seems correct. It looks like a very newbie issue, I feel I'm missing something huge here.
I'm pasting below the output of the compiler, just in case some compiling guru step in. Please feel free to ask for more details.
Compiler output
Pastebin Link: Compiler output
I used PB since the output is quite large.
The relevant section are the invocation of as and collect2 soon after the compiling phase of the very first .cpp file. The missing symbols are defined in other .cpp files in the same dir.
/usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin11/4.2.1/as -arch x86_64 -force_cpusubtype_ALL -o /var/folders/br/h6ln_j014ll56zwc8x6xjmk80000gn/T//ccSUmHal.o /var/folders/br/h6ln_j014ll56zwc8x6xjmk80000gn/T//ccn8ex81.s
/usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin11/4.2.1/collect2 -dynamic -arch x86_64 -macosx_version_min 10.8.3 -weak_reference_mismatches non-weak -o Calcoli.o -lcrt1.10.6.o -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/llvm-gcc-4.2/bin/../lib/gcc -L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/../../.. -L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/../../.. /var/folders/br/h6ln_j014ll56zwc8x6xjmk80000gn/T//ccSUmHal.o -lstdc++ -lSystem -lgcc -lSystem
The compiler output ends with the "classic" undefined symbol issue. All emphasized text*emphasized text*emphasized text
Undefined symbols for architecture x86_64:
"typeinfo for TipoPuntoCalc", referenced from:
Calcoli::setPuntoS(GTGraphicObject*) in ccSUmHal.o
"typeinfo for TipoPali", referenced from:
Calcoli::setPaloS(GTGraphicObject*) in ccSUmHal.o
"typeinfo for TipoRett", referenced from:
Calcoli::setFondazioneS(GTGraphicObject*) in ccSUmHal.o
"_main", referenced from:
start in crt1.10.6.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make: *** [Calcoli.o] Error 1
This shouldn't be an architecture related issue, since specifing i386 as target has the same result (symbol(s) not found for architecture i386).
Thank you,
Evelina
Go to your target's "Build Phases" section and verify that all the files you need to compile and link are actually included in the proper sections.
It sounds as if the compiler is not being told to include some things you need.