I'm trying to build headless blackcoin from source on Windows 8 with mingw 6.3
and I got the following error: .../src/leveldb/libleveldb.a(env_win.o):env_win.cc:(.text+0xaff): undefined reference to '_imp__PathFileExistsW#4'
This function is mentioned here https://msdn.microsoft.com/en-us/library/windows/desktop/bb773584(v=vs.85).aspx
I would appreciate if someone can help me.
P.S. I linked the appropriate library.
Finally I was able to build it. Probably it is obvious for thoose guys who down voted the question. I simply answer since it might save time to somebody.
I relied on the Makefile which is a part of the project source code. Required library (shlwapi) present in the file so I was confused when it failed to build. Everything went well when I placed the library at the end of the linked files.
It was something like this
g++ ... -o -lshlwapi... /src/leveldb/libleveldb.a /src/leveldb/libmemenv.a
And became this
g++ ... -o /src/leveldb/libleveldb.a /src/leveldb/libmemenv.a -lshlwapi
Related
I've been working on a Gameboy emulator, and everything's looking great, I've already implemented the core, flag updates, cycle accurate interrupts, etc. I thought it was time to see something.
I chose SFML for the graphics, and, so far I was able to compile the example program. But, when I tried to compile my emulator, it seems that the actual C++ standard library was unlinked, as the log reports undefined references from STD methods, such as:
agb\main.o:main.cc:(.text+0x91): undefined reference to `__ZSt4cout'
agb\main.o:main.cc:(.text+0x120): undefined reference to `__ZNSt8ios_base4InitD1Ev'
agb\main.o:main.cc:(.text+0x141): undefined reference to `__ZNSt8ios_base4InitC1Ev'
and, this particularly interesting one:
C:/Users/Astherix/Desktop/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o):crt0_c.c:(.text.startup+0x2e): undefined reference to `WinMain'
Anyone has a clue as to why this is happening?
I use a custom BAT to compile, this is the source:
#echo off
set name=%1
echo Started building project '%name%' through gcc.
echo Creating object file '%name%.o'...
g++ -c %name%.cc -IC:\Users\Astherix\Desktop\mingw64\sfml\include
echo Compiling executable '%name%.exe'...
g++ %name%.o -o %name%.exe -LC:\Users\Astherix\Desktop\mingw64\sfml\lib -lsfml-graphics -lsfml-window -lsfml-system
Thanks in advance.
If the source code is within a folder, you might want to move it to the same folder g++, c++ or whatever compiler you're using is in. Or just make a copy-move script of sorts.
Recently I found an example of how to use the expect library in C++. I tried to compile it, but the compiler (g++) said, that tcl8.5/expect.h doesn't exists. So I tried to include tcl8.6/expect.h - still the same error. I checked the /usr/include/ directory and I wasn't surprised when I've noticed, that there is no tcl8.x directory.
I've searched for files with "expect" in their name. Here's what I found:
/usr/include/expect_tcl.h
/usr/include/expect_comm.h
/usr/include/expect.h
Unfortunately when I tried to include any of these I got the following list of errors during compilation:
> g++ test.cpp -Wall -std=c++0x -ltcl8.6 -lglog -o test
/tmp/cce8k1BA.o: In function `task(std::string const&, std::string const&, std::string const&)':
test.cpp:(.text+0x16): undefined reference to `exp_is_debugging'
test.cpp:(.text+0x20): undefined reference to `exp_timeout'
test.cpp:(.text+0x38): undefined reference to `exp_popen'
etc...
How can I solve this problem?
[EDIT]
When I tried to link it with the expect lib (-lexpect) I got the following error:
/usr/bin/ld: cannot find -lexpect
collect2: error: ld returned 1 exit status
I'm sure that both - tcl8.6 and expect 5.45-4 are installed.
The usual way of distributing Expect these days puts the shared library in a non-standard location and loads it dynamically by full pathname. This works well and is minimal fuss for most people, but does make it rather hard to use Expect's C interface in your own code.
The easiest way is going to be to build your own copy from source, especially as that will give you control over how exactly it was built. This can particularly include keeping the majority of symbols in the library instead of stripping them on install, which will help a lot with debugging. You probably ought to use the current supported version. (Yes, it's a release from several years ago. It doesn't need a lot of support effort most of the time.)
You haven't linked to the expect library during your build. Add -lexpect to your g++ command.
I've been having some difficulty compiling a piece of C++ code for the physics engine Bullet Physics, and was hoping to get some advice.
This is my first time using gcc as a compiler, and including directories for compiling in general, so I'm going to give my whole process of problem-solving because I'm not sure where I went wrong or what the pertinent information is.
When I first tried to compile the code I got a fatal error about "No such error or directory", so I decided to add the directory with the -I option (1). It fixed the first error, but another popped up. Again, I was able to make the error go away with a -I option to the directory needed(2).
Then I got a whole long list of errors like the following:
main.cpp:(.text+0x33): undefined reference to 'RagdollDemo::initPhysics()'
main.cpp:(.text+0x84): undefined reference to 'glutmain(int, char**, int, int, char const*, DemoApplication*)'
/tmp/cc4MqhHm.o: In function '__static_initialization_and_destruction_0(int, int)':
main.cpp:(.text+0xe7): undefined reference to `std::ios_base::Init::Init()'
I tried a few different things, but the solution ended up using my home bullet folder (or usr/local/include/bullet/) with the --sysroot option (3).
This created a lot of errors for the C++ header files, and then I linked to a few more directories with -I (4-5), but at after one of the added directories the same set of errors that I thought I solved with the --sysroot addition popped up again (6).
I can't tell what to do now. I would guess that declaring the bullet folder as my root makes it impossible for the compiler to find the required C++ files in my actual root directories, but I don't what to do about that... and when I tried including the C++ files I needed, the compiler seemingly forgot I told it to use bullet as my root.
Final compilation I tried before I gave up and realized asking for help might be better than spending 3 hours looking at documentation without any idea of what the exact problem is. Numbers correspond to the steps above.
gcc
(3)--sysroot=/home/josh/bullet-2.82-r2704/
(1)-isystem/home/josh/bullet-2.82-r2704/Demos/OpenGL/
(2)-isystem/home/josh/bullet-2.82-r2704/src/
(4)-I/usr/include/
(5)-I/usr/include/c++/4.8
(6)-I/usr/include/x86_64-linux-gnu/c++/4.8/
./main.cpp
I'm using Ubuntu 14.04 LTS and my OS and emacs 24.3.1 as my IDE.
Any help would be greatly appreciated.
Best,
Josh
What you are seeing is not include issue. Linker is failing to link with symbols. You need to link with proper library, for example lglut
I'm trying to build a simple unit test executable, using cpputest. I've built the cpputest framework into a static library, and am now trying to link that into an executable. However, I'm tied into a fairly complicated Makefile setup, because of the related code.
This is my command line:
/usr/bin/qcc -V4.2.4,gcc_ntoarmle_acpp-ne -lang-c++ -O2 -g -g -o Application/UnitTests/Tests/symbols/UnitTestExe -Wl,--start-group Application/UnitTests/Tests/../.objs/main.o Application/UnitTests/lib/libcpputest.a -Wl,--end-group -lm
I'm getting many errors like the following:
Application/UnitTests/lib/libcpputest.a(CommandLineTestRunner.o): In function `CommandLineTestRunner::parseArguments(TestPlugin*)':
Application/UnitTests/cpputest/src/CppUTest/.objs/../CommandLineTestRunner.cpp:114: undefined reference to `operator new(unsigned int, char const*, int)'
I can't figure out what's causing this. Don't I get operator new for free with C++?
You probably need to link with the C++ support runtime library. This happens automatically when you invoke g++. On Linux, this is achieved by adding the -lstdc++ flag to the linker. You have to figure out how to do the same on your platform.
Maybe you're calling gcc, the C compiler instead of g++, which is the C++ compiler.
There's very little information in your question to work from, but it looks like some code uses some form of placement new, and while that special operator new is declared (the compiler finds it and compiles the code using it), the linker can't find its definition.
(Since this old answer of mine seems to still get attention: See here for an extensive discussion on declaration vs. definition.)
You need to rebuild your code from scratch, including the library. I got this error because I inadvertently copied object files compiled on another machine (with the rest of the source) to my machine. Most likely this disturbs the linking step since there are now two types of object files, native (for modified source files) and non-native (all others). I am guessing here, but the operator 'new' means slightly different things on different architectures and that's why you are getting this error.
p.s. I know this is way too late for a useful answer but I'm still posting this for the record.
For QNX 6.5.0 I have specified flag -lang-c++ for qcc (gcc) to avoid the error.
Like the original post, in my case this error happened while trying to link a software using CppUTest framework.
In my case, the source of the problem seems to be related to the fact I disabled the MEMORY_LEAK_DETECTION compile option of CppUTest. I enabled it again, which solved the problem.
Sometimes adding -lstdc++ is not enough. You should add it to the right place. For example I had list like this, not working:
target_link_libraries(cfr2 pthread m stdc++ "${CMAKE_SOURCE_DIR}/compressor/libcompressor.a" )
But this one works fine:
target_link_libraries(cfr2 pthread m "${CMAKE_SOURCE_DIR}/compressor/libcompressor.a" stdc++)
It'd be great if someone explained it in the comment section.
I have been trying to build the logstalgia project (http://code.google.com/p/logstalgia/) on my Mac (10.5). Rather than having to link it to the system libraries correctly, I have built and added all of the dependencies to the project. I am new at this, but I do think I have done this correctly, mostly because I have had two of my friends who are much more experienced say so.
Adding the frameworks removed all of the compile errors, but I still get a linker error. It seems to not be able to find the main() function. I have verified I included main.cpp in the sources to be compiled (using XCode) and that there are no accidental double declarations. I have also verified that the main function is correctly declared (no missing brackets, etc).
It is as though XCode does not link in the correct order. Any help would be really appreciated, I am really excited to be down to a single error! (Hope fixing this does not open a floodgate).
Thanks,
Hamilton
PS - I can definitely provide a zip of the Xcode project if anyone is willing to look!
Checking Dependencies
Ld "/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled/build/Debug/Untitled" normal i386
cd "/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled"
setenv MACOSX_DEPLOYMENT_TARGET 10.5
/developer/usr/bin/g++-4.0 -arch i386 -isysroot /developer/SDKs/MacOSX10.5.sdk "-L/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled/build/Debug" -L/sw/lib "-L/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled/../../pcre-7.9/.libs" -L/opt/local/lib -L/sw/lib "-F/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled/build/Debug" -F/Users/hamiltont/Downloads/logstalgia-0.9.2 -F2/src/SDL.framework "-F/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled" -filelist "/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled/build/Untitled.build/Debug/Untitled.build/Objects-normal/i386/Untitled.LinkFileList" -mmacosx-version-min=10.5 -framework OpenGL -lpcre -lSDL -lSDL_image-1.2.0 -prebind -o "/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled/build/Debug/Untitled"
Undefined symbols:
"_main", referenced from:
start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
I got this error to go away. If I understand, essentially SDL re-names the main function, so that it can do some stuff, then run your application, then clean up. Turns out that if you are building in Xcode, you must use ObjectiveC to compile your application.
In Xcode, telling the linker to try and use SDL_main(), rather than just main() does not work (for some technical reasons that are a bit beyond me). So, you include a few Objective C files. In Oc, you get the benefit of being able to say explicitely what the name of your main class is. Hence, the Objective C files you include seem to do nothing more than let Xcode know to look for SDL_main().
In summary, this really had nothing to do with Logstalgia, but was entirely a problem with getting SDL to link correctly in Xcode. This link is talking about this problem exactly. The SDLMain.h and SDLMain.m are Objective C files. If you can't find them, try googleing "Setting up SDL templates in Xcode." I installed the templates in Xcode, used one of them to create an empty project that would compile, link, and run (and promptly do nothing!) and then I added the project files I wanted to the pre-configured project.
Thanks!
Double-check the link file list to make sure main.cpp's object file is present there:
/Users/hamiltont/Downloads/logstalgia-0.9.2 2/Untitled/build/Untitled.build/Debug/Untitled.build/Objects-normal/i386/Untitled.LinkFileList
You might also want to preprocess the main.cpp to make sure main isn't getting inadvertently renamed (via a rogue macro) or omitted (via a rogue #if).