gcc -L/root/Desktop - Wall -o prog3.c -pthread -lcopy
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.0: In function '_start': (.text+0x20): undefined reference to 'main'
collect2: error: ld returned 1 exit status
This is my error code. prog3.c is nowhere to be found, what on earth happened is there any way to get my file back?? The bold is the command I ran and the rest is the resultant console output
Your problem is here: -o prog3.c. gcc’s -o option is used to tell gcc which name it should give to the executable it generates. So here, you’re basically asking your compiler to replace your prog3.c source file by an executable. Sadly your code is gone...
Little addendum of your options in such scenario:
It was Git (or any other version control) repository. In such case, you can simply bring it from previous commit
Your editor/IDE has some back-up system. Sometimes I need to bring back a file I've thought was needless. For such case, my favourite text editor should have create already back-up file in appropriate location (e.g. $XDG_DATA_HOME/vim/backup in my case).
If none of above, but you still have previously correctly compiled binary file
You can try to decompile, but this process - even if successful - isn't lossless (e.g. code is basically spaghetti).
Had you compiled with -g flag, you could possibly retrieve the code from debug info.
You can at least de-assemble to Assembly code.
Related
There's a TL;DR at the end if the context is too much!
Context
I am trying to update the version of glibc a project uses to 2.23 (I know it's old, that's another issue). In order to do this, I need to swap out the libraries and use the associated interpreter.
I encountered some issues when swapping out the interpreter that looked like an ABI change, so I figured it was probably because the header files had changed somehow and started working on getting those included into the project.
At first I tried using -I to include the headers, but got an error (see below). Later I tried setting --sysroot, but this quickly felt like the wrong way of doing things since I was essentially reinventing what g++ already did with system headers. I later found another mechanism that looked more promising (see Problem section).
Could this be an XY issue? Absolutely, but either way, the problem I'm seeing seems odd to me.
Problem
I looked into whether there was a different mechanism to include headers for system libraries, such as glibc, in gcc and g++. I found the flag -isystem:
-isystem dir
Search dir for header files, after all directories specified by -I but before the standard system directories. Mark it as a system directory, so that it gets the same special treatment as is applied to the standard system directories. If dir begins with "=", then the "="
will be replaced by the sysroot prefix; see --sysroot and -isysroot.
I figured that this was probably wanted and set about intergrating this flag into the build system for the project. The resulting g++ command looks like this (simplified and broken onto multiple lines):
> /path/to/gcc-6.3.0/bin/g++
-c
-Wl,--dynamic-linker=/path/to/glibc-2.23/build/install/lib/ld-linux-x86-64.so.2
-Wl,--rpath=/path/to/glibc-2.23/build/install/lib
-isystem /path/to/glibc-2.23/build/install/include
-I.
-I/project-foo/include
-I/project-bar/include
-o example.o
example.cpp
This leads to the following error, followed by many similar ones:
In file included from /usr/include/math.h:71:0,
from /path/to/gcc-6.3.0/include/c++/6.3.0/cmath:45,
from example.cpp:42:
/path/to/glibc-2.23/build/install/include/bits/mathcalls.h:63:16: error: expected constructor, destructor, or type conversion before '(' token
__MATHCALL_VEC (cos,, (_Mdouble_ __x));
Looking into this, it appears that this particular math.h is incompatible with this version of glibc. The fact it tries to use it surprises me, because the math.h file exists in the glibc directory I specified; why didn't it use that? Here's how I verified that file exists:
> ls /path/to/glibc-2.23/build/install/include/math.h
/path/to/glibc-2.23/build/install/include/math.h
Research
I searched around on the internet for people with a similar issue and came across the following relevant things:
https://github.com/riscv/riscv-gnu-toolchain/issues/105
https://askubuntu.com/questions/806220/building-ucb-logo-6-errors-in-mathcalls-h
-isystem on a system include directory causes errors
The last of these is the most promising; it talks about why -isystem won't work here stating that the special #include_next traverses the include path in a different way. Here, the solution appears to be "don't use -isystem where you can help it", but since I've tried using -I only get get the same problem again, I'm not sure how I'd apply that here.
Original issue
When compiling with the new glibc, I get the following error (our build process ends up running some of the programs it compiles to generate further source to be compiled, hence this runtime error whilst compiling):
Inconsistency detected by ld.so: get-dynamic-info.h: 143: elf_get_dynamic_info: Assertion `info[DT_RPATH] == NULL' failed!
I found a couple of relevant things about this:
https://www.linuxquestions.org/questions/linux-software-2/how-to-get-local-gcc-to-link-with-local-glibc-404087/
https://www.linuxquestions.org/questions/programming-9/inconsistency-detected-by-ld-so-dynamic-link-h-62-elf_get_dynamic_info-assertion-621701/
The only solution I see there is completely recompiling gcc to use the new glibc. I'd like to avoid that if possible, which is what lead me down the include route.
Eliminating the complex build system
To try and eliminate the complex build system on the "real" project, I reproduced the problem using the following test.cpp file:
#include <cmath>
int main() {
}
Compiled using:
> /path/to/gcc-6.3.0/bin/g++ test.cpp -Wl,--dynamic-linker=/path/to/glibc-2.23/build/install/lib/ld-linux-x86-64.so.2 -Wl,--rpath=/path/to/glibc-2.23/build/install/lib
Running yields the same original issue:
> ./a.out
Inconsistency detected by ld.so: get-dynamic-info.h: 143: elf_get_dynamic_info: Assertion `info[DT_RPATH] == NULL' failed!
Trying to use the newer headers yields the same include issue:
> /path/to/gcc-6.3.0/bin/g++ test.cpp -Wl,--dynamic-linker=/path/to/glibc-2.23/build/install/lib/ld-linux-x86-64.so.2 -Wl,--rpath=/path/to/glibc-2.23/build/install/lib -isystem /path/to/glibc-2.23/build/install/include
In file included from /usr/include/math.h:71:0,
from /path/to/gcc-6.3.0/include/c++/6.3.0/cmath:45,
from test.cpp:1:
/path/to/glibc-2.23/build/install/include/bits/mathcalls.h:63:16: error: expected constructor, destructor, or type conversion before '(' token
__MATHCALL_VEC (cos,, (_Mdouble_ __x));
TL;DR
How can I get g++ to include the headers from my glibc build correctly, without it accidentally including incompatible files from /usr/include?
In your GCC version,<cmath> uses #include_next, which means that you need to make sure that the directory which contains the cmath file comes before (on the include search path) the directory with the proper math.h for the version of glibc you are building against.
You can use g++ -v to view the search path. In your case, it probably looks like this:
#include "..." search starts here:
#include <...> search starts here:
.
/project-foo/include
/project-bar/include
/path/to/glibc-2.23/build/install/include
/usr/include/c++/6
/usr/include/x86_64-linux-gnu/c++/6
/usr/lib/gcc/x86_64-linux-gnu/6/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
If you configure glibc with --prefix=/usr and install it with DESTDIR=/path/to/glibc-2.23/build/install, its header files will be installed into the directory /path/to/glibc-2.23/build/install/usr/include. This means you should be able to use the -isysroot option, which rewrites the default /usr/include directory, resulting in the right ordering of the search path:
#include "..." search starts here:
#include <...> search starts here:
.
/project-foo/include
/project-bar/include
/usr/include/c++/6
/usr/include/x86_64-linux-gnu/c++/6
/usr/include/c++/6/backward
/usr/lib/gcc/x86_64-linux-gnu/6/include
/usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
/path/to/glibc-2.23/build/install/usr/include
While compiling my nasm programm, the command nasm -felf prgname.asm works fine but when i use the gcc command gcc -o prgname prgname.o driver.c asm_io.o it gives me an error
file format not recognized; treating as linker script
/usr/bin/ld:asm_io.o:1: syntax error
collect2: ld returned 1 exit status
I do not understand this error. Has it to do something with my system architecture?
Based on the error output, it's not your prgname.o file that's causing the issue but the asm_io.o one. As per the output:
file format not recognized; treating as linker script
/usr/bin/ld:asm_io.o:1: syntax error
you can see that it's treating some file as a textual linker script and then complaining about a syntax error in asm_io.o.
Since you tend to get syntax errors from textual source code rather than binary object files, it's a fairly safe bet that the file being treated as a linker script is the asm_io.o one.
So you should probably concentrate your efforts there. The first thing to do is to check both files to see what type they are:
file prgname.o asm_io.o
I'm including the first not because I think it's wrong but because, if it's right, it'll give an indication of what the second one should be.
You could also leave asm_io.o out of the compilation command altogether. You'll probably get unresolved symbol errors but it'll at least prove which file is causing the problem.
Once you've established the problem is asm_io.o, you'll need to rebuild that (assuming you have source) with the correct options.
I do not know why, but the (Android ADB) shell says no such file or directory when I compile with arm-linux-gnueabi-gcc without the -static option, and then attempt to execute the native executable. This is the no such file or directory you get when the shell knows the file exists at that path, but doesn't want to give the user permission to know the file exists. (e.g. you can check with chmod 4755 which returns no error message).
If I compile with the -static option then the program executes normally.
Why does this happen when compiling without the static option?
if you link statically everything the program needs will be built in. There are no
dependencies to libraries on your device, so it will run perfectly. Bad is the size
of this programming style (huge)!
If you leave out the -static your compiler assumes dynamic linking, but without some
magic you link against (Linux)-glibc: crash!
Search for "native C on Android" tutorial on the net, please. They explain all
the (horrible) linker-stuff you nee to link against Android)-glibc aka "Bionic".
Good luck
may the sources be with you
Martin
I have the following warning during link:
/usr/bin/ld: warning: libxxx.so.6, needed by /a/b/c/libyyy.so, not found (try using -rpath or -rpath-link)
Setting environment variable LD_LIBRARY_PATH=path_to_libxxx.so.6 silence the warning (adding -Lpath_to_libxxx.so.6 doesn't help).
I have a separate compilation server, where the resulting binary is only compile.
The binary is executed on other server and there the libxxx.so.6 is seen by the binary (checked with ldd executable).
Is there're other way to get rid of the warning at compilation time (I have it several times and it's very annoying)?
You need to add the dynamic library equivalent of -L:
-Wl,-rpath-link,/path/to/lib
This will cause the linker to look for shared libraries in non-standard places, but only for the purpose of verifying the link is correct.
If you want the program to find the library at that location at run-time, then there's a similar option to do that:
-Wl,-rpath,/path/to/lib
But, if your program runs fine without this then you don't need it.
Make sure the paths to the needed libraries are known to the runtime linker. This is done by adding a file in /etc/ld.so.conf.d/ with the needed path. For example, /etc/ld.so.conf.d/foo with the following contents:
/usr/local/lib/foo/
If you have a very old Linux version, /etc/ld.so.conf.d/ might not be supported, in which case you might have to add the paths directly into the /etc/ld.so.conf file.
After you've done that, you need to update the linker's database by executing the "ldconfig" command.
I know this is old, but here's a better fix:
The root cause:
The problem actually happens when LD invoked by GCC starts resolving
library dependencies. Both GCC and LD are aware of the sysroot
containing libraries, however LD may be missing one critical
component: the /etc/ld.so.conf file. Here’s an exampleld.so.conf file
from a Raspberry PI system:
include /etc/ld.so.conf.d/*.conf
The /etc/ld.so.conf.d directory contains the following files:
00-vmcs.conf:
/opt/vc/lib
arm-linux-gnueabihf.conf:
/lib/arm-linux-gnueabihf /usr/lib/arm-linux-gnueabihf
libc.conf:
/usr/local/lib
The universal solution
The problem can be easily solved by copying the LD configuration files
to a location where the cross-toolchain’s LD can find them. There’s
one pitfall however: if your cross-toolchain was built with MinGW
(most are), it probably did not have access to the glob() function so
it won’t be able to parse a wildcard-enabled include statement
like *.conf. The workaround here is to just manually combine the
contents of all .conf files from /etc/ld.so.conf.d and paste them
into /etc/ld.so.conf
*/opt/vc/lib
/lib/arm-linux-gnueabihf
/usr/lib/arm-linux-gnueabihf
/usr/local/lib*
Once you create the ld.so.conf file in the correct folder, your
toolchain will be able to resolve all shared library references
automatically and you won’t see that error message again!
The only way to silence these warning using command line options would be the -L flag which curiously does not work for you (maybe you can post more details on this). Since the warning is generated by ld we could try to use -Wl,option to disable a linker warning but from the documentation of GNU ld however there is no option for (de)activating this warnings.
So this leaves us with writing a wrapper script filtering out this warning or compile a custom version of ld.
The project I'm currently working on uses a bunch of dynamic libs bundled together with the source code. There is a subset of libs which is named as follows:
for a given lib libABC, there are four files:
libABC.so
libABC.so.4
libABC.so.4.5
libABC.so.4.5.0
They are daisy-chained like this:
the first file, libABC.so, contains the following:
link libABC.so.4
whereas the next file, libABC.so.4, contains the following:
link libABC.so.4.5
and so on till the actual lib file, libABC.so.4.5.0.
I know that this kind of stuff should be done using symlinks, but we can't change that, it's a commercial project. So the linker chokes on that!
/usr/bin/ld: path/to/the/packaged/libs/libABC.so:unrecognized file format, treating as linker script
(which it actually is, heh)
/usr/bin/ld: path/to/the/packaged/libs/libABC.so:1:syntax error
Now I can't seem to find any info on the GNU ld linker script command "link" or any complete reference to the GNU ld linker script commands.
What could that be?
The linker script format is described in the GNU ld manual.
I found this issue myself today, and what happens is when you do a checkout using SVN on Windows (e.g. TortoiseSVN), the Linux symlink is converted into a text file.
Then, on the build process, ld is receiving a text file instead of a symlink that would lead to the concrete file.
Solution: svn checkout on the Linux machine.