I have cross platform solution wich is succesfully built for Windows, Linux but during the build at Mac OS X. I have such issue:
Undefined symbols for architecture x86_64:
"qx::syb::DataType<boost::shared_ptr<qx::DistributedObject>, void>::DataType()", referenced from:
qx::syb::AbsDynInfo const& qx::syb::dynInfo<boost::shared_ptr<qx::DistributedObject> >()in ThemeKit.cpp.o
qx::syb::AbsDynInfo const& qx::syb::dynInfo<boost::shared_ptr<qx::DistributedObject> >()in libguiserver.a(MemUtils.cpp.o)
"qx::syb::DataType<boost::shared_ptr<qx::aum::Color>, void>::DataType()", referenced from:
qx::syb::AbsDynInfo const& qx::syb::dynInfo<boost::shared_ptr<qx::aum::Color> >()in ThemeKit.cpp.o
"qx::syb::DataType<boost::shared_ptr<qx::ffm::Field>, void>::DataType()", referenced from:
qx::syb::AbsDynInfo const& qx::syb::dynInfo<boost::shared_ptr<qx::ffm::Field> >()in libguiserver.a(FormConverter.cpp.o)
"qx::syb::DataType<boost::shared_ptr<qx::lfm::EventType>, void>::DataType()", referenced from:
qx::syb::AbsDynInfo const& qx::syb::dynInfo<boost::shared_ptr<qx::lfm::EventType> >()in libguiserver.a(FormConverter.cpp.o)
"qx::syb::DataType<boost::shared_ptr<qx::lfm::ParsedExpression>, void>::DataType()", referenced from:
qx::syb::AbsDynInfo const& qx::syb::dynInfo<boost::shared_ptr<qx::lfm::ParsedExpression> >()in libguiserver.a(FormConverter.cpp.o)
ld: symbol(s) not found for architecture x86_64
I've checked the linker line and it contains object files which contains definition of such symbols.
For example:
bash-3.2$ nm -arch x86_64 -U instance*.o | c++filt | grep -i "qx::syb::DataType<boost::shared_ptr<qx::DistributedObject>, void>::DataType()"
00000000001e6e68 S qx::syb::DataType<boost::shared_ptr<qx::DistributedObject>, void>::DataType()
0000000000092e48 S qx::syb::DataType<boost::shared_ptr<qx::DistributedObject>, void>::DataType()
000000000009b170 S qx::syb::DataType<boost::shared_ptr<qx::DistributedObject>, void>::DataType()
It defined several times but another one "qx::syb::DataType<boost::shared_ptr<qx::aum::Color>, void>::DataType()" is defined only once and also missed. So this shouldn't be an issue.
I have latest possible environment
Mac OS X version:Darwin mac.qx 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
IDE: XCode:4.2
Compiler:gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
The issue was connected with compiler optimization. Usage limited optimization like -O1 is possible but more advanced -O2 or -O3 generates such error.
Related
I installed testu01 on my mac (OS El Capitan). I want to compile one of the examples using gcc, code below. But I get the following error, below. Did anybody run TestU01 on x86_64 successfully? Any other suggestions?
MacBook-Pro-2:examples Joan$ gcc -std=c99 -Wall -O3 -o birth1 birth1.c -I/Users/TestU01/TestU01-1.2.3/include -I/Users/TestU01/TestU01-1.2.3/mylib
Undefined symbols for architecture x86_64:
"_smarsa_BirthdaySpacings", referenced from:
_main in birth1-c99705.o
"_ulcg_CreateLCG", referenced from:
_main in birth1-c99705.o
"_ulcg_DeleteGen", referenced from:
_main in birth1-c99705.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 am trying to use the hdf5-format to store data. Problem is, that I fail to link against the library. I have the following code
#include <H5Cpp.h>
int main(void){
H5::H5File file("test_MatrixRoundTrip_Double.h5", H5F_ACC_TRUNC);
}
and compile it using
gcc -std=c++11 -o main main.cpp -I /usr/local/include/ -L /usr/local/lib/ -lhdf5 -lhdf5_hl
This always returns the error
Undefined symbols for architecture x86_64:
"H5::FileAccPropList::DEFAULT", referenced from:
_main in main-c207d1.o
"H5::FileCreatPropList::DEFAULT", referenced from:
_main in main-c207d1.o
"H5::H5File::H5File(char const*, unsigned int, H5::FileCreatPropList const&, H5::FileAccPropList const&)", referenced from:
_main in main-c207d1.o
"H5::H5File::~H5File()", referenced from:
_main in main-c207d1.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 installed the hdf5 library on OSX using
brew install homebrew/science/hdf5
What am I doing wrong here?
You are including the HDF5 C++ header file, but only linking the HDF5 C library. Add the line: -lhdf5_cpp to link the C++ shared object and use locate libhdf5_cpp to find it's libpath.
I am trying to use the code Nauty and Traces http://pallini.di.uniroma1.it/. But when I complied an example, say nautyex8.c (provided by the package), the following error showed up:
Undefined symbols for architecture x86_64:
"_alloc_error", referenced from:
_main in nautyex8-54d9da.o
"_densenauty", referenced from:
_main in nautyex8-54d9da.o
"_dispatch_graph", referenced from:
_main.options in nautyex8-54d9da.o
"_nauty_check", referenced from:
_main in nautyex8-54d9da.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 am using Mac OS X Yosemite (10.10.5) and Xcode (version 7.1). I believe that there is no error in the codes because they are widely used so I guess the problem comes from my system settings.
Thank you so much!
I've just opened a pull request to make brew install nauty work on OS X: https://github.com/Homebrew/homebrew-core/pull/48701
Until then, here's how you would build nautyex8.c on OS X, as of Nauty/Traces 2.6r12.
Step 1 is to download the code and build the library:
wget http://pallini.di.uniroma1.it/nauty26r12.tar.gz
tar zxvf nauty26r12.tar.gz
cd nauty26r12
./configure
make
ls -l nauty.a
Step 2 is to compile nautyex8.c and link it against the library you just built:
gcc -O3 nautyex8.c nauty.a
./a.out
You probably forgot to put that "nauty.a" at the end of your compiler command line. If I do that too, I get:
gcc -O3 nautyex8.c
Undefined symbols for architecture x86_64:
"_alloc_error", referenced from:
_main in nautyex8-05f086.o
"_densenauty", referenced from:
_main in nautyex8-05f086.o
"_dispatch_graph", referenced from:
_main.options in nautyex8-05f086.o
"_nauty_check", referenced from:
_main in nautyex8-05f086.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
which exactly matches the symptom you described.
The upcoming release of Go 1.5 comes with new buildmodes which allow for exporting Go symbols to be linked and called from C code. I've been playing around with it and got basic "Hello world" examples working, but now I'm trying to link a Go library which starts a net/http.Server and it's failing. The code looks like this (it's also available here):
gohttplib.go:
package main
import "C"
import "net/http"
//export ListenAndServe
func ListenAndServe(caddr *C.char) {
addr := C.GoString(caddr)
http.ListenAndServe(addr, nil)
}
func main() {}
examples/c/main.c:
#include <stdio.h>
#include "../../gohttplib.h"
int main()
{
ListenAndServe(":8000");
return 0;
}
Producing the statically-linked object and headers works fine:
$ go build -buildmode=c-archive
But compiling against it is failing:
$ gcc -o gohttp-c examples/c/main.c gohttplib.a -lpthread
Undefined symbols for architecture x86_64:
"_CFArrayGetCount", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
"_CFArrayGetValueAtIndex", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
"_CFDataAppendBytes", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
"_CFDataCreateMutable", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
"_CFDataGetBytePtr", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
__cgo_6dbb806e9976_Cfunc_CFDataGetBytePtr in gohttplib.a(000003.o)
(maybe you meant: __cgo_6dbb806e9976_Cfunc_CFDataGetBytePtr)
"_CFDataGetLength", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
__cgo_6dbb806e9976_Cfunc_CFDataGetLength in gohttplib.a(000003.o)
(maybe you meant: __cgo_6dbb806e9976_Cfunc_CFDataGetLength)
"_CFRelease", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
__cgo_6dbb806e9976_Cfunc_CFRelease in gohttplib.a(000003.o)
(maybe you meant: __cgo_6dbb806e9976_Cfunc_CFRelease)
"_SecKeychainItemExport", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
"_SecTrustCopyAnchorCertificates", referenced from:
_FetchPEMRoots in gohttplib.a(000003.o)
"_kCFAllocatorDefault", referenced from:
_FetchPEMRoots in gohttplib.a(000003.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: *** [example-c] Error 1
This is using a recent version from the Go github repository (38e3427) on OS X 10.9.5. I understand that Go 1.5 is not released yet and that there are no guarantees about it working, but I'm doing this for educational purposes and I suspect I'm missing something.
Related versions:
$ ld -v
#(#)PROGRAM:ld PROJECT:ld64-241.9
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7m armv7em
LTO support using: LLVM version 3.5svn
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
Turns out this problem exists on OSX/darwin. To work around it, we need to add -framework CoreFoundation -framework Security options to the gcc linking command. The final command looks like this:
$ gcc -o gohttp-c examples/c/main.c gohttplib.a \
-framework CoreFoundation -framework Security -lpthread
This requirement might be removed in a future version of Go. More discussion on this issue here: https://github.com/golang/go/issues/11258
Yet another symbol(s) not found issue with Mac OS X. I wrote a C program that uses the libev event loop library that when compiled produces this output:
$ make
clang midnight.c midnight_logging.c -o midnight
Undefined symbols for architecture x86_64:
"_ev_default_loop", referenced from:
_main in midnight-Wlcawk.o
"_ev_io_start", referenced from:
_main in midnight-Wlcawk.o
"_ev_run", referenced from:
_main in midnight-Wlcawk.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: *** [midnight] Error 1
I used homebrew to install libev. The shared library is in /usr/local/lib per normal and I've used every combination of compiler arguments including "-I /usr/local/lib", "-l libev" and "-L /usr/local/lib".
Assistance appreciated, I'd rather not have to statically compile.
But you do not link against libev! The compiler isn't a clairvoyant (nor is the linker), you have to tell it what to search for those symbols...
clang midnight.c midnight_logging.c -o midnight -lev