g++ crashes after consecutive calls - c++

I'm developing a tool that makes several calls to g++ in order to compile and execute different versions of an original C++ program. More or less, this calls are made inside a loop (it's not a real "loop", but the calls are made inside a function that is part of an iterative algorithm).
For short executions of the algorithm, everything goes smoothly and all the g++ calls finish correctly (I get the binaries ready for its execution). However, the longer the algorithm executions are, the more likely the tool is to crash.
This crashes are due to subsequents crashes of g++ calls, that instead of returning the expected compiled binaries, return the following errors:
Compiling test_oclopts_23_14_6_6000.cpp...
g++ -O3 -L/opt/AMDAPP/lib -lOpenCL -I/opt/AMDAPP/include test_oclopts_23_14_6_6000.cpp -o test_oclopts_23_14_6_6000
/usr/bin/ld: cannot find /usr/lib/i386-linux-gnu/libc_nonshared.a
/usr/bin/ld: cannot find /lib/i386-linux-gnu/ld-linux.so.2
collect2: ld returned 1 exit status
I've googled a bit about this error messages, but I don't understand how they can be applied to my problem: the supposedly missing libraries really are well installed in the system (former g++ calls went OK).
Any idea? Moreover, if you know a better way to compile C++ source code inside a C++ program instead of using system(), I'm accepting suggestions, :)
Thank you so much in advance,
Jorge.

Related

Using SFML on MinGW

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.

How to solve C++ conflicts between system and library dependencies

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.

Including expect/tcl library for C/C++

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.

G++ does not compile my source code with -O0 but it does with -O2 -DNDEBUG, how can I solve it?

I am writing a firmware for an ARM microcontroller. I have built the cross-compiler without syscalls, actually my RTOS (ChibiOS) provides a simple syscalls implementation.
All my code is written in C excepting some parts where I only use C++ for linking with Eigen library (a C++ template library for linear algebra, it is only headers).
If I compile my source example code with -O2 -DNDEBUG (as far as I know with NDEBUG the code won't need assert()) everything compiles fine and the firmware works.
If I compile my source example code with -O0 I have the following:
Linking build/ch.elf
/home/noether/workspace/tool-chains/arm-none-eabi-4.6.2/lib/gcc/arm-none-eabi/4.6.2 /../../../../arm-none-eabi/lib/thumb/cortex-m4/libc.a(lib_a-abort.o): In function `abort':
/home/noether/workspace/tool-chains/summon-arm-toolchain/build/arm-none-eabi/thumb /cortex-m4/newlib/libc/stdlib/../../../../../../../gcc-4.6.2/newlib/libc/stdlib /abort.c:63: undefined reference to `_exit'
/home/noether/workspace/tool-chains/arm-none-eabi-4.6.2/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/thumb/cortex-m4/libc.a(lib_a-signalr.o): In function `_kill_r':
/home/noether/workspace/tool-chains/summon-arm-toolchain/build/arm-none-eabi/thumb/cortex-m4/newlib/libc/reent/../../../../../../../gcc-4.6.2/newlib/libc/reent/signalr.c:61: undefined reference to `_kill'
/home/noether/workspace/tool-chains/arm-none-eabi-4.6.2/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/thumb/cortex-m4/libc.a(lib_a-signalr.o): In function `_getpid_r':
/home/noether/workspace/tool-chains/summon-arm-toolchain/build/arm-none-eabi/thumb/cortex-m4/newlib/libc/reent/../../../../../../../gcc-4.6.2/newlib/libc/reent/signalr.c:96: undefined reference to `_getpid'
collect2: ld returned 1 exit status
make: *** [build/ch.elf] Error 1
It does not matter if I put -DNDEBUG, I have the same output.
I am using those flags as well, -fno-exceptions and fno-rtti.
If I do not use/link the Eigen library (the only C++ stuff), g++ compiles the source fine even with -O0.
Actually, I implemented a simple _kill _getpid and _exit functions, and the code compiles, but the code goes from 13KB to 130KB, and It crashes (maybe I haven't written well those functions).
What I want is to remove this stuff from my code (abort, etc) if I use -O0, as it is done (I guess) with -O2.
Thank you very much. Let me know if you need more information.
These references are almost certainly due to using assert(); that will call abort() on failure, which in turn will try to raise a signal (using the kill() syscall in this implementation) to abort the process. Obviously, this isn't possible if you can't make syscalls.
Building with -DNDEBUG (like you do in the optimised version) will fix this; it causes the assert() macro to generate no code, so there will be no references to abort(). The optimisation level itself shouldn't make any difference.
Alternatively, if you want to preserve your assertions, you could implement your own assert() macro that doesn't require any syscalls.
You could simply implement stubs for those missing syscalls and link them to your code. That will keep the linker quiet, but you might make the stubs do something sensible or useful. exit() might disable interrupts and loop indefinitely or force a reset. _kill() might hook into your RTOS to terminate a thread, or simply call _exit(), and _getpid() might return some dummy value or an RTOS thread ID.

Compiling error opencv

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.