/Usr/Bin/Ld: Skipping Incompatible /Usr/Lib/Gcc/X86_64-Linux-Gnu/9/Libstdc++.A When Searching for -Lstdc++ /Usr/Bin/Ld: Cannot Find -Lstdc++

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/9/libstdc++.a when searching for -lstdc++ /usr/bin/ld: cannot find -lstdc++

You are building a 32-bit binary on a 64-bit system (because you used the -m32 flag), but have not installed 32-bit versions of the development libraries.

If you're on Ubuntu, try:

sudo apt install gcc-multilib g++-multilib libc6-dev-i386

As for your assembly file, it can't work as-is. start will be defined by the cpp file, so remove it from the asm file. Next, remove the underscore from _calcsum. When building ELF binaries, function names do not start with an underscore:

section .text
global calcsum
calcsum:

push ebp
mov ebp, esp

mov eax, [ebp+8]
mov ecx, [ebp+12]
mov edx, [ebp+16]

add eax, ecx
add eax, edx

pop ebp
ret

Build that as a 32-bit ELF object file with:

nasm -felf32 func.s -o func.o

Linking using g++ fails searching for -lstdc++

Posting for future reference, a solution I found was to install g++-multilib. I had the same incompatible problem relating to -lstdc++ on g++ version 4.6.1

On further probing: g++-multilib is a dummy package which installed g++4.6-multilib which in turn installed the appropriate libstdc++.so under the /usr/lib/gcc/x86_64-linux-gnu/4.6/32 folder.

library stdc++ is not found

As you are evidently aware you need to install the multilib support for your
gcc/g++ compiler(s) to build 32-bit binaries on your 64-bit host. However,
you have installed multilib support for g++-4.8 while, according to your
config log, you are building with gcc/g++ 5.3.1, for which you have no
multilib support.

I do not know why you might want to use 4.8, but either build with 4.8, not 5.3.1, or else install multilib support for 5.3.1
and then build with 5.3.1.

If you have both compilers installed you can specifically invoke the one you
want like:

$ gcc-4.8 ...
$ g++-5 ...

Similarly if you wish to specify a specific compiler version to a
configure script then do so like:

./configure CC=gcc-4.8 CXX=g++-4.8 ...

BTW, boomerang is not a compiler, it is decompiler.

Red Hat: using atomic compiles fine but linker can't find __atomic_store_16; what library?

There is a sample libatomic.c implementation here: https://gcc.gnu.org/wiki/Atomic/GCCMM?action=AttachFile&do=view&target=libatomic.c Its compilation produces several warnings but ultimately produces an object file.

> gcc -c -o libatomic.o libatomic.c
libatomic.c:475:1: warning: conflicting types for built-in function '__atomic_compare_exchange_1' [-Wbuiltin-declaration-mismatch]
__atomic_compare_exchange_ ## SIZE (I ## SIZE *mem, I ## SIZE *expect, I ## SIZE desired, int success, int failure) \
^
libatomic.c:524:1: note: in expansion of macro 'ATOMIC_COMPARE_EXCHANGE'
ATOMIC_COMPARE_EXCHANGE (1)
^~~~~~~~~~~~~~~~~~~~~~~
libatomic.c:475:1: warning: conflicting types for built-in function '__atomic_compare_exchange_2' [-Wbuiltin-declaration-mismatch]
__atomic_compare_exchange_ ## SIZE (I ## SIZE *mem, I ## SIZE *expect, I ## SIZE desired, int success, int failure) \
^
libatomic.c:537:1: note: in expansion of macro 'ATOMIC_COMPARE_EXCHANGE'
ATOMIC_COMPARE_EXCHANGE (2)
^~~~~~~~~~~~~~~~~~~~~~~
libatomic.c:475:1: warning: conflicting types for built-in function '__atomic_compare_exchange_4' [-Wbuiltin-declaration-mismatch]
__atomic_compare_exchange_ ## SIZE (I ## SIZE *mem, I ## SIZE *expect, I ## SIZE desired, int success, int failure) \
^
libatomic.c:551:1: note: in expansion of macro 'ATOMIC_COMPARE_EXCHANGE'
ATOMIC_COMPARE_EXCHANGE (4)
^~~~~~~~~~~~~~~~~~~~~~~
libatomic.c:475:1: warning: conflicting types for built-in function '__atomic_compare_exchange_8' [-Wbuiltin-declaration-mismatch]
__atomic_compare_exchange_ ## SIZE (I ## SIZE *mem, I ## SIZE *expect, I ## SIZE desired, int success, int failure) \
^
libatomic.c:565:1: note: in expansion of macro 'ATOMIC_COMPARE_EXCHANGE'
ATOMIC_COMPARE_EXCHANGE (8)
^~~~~~~~~~~~~~~~~~~~~~~
libatomic.c:475:1: warning: conflicting types for built-in function '__atomic_compare_exchange_16' [-Wbuiltin-declaration-mismatch]
__atomic_compare_exchange_ ## SIZE (I ## SIZE *mem, I ## SIZE *expect, I ## SIZE desired, int success, int failure) \
^
libatomic.c:579:1: note: in expansion of macro 'ATOMIC_COMPARE_EXCHANGE'
ATOMIC_COMPARE_EXCHANGE (16)
^~~~~~~~~~~~~~~~~~~~~~~
> ar rcs libatomic.a libatomic.o

> g++ Foo.cxx -g -o Foo-pthread -L. -latomic

Linking success: binary is created without error. My application is too partially-written to judge whether it actually works though.

Even if this works, it's pretty clearly "not what you're supposed to have to do to get it to work." So I'm not marking this as "the" answer, just leaving it for future reference.

Android NDK linking V8 static library: cannot find symbols, but they are there

I finally fixed it, with help of a friend. First I tried a workaround where I tried to link V8 as a shared library, which didn't turn out well because the NDK native activity interface I'm using turned out to be incompatible with loading additional shared objects.

There were two different issues going on with my static libraries. The first and most important one is that the static libraries built by V8 are not suitable for linking. You can check this by using:

ar x [static_library.a]

which will normally extract the *.o objects from the library. In this case, it reported:

`x' cannot be used on thin archives

A thin archive is just a set of references to the absolute paths of the *.o files, and no actual content. That explains why my build stopped working at one point where I moved or deleted the original *.o files from the V8 build tree. Strangely, the linker kept silent about that.

Creating static libraries is not currently a build option in V8. Thankfully, this guy has a patch for creating proper static libraries in V8.

The app still didn't link after I did that, because I copied the wrong files the first time round. As it turned out, the static libraries are also built for the host architecture (don't ask me why), and I accidentally copied those. I learned that you can use:

file objectfile.o

to see what architecture it is. Hence I found my static libraries were i386 and not arm. So, the linker was skipping these files, because the architecture didn't match (you can mix architectures in a static library).

Here is the V8 patch that I made to V8 3.27.28 based on the patch by Curu Wong. I will try to get this patch committed. Patch 1:

~/Work/javascript/Engines/v8-trunk/tools/gyp$ diff -u v8.gyp.orig  v8.gyp
--- v8.gyp.orig 2014-06-18 21:09:59.368336736 +0200
+++ v8.gyp 2014-06-18 21:12:20.264331660 +0200
@@ -108,6 +108,7 @@
{
'target_name': 'v8_snapshot',
'type': 'static_library',
+ 'standalone_static_library': 1,
'conditions': [
['want_separate_host_toolset==1', {
'toolsets': ['host', 'target'],
@@ -180,6 +181,7 @@
{
'target_name': 'v8_nosnapshot',
'type': 'static_library',
+ 'standalone_static_library': 1,
'dependencies': [
'v8_base',
],
@@ -237,6 +239,7 @@
{
'target_name': 'v8_base',
'type': 'static_library',
+ 'standalone_static_library': 1,
'dependencies': [
'v8_libbase.<(v8_target_arch)',
],

Patch 2:

~/Work/javascript/Engines/v8-trunk/third_party/icu$ diff -u icu.gyp.orig icu.gyp
--- icu.gyp.orig 2014-06-18 21:10:22.060335920 +0200
+++ icu.gyp 2014-06-18 21:15:06.468325674 +0200
@@ -56,6 +56,7 @@
{
'target_name': 'icudata',
'type': 'static_library',
+ 'standalone_static_library': 1,
'defines': [
'U_HIDE_DATA_SYMBOL',
],
@@ -141,6 +142,11 @@
{
'target_name': 'icui18n',
'type': '<(component)',
+ 'conditions': [
+ [ 'component!="shared_library"', {
+ 'standalone_static_library': 1,
+ }],
+ ],
'sources': [
'<@(icui18n_sources)',
],
@@ -241,6 +247,11 @@
{
'target_name': 'icuuc',
'type': '<(component)',
+ 'conditions': [
+ [ 'component!="shared_library"', {
+ 'standalone_static_library': 1,
+ }],
+ ],
'sources': [
'<@(icuuc_sources)',
],


Related Topics



Leave a reply



Submit