I've built my code on a machine with gcc 6.3 before. I'm building the same code on another machine with gcc 5.3. I tried using the working oed library from a different location. But still the error persists. I went through suggestions in other questions similar to this on Stackoverflow, but they suggest that the library must be already linked. This is not the case though.
Oed is a fortran library and the code is in C and C++.
I'm at a loss to think how to figure out this problem. Any help is welcome.
/usr/bin/ld: oed__gener_nai_batch.o: access beyond end of merged section (380)
/usr/bin/ld: oed__gener_nai_batch.o: access beyond end of merged section (586)
/usr/bin/ld: oed__gener_nai_batch.o: access beyond end of merged section (580)
/usr/bin/ld: /home/umunipala/gamess/gamess-kris-simgms/simgms/oed/liboed.a(oed__gener_nai_batch.o)(.debug_info+0x203): reloc against `.debug_str': error 2
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
Well, there are two solutions I think.
recompile the .c file with your current library settings.
export a corresponded version LD library.
The problem is basically caused by the disagreement between .o file and your gcc(compiler).
Related
I have recently started using the OpenCascade defeaturing operation and found issues compiling with gcc and link time optimization. When including "#include <BRepAlgoAPI_Defeaturing.hxx>" and using flag "-flto" I get the error:
`_ZThn80_N23BRepAlgoAPI_DefeaturingD1Ev' referenced in section `.rdata$_ZTV23BRepAlgoAPI_Defeaturing[_ZTV23BRepAlgoAPI_Defeaturing]'
of /opt/opencascade/lib/libTKBO.a(BRepAlgoAPI_Defeaturing.cxx.o):
defined in discarded section `.gnu.linkonce.t._ZN23BRepAlgoAPI_DefeaturingD1Ev[_ZThn80_N23BRepAlgoAPI_DefeaturingD1Ev]'
of obj/occt_ops.o (symbol from plugin)
collect2: error: ld returned 1 exit status
make: *** [Makefile:147: occt-test] Error 1
If I understand correctly the defeaturing symbol has been discarded, and is therefore not found. No other changes have been made and it compiles without the -flto flag, so I wonder how can I assure that the symbol will not be discarded? Or what could potentially be in the defeaturing code that causes this, as this issue has never come up before?
I'm trying out halide and want to build a small shared library on top of it. But the code generated by Halide's AOT compilation seems not being position independent. How do I link the objects generated by Halide into my shared library?
[Update] extracted a small example from my code.
Specifically I used a generator with c++:
class SimpleAddition : public Halide::Generator<SimpleAddition> {
public:
SimpleAddition() : vars(4) {}
Input<Halide::Buffer<>> lhs{"lhs"};
Input<Halide::Buffer<>> rhs{"rhs"};
Output<Halide::Buffer<>> out{"out"};
std::vector<Var> vars;
void generate() {
out(vars) = lhs(vars) + rhs(vars);
}
};
HALIDE_REGISTER_GENERATOR(SimpleAddition, simple_addition)
with helpers from CMake:
halide_library(ops SRCS ${CMAKE_CURRENT_LIST_DIR}/src/simple_addition.cc
GENERATOR_NAME simple_addition
GENERATOR_ARGS lhs.type=float32 lhs.dim=4 rhs.type=float32 rhs.dim=4 out.type=float32)
and got the following error:
/usr/bin/ld: ./genfiles/halide_rt_host/halide_rt_host.a(halide_rt_host.a.o): relocation R_X86_64_PC32 against symbol `_ZN6Halide7Runtime8Internal13custom_mallocE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
I also tried generating object by running the generator myself (without CMake wrapper) with -e o,h, and similarly with llvm bitcode followed by llc -relocation-model=pic, also Func::compile_to_object. similar error occurred when I try to link the generated object back to shared library:
/usr/bin/ld: halide_runtime_x86.o: relocation R_X86_64_PC32 against symbol `_ZN6Halide7Runtime8Internal13custom_mallocE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
I'm running this on Ubuntu 18.10. Both Halide and my code are compiled with gcc-8.2.0. LLVM/Clang-7 is the one shipped in their repository. Halide is built with simple cmake ../ && make && make install.
For compiler flags of my testing code, command used in CMake is add_libarary(mylib SHARED ...). Non-CMake build is with flags like -fPIC -shared, nothing special since I'm still learning.
Halide should be generating PIC by default (see Codegen_Internal.cpp, make_target_machine()). What architecture are you targeting? What compiler/linker are you using, with what options, etc?
I am compiling a C++ program using make, this is the error i'm getting.
/usr/bin/ld: fglut/libfglut.a(freeglut_state.o): undefined reference to symbol 'XGetWindowAttributes'
//usr/lib/i386-linux-gnu/libX11.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:55: recipe for target 'morphlines' failed
make: *** [morphlines] Error 1
I'm beginner
/usr/bin/ld: fglut/libfglut.a(freeglut_state.o):
This tells me you link libfglut statically (*.a is just an archive of object files). When you do this, you must link all dependencies as well, because with the object files from the static library actually compiled into your program, your program will depend on them.
Either link libfglut dynamically (this is the default with the GNU toolchain), so your program will depend on libfglut.so which will itself depend on libX11.so -- or add -lX11 after -lfglut on the command line of your final linking step. You might need -Wl,-Bdynamic before -lX11 to switch the linker back to dynamic linking.
If this doesn't directly solve your problem, I suggest you edit your question to include the relevant parts of the Makefile you're using.
I'm building an application that results in the following error:
hidden symbol `__popcountdi2' in /usr/lib/gcc/x86_64-redhat-linux/4.8.3/libgcc.a(_popcountsi2.o) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
This can be fixed with '-shared-libgcc' linked option, but I would like to understand the issue and what is causing it. Also it appears that others don't observe the issue, although we all run the same Linux distribution (Fedora 20), the same tools and libraries (gcc-4.8.3-7.fc20.x86_64, libgcc-4.8.3-7.fc20.x86_64 and binutils-2.23.88.0.1-13.fc20.x86_64), so I suspect there's something wrong with my platform, may be some libs are missing etc.
I would appreciate if someone could give hints to understand what is going on. Thanks.
I am trying to build CEF in Release mode but I get the following linker error:
AR(target)
/home/adminuser/temp/build/linux/Release/obj.target/libcef_dll_wrapper.a
LINK(target) /home/adminuser/temp/build/linux/Release/cefclient
/home/adminuser/temp/build/linux/Release/ldb.a(ldbJS.o): In function
LdbURLLoader::LoadURL(std::string)': ldbJS.cpp:(.text+0x34e):
undefined reference toCefURLRequest::Create(CefRefPtr,
CefRefPtr)' collect2: error: ld returned 1 exit
status make: *** [/home/adminuser/temp/build/linux/Release/cefclient]
Error 1
I don't get this problem when building the Debug version so I am not quite sure how to resolve it. I tried various #pragma directives to stop the compiler from optimizing out this method but to no avail.
* UPDATE *
When I remove the -DNDEBUG flag from CFLAGS_Release in the libcef_dll_wrapper.target.mk file it will build. I don't want to do this in the Release build without knowing what I'm doing though.
I am using gcc 4.8.2.
It turns out forcing the LD linker to reanalyze my libraries was the solution. The CEF application already had an elaborate scheme of makefiles that used the --start-group and --end-group indicators to do this, but the library I previously added was not included with them. I added it and linked my application without any more problems!