I'm using libUV in my project and I'm getting the following error when I'm linking...
In function `uv__signal_global_init': ... undefined reference to `pthread_atfork'
The strange thing is, my project only fails to link on certain flavors of Linux, but works on MacOS and Windows.
Any idea how to resolve this error?
After scouring the internet, I found the solution in an obscure post from Ben Noordhuis in a Google group post.
#tl;dr
Link with -luv -ldl -lrt -pthread (in that order or it'll break when
-W,--as-needed is in effect.)
Related
I'm trying to build a C++ program that incorporates Cepstral's voice synthesis features. The library was already downloaded on the machine by my predecessor but apparently he never got around to using it. The documentation is pretty much non-existent (there is a single forum that doesn't really have anything helpful). All of their included examples are in C and lack a MakeFile so I'm trying to compile them myself. The little documentation there is simply tells me I need to link to the libswift.so library.
It is a Ubuntu 12.04.5 OS and I tried this compile command
g++ -Wall -g tts.c -o tts -I/opt/swift/include -L/opt/swift/lib -lswift -lm
Which gives this error
/opt/swift/lib/libswift.so: undefined reference to 'sin'
/opt/swift/lib/libswift.so: undefined reference to 'exp'
/opt/swift/lib/libswift.so: undefined reference to 'cos'
/opt/swift/lib/libswift.so: undefined reference to 'log'
/opt/swift/lib/libswift.so: undefined reference to 'pow'
collect2: ld returned 1 exit status
This seems to indicate that -lm is not properly linking for some reason (I also tried switching the order of m and swift for the same result).
I usually use C++ and have very little C experience. I also frequently use Makefiles or edit previous/provided Makefiles and rarely call g++ itself so it's possible I'm missing something fairly obvious. Thanks.
Gurus!
I am using Ubuntu 13.10 64-bit to compile latest Google RE2 library, but 'make testinstall' failed to compile, here is the log:
kevin#ubuntu:~/re2$ make testinstall
cp testinstall.cc obj
(cd obj && g++ -I/usr/local/include -L/usr/local/lib testinstall.cc -lre2 -pthread -o testinstall)
/tmp/ccSsaSXS.o: In function main':
testinstall.cc:(.text+0xce): undefined reference tore2::FilteredRE2::FirstMatch(re2::StringPiece const&, std::vector > const&) const'
/usr/local/lib/libre2.so: undefined reference to pthread_rwlock_rdlock'
/usr/local/lib/libre2.so: undefined reference topthread_rwlock_wrlock'
/usr/local/lib/libre2.so: undefined reference to pthread_rwlock_destroy'
/usr/local/lib/libre2.so: undefined reference topthread_rwlock_init'
/usr/local/lib/libre2.so: undefined reference to `pthread_rwlock_unlock'
collect2: error: ld returned 1 exit status
make: * [testinstall] Error 1
I tried to replace -pthread with -lpthread, still failed, then I dumped libre2.so and found that pthread_xxx is in it.
Here is the issue tracking in RE2 forum: https://code.google.com/p/re2/issues/detail?id=100
Anyone here have ever complied RE2 successfully ? Thank you!
See this comment:
Adding -pthread to LDFLAGS seems to fix make test (all tests are
passing), but not make testinstall.
That will get you to the next error
Depending on what you build it for 'make testinstall' might not be necessary.
I just needed to get python re2 port working, and this can be installed after running make install.
I encounter this problem before. Modify the makefile and use -lpthread instead of -pthread.
So I tried looking for the lines in testinstall.cc that were causing the symbol errors and I found out that the only line was on line 18:
18 - f.firstMatch(:abbccc:, ids);
I commented this line out (so that the FullMatch function below is still called) and just ran g++ testinstall.cc -lre2 -pthread -o testinstall (basically what the Makefile does) and I was able to get a binary successfully. Although this might not really solve the problem, its good to know that we can still use the RE2::Fullmatch and partial match functions
If I were to guess, maybe there is a dependency somewhere inside the filtered_re2 module?
I had the same problem. But if you compile with -static everything goes well.
nm -C shows that the "missing" symbol exists in both .a and .so files.
I am trying to follow the basic "hello world" example for Google's V8 as found here. I'm on Ubuntu 13.10, gcc version 4.8.1; this should be straighforward, no?
After building v8 itself and creating the hello world .cpp file,
I run (exactly** as Google suggests)
** Update: Okay, per my comments on the accepted answer below, I unwittingly wasn't running it exactly as Google suggests, because I thought the braces in the file name were an instruction to the reader to choose one option, not a
syntax that g++ would understand. Nontheless, it still doesn't work except with the additions suggested in the answer below
g++ -Iinclude helloworld.cpp -o hello_world out/x64.debug/obj.target/tools/gyp/libv8_base.x64.a -lpthread
And get bombarded with compile errors. There are too many to print here, but nearly all the errors are of the form:
undefined reference to 'icu_46 ...'
for example (some sample lines)
/home/ray/Playground/v8/out/../src/i18n.cc:138: undefined reference to `icu_46::UnicodeString::~UnicodeString()'
/home/ray/Playground/v8/out/../src/i18n.cc:125: undefined reference to `icu_46::UnicodeString::~UnicodeString()'
/home/ray/Playground/v8/out/../src/i18n.cc:147: undefined reference to `icu_46::UnicodeString::~UnicodeString()'
After much Googling I can figure out this has something to do with something called ICU (see http://userguide.icu-project.org/howtouseicu) but why I'm getting the error, and what I can do about it, I don't know.
While the majority of errors are icu_46 related, there are some like this as well, from the 'bootstrapper.o':
/home/ray/Playground/v8/out/x64.debug/obj.target/v8_base.x64/src/bootstrapper.o: In function `v8::internal::Bootstrapper::NativesSourceLookup(int)':
/home/ray/Playground/v8/out/../src/bootstrapper.cc:77: undefined reference to `v8::internal::NativesCollection<(v8::internal::NativeType)0>::GetBuiltinsCount()'
/home/ray/Playground/v8/out/../src/bootstrapper.cc:81: undefined reference to `v8::internal::NativesCollection<(v8::internal::NativeType)0>::GetRawScriptSource(int)'
/home/ray/Playground/v8/out/x64.debug/obj.target/v8_base.x64/src/bootstrapper.o: In function `v8::internal::Genesis::CompileBuiltin(v8::internal::Isolate*, int)':
/home/ray/Playground/v8/out/../src/bootstrapper.cc:1448: undefined reference to `v8::internal::NativesCollection<(v8::internal::NativeType)0>::GetScriptName(int)'
I'm Googled endlessly on this and have found signs that other people have run into the issue but no solutions. Any help will be hugely appreciated. Thank you.
I had the same problem on Ubuntu 12.04, g++ 4.6.3 and v8 3.22.18.
To compile hello_world.cc successfully it is necessary to add icu .a libraries and link to rt library too. As you have built v8 with make x64.debug your completed command should be:
g++ -Wall -Iinclude -o hello_world hello_world.cc ./out/x64.debug/obj.target/tools/gyp/libv8_{base.x64,snapshot}.a ./out/x64.debug/obj.target/third_party/icu/libicu{i18n,uc,data}.a -lrt
I'm getting really frustrated now with trying to link this glew Library
Here's the build log:
g++ -o test.exe "src\\test.o" -lglew32 -lglfw -lglu32 -lopengl32
src\test.o: In function `main':
C:\dev\test\Debug/../src/test.cpp:31: undefined reference to `_imp__glewInit#0'
C:\dev\test\Debug/../src/test.cpp:41: undefined reference to `_imp____glewGenVertexArrays'
C:\dev\test\Debug/../src/test.cpp:42: undefined reference to `_imp____glewBindVertexArray'
I've tried moving around which libraries go first in the build command.
This seems to be an issue that others on the internet are having but i cant seem to find any of them that have fixed it
Ok I know it's a bit wierd be answering my own question but here was the issue:
Apparently the errors were occuring in two areas
For a starter, i didn't need glu32 only opengl32 as i beleive glew handled this itself
Secondly, for some wierd reason i had to call
#define GLEW_STATIC
manually before I imported
I am using MinGW compiler on Windows to compile my C++ application with sockets. My command for linking looks like:
g++.exe -Wall -Wno-long-long -pedantic -lwsock32 -o dist/Windows/piskvorky { there are a lot of object files }
and I have also tried
g++.exe -Wall -Wno-long-long -pedantic -lws2_32 -o dist/Windows/piskvorky { there are a lot of object files }
but in both case I get this error:
build/Windows/MinGW-Windows/src/utils/tcpunit.o:tcpunit.cpp:(.text+0x33): undefined reference to `closesocket#4'
build/Windows/MinGW-Windows/src/utils/tcpunit.o:tcpunit.cpp:(.text+0xd0): undefined reference to `send#16'
build/Windows/MinGW-Windows/src/utils/tcpunit.o:tcpunit.cpp:(.text+0x1ee): undefined reference to `recv#16'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x184): undefined reference to `WSAStartup#8'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x1a5): undefined reference to `closesocket#4'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x1cb): undefined reference to `closesocket#4'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x1d3): undefined reference to `WSACleanup#0'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x6fe): undefined reference to `bind#12'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x724): undefined reference to `listen#8'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x7f0): undefined reference to `gethostbyaddr#12'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x83c): undefined reference to `socket#12'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x86f): undefined reference to `htons#4'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x8b5): undefined reference to `connect#12'
build/Windows/MinGW-Windows/src/utils/tcpdevice.o:tcpdevice.cpp:(.text+0x9c6): undefined reference to `accept#12'
Do you have any ideas where the problem can be, please?
Put the -lws2_32 AFTER the list of object files - GCC searches libraries and object files in the order they appear on the command line.
Just to help the other viewers out there:
gcc hello.c -o hello.o -lws2_32
With MinGW on eclipse:
Menu >> Project >> Properties >> C/C++ Build >> Settings: Register "Tool Settings" - MinGW C Linker - Miscellaneous: Lower Part "other objects"
Add: "D:\Programmierung\mingw\lib\libwsock32.a" for example. No other entries for libwsock32.a on any other properties required, especially not in Library-entries. Also no flags relating to this Lib.
In:
Menu - Project - Properties - c/c++Build - Settings: Register "Tool Settings" - MinGW C++ Linker - Miscellaneous: Lower Part "other objects"
Add: libwsock32.a from bin folder of MinGW.
Greetings I just went through the problem above....
So here are some observations first off....
I know you are refering to MinGw, but you may need cygwin to get around this, I don't know mingw that well, I know cygwin better. But I know that they are cousins of each other.
Cygwin comes with the precompiled boost libraries, but who knows of which version they are. I'm sure it's possible to check, but who has time to do that right? I do not link against cygwin boost libraries, or the mingw boost libraries, I built boost from scratch using gcc on windows (cygwin). The compile did fine.
At the time of this writing boost is on version 1.47.0 I beleive.
Already that fact that cygwin uses version (x?) and boost is 1.47.0 could be a major issue. Make you know what you are using in the way of boost.
I was using code developed on boost 1.42, and had related linker errors. The code compiled, headers were found, etc..etc... but then I got the undefined reference to WSA etc...etc...opensocket this, close socket that, etc....
So, apparantly boost, in order to do network sockets, requires a platform library, in which was found in the form of ws2_32 for windows, and socket for linux for sure.
So if you are properly using boost, and including the correct boost system libraries, you may also need an OS specific library to access some resources (networking in this case).
Linker errors dissappear after that. It's probably obvious to boost veterans what's going on here, but I was unable to find a clear answer via google.