I get this error at the linker stage when compiling the webkit-1.1.5 package on my Ubuntu 9.04 box:
libtool: link: gcc -ansi -fno-strict-aliasing -O2 -Wall -W -Wcast-align -Wchar-subscripts -Wreturn-type -Wformat -Wformat-security -Wno-format-y2k -Wundef -Wmissing-format-attribute -Wpointer-arith -Wwrite-strings -Wno-unused-parameter -Wno-parentheses -fno-exceptions -fvisibility=hidden -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -O2 -o Programs/.libs/GtkLauncher WebKitTools/GtkLauncher/Programs_GtkLauncher-main.o -pthread ./.libs/libwebkit-1.0.so /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libpangoft2-1.0.so /usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangocairo-1.0.so /usr/lib/libgio-2.0.so /usr/lib/libcairo.so /usr/lib/libpango-1.0.so /usr/lib/libfreetype.so -lfontconfig /usr/lib/libgmodule-2.0.so /usr/lib/libgobject-2.0.so /usr/lib/libgthread-2.0.so -lrt /usr/lib/libglib-2.0.so -pthread
make[1]: Leaving directory `/home/nagul/build_area/webkit-1.1.5'
WebKitTools/DumpRenderTree/gtk/TestNetscapePlugin/TestNetscapePlugin.cpp: In function ‘NPError webkit_test_plugin_get_value(NPP_t*, NPPVariable, void*)’:
WebKitTools/DumpRenderTree/gtk/TestNetscapePlugin/TestNetscapePlugin.cpp:221: warning: deprecated conversion from string constant to ‘char*’
WebKitTools/DumpRenderTree/gtk/TestNetscapePlugin/TestNetscapePlugin.cpp:224: warning: deprecated conversion from string constant to ‘char*’
WebKitTools/DumpRenderTree/gtk/TestNetscapePlugin/TestNetscapePlugin.cpp: In function ‘char* NP_GetMIMEDescription()’:
WebKitTools/DumpRenderTree/gtk/TestNetscapePlugin/TestNetscapePlugin.cpp:260: warning: deprecated conversion from string constant to ‘char*’
/usr/bin/ld: Programs/.libs/GtkLauncher: hidden symbol `__stack_chk_fail_local' in /usr/lib/libc_nonshared.a(stack_chk_fail_local.oS) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[1]: *** [Programs/GtkLauncher] Error 1
make: *** [all] Error 2
I'd like some pointers on how to attack this problem, either by looking into the "hidden sybmol" error or by helping me understand what the "Nonrepresentable section on output" message from the linker actually means.
I have already checked that this is consistent behaviour that persists across a make clean;make invocation.
I've received the "nonrepresentable section on output" error when crosscompiling for ARM and some of the libraries was not correctly compiled with -fPIC.
Pretty sure that's not the error here though...
My answer is specific to the combination of the hidden symbol (...) is referenced by DSO and Nonrepresentable section on output errors.
The short answer is: a symbol was marked extern but also marked hidden (see Visibility (GCC wiki) and How To Write Shared Libraries (Ulrich Drepper)). No objects or archives were linked in to satisfy the dependency, but a shared object was linked in with a matching symbol.
You probably compiled with -fvisibility=hidden, and whether it was a compiler-added feature (like stack protector) or something else entirely, the symbol emitted in your code overrode the default visibility of an undefined symbol reference of the same name in libc_nonshared.a that would normally be satisfied by libc.so.
You can reproduce a similar problem like this:
#include <stdio.h>
extern __attribute__((visibility ("hidden")))
FILE* open_memstream( char**, size_t* );
char* asdf;
size_t mysize;
FILE* blah() {
return open_memstream( &asdf, &mysize );
}
... then compiling it:
# with gcc 4.9.2:
~ gcc badcode.c -shared -fPIC -o libbad.so -lc
/tmp/ccC0uG80.o: In function `blah':
badcode.c:(.text+0x19): undefined reference to `open_memstream'
/usr/bin/ld: /tmp/libbad.so: hidden symbol `open_memstream' isn't defined
/usr/bin/ld: final link failed: Bad value
# with gcc 4.4.7:
~ gcc badcode.c -shared -fPIC -o libbad.so -lc
/tmp/cc2SHUFD.o: In function `blah':
badcode.c:(.text+0x26): undefined reference to `open_memstream'
/usr/bin/ld: /tmp/libbad.so: hidden symbol `open_memstream' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
# with oracle solaris studio (still in Linux) 12.3:
~ cc -shared -Kpic -o /tmp/libbad.so badcode.c -lc
badcode.o: In function `blah':
badcode.c:(.text+0x32): undefined reference to `open_memstream'
/usr/bin/ld: /tmp/libbad.so: hidden symbol `open_memstream' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
In short: I've forward declared the existence of a symbol, marked it hidden, then didn't link in a static library or object file that satisfied the dependency. Since it's marked hidden, the dependency must be satisfied, otherwise it's an invalid ELF object.
In my specific case, a header was going down the wrong #if path and causing the above hidden declaration of open_memstream.
Please try removing the -fvisibility=hidden option from the commandline. It will produce a larger object (with some unnecessary symbols, which won't matter in the end because it is an execultable), but should eliminate the problem. This is not a solution; rather a workaround. Please check (this is just a hunch) if there are no libc version mismatches between libraries and GtkLauncher.o
Related
I'm having difficulty linking my STM32 project using CMake. The link command that is generated is:
/Users/jeremy/gcc-arm-none-eabi-6-2017-q2-update/bin/arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -fdata-sections -ffunction-sections -g -Og -gdwarf-2 -MMD -MP -std=c++11 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -specs=nano.specs -T/Users/jeremy/stm32l432kc_freertos_template/STM32L432KCUx_FLASH.ld -Wl,-Map=target.map,--cref -Wl,--gc-sections
< ... lots of .o files here ...>
-o stm32l432kc_freertos -lc -lm -lnosys
Unfortunately I get two sets of errors. The first is:
arm-none-eabi/bin/ld: warning: cannot find entry symbol arch_paths_first; defaulting to 0000000008000190
which indicates that there is no entry symbol, but in the LD file the first line of code is: ENTRY(Reset_Handler). The symbol Reset_Handler is defined in a linked file startup_stm32l432xx.s.
The second set of errors relate to the stdlib:
/Users/jeremy/gcc-arm-none-eabi-6-2017-q2-update/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libg_nano.a(lib_a-signalr.o): In function `_kill_r':
signalr.c:(.text._kill_r+0xe): undefined reference to `_kill'
/Users/jeremy/gcc-arm-none-eabi-6-2017-q2-update/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libg_nano.a(lib_a-signalr.o): In function `_getpid_r':
signalr.c:(.text._getpid_r+0x0): undefined reference to `_getpid'
Which are supposed to be solved by linking -lnosys, but the linker appears to be ignoring that.
Essentially, the linker appears to be ignoring some of the directives in the LD file and ignoring some of the flags I have passed. I realise it is probably something I am doing wrong, but I can't see what it is.
If I add -specs=nosys.specs the latter two errors go away, but this shouldn't be necessary? Can someone please help me understand what is going wrong here?
Looks like CMake on OSX is adding the -Wl,-search_paths_first which is unsupported for the gcc arm toolchain. Fix is to add this to the CMakelists.txt file:
if ( APPLE )
string ( REPLACE "-Wl,-search_paths_first" "" CMAKE_C_LINK_FLAGS ${CMAKE_C_LINK_FLAGS} )
string ( REPLACE "-Wl,-search_paths_first" "" CMAKE_CXX_LINK_FLAGS ${CMAKE_CXX_LINK_FLAGS} )
endif ()
Fix is taken from here: https://github.com/kiibohd/controller/blob/master/Lib/CMake/build.cmake
Still have no idea about the -lnosys being ignored though.
I am compiling some files on the odroidC2 board (armv8-64bit) running Ubuntu 16.04.1, and I got the following error:
odroid#odroid64:~/flext-master/tutorial/simple1$ g++ -fPIC -L/usr/lib -pthread -shared -Wl,-S -L/usr/local/src/pd/bin -L/usr/local/lib -o pd-linux/release-single/simple1.pd_linux pd-linux/release-single/main.opp -lflext-pd_s
/usr/bin/ld: /usr/local/lib/libflext-pd_s.a(libflext_pd_s_la-flxlet.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against external symbol `__stack_chk_guard##GLIBC_2.17' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libflext-pd_s.a(libflext_pd_s_la-flxlet.o)(.text+0x344): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `__stack_chk_guard##GLIBC_2.17'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
As you can see the -fPIC option is present. So I don't understand why the compiler suggest to "recompile with -fPIC". Any Idea?
The problem is not in the pd-linux/release-single/main.opp (BTW, maybe .cpp?) that you're compiling with -fPIC, but in the libflext-pd_s.a archive that contains an object libflext_pd_s_la-flxlet.o which is not compiled with -fPIC, so you need to recompile flext library properly.
I know this question has been asked a few times, but none of the solutions have worked for me. I have a statically linked library that I would like to use with a JNI layer with versions pre Java 8. Based on my reading of "how to link static library into dynamic library in gcc", it seems possible. Here is my command line:
/usr/bin/g++ -shared -std=c++0x -D__extern_always_inline=inline -Wall -pedantic -O3 -fomit-frame-pointer -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -DNDEBUG -fPIC -Wl,--whole-archive target/vw_jni.a -o target/vw_jni.lib
This is based on writing a JNI layer to the Vowpal Wabbit library.
At this point in the build process I have statically created a file called target/vw_jni.a through static linking
target/vw_jni.a: In function `_fini':
(.fini+0x0): multiple definition of `_fini'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o:(.fini+0x0): first defined here
target/vw_jni.a: In function `data_start':
(.data+0x8): multiple definition of `__dso_handle'
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtbeginS.o:(.data.rel.local+0x0): first defined here
target/vw_jni.a: In function `_init':
(.init+0x0): multiple definition of `_init'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o:(.init+0x0): first defined here
/usr/lib/x86_64-linux-gnu/libc_nonshared.a(elf-init.oS): In function `__libc_csu_init':
(.text+0x0): multiple definition of `__libc_csu_init'
target/vw_jni.a:(.text+0x1cea20): first defined here
/usr/lib/x86_64-linux-gnu/libc_nonshared.a(elf-init.oS): In function `__libc_csu_fini':
(.text+0x70): multiple definition of `__libc_csu_fini'
target/vw_jni.a:(.text+0x1ceab0): first defined here
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtendS.o:(.tm_clone_table+0x0): multiple definition of `__TMC_END__'
target/vw_jni.a:(.data+0x2630): first defined here
/usr/bin/ld: target/vw_jni.a: .preinit_array section is not allowed in DSO
/usr/bin/ld: failed to set dynamic section sizes: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
I'm not sure what this means and when I search around for it find results such as "C program no longer compiles in Ubuntu" that seem to suggest that I forgot a -o flag, but I know I have not.
Is what I'm trying to do possible?
What am I doing wrong?
I'm doing this on a Docker instance obtained through docker pull ubuntu:14.04
UPDATE:
I'm able to get rid of a few of the errors with the following command line
/usr/bin/g++ -shared -std=c++0x -D__extern_always_inline=inline -Wall -pedantic -O3 -fomit-frame-pointer -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -DNDEBUG -fPIC -nostdlib -Wl,--whole-archive target/vw_jni.a -o target/vw_jni.lib
This generates the following output
/usr/bin/ld: warning: Cannot create .note.gnu.build-id section, --build-id ignored.
/usr/bin/ld: target/vw_jni.a: .preinit_array section is not allowed in DSO
/usr/bin/ld: failed to set dynamic section sizes: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
The reason I think this works is that by excluding the standard lib I don't have the redefinitions. I'm not sure where to go from here though.
I think the problem here is with the command line you're using. The flags --whole-archive and --no-whole-archive apply to all subsequent arguments on the command line, which includes a number of standard libraries and object files (e.g., -lc, crt0.o, libc_nonshared.a, etc.) that are automatically appended behind the scenes.
If there's no --no-whole-archive switch directly after the filenames of static libraries you intend to bring in, this will also apply --whole-archive to the built-in archives that come after your last argument, e.g., it will try to also bring in every object from libc.a, libm.a, etc. which will at the very least fail with a "multiple definition" error. Try adding --no-whole-archive switch to your command line directly after target/vw_jni.a so you end up with something like:
/usr/bin/g++ -shared -std=c++0x -D__extern_always_inline=inline -Wall -pedantic -O3 \
-fomit-frame-pointer -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -DNDEBUG -fPIC \
-Wl,--whole-archive target/vw_jni.a -Wl,--no-whole-archive \
-o target/vw_jni.lib
This is practically not wise, because if you put the object files extracted from some static library these object files still remain position dependent code.
Shared libraries should very preferably contain position independent code (because the dynamic linker ld-linux.so is mmap-ing segments inside the .so at some random address, e.g. because of ASLR), otherwise the dynamic linker would have to process a big lot of relocations (so dynamic linking becomes very inefficient).
So even if you succeed to convert your static library into a shared one, it won't be wise to do so.
So keep your static library as is, or recompile their source code with -fPIC to build a shared object.
I'm trying to build a library that makes use of boost, and while the library compiles OK, it's hitting a weird linker error that I don't understand. I built and installed Boost 1.54 (also tried 1.52), which went fine.
It claims to not be able to find __assert_fail, which I think is part of the standard library. I tried to build everything in 64-bit. I'm on Fedora 16, using gcc 4.6.3
Any ideas?
make all-am
make[1]: Entering directory `/data/adrian/code/ext/mapper/cmappertools'
/bin/sh ./libtool --tag=CXX --mode=link g++ -g -O2 -o libcmappertools.la -rpath /usr/local/lib/python2.7/site-packages cmappertools.lo
libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.6.3/crtbeginS.o .libs/cmappertools.o -L/usr/lib/gcc/x86_64-redhat-linux/4.6.3 -L/usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.6.3/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../lib64/crtn.o -O2 -Wl,-soname -Wl,libcmappertools.so.0 -o .libs/libcmappertools.so.0.0.0
.libs/cmappertools.o: In function `condition_variable':
/usr/local/include/boost/thread/pthread/condition_variable_fwd.hpp:69: undefined reference to `__assert_fail'
/usr/local/include/boost/thread/pthread/condition_variable_fwd.hpp:69: undefined reference to `__assert_fail'
.libs/cmappertools.o: In function `~mutex':
/usr/local/include/boost/thread/pthread/mutex.hpp:108: undefined reference to `__assert_fail'
.libs/cmappertools.o: In function `condition_variable':
/usr/local/include/boost/thread/pthread/condition_variable_fwd.hpp:69: undefined reference to `__assert_fail'
.libs/cmappertools.o: In function `~mutex':
/usr/local/include/boost/thread/pthread/mutex.hpp:108: undefined reference to `__assert_fail'
.libs/cmappertools.o:/usr/local/include/boost/smart_ptr/shared_array.hpp:194: more undefined references to `__assert_fail' follow
/usr/local/bin/ld: .libs/libcmappertools.so.0.0.0: hidden symbol `__assert_fail' isn't defined
/usr/local/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[1]: *** [libcmappertools.la] Error 1
make[1]: Leaving directory `/data/adrian/code/ext/mapper/cmappertools'
make: *** [all] Error 2
several years later, on different Fedora (29), later version of boost, gcc, etc.etc. I ran into the same problem.
Led more by intuition than understanding I got rid of gcc visibility pragmas
(i.e. I commented out all the:
#pragma GCC visibility push({whatever})
...
#pragma GCC visibility pop)
and that did the trick - it compiled, linked and run successfully.
As Tarni mentioned,
hidden symbol `__assert_fail' isn't defined
is indeed caused by #pragma GCC visibility push(hidden)
However, if you absolutely need to hide some function that calls assert macro, you should include before hiding any symbols, e.g.
// Wrong place to hide
// #pragma GCC visibility push(hidden)
#include <assert.h>
// Right place to hide
#pragma GCC visibility push(hidden)
void fatal_debug(int foo, int bar){
assert(foo == bar);
}
#pragma GCC visibility pop
I have to implement the machine translation system hence I am planning use moses but I facing following error while executing make command on Cygwin:
Administrator#diebold-69b7050 /cygdrive/c/JT/NewSetup/Moses/moses-2010-08-13/moses/scripts/training/memscore$ make
make all-am
make[1]: Entering directory `/cygdrive/c/JT/NewSetup/Moses/moses-2010-08-13/moses
scripts/training/memscore'
g++ -I/usr/include -Wall -ffast-math -ftrapping-math -fomit-frame-pointer -g -O2 -o memscore.exe phrasetable.o memscore.o scorer.o lexdecom.o -lz -lm
phrasetable.o: In function `_ZlsRSoRK15PhraseAlignment':
/cygdrive/c/JT/NewSetup/Moses/moses-2010-08-13/moses/scripts/training/memscore/phrasetable.cpp:111: undefined reference to `boost::system::system_category()'
phrasetable.o: In function `__tcf_0':
/cygdrive/c/JT/NewSetup/Moses/moses-2010-08-13/moses/scripts/training/memscore/datastorage.h:31: undefined reference to `boost::system::system_category()'
phrasetable.o: In function `_ZN14PhrasePairInfo12realloc_dataEj':
/usr/include/boost/pool/simple_segregated_storage.hpp:97: undefined reference to `boost::system::system_category()'
phrasetable.o: In function `_ZNK14PhrasePairInfo14get_alignmentsEv':
Please don't give me suggestion like linker error because I am completely fad up of trying linker option.
I think, I have some Cygwin->Boot library problem. Can you suggest me where I am wrong?
You are mssing -lboost_system on your compilation commands.
Some of the boost libraries are header only. Others need to be compiled. And the libraries sometimes depend on each other. In this case you are using some boost library which needs -lboost_system. Add it so that it gets linked with your project.
and it should be on this line. Where linking is done
g++ -I/usr/include -Wall -ffast-math -ftrapping-math -fomit-frame-pointer -g -O2 -o memscore.exe phrasetable.o memscore.o scorer.o lexdecom.o **-lboost_system** -lz -lm