I am trying to use ImageMagick 6.7.3 with a C++ project in eclipse on my mac air running osx lion. I have been fighting with it for a few days googling and researching I can't seem to get the linker to find the files no matter what I try. Here is my linker log from eclipse does anyone have any idea why this isnt working?
I have populated the library search path and the include path settings in properties -> c/c++ build -> settings menus with the paths to the ImageMagick installation. Any help would be greatly appreciated!!!
Build of configuration Debug for project ImportingLibrary **
make all
Building target: ImportingLibrary
Invoking: MacOS X C++ Linker
g++ -L/Users/jon/Programs/ImageMagick-6.7.3/lib -o "ImportingLibrary" ./src/ChoicePath.o ./src/ImageCreation.o ./src/NavFocus.o ./src/RouteInputAnalyzer.o
Undefined symbols for architecture x86_64:
"_MagickWandGenesis", referenced from:
_main in NavFocus.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make: * [ImportingLibrary] Error 1
Build Finished **
Build of configuration Release for project ImportingLibrary **
make all
Building file: ../src/NavFocus.cpp
Invoking: GCC C++ Compiler
g++ -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/NavFocus.d" -MT"src/NavFocus.d" -o "src/NavFocus.o" "../src/NavFocus.cpp"
../src/NavFocus.cpp:13:29: warning: wand/MagickWand.h: No such file or directory
../src/NavFocus.cpp: In function 'int main()':
../src/NavFocus.cpp:19: error: 'MagickWandGenesis' was not declared in this scope
make: * [src/NavFocus.o] Error 1
Build Finished **
Related
Building C++ app using xerces, here is where it worked, on the build part
g++ -I/usr/local/include/xercesc -O0 -g3 -Wall -c -fmessage-length=0 -v -MMD -MP -MF"mypoject/xercesserver.d" -MT"myproject/xercesserver.o" -o "myproject/xercesserver.o" "../myproject/xercesserver.c"
...etc,etc, blah, blah, blah
Here is where it failed, linking
gcc -L/usr/local/lib -lxerces-c -o "myprojectapp" ./myproject/textfileread.o ./myproject/xercesserver.o
Undefined symbols for architecture x86_64:
"vtable for __cxxabiv1::__class_type_info", referenced from:
typeinfo for xercesc_3_2::XMLDeleter in xercesserver.o
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
"operator delete(void*)", referenced from:
xercesc_3_2::XMLDeleter::~XMLDeleter() in xercesserver.o
"___cxa_begin_catch", referenced from:
_main in xercesserver.o
"___cxa_end_catch", referenced from:
_main in xercesserver.o
"___gxx_personality_v0", referenced from:
xercesc_3_2::XMLDeleter::~XMLDeleter() in xercesserver.o
_main in xercesserver.o
Dwarf Exception Unwind Info (__eh_frame) in xercesserver.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Mac 10.13.1 High Sierra, Xerces 3.2, Eclipse Oxygen 3.a, CDT 9.4.3, gcc g++ both
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.2.0
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
A symbolic link, g++ -> gcc , but binaries differ in /usr/bin though same size.
Problem originated by creating C++ Project, C Managed Build, instead of a C++ Project, C++ Managed Build, which then necessitated the corrective given below. I had begun working on a C code project and later realized I needed the xerces code, which of course is C++. Otherwise you would just need to add the library as in the following image.
Note that the actual file's name is libxerces-c.a in the directory /usr/local/lib but Eclipse wants you to just give the root name, meaning xerces-c.
Now for the error caused by creating a C Managed build, a good clue was found here: How can I fix g++ Undefined symbols for architecture x86_64 error?
Problem finding this was partly that Eclipse is using g++ for the compiling but then gcc by default for the linking. So the problem is really how to fix gcc, not g++, and then the solution is actually to switch to g++. Also xerces FAQs brings up similar issues with different solutions. Attached pix shows the place to fix in Eclipse.
Hi I read one similar question- on using mex + nvcc linker problems with standard library. My problem is similar as I have code which compiles Ok with gcc on the Mac OS X. ( I am a beginner)
Code
gcc -lstdc++ trnr.c -o trnr works fine
Error
But I get these errors when I use mex
Building with 'Xcode with Clang'.
Error using mex
Undefined symbols for architecture x86_64:
"_mexFunction", referenced from:
-exported_symbol[s_list] command line option
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Not sure how to procede can anyone help
I am getting an error when I am compiling my project on Eclipse Kepler.
The project builds successfully, but the object is unsuccessfully created.
I am getting the following output on my console
23:13:32 **** Build of configuration Debug for project Dictionary ****
make all
Building file: ../src/Diction.cpp
Invoking: GCC C++ Compiler
g++ -O0 -g3 -Wall -c -fmessage-length=0 -MM -MMD -MP -MF"src/Diction.d" -MT"src/Diction.d" -o "src/Diction.o" "../src/Diction.cpp"
Finished building: ../src/Diction.cpp
Building target: Dictionary
Invoking: GCC C++ Linker
g++ -o "Dictionary" ./src/Diction.o
./src/Diction.o: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [Dictionary] Error 1
23:13:32 Build Finished (took 69ms)
Can someone please tell me what am I doing wrong??
So I am trying to use a C library in a Objective-C, iPhone project. I am getting this linker error when I try to compile:
file was built for unsupported file
format which is not the architecture
being linked (i386)
I build this library using the standard
./configure
make
Which architecture should I build this with to work with iPhone project? Thanks!
Update
I updated the Makefile and added -arch i386 to the CFLAGS line. When I run make I now this get this error:
Compiling spammer.c
gcc -o spammer spammer.o ../src/libircclient.a -lpthread
ld: warning: in ../src/libircclient.a, file was built for unsupported file format which is not the architecture being linked (x86_64)
Does this mean I need to edit another makefile somewhere??
It likely was built for x86_64 which is the default. You need to modify the library so that it's compiled for i386 and will match your application.
Typically you do that by setting the CFLAGS environment variable to -arch i386 before running configure. Make sure to do a "make dist clean" first though. If that doesn't work, you can also hand-edit the Makefile after configure creates it and add -arch i386 to the CFLAGS= line.
This error:
Compiling spammer.c gcc -o spammer spammer.o ../src/libircclient.a -lpthread ld: warning: in ../src/libircclient.a, file was built for unsupported file format which is not the architecture being linked (x86_64)
Comes when building the examples and that's not really what you want right?
Do a make in the SRC folder and building with -arch i386 or -arch arvm7 will work.
I built an iPhone toolchain on Ubuntu based on the directions at http://www.saurik.com/id/4 . When I try to compile something as simple as:
int main () {
return 4;
}
It gives me this:
Undefined symbols:
"_main", referenced from:
_main$non_lazy_ptr in crt1.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
This happens for both the crt1.o from the iPhone SDK and from the http://code.google.com/p/iphone-dev/wiki/Building . Using -save-temps, I found out that the cc1 command produced no output. Why is that? Is there something wrong with my specs file?
Using built-in specs.
Target: arm-apple-darwin10
Configured with: ../llvm-gcc-4.2-2.8.source/configure --target=arm-apple-darwin10 --prefix=/home/kevin/it --with-sysroot=/home/kevin/is --enable-languages=c,c++,objc,obj-c++ --with-as=/home/kevin/it/bin/arm-apple-darwin10-as --with-ld=/home/kevin/it/bin/arm-apple-darwin10-ld --enable-wchar_t=no --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658)
/home/kevin/it/libexec/gcc/arm-apple-darwin10/4.2.1/cc1 -quiet -v -D__DYNAMIC__ test.c -miphoneos-version-min=3.0 -fPIC -fno-builtin-strcat -fno-builtin-strcpy -quiet -dumpbase test.c -auxbase test -version -o /tmp/ccyVHwhV.s
ignoring nonexistent directory "/home/kevin/is/usr/local/include"
ignoring nonexistent directory "/home/kevin/is/home/kevin/it/lib/gcc/arm-apple-darwin10/4.2.1/../../../../arm-apple-darwin10/include"
ignoring nonexistent directory "/home/kevin/is/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/home/kevin/it/lib/gcc/arm-apple-darwin10/4.2.1/include
/home/kevin/is/usr/include
/home/kevin/is/System/Library/Frameworks (framework directory)
End of search list.
GNU C version 4.2.1 (Based on Apple Inc. build 5658) (arm-apple-darwin10)
compiled by GNU C version 4.4.5.
GGC heuristics: --param ggc-min-expand=150 --param ggc-min-heapsize=131072
Compiler executable checksum: 47b826ed9d7049d0b0acd26e928e4c9e
/home/kevin/it/bin/arm-apple-darwin10-as -arch arm -force_cpusubtype_ALL -o /tmp/cck3gviA.o /tmp/ccyVHwhV.s
ERROR: ld.so: object '/etc/override.so' from /etc/ld.so.preload cannot be preloaded: ignored.
ERROR: ld.so: object '/etc/override.so' from /etc/ld.so.preload cannot be preloaded: ignored.
/home/kevin/it/libexec/gcc/arm-apple-darwin10/4.2.1/collect2 -dynamic -arch arm -force_cpusubtype_ALL -iphoneos_version_min 3.0 -syslibroot /home/kevin/is -weak_reference_mismatches non-weak -o test -lcrt1.o -L/home/kevin/is/usr/lib -L/home/kevin/it/lib/gcc/arm-apple-darwin10/4.2.1 -L/home/kevin/it/lib/gcc/arm-apple-darwin10/4.2.1/../../../../arm-apple-darwin10/lib /tmp/cck3gviA.o -lgcc -lSystem
ERROR: ld.so: object '/etc/override.so' from /etc/ld.so.preload cannot be preloaded: ignored.
ld warning: unknown option to -iphoneos_version_min, not 1.x or 2.x
Undefined symbols:
"_main", referenced from:
_main$non_lazy_ptr in crt1.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
Never mind, it turns out that I forgot to compile llvm along with it, and I didn't realize that obviously llvm-gcc would need llvm to function correctly.