I'm trying to compile my application on AIX. It builds fine on Linux, Solaris x86 and Windows but this is the first time we've tried to build on AIX.
I've managed to get to the point of linking all of the libraries together and I get the error message:
Linking...
ld: 0711-101 FATAL ERROR: Allocation of 96864 bytes failed
in routine get_RLDs. There is not enough memory available.
Please check your ulimit or paging space
or use local problem reporting procedures.
collect2: ld returned 12 exit status
I've increased the page space by 1GB - no difference
I've increased the ulimit values - no difference
I've tried passing in the maxdata flag to the linker - no difference
Is there anything else I should be trying?
I'm not sure how to identify which library is causing the problem. We're trying to link statically against boost_date_time, xerces-c and libz and against 50 internal libraries. I can't change to dynamic linking and I can't change much about the structure of the system so I'm looking for ideas of configuration or parameters to try for ld.
The problem turned out to be the ulimit on the data seg size. Apparently that was still set quite small. Making it bigger like:
ulimit -d 1048575
allows the linker to get further.
Now to just figure out what I do about all of these undefined symbols.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 28 days ago.
Improve this question
I am compiling LLVM and Clang from source but getting the following error when it tries to link lib/libclang-cpp.so.14git:-
/usr/bin/ld.gold: internal error in open, at ../../gold/descriptors.cc:99
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
I am using Gold Linker and my GCC version is 9.3.0. The LLVM branch is that of LLVM-12 (llvmorg-12.0.0). Earlier I was using LLD linker but that was causing memory overflow, after switching to Gold memory does not overflow but it still fails.
System specs:-
16GB RAM
512GB NVMe SSD
i7 10th Gen 8-cores
Also my swap size is 4GB. I have tried using lesser cores too, but the error still persists.
Any help would be appreciated. Thanks.
P.S:- I am an absolute noob when it comes to LLVM.strong text
I finally figured this out. I was getting the same error, but building a different project.
Turns out that gold is bad at reporting errors. The actual issue is that the OS is running out of file descriptors. In my case it was set to 1024 (you can check with ulimit -n) but a large linking job needed more than that.
If you bump the number of file descriptors then gold works just fine.
# I choose 65536, you can change this number
ulimit -n 65536
Why do I say gold is bad at reporting errors? Because if you force it to run on multithreaded mode (it defaults to single threaded) then it properly reports:
/usr/bin/ld.gold: fatal error: out of file descriptors and couldn't close any
Which is a more useful message.
I’m trying to call into a bulky C++ library from OCaml, and I’m having trouble with ocamlopt, which sitently fails with error code 2.
I’m doing the whole dance with putting up a C interface, and I can get it to work in general, but as soon as I reference this library, build breaks.
Is there some way to know what exactly is failing? I tried the -verbose flag, but it just prints the commandline arguments (which are quite long).
Would you have any tips as to how to investigate a silent failure like this?
TL;DR; check that you have enough memory and/or disk space.
Something like this could happen when ocamlopt is either killed by a signal or runs out the memory (or both), check the dmesg output, look for OOM messages from the kernel, also use htop to get the idea on the memory footprint.
Also, since this happens when you're trying to link with the C++ library, it is most likey that it is the ld process which is failing (again, most likely with OOM), as ocamlopt uses the system linker.
In case anyone else runs into this again: the problem was that there were too many -ccopt and -cclib arguments getting passed in by the build driver. When I started including a C++ library with lots of other dependencies, we seemed to have reached the breaking point.
The solution was to change the build driver's OCaml compiler and linker rules to write all the compiler and linker args into files so they could all be passed in as a single -ccopt #<compiler.args> or -cclib #<linker.args> argument. Both gcc and ld support the #file command line option.
GitHub issue: ocamlopt lets the compiler/linker silently fail if too many -ccopt or -cclib arguments are passed in
When we try to compile our C++ iOS game app with these two profilers in Xcode, we're getting the following linker error.
Ditto /Users/Max/Library/Developer/Xcode/DerivedData/TowerDuel-dsejjkbvgengpngaqrfokeoaquvx/Build/Products/Debug-iphoneos/TowerDuel-mobile.app/Frameworks/libclang_rt.asan_ios_dynamic.dylib /Users/Max/Documents/XcodeWorkspace/TowerDuelWorkspace/TowerDuel/lib/clang/8.1.0/lib/darwin/libclang_rt.asan_ios_dynamic.dylib
cd /Users/Max/Documents/XcodeWorkspace/TowerDuelWorkspace/TowerDuel/proj.ios_mac
export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/usr/bin/ditto -rsrc /Users/Max/Documents/XcodeWorkspace/TowerDuelWorkspace/TowerDuel/lib/clang/8.1.0/lib/darwin/libclang_rt.asan_ios_dynamic.dylib /Users/Max/Library/Developer/Xcode/DerivedData/TowerDuel-dsejjkbvgengpngaqrfokeoaquvx/Build/Products/Debug-iphoneos/TowerDuel-mobile.app/Frameworks/libclang_rt.asan_ios_dynamic.dylib
ditto: can't get real path for source '/Users/Max/Documents/XcodeWorkspace/TowerDuelWorkspace/TowerDuel/lib/clang/8.1.0/lib/darwin/libclang_rt.asan_ios_dynamic.dylib'
Command /usr/bin/ditto failed with exit code 1
It seems like it's trying to use some iOS 8.1 library, even though our deployment target is iOS 9.
How can we fix this?
EDIT: Just to clarify, the issue also happens when only using ONE of these at the same time.
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.
I have a multi-process program run on MIPS CPU with uclibc and it is compiled with gcc 4.5.3.
One of the process(it is name "tv") require to linked with one shared library(libtest.so) which is also written by me. The "tv" process is written in C++ and libtest.so is in C.
I have also dump the elf header from libtest.so, it has both PIC and CPIC flag set, so I think the creation of the library is OK.
When I try to run the program, all the processes starts fine except the "tv" process. There is no error message. When I use ps to check it's status, it has become a zombie process.
I have tried the following
If I remove the libtest.so from linking process, and remove any reference to the libtest.so, the "tv" process can run without any issue.
If I remove any reference to the libtest.so BUT keep the libtest.so in the linking process, the "tv" process still does not run.
I have tried to use LD_DEBUG=all to debug, but it does not work in my board as there is no valid output.
So I am guess there is something went wrong when ld try to load the libtest.so when "tv" process is starting. But I don't know how to debug? How should I find out if the which part of libtest.so is causing the problem?
Any suggestion is welcome. Thanks in advance.
Make sure this isn't related to missing out on the extern C declaration for your API which are to be invoked as C functions.
You have error in load process. So write simplest application which loads your library and unloads it immediatelly and debug it.