I have started learning C++ on Ubuntu. I am only a few months into using Linux as well.
I am attempting to port over a 2D Ball Collision Script from Javascript to C++ for learning purposes.
I am using simple2D for the drawing in C++: https://github.com/simple2d/simple2d
I go to run this command:
simple2d build c-code-test.cpp
I receive this response:
cc1plus: warning: command line option ‘-std=c11’ is valid for C/ObjC but not for C++
/usr/bin/ld: /tmp/ccl07DBG.o: undefined reference to symbol '_ZNSt8ios_base4InitD1Ev##GLIBCXX_3.4'
//usr/lib/x86_64-linux-gnu/libstdc++.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Due to how fresh I am with Linux and C++ I am unable to make the correct inferences to solve this based on previous questions on stack overflow. I have installed libstdc++6 so I would have though it would be linked correctly.
Can someone walk me through in steps 1, 2, 3 ... Please? Thank you kindly!
The errors you see look to be from trying to compile C++ as C. The command line option is selecting the C11 standard, which is for C, not C++. The missing symbol is because the C++ library isn't being linked in, which also happens when linking a program as C.
I haven't used simple2d, but my guess here is that the compile script they wrote does not support C++ or there is some option you need to use C++. If we look at docs:
The simple2d build command is a helpful shortcut for compiling a
single source file. Of course, you can also use a compiler directly,
for example on Unix-like systems:
cc triangle.c `simple2d --libs` -o triangle
Why don't you try something like their example that invokes the compiler directly. But you would need to use g++ instead of cc. Something like: g++ c-code-test.cpp `simple2d --libs` -o c-code-test
This is a bug with the simple2d script.
They're basically using the wrong build command for C++.
You could work around it by patching in the fix I've linked to, or using the manual build step shown by TrentP.
Or wait for the next version after v1.1.0.
Related
I'm running a Makefile given to me to compile some Fortran code along with some C++ code. This is being compiled on CentOS using the intel compiler.I didn't write any of the code or the Makefile, also I have no clue what I'm doing.
When I run the Makefile script I get the following error when trying to do something with Fortran code 'libStuff':
ld: /home/myProject/trunk/libStuff/lib/libStuff.a(stuff.o): undefined reference to symbol 'for_inquire'
/opt/intel2019/compilers_and_libraries_2019.0.117/linux/compiler/lib/intel64_lin/libifcore.so.5: error adding symbols: DSO missing from command line
make[1]: *** [myProject] Error 1
I've played around with the Makefile and I've figured out that I need to add a flag to a specific line
MYFORTRANCODE=-L$(MYFORTRANCODE_LIB) -lSTUFF -lmpi_usempif08 -lmpi_mpifh -l_I_NEED_TO_ADD_SOMETHING_HERE
The problem is I don't know which flag to add, and couldn't find any helpful documentation on the intel website. Also I couldn't figure out what the 'for_inquire' thing means.
Anybody got any ideas?
the flag I needed to add was -lifcore. I figured it out.
My problem is rather specific, but bear with me.
This in the end is kinda reverse engineering, but this problem in particular seems to fit more this board.
So, I have a shared object compiled for MIPS written in C++. I don't have the source code of the lib. The lib is compiled using GCC 4.3.3. I want to use functions present in this shared object in my amd64 computer running elementary OS. To do this, I used the sourcery cross compiler to cross compile some C++ code to MIPS, that would use this object.
So far I managed this except for this one compile error, which I cannot figure out. The lib is called libdvl.so, and uses as dependency libc.so.0 (and both are in the same folder as the cpp code).
mips-linux-gnu-g++ -g -L/path/to/lib -Wl,-rpath,/path/to/lib -o verifier verifier.cpp -ldvl
which gives me
(...)/mgc/embedded/codebench/bin/../lib/gcc/mips-linux-gnu/4.9.1/../../../../mips-linux-gnu/bin/ld: warning: libc.so.0, needed by /path/to/lib/libdvl.so, may conflict with libc.so.6
(...)/mgc/embedded/codebench/bin/../lib/gcc/mips-linux-gnu/4.9.1/../../../../mips-linux-gnu/bin/ld: errno##GLIBC_PRIVATE: TLS definition in (...)/mgc/embedded/codebench/bin/../mips-linux-gnu/libc/lib/libc.so.6 section .tbss mismatches non-TLS definition in /path/to/lib/libc.so.0 section .bss
/path/to/lib/libc.so.0: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
So I added "-l:libc.so.0" and got this
(...)/mgc/embedded/codebench/bin/../lib/gcc/mips-linux-gnu/4.9.1/../../../../mips-linux-gnu/bin/ld: errno: TLS definition in (...)/mgc/embedded/codebench/bin/../mips-linux-gnu/libc/lib/libc.so.6 section .tbss mismatches non-TLS definition in libc.so.0 section .bss
(...)/mgc/embedded/codebench/bin/../mips-linux-gnu/libc/lib/libc.so.6: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Any idea how to solve this? I know I am using GCC 4.9.1, but I already downloaded the older code sourcery version which uses GCC 4.3.154 and got the exact same error.
EDIT 1: Exactly as Lol4t0 said, filtered using c++filt it gives an actual function name from stdc++. Using
mips-linux-gnu-g++ -g -L/path/to/lib -Wl,-rpath,/path/to/lib -I/path/to/lib -o verifier verifier.cpp -ldvl -l:libuClibc++.so.0 -l:libutil.so.0 -l:libc.so.0 -l:ld-uClibc.so.0 -nodefaultlibs
to give to libdvl its depencies (as I will not rewrite stdc++ :p), I get the following compile error:
(...)/mgc/embedded/codebench/bin/../lib/gcc/mips-linux-gnu/4.9.1/../../../../mips-linux-gnu/bin/ld: /tmp/cc66DLda.o: undefined reference to symbol '_Unwind_Resume##GCC_3.0'
(...)/mgc/embedded/codebench/bin/../mips-linux-gnu/libc/lib/libgcc_s.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
I already confirmed lib dependencies and the order in which they appear.
Any thoughts on this?
Thanks for all the help.
Using -nodefaultlibs solves the first problem though.
You are linking against GLIBC (libc.so.6) and some other libc (libc.so.0).
That could never work: you have to have everything compiled and linked against a single, consistent libc.
Since your libdvl.so uses as dependency libc.so.0, and assuming you can't rebuild libdvl.so, you have to use crosscompiler that targets libc.so.0 (which is possibly dietlibc, or uClibc), and compile and link everything else using that toolchain. Your crosscompiler on the other hand appears to target GLIBC, and will not do you any good.
After a lot of trial and error, you may be able to link the final binary using inconsistent builds, and your binary may even get to main (that is very unlikely). But chances of such binary actually working correctly are minuscule.
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 was using flex and bison to build a simple calculator project I cloned from Github.
But after I typed make in terminal, I got the following message:
gcc -o calc calc.tab.c lex.yy.c -lfl
calc.y:48:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
main() {
^~~~
1 warning generated.
ld: library not found for -lfl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [calc] Error 1
How could I resolve this problem?
let me guess, trying to use flex on OS/X?
Try -ll instead of -lfl
Using Flex on OS/X
So yea, the flex library name on OS/X is just arbitrarily different for some reason. OS/X is not exactly Linux, but it's pretty close. You have some options here.
You can just simply have a separate build system and source files for OS/X. Certainly Apple might like that with their pushing XCode, objective-C and not much interoperability.
You can build vs Linux and then engage with Mac Ports and Homebrew.
You can create your project using autotools. That's not an awesome link, learning this system is rough going, but it's a standard thing for Linux for sure. This will actually work, I find if you have the patience for it, OS/X is close enough that autotools based builds will work on it.
Lately, I've been turned on to Cocoapods, which I believe to be an attempt to join the open source community and XCode. It's kind of half 1 and 3 sorta with an emphasis on modularizing the external source and getting it compiled into a .app (via Xcode).
warning: type specifier missing, defaults to 'int'
mean that you should declare return type for main function. Place int in function difinition.
ld: library not found for -lfl
flag -l mean that compiller must use libfl.a to build programm. As #waTeim said above, for Mac OS you can use libl.a instead, but this lib can be not exist alse. There is another way is to place
%option noyywrap
at the top of flex *.l file. In this case you can compile without additional libs.
I'm working on opencv implemented codes which I downloaded already by svn. These codes such as SIFT or SURF and codes for opencv were working perfectly before, but suddenly I got this error while I want to compile any code concerns opencv
/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status
So how can I solve it please, I have red already some problems but they were not helpful with my case, such as I have to change the compilation code from g++ SIFT.cpp -o SIFT .... to g++ -o SIFT SIFT.cpp .... but it didn't work out with me.
Thank you.
I know this is old, but I just had a similar problem (with OpenCV 2.4.4a (and also 2.4.1)) and this was the first thing that popped up on google.
I disabled the "precompiled headers" option in the OpenCV configuration (do it from cmake-gui, or pass -DENABLE_PRECOMPILED_HEADERS=OFF to cmake when generating), and everything works fine.
main is the starting point of execution of any C++ program. And you probably have forgot to build the source file that has main function. Since the file you built doesn't has main, linker failed to find the starting point of execution.
g++ SIFT.cpp fileThatHasMainFunctionDefinition.cpp -o SIFT
or alternatively provide the main in SIFT.cpp itself.