I'm unable to compile anything in my linux pc. I have no idea why, probably I've installed some package and made a mess. I've uninstalled and reinstalled gcc and other packages, but no good news.. still this problem.
This is the message:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-
linux/bin/ld: /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/crt1.o: unrecognized relocation (0x29) in section `.text'
Any idea of what does it mean and how to fix this problem?
cheers
For anyone else that encounters this issue: I think #gabib44's problem was using a older version of ld to link a library that had been built with a newer version.
"unrecognized relocation" occurs when the relocation type is greater than the greatest known relocation type in your version of ld. 0x2a (R_X86_64_REX_GOTPCRELX) is presently the relocation type with the greatest value; I guess #gabib44's ld was old enough to not know about the relocation type before that one (0x29, R_X86_64_GOTPCRELX).
I had this problem myself when I was building a library with binutils v2.26 (which knew about relocation 0x2a) but then incorporating that library on a build machine using binutils v2.24
The fix is either to build the library that you want to link with a older version of the binutils suite, or to upgrade ld on the machine that wants to link that library.
I've found this in another post:
[...which when compiled brings this error:
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-
gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-
gnu/6.4.0/../../../../lib64/Scrt1.o: unrecognized relocation (0x2a) in
section `.text'
After trying a lot of things out, including emerging binaries from a different Gentoo system, I finally reverted, and got the problem solved thanks to optiz0r (for solving my issue) and Ryuno-Ki[m] (for letting me know about optiz0rs reply when I had logged off).
sudo binutils-config x86_64-pc-linux-gnu-2.29.1
Very simple! The solution to your problem may differ, but running
sudo binutils-config -l
may reveal the version you can enter instead of the version I used...]
by necrophcodr » Tue Feb 06, 2018 21:24
on https://forum.sabayon.org/viewtopic.php?f=57&t=34076&p=181260#p181260
It worked for me.
I fixed installing gcc-32bit and removing various other packets
Related
I tried and tried to create a debug build for a recent version of Tensorflow , using the official docker images (latest-cuda-devel-py3 -> r1.12.0) but nothing seems to work. Has someone recently created a successful debug build for Tensorflow (>= r1.11.0) and can share his approach ?
This is what I tried so far.
I basically tried to follow the instructions at https://www.tensorflow.org/install/source, but tried to modify them to generate a debug build. Nothing I tried resulted in a successful build.
The Host System is a Linux x86-64 machine with lots of RAM (e.g. 512 GB of RAM -> DGX-1). The CUDA Version within the Docker-Image is CUDA-9.0. The recent "latest" Tensorflow Version which is inside the docker image is r1.12.0
In order to get any cuda-build working, I needed to use "nvidia-docker", otherwise I get a linker error with "libcuda.so.1".
I started like this:
nvidia-docker pull tensorflow/tensorflow:latest-devel-gpu-py3
nvidia-docker run --runtime=nvidia -it -w /tensorflow -v $PWD:/mnt -e HOST_PERMS="$(id -u):$(id -g)" \
tensorflow/tensorflow:latest-devel-gpu-py3 bash
Then I tried to configure the project using
cd /tensorflow
./configure
I tried various configs. I tried keeping all values at their defaults. I tried enabling only the parts which I need. I tried not running ./configure at all. I pointed it to my own cuda-9.0 and tensorrt installtion. But not running ./configure at all (in the docker image) seems to produce best results (e.g. I can do optimized builds successfully with least effort).
If I build it using the exact official build instructions, i.e. creating an optimized/non-debug build, everything works as expected. So running the following seems to succeed.
bazel build --config=opt --config=cuda //tensorflow/tools/pip_package:build_pip_package
Same thing, if I run the following, which includes debug info, but does not turn off optimization (e.g. I cannot really use this for debug purposes).
bazel build --config cuda --strip=never -c opt --copt="-ggdb" //tensorflow/tools/pip_package:build_pip_package
But everything which disables optimizations does not seem to work. If I run the following (with or without the --strip=never flag )
bazel build --config cuda --strip=never -c dbg
//tensorflow/tools/pip_package:build_pip_package
I arrive at the following error:
INFO: From Compiling
tensorflow/contrib/framework/kernels/zero_initializer_op_gpu.cu.cc:
external/com_google_absl/absl/strings/string_view.h(496): error:
constexpr function return is non-constant
Which can be resolved by defining -DNDEBUG (see nvcc error: string_view.h: constexpr function return is non-constant ).
But If I run the following:
bazel build --config cuda --strip=never -c dbg --copt="-DNDEBUG" //tensorflow/tools/pip_package:build_pip_package
I get these linking errors at the final step of the build:
ERROR:
/tensorflow/python/BUILD:3865:1:
Linking of rule '//tensorflow/python:_pywrap_tensorflow_internal.so'
failed (Exit 1)
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o: In
function _init': (.init+0x7): relocation truncated to fit:
R_X86_64_REX_GOTPCRELX against undefined symbolgmon_start'
/usr/lib/gcc/x86_64-linux-gnu/5/crtbeginS.o: In function
deregister_tm_clones': crtstuff.c:(.text+0x3): relocation truncated
to fit: R_X86_64_PC32 against.tm_clone_table'
crtstuff.c:(.text+0xa): relocation truncated to fit: R_X86_64_PC32
against symbol __TMC_END__' defined in .nvFatBinSegment section in
bazel-out/k8-dbg/bin/tensorflow/python/_pywrap_tensorflow_internal.so
crtstuff.c:(.text+0x1e): relocation truncated to fit:
R_X86_64_REX_GOTPCRELX against undefined symbol
_ITM_deregisterTMCloneTable'
/usr/lib/gcc/x86_64-linux-gnu/5/crtbeginS.o: In function
register_tm_clones': crtstuff.c:(.text+0x43): relocation truncated to
fit: R_X86_64_PC32 against.tm_clone_table' crtstuff.c:(.text+0x4a):
relocation truncated to fit: R_X86_64_PC32 against symbol
__TMC_END__' defined in .nvFatBinSegment section in
bazel-out/k8-dbg/bin/tensorflow/python/_pywrap_tensorflow_internal.so
crtstuff.c:(.text+0x6b): relocation truncated to fit:
R_X86_64_REX_GOTPCRELX against undefined symbol
_ITM_registerTMCloneTable'
/usr/lib/gcc/x86_64-linux-gnu/5/crtbeginS.o: In function
__do_global_dtors_aux': crtstuff.c:(.text+0x92): relocation truncated
to fit: R_X86_64_PC32 against.bss' crtstuff.c:(.text+0x9c):
relocation truncated to fit: R_X86_64_GOTPCREL against symbol
__cxa_finalize##GLIBC_2.2.5' defined in .text section in
/lib/x86_64-linux-gnu/libc.so.6 crtstuff.c:(.text+0xaa): relocation
truncated to fit: R_X86_64_PC32 against symbol__dso_handle' defined
in .data.rel.local section in
/usr/lib/gcc/x86_64-linux-gnu/5/crtbeginS.o crtstuff.c:(.text+0xbb):
additional relocation overflows omitted from the output
bazel-out/k8-dbg/bin/tensorflow/python/_pywrap_tensorflow_internal.so:
PC-relative offset overflow in GOT PLT entry for
`_ZNK5Eigen10TensorBaseINS_9TensorMapINS_6TensorIKjLi1ELi1EiEELi16ENS_11MakePointerEEELi0EE9unaryExprINS_8internal11scalar_leftIjjN10tensorflow7functor14right_shift_opIjEEEEEEKNS_18TensorCwiseUnaryOpIT_KS6_EERKSH_'
collect2: error: ld returned 1 exit status Target
//tensorflow/tools/pip_package:build_pip_package failed to build
I hoped to be able to solve that by doing a monolithic build. So I tried that, and got essentially the same error.
bazel build --config cuda -c dbg --config=monolithic --copt="-DNDEBUG" //tensorflow/tools/pip_package:build_pip_package
I also tried the approaches from TensorFlow doesnt build with debug mode and several other variants I found by extensive googling. I'm running out of options.
I'd take any Tensorflow version from 1.11 onwards, including (working) nightly builds. It just needs to work with CUDA 9 on x86 linux, include debug symbols and disabled optimizations.
thank you very much in Advance..
Just in case someone else stumbles over this problem. I finally got it to compile, using the following command:
bazel build --config cuda --strip=never --copt="-DNDEBUG" --copt="-march=native" --copt="-Og" --copt="-g3" --copt="-mcmodel=medium" --copt="-fPIC" //tensorflow/tools/pip_package:build_pip_package
After that, installation is a bit of a hazzle, since the wheel cannot be built anymore. But the tensorflow build can be installed anyway:
When building the wheel, via
./bazel-bin/tensorflow/tools/pip_package/build_pip_package /tmp/tensorflow_pkg
The process fails with an error which seems to be a problem with python's builtin zip compression library (i.e. it cannot compress the resulting archive, since it's too large).
It's important to run it anyway, since it only fails at the final step (archiving). When running build_pip_package, it prints to the console right at the start of the process, that it's building the package in a temporary directory (say, /tmp/Shjwejweu ) - the contents of that temp directory can be used to install tf debug version. Simply copy it to the target machine, then make sure you have any old tensorflow package removed (e.g. pip uninstall tensorflow), and run within:
python setup.py install
But be careful to actively uninstall the "tensorflow" package first, otherwise you can get two simultaneously installed tensorflow versions..
I am trying to cross compile NPM Sqlite3 with sqlcipher support. I am using Ubuntu 16.04 to cross compile for linux armv7 based SOC(system on chip).
So I started with cross-compiling OpenSSL to build sqlcipher for arm. I successfully cross compiled sqlcipher to produce a static library (libsqlcipher.a).
Now I am trying to get the NodeJS side of the project. I need sqlite with sqlcipher support, compiled for arm. I am using SOC SDK to built till now.
I am using node v4.6.1 and npm v2.15.9 to cross compile. I made sure I have the same version installed on Ubuntu as the SOC.
The command I use to cross compile is as follows :
npm install sqlite3 --target_arch=arm --enable-static=yes --build-from-source --sqlite_libname=sqlcipher -fPIC --sqlite=home/onkar/Library/sqlcipher-master/.libs --verbose
I exported the location of the libsqlcipher.a to LDFLAGS. I get the following error when I try to cross compile. Can someone help me with this error?
/home/linuximage/sdk/sysroots/x86_64-angstromsdk-linux/usr/libexec/arm-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/5.2.1/real-ld: error: /home/Library/sqlcipher-master/.libs/libsqlcipher.a(sqlite3.o): requires unsupported dynamic reloc R_ARM_THM_MOVW_ABS_NC; recompile with -fPIC
collect2: error: ld returned 1 exit status
node_sqlite3.target.mk:129: recipe for target 'Release/obj.target/node_sqlite3.node' failed
make: *** [Release/obj.target/node_sqlite3.node] Error 1
Please let me know if you require any additional information, I would be more than happy to provide you with the same.
Thanks,
Onkar
In the first instance, you should check if the -fPIC (position independent code) flag was correctly applied when the libsqlcipher.a file was originally created.
In your output above, it looks like the linker is using the file at:
/home/Library/sqlcipher-master/.libs/libsqlcipher.a
Run the command
objdump -r /home/Library/sqlcipher-master/.libs/libsqlcipher.a | more
... and check for a line close to the start of the output beginning with the text
RELOCATION RECORDS FOR
If you see this line, then the library doesn't contain position independent code.
I start saying that i am a newbie in programming and then i am not sure i will be able to explain well my problem.
I had some c++ code i wrote, this code are loaded and used by some R functions.
To compile the code i used the following:
R CMD SHLIB MyCode.cpp
and i loaded the library in R with
dyn.load("MyCOde.so")
Sometimes i built also an R package and i was able to load it into R.
If i do all these stuff on a Mac with mountain lion everything work fine, but now that i switched to mavericks, i have some problems. The R CMD SHLIB MyCode.cpp command works but when i used dyn.load("MyCOde.so") i get the following text:
Errore in dyn.load(paste(dir_function, "MyCOde.so", sep = "")) :
unable to load shared object 'MyCOde.so':
dlopen(MyCOde.so, 6): Symbol not found: __ZNSt8ios_base4InitC1Ev
Referenced from: MyCOde.so
Expected in: flat namespace
in MyCOde.so
Moreover if i try to load the package in R, i get the following
ld: warning: directory not found for option '-L/usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2'
ld: library not found for -lquadmath
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [MyCode.so] Error 1
Can someone helps me?
Based on the helpful website of:
thecoatlessprofessor
Type this into your terminal shell:
curl -O http://r.research.att.com/libs/gfortran-4.8.2-darwin13.tar.bz2
sudo tar fvxz gfortran-4.8.2-darwin13.tar.bz2 -C /
This will create what you need to resume compiling as before.
Since it starts to work I can publish the answer for such a cases.
When you change the compiler and standard libraries - please note that different libraries have different implementation and different standard support. Changing the basement of your system might require total rebuild of your system with the new C++ standard library.
Your libraries are not the exception. So if have the errors in your linker like this:
warning: directory not found for option
'-L/usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2'
apply next algorithm:
Check whether the directory /usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2 still exists. I bet it is not.
Check if you still have the libstdc++ from the missed compiler? Usually if you upgrade the same compiler and the C++ standard library ABI does not change everything should continue to work. If the ABI changed or you switch standard C++ library and compiler - you face the massive system rebuild.
Recompile your library and apps with the new C++ standard library and compiler.
Like previously referred here, ___sincos_stret can not be found when compiling a project that uses this symbol using the Xcode5 command line tools.
In the above referenced thread a solution is posted for IOS targets (passing -miphoneos-version-min=5.0 to the compiler), is there a solution for desktop (x64) targets?
It for example happens for me when trying to compile polycode.
Edit 2:
Strangely, after compiling the libraries referenced in the previous error manually, the error now happens to be located in lto.o, which is an internal llvm header itself...
undef: ___sincos_stret
Undefined symbols for architecture x86_64:
"___sincos_stret", referenced from:
_mdct_init in lto.o
_dradfg in lto.o
I'm running OSX 10.9 DP with Xcode 5. This is the link step.
stret is Apple-speak for "returns a structure". ___sincos_stret is an LLVM optimisation — if you write code that calls sin(n) and then cos(n) and uses both results then the compiler will make one call to the structure-returning sincos method, receiving a structure with both things in it. It's faster to work out both at once rather than individually if the operand is the same.
On a superficial browsing I can't see a sin or cos in initInterTab2D but I expect something is being inlined.
While poking around I tried:
cd /Applications/Xcode.app/Contents/Developer/Platforms
grep -lr ___sincos_stret *
Via that and using nm on likely results, I found the ___sincos_stret function is exposed in both iOS since 7.0 and OS X since 10.9 as part of their libsystem_m.dylibs. E.g. if your Xcode is installed in the default place, try:
nm /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/lib/system/libsystem_m.dylib | grep sincos
And/or:
nm /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/system/libsystem_m.dylib | grep sincos
You'll see the symbol in either of those. So the correct solution would be to set an older deployment target in Xcode, or do the equivalent in your makefile.
You want -mmacosx-version-min=10.8 (or whatever your targeted OS version is).
It seems like un- and reinstalling Xcode5 DP and the OSX 10.9 command line tools solved the problem. I guess there was a problem with updating from the previous versions.
Open the following file in a text editor
/opt/local/etc/macports/macports.conf
and add there a lines like
# MACOSX_DEPLOYMENT_TARGET - osx version to be compatible with earlier OSX version.
macosx_deployment_target 10.8
MACOSX_DEPLOYMENT_TARGET 10.8
I have just downloaded clang 3.3 (homebrew) from the LLVM web page to my mac (OS X 10.8.4), but get this compiler error when using std=c++11 stdlib=libc++:
In file included from /usr/include/c++/v1/string:434:
In file included from /usr/include/c++/v1/algorithm:594:
In file included from /usr/include/c++/v1/memory:590:
In file included from /usr/include/c++/v1/typeinfo:61:
/usr/include/c++/v1/exception:146:5: error: an attribute list cannot appear here
_LIBCPP_NORETURN friend void rethrow_exception(exception_ptr);
^~~~~~~~~~~~~~~~
/usr/include/c++/v1/__config:190:28: note: expanded from macro '_LIBCPP_NORETURN'
# define _LIBCPP_NORETURN [[noreturn]]
^~~~~~~~~~~~
It seems that I also need another libc++ (even though it was said that it was 100% complete on MAC ...), but I cannot find any. Any help appreciated. Just for your info:
> clang++ -v
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
And, yes, I googled it and found this: http://comments.gmane.org/gmane.comp.compilers.llvm.bugs/24138 claiming it's resolved in libc++ trunk ???
Okay, as suggested by Howard, I've downloaded tip-of-the-trunk libc++ into /opt/local/share/libcxx, but have trouble building it. The manual says to cd libcxx/lib, export TRIPLE=-apple-, and run ./buildit. I presume this implies bash (I'm usually a tcsh user, so I moved my .tcshrc, got a new shell and started bash). I did that and the compilations worked, but the library build failed. Apparently ./buildit doesn't see $TRIPLE=-apple-, as it picks the wrong LDSHARED_FLAG (not that on line 81, but that on line 103, which is to be used if $TRIPLE is not set), even though echo $TRIPLE yields -apple- as it should. When I add the statement echo TRIPLE = $TRIPLE at the top of buildit, it reports nothing. How come? What is wrong here?
The failure was that because the wrong LDSHARED_FLAG was picked the loading didn't work (ld complaint about the unknown option -soname which, I think, makes sense under linux). I don't know why buildit (a #! /bin/sh file) didn't pick up the TRIPLE environment variable (it did pick up several unwanted ones such as CXX and CC). I now simply added TRIPLE=-apple- at the top of that file and it did built the library. However, the loader spitted out several warnings all of which were of the form
ld: warning: direct access in ___cxa_bad_typeid to global weak symbol typeinfo for std::bad_typeid means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
But most importantly, it works (the compilation at least, I have yet to test the library). I have one final question. The advice was to use -I and -L to tell the compiler about the whereabouts of this version. Is it not possible to put it into the usual place /usr/include/c++/v1/? Note that Xcode has its version somewhere else anyway and I had put in a symbolic link (/usr/include/c++/v1/) to that one to get my homebrew clang 3.2 working (after the some Xcode update). What about the library? Can I also put it in a standard place?
Here is the home page of libc++:
http://libcxx.llvm.org
You can download the tip-of-trunk libc++ from there. You can tell clang to point to your download with -nostdinc++ -I<path-to-libc++>/include. You can also tell clang to link to your tip-of-trunk libc++ with -L<path-to-libc++>/lib and export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib. The directions are all on the libc++ home page.
Xcode is the easiest way to get clang + libc++. But if you want the very latest, this is the place to go.
Congratulations!
Don't worry about the ld warning. It is a harmless ld bug that will be fixed in a future release. I see it on 10.8.4 too and it doesn't hurt anything.
The libc++ headers no longer live at /usr/include/c++/v1. Xcode has migrated them into itself. Having libc++ headers at /usr/include/c++/v1 from older installs has been a source of confusion and bugs. I regularly use -nostdinc++ -I to point to the libc++ headers I want (I often have several versions going at the same time), and that works well for me.
It is possible for you to replace your /usr/lib/libc++.1.dylib with that you have built. I do not recommend doing this. I have to sometimes to do a proper test, but I always do so very carefully because sometimes this causes me to have to reboot onto a backup disk and restore my /usr/lib to its original state. If you do go this route, it is a very good idea to have a backup of the original /usr/lib/libc++.1.dylib very handy.
I recommend instead -L on the command line, and export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib in the shell. More than one person (including myself) has gotten their computer into a really nasty place by not following this advice.
If you run testit (under test/), all you need is DYLD_LIBRARY_PATH in that shell. The testit script is set up to point to the right places without an install.
Also I recommend figuring out why you had to modify buildit. No one else is seeing that behavior. printenv on your command line may help in this endeavor.
libc++ is updated often. We try to keep tip-of-trunk always in a shippable state.