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.
Related
Basic Info:
system: macOS High Sierra(10.13.6)
editor : vs code(latest version)
Compiler: g++ (Xcode)
Target:deploy GLFW + GLAD
Question Description:
Recently, I'm learning to do some Computer Graphics related work. Everything is going smooth. However, when i create a window to test the env.Link error happened:
Undefined symbols for architecture x86_64:
"_gladLoadGLLoader", referenced from:
_main in main-5c211c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The terminal process terminated with exit code: 1
It seems I have not link some third party file. I
have fixed exactly the same problem by add "-lglfw" args to g++ when using functions in glfw3.h.
But when meeting glad related function : gladLoadGLLoader, I don't know how to do.
Something I have done:
Can find the head file.
#include glad/glad.h
#include GLFW/glfw3.h
Have put the file "glad.c" in workspace.
Try to Add "g++ -framework XXXXX" , But doesn't work.
Try to Add "g++ -lglfw3", But doesn't work.
Add "g++ -L or I /usr/lib or /usr/local/lib or /usr/local/include", But doesn't work.
Just tell the g++ to compile glad.c by adding "glad.c" to args. I thought glad.c will be compiled by default. Although I am not clear what happened, the problem is resolved anyway.
Add glad.c into Build Phases->Compile Sources
I'm trying to build an external PostgreSQL function on OSX 10.11 with both clang and gcc, but link failed with the following errors:
c++ -I/usr/local/Cellar/postgresql/9.5.3/include/server -fpic -c ./main.c
c++ -shared -o ttt.dylib main.o
Undefined symbols for architecture x86_64:
"_deconstruct_array", referenced from:
_psql_nearest in main.o
"_elog_finish", referenced from:
_psql_nearest in main.o
"_elog_start", referenced from:
_psql_nearest in main.o
"_get_typlenbyvalalign", referenced from:
_psql_nearest in main.o
"_pfree", referenced from:
_psql_nearest in main.o
"_pg_detoast_datum", referenced from:
_psql_nearest 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)
It looks like I need to link my library with some of PostgreSQL libraries. What are these libraries?
main.cpp:
extern "C" {
#include <postgres.h>
#include <fmgr.h>
#include <utils/array.h>
#include <utils/lsyscache.h>
#include <catalog/pg_type.h>
#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif
PG_FUNCTION_INFO_V1(psql_nearest);
Datum psql_nearest(PG_FUNCTION_ARGS) {
if(PG_ARGISNULL(0) || PG_ARGISNULL(1)) {
elog(ERROR, "DOC2VEC: NULL INPUT DATA");
PG_RETURN_NULL();
}
ArrayType *_docVector = PG_GETARG_ARRAYTYPE_P(0);
Oid elTypeVals = ARR_ELEMTYPE(_docVector);
if (elTypeVals != FLOAT4OID) {
elog(ERROR, "DOC2VEC: INVALID INPUT DATA TYPE");
PG_RETURN_NULL();
}
int16 typeLenVals = 0;
bool typeByValVals = false;
char typeAlignVals = char(0);
get_typlenbyvalalign(elTypeVals, &typeLenVals, &typeByValVals, &typeAlignVals);
Datum *inputVals;
bool *nullVals;
int nVals;
deconstruct_array(_docVector, elTypeVals, typeLenVals, typeByValVals, typeAlignVals, &inputVals, &nullVals, &nVals);
pfree(inputVals);
pfree(nullVals);
PG_RETURN_NULL();
}
}
Thanks to PostgreSQL developers, they explained me the difference in Linux and OSX linking of external functions.
Instead of -shared you need -bundle -bundle_loader /path/to/postgres,
and there are some other linker flags that are advisable too.
Also, PostgreSQL expects the file extension for loadable modules to be .so even on OSX.
It's usually better to use PGXS to build extensions, instead of
learning such details for yourself.
Or you can crib from one of the extensions in the contrib/
source tree.
If you need to link, you will need the -L flag to point the linker to the path where the postgres libraries are located (the linker equivalent of the -I compiler flag). and the -l flag to actually link the libraries (one for each library); the library name without the lib prefix and without the extension.
In your case, something along the lines of -L/usr/local/Cellar/postgresql/9.5.3/lib -lpostgres
(There's a variety of library files in that directory; try -lpg to start with.
The reference to _pfree in your error message also suggest to link pgcommon, which contains the implementation of pgree (at least when using nm libpgcommon.a).
)
You may want to read up a bit more on compiling and linking in general; you do the right thing for compiling with the -I flag, but oddly then miss out on the linking step. And learning about make and Makefiles will come in handy.
I also don't understand the extern "C" { part for a .c file, which is clearly a C-only file. extern "C" is usually used in C++ files for compatibility with C.
I created a new cocoa application in Xcode with 3 *.m files (main.m, AppDelegate.m, and projectnameTests.m).
In order to to use object-cpp, I renamed the 3 *.m files to *.mm files.
Then I get this following error from Xcode:
"Undefined symbols for architecture x86_64:
"_NSApplicationMain", 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)"
I have never dealt .o files, so am not sure what's wrong.
Please help.
P.S.: I use the latest Xcode, version(6.1.1).
Add AppKit.framework to the "Link Binary With Libraries" section under the Build Phases for your project target, and that should fix the problem.
P.S. Don't ask me why XCode automatically finds the necessary framework (i.e. AppKit.framework) for .m files but not for .mm files, but adding AppKit.framework fixes the issue because NSApplicationMain is defined in AppKit. Adding Cocoa.framework also fixes the issue, likely because it triggers XCode to automatically link with AppKit.framework.
I developed a couple of C++ libraries some years ago that were used by three C++ projects. I compiled the libraries as shared libraries as to not have to recompile/relink the program when the libs changed. I am porting their compilation process to CMake 3.0, but am having trouble with the compilation of one.
This library cannot provide some functionality; a couple of functions must be defined in the main program even though they are used inside the library. The reason is that the implementations of these functions depend on the program internal structure.
So the libraries have been compiled with a header declaring all these functions as extern. Here is an example coming from a header of the problematic's library:
extern char * Get_Name(void *b);
I am declaring the functions using extern keyword. After reading more about it, it seems the extern might be superfluous.
On x86_64 linux, I've never had any issue and used this organisation for years.
But now, the compilation of the library fails on OSX Mavericks (clang: Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)). It could be problem with my CMake files or worst, a quirk of OSX. The problem is that at linking time (when creating the .dynlib file) it can't find the definitions of the functions. The specific error is:
cmake VERBOSE=1
[...]
Linking CXX shared library libtiming.dylib
/Applications/CMake.app/Contents/bin/cmake -E cmake_link_script CMakeFiles/timingShared.dir/link.txt --verbose=1
/usr/bin/c++ -dynamiclib -Wl,-headerpad_max_install_names -o libtiming.dylib -install_name #rpath/libtiming.dylib <list of .o files> /Users/me/usr/lib/libone.dylib -Wl,-rpath,/Users/me/usr/lib
Undefined symbols for architecture x86_64:
"Function_Name(void*)", referenced from:
[...]
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
My questions are:
Is it possible for a C++ library to use functions that are defined in the program using the library?
If not, what is special about linux compilation that allowed me back then to compile the .so dynamic library even though some symbols are not defined in the objects (only in the main program)?
If it is possible, am I doing something wrong with CMake? Is the linking command posted above just missing something? Should I be using something different than "linking" to get the library I need?
Thank you.
Answer to 1:
The library may have unresolved symbols that need to be resolved. They can be resolved in another library or your program.
However, libraries need to be rebuilt in order to know what functions your program contains. So if a library needs to access a specific function in your program, it needs to be rebuilt with the declaration of that function.
In general, if a library is calling a function outside of its library, that function will be an unresolved symbol and should be declared in a header file.
Thanks Chris Statton; I had to tell the linker to ignore undefined symbols at link time.
On OSX Mavericks, man ld states:
-undefined treatment
Specifies how undefined symbols are to
be treated. Options are: error, warning,
suppress, or dynamic_lookup. The
default is error.
Passing -undefined dynamic_lookup to the linking process of the question solved the issue.
For the CMake part, I had to add the following after the add_library():
set_target_properties(${PROJECT_NAME} PROPERTIES LINK_FLAGS "-undefined dynamic_lookup")
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.