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.
Related
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.
I understand that this has come up a lot, but I've looked through all the other answers and none of them are relevant to me.
I am trying to compile the neuroimaging software FSL from source (I have to, it's not supported on my Linux Distro). I've followed all the instructions listed here, and it's about 80% compiled. There are a few modules that have not been successful, however, and they all seem to trace back to a problem trying to compile CiftiLib-master.
Per the instructions, whenever I try to run the 'make' command, it returns:
Makefile:34: warning: overriding recipe for target 'clean'
/home/thosvarley/Desktop/fslbuild/fsl/config/common/rules.mk:32: warning: ignoring old recipe for target 'clean'
gcc -c -Wall -ansi -pedantic -Wno-long-long -m64 -g -O3 -fexpensive-optimizations -m64 -I/home/thosvarley/Desktop/fslbuild/fsl/extras/include/boost -g -DCIFTILIB_USE_XMLPP -I/home/thosvarley/Desktop/fslbuild/fsl/extras/include -I/home/thosvarley/Desktop/fslbuild/fsl/extras/include/libxml2 -I/home/thosvarley/Desktop/fslbuild/fsl/extras/include/libxml++-2.6 -I/home/thosvarley/Desktop/fslbuild/fsl/extras/lib/libxml++-2.6/include -I/home/thosvarley/Desktop/fslbuild/fsl/extras/include/boost -I./Common -I./Nifti -I./Cifti -I. -I/include -I/home/thosvarley/Desktop/fslbuild/fsl/include -o Common/XmlAdapter.o Common/XmlAdapter.cxx
In file included from Common/XmlAdapter.cxx:28:0:
Common/XmlAdapter.h:56:10: fatal error: libxml++/libxml++.h: No such file or directory
#include "libxml++/libxml++.h"
^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:19: Common/XmlAdapter.o] Error 1
As I am not trying to compile one foo.c file, but rather, make a program a lot of the advice I've seen doesn't seem like it would apply to me. I've already installed all of the various libxml packages that get suggested in other posts (libxml2, libxslt1, etc).
I cannot make heads or tails of the error message: I'm not familiar with compiling C programs at all (this is my first serious foray into building from source). Apologies in advance if the answer is obvious and I just don't recognize it.
I'm on Antergos Linux (Arch kernel), which I think may be where the problem is coming from as all the other people who have asked after this seem to be on Debian or Ubuntu.
I have been attempting to solve the same problem. It seems that libxml++ is bundled with FSL by default, and the bundled version fails to compile.
Solution #1: Install and use an older compiler (e.g. GCC 4.8), since the project's configurations are made to fit those old compilers
I cannot vouch for this solution, as I haven't tried it myself (because apparently, I like to make life difficult for myself), but it's probably your best bet.
Solution #2: Fix the problems manually
NOTE: This is not a comprehensive solution, but it might point you in the correct direction.
Your first problem is most likely that the compiler you're using by default uses a more recent C++ standard than the project is written to be compiled with. This causes the implicit conversion of input streams and output streams to booleans to fail. You might be able to solve it by messing around with compiler flags in the makefile configurations, but it's probably easier to just fix the problematic parts of the code. The relevant lines (FSL 5.0.11) are:
- extras/src/libxml++-2.34.0/libxml++/io/istreamparserinputbuffer.cc (line 42)
return _input;
SHOULD BE
return static_cast<bool>(_input);
- extras/src/libxml++-2.34.0/libxml++/io/ostreamoutputbuffer.cc (line 32)
return _output;
SHOULD BE
return static_cast<bool>(_output);
- extras/src/libxml++-2.34.0/libxml++/io/ostreamoutputbuffer.cc (line 39)
return _output;
SHOULD BE
return static_cast<bool>(_output);
Depending on the version you're trying to install, the actual line numbers may be different, but they're probably in the same general area.
The next problem is that the include paths are not defined for INC_XML++, INC_XML++CONF and INC_XML2 in the generic makefile configuration. This is most likely the one your system defaults to, as there are no configurations for GCC versions > 4.8. Edit the config/generic/externallibs.mk file by adding the following lines (where exactly you add it is not important):
# XML++
LIB_XML++ = ${FSLEXTLIB}
INC_XML++ = ${FSLEXTINC}/libxml++-2.6
INC_XML++CONF = ${FSLEXTLIB}/libxml++-2.6/include
INC_XML2 = ${FSLEXTINC}/libxml2
(I addeed the LIB_XML++ for good measure, because the lib path was defined by other variables in the file, but I'm not 100% sure it's necessary.)
Again, this is what fixed it on my system. Depending on the version of the source code you downloaded, it might be different for you, but at least this is a starting point.
After fixing these errors, the CiftiLib-master target should compile. HOWEVER, if your system is anything like mine, this is far from the only error in the build process. Looking at the build.log file and searching for error: should give you a pretty good idea of which projects result in which errors, and what might be needed to fix them. The problems are likely to be similar in nature to the CiftiLib ones.
Final tip: If your libgd project fails to compile, look at the error: message. It probably complains about some undeclared identifiers (IMG_FMT_I420, PLANE_Y, PLANE_U, PLANE_V). If you prefix these identifiers with VPX_, it should work. The reason this fails is because of an update to the library that removes the definitions of the deprecated identifiers, forcing users to use the newer prefixed ones.
This is as far as I've come. I'm assuming you're not still troubled with this a year later, but I'm leaving this here for posterity.
I ran across this error while trying to compile the NMR software modelfree4.20 for Linux. The distribution comes with a MakeFile, and so I type "make" in the modelfree folder to try and compile it, and after it writes a few files I get the following error:
/usr/bin/ld: -f may not be used without -shared
collect2: error: ld returned 1 exit status
Makefile:74: recipe for target 'modelfree4' failed
make: *** [modelfree4] Error 1
I have no idea what "-f may not be used without -shared" means or what it is trying to tell me to fix? I don't see anything with a -f or -shared in the MakeFile when I open it up, and I didn't specify any options when I ran "make."
Any help on this is greatly appreciated!
I think I could see 2 possibilities.
If the Makefile is generated by a configure script, you may need to run it again. You may have picked up a bad Makefile due to misconfiguration. Possibly you need to run the autotools to generate the configure script again.
It's possible that there is some system- or session-specific LDFLAGS environment variable interfering with linking. Try unset LDFLAGS?
I'm trying to compile fbsplash under Tiny Core Linux using autotools. In the middle of compilation it crashed saying "LD: attempted static link to dynamic object /usr/local/lib/libpng16.so"
I've got rid of that, commenting out option "-all-static" in the Makefile. Now it crashes after
/bin/bash: O2: not found
/bin/bash: w: not found
/bin/bash: DTARGET_KERNEL: not found
All of these options have dashes before them. It looks like:
fbcondecor_helper_CFLAGS = -O2 -w \...
fbcondecor_helper_CPPFLAGS = $(AM_CPPFLAGS) -DTARGET_KERNEL
But somehow my shell interprets them as commands without dashes.
What's wrong?
First, you are not using the autotools. You are using a configure script that was generated using the autotools. (If indeed you are running autoconf, or autoreconf, that is a different issue and there is (much) more room for error on your part.) In either case, you should never hand edit the generated Makefile. (So short answer to "What's wrong?" is, "you edited the Makefile".) Instead, add --disable-static when you run configure.
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.