While building glibc, I get this error.
*glibc/build/elf/dl-allobjs.os: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status*
What is an .os file and what binutil do I need to install to fix this?
What is an .os file
It's just an object file, intended to be linked into a shared library. UNIX linkers for the most part don't care about file extension, you can call file foo.o, foo.oS, or just about anything else, it would still work.
what binutil do I need to install to fix this?
It's unlikely that your problem has anything to do with binutils. It is more likely that the file got corrupted somehow.
What does file glibc/build/elf/dl-allobjs.os report? Are you cross-compiling? Does the problem reproduce if you reconfigure and rebuild in a different directory?
Related
-- Question solved --
This question is solved. Thanks for all the help!
The problem and the reason is briefly stated as following for other readers in the future:
[Environment]
Ubuntu 14.04, Bazel, C++
[Question]
I want to include an external library. So I download the source file and make it as as a static lib .a.
I correctly set the BUILD, WORKSPACE and related files. However, when compile, it alerts the error:
Linking of rule '//main' failed (Exit 1)
main: error: undefined reference to 'void ex_lib::compute(double*, double const*, double const*)'
collect2: error: ld returned 1 exit status
I tried with the .lo and alwayslink method here but doesn't work.
Alternate to "`--whole-archive`" in bazel
[Reason]
It is because that the external library source files contains duplicate header files. So I fix the header file problem. Make the .a again. Then everything works.
So nothing wrong with the bazel. It is the library itself that cause the problem. But the error information is confusing and I think it is caused by bazel.
What you can do to investigate further is to run the clean bazel build with --subcommands to see individual command lines of actions executed. Then you can cd into the sandbox, and execute the same gcc command as bazel does and debug what's wrong. Or you can try to get linking to work by handwriting gcc command, and pasting here both the command bazel generated, and your desired command. Is it possible that you have multiple liegroups libs installed on the system and gcc is getting one that's incompatible with headers you're including?
The problem is solved. Special thanks to mhlopko.
It is mainly because there is errors with the lib source file. Thus .a file I use contains errors. Now the bazel works fine with the new lib file.
By the way, now bazel works fine with both .a or .so file that I generated.
I have a question very simliar to Cross compiler default include path setup but there wasn't the answer I was looking for.
I built a cross-compiler for openrisc. I have it in ~/openrisck/toolchain/
under there, I have bin(or32-linux-* excutables are here), include, lib, lib64, libexec, or32-linux, share.
under or32-linux, I have bin, include, lib, sys-root.
When I build busybox, I gave CONFIG_CROSS_COMPILER_PREFIX as "or32-linux-".
and CONFIG_SYSROOT as "$SYSROOT" which is ~/openrisk/toolchain/or32-linux/sys-root.
then I run 'make install' in buxybox source. Since the path includes the cross-compiler directory, it compiles for or32-linux-. But I have an error below
ckim : srctree = /home/ckim/openrisc/busybox
CC applets/applets.o
In file included from /home/ckim/openrisc/toolchain/bin/../lib/gcc/or32-linux/4.5.1-or32-1.0rc1/include-fixed/syslimits.h:7:0,
from /home/ckim/openrisc/toolchain/bin/../lib/gcc/or32-linux/4.5.1-or32-1.0rc1/include-fixed/limits.h:34,
from include/platform.h:141,
from include/libbb.h:13,
from include/busybox.h:8,
from applets/applets.c:9:
/home/ckim/openrisc/toolchain/bin/../lib/gcc/or32-linux/4.5.1-or32-1.0rc1/include-fixed/limits.h:169:61: fatal error: limits.h: No such file or directory
compilation terminated.
make[1]: *** [applets/applets.o] Error 1
make: *** [applets_dir] Error 2
which makes me thinks that Ah! the cross-compiler uses the include path relative to the executable. (see above bin/../lib/gcc/or32-linux/version/include-fixed)
So the include limits.h goes to the gcc's limits.h correctly. The last file syslimits.h has #include_next when the limits.h file have already been included. and the compiler complains that the file cannot be found.
Can somebody tell me how to solve this problem? (limits.h includes syslimits.h and syslimits.h includes limits.h .. )
EDIT : I ran 'make CROSS_COMPILE=or32-linux- CONFIG_PREFIX=$SYSROOT install'
then I got 'lutimes undeclared in coreutil/touch.c' error. Assuming the limit.h problem is gone, this means I should give these command line arguments because CROSS_COMPILE for make is different from CONFIG_CROSS_COMPILER_PREFIX in busybox configuration and make's CONFIG_PREFIX is different from CONFIG_SYSROOT for busybox configuration. so to remove the lutimes error, I ran 'make menuconfig' and removed CONFIG_TOUCH. Then I reran the make(make CROSS_COMPILE=or32-linux- CONFIG_PREFIX=$SYSROOT install), and this time got
procps/free.c: In function 'free_main':
procps/free.c:51:17: error: storage size of 'info' isn't known
procps/free.c:77:2: warning: implicit declaration of function 'sysinfo'
I found that in $SYSROOT/usr/include/sys/sysinfo.h, struct sysinfo is defined. I don't know why it says it's not defined. Any help would be deeply appreciated. Thanks!
For anyone who might be facing the same problem I had..
I tried about 3 times with the old toolchain but failed.
Yesterday, I got help from IRC (openrisc) and someone told me there is an updated toolchain for or1k. (not or32 which is old. I should have read the opencore page first..)
The page is
http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Linux_.28uClibc.29_toolchain_.28or1k-linux-uclibc.29 (read from Linux (uClibc) toolchain (or1k-linux-uclibc))
I have a question regarding the inclusion of boost libraries to make files. This question has been asked (and answered) multiple times in this forum and others, I could not solve my problem however using suggestions from there, since I am stuck in a much more basic stage.
I am using a ready made make file that includes the address of the boost libraries via an env file that is included in the beginning of the makefile. Thus, all I have to do is provide the correct folder of the boost libraries, however I seem to be providing the wrong address, as I get an error that the boost libraries could not be found:.
Demo_00.cpp:(.text+0x28): undefined reference to `boost::mpi::environment::environment(int&, char**&, bool)'
Demo_00.cpp:(.text+0x34): undefined reference to `boost::mpi::communicator::communicator()'
Demo_00.cpp:(.text+0x40): undefined reference to `boost::mpi::communicator::rank() const'
Demo_00.cpp:(.text+0x55): undefined reference to `boost::mpi::communicator::rank() const'
Demo_00.cpp:(.text+0x8b): undefined reference to `boost::mpi::environment::~environment()'
Demo_00.cpp:(.text+0xb3): undefined reference to `boost::mpi::environment::~environment()'
collect2: ld returned 1 exit status
The specific part of the env file looks like this:
BOOST_INCLUDE=-I./home/user/Documents/RHPC_2.0/INSTALLATION/boost_1_54_0/
BOOST_LIB_DIR=-L./home/user/Documents/RHPC_2.0/INSTALLATION/boost_1_54_0/stage/lib
BOOST_LIBS=-lboost_mpi-xgcc42-mt -lboost_serialization-xgcc42-mt -lboost_system-xgcc42-mt -lboost_filesystem-xgcc42-mt
My questions:
In the template file of the env file, the first address ended with '.../boost_1_54_0/include', my boost folder does not have an include folder however (there are some further within the folder only). Is this a problem?
Do I need to make any adjustment to BOOST_LIBS?
Is there maybe a simple way of identifying the correct addresses using cmake? I worked my way through the cmake documentary but did not quite get how this would be implemented.
Also: I have just tried to 'compile+link' by hand, which only worked for the compiling part but not for linking. Here is the compiling:
/home/user/Documents/RHPC_2.0/INSTALLATION/mpich2-1.4.1p1/bin/mpicxx -c -I/home/user/Documents/RHPC_2.0/INSTALLATION/boost_1_54_0/ -o Demo_00.o Demo_00.cpp
Here is the Linking part, which did not work
/home/user/Documents/RHPC_2.0/INSTALLATION/mpich2-1.4.1p1/bin/mpicxx -L/home/user/Documents/RHPC_2.0/INSTALLATION/boost_1_54_0/stage/lib/ Demo_00.cpp -lboost_mpi-xgcc42-mt -lboost_serialization-xgcc42-mt -lboost_system-xgcc42-mt -lboost_filesystem-xgcc42-mt
After this command I get the following error:
/usr/bin/ld: cannot find -lboost_mpi-xgcc42-mt
/usr/bin/ld: cannot find -lboost_serialization-xgcc42-mt
/usr/bin/ld: cannot find -lboost_system-xgcc42-mt
/usr/bin/ld: cannot find -lboost_filesystem-xgcc42-mt
collect2: ld returned 1 exit status
It seems, here the problem lies with the these last 4 files and not the entire boost folders. The above folders /usr/bin/ld are also not existent to my knowledge.
I appreciate your help and again my apologies for bringing up this topic yet again.
Thanks,
Tartaglia
Whatever is passed to -I should be pointing to the folder having boost/*hpp files under it (say boost/shared_ptr.hpp).
Whatever is passed to -L should be the folder where all of those passed to -l reside (when you say -lthename the respective file name is libthename.so).
Also these BOOST_* environment variables should be concatenated to the compiler/linker command line (I assume that is already happening automatically in your case).
When I make a use of Qwebview in my application. and then build it I get an error of
:: error: collect2: ld returned 1 exit status
:: error: [debug\Browseweb.exe] Error 1
so it does not run I have seached Quit But didn't got the solution So what should I do to solve this error. if You have a Solution kindly help me.
That error is coming from the linker ld and, based on error: [debug\Browseweb.exe] Error 1, my first thought is that it's a problem creating the executable file.
If that error 1 matches what's in errno.h, then it's an EPERM error which is related to permissions. You should check whether the debug directory exists and, if it does, check to make sure you can create files in there.
However, given that you seem to be on a Windows platform (due to the backslash path separator and an exe extension), I'm not sure that's the actual case.
One other thing that may be causing the problem is if your executable is running when you try to rebuild it.
I've seen this problem before under Windows since the OS locks the executable while it's running.
When compiling GCC it is possible to get very far in the build process only to hiccup on an error complaining about the lack of gperf installed. After installing gperf and running, I hit an "undefined reference to libc_name_p." I've looked at the solutions here and here but they weren't helpful.
When gperf wasn't installed, the compilation script ran the command anyway but generated a blank ./gcc/cp/cfns.h. Since this file was newer than the source (./gcc/cp/cfns.gperf) the makefile left it alone and never regenerated the 'real' file when you actually had gperf. To continue, run rm ./gcc/cp/cfns.h and try again.