Solved -Wl,-rpath=/usr/local/lib/gcc9

gh_origin

Member

Reaction score: 22
Messages: 97

I compared two binary compiled by gcc I installed from pkg, the only different between them is libgcc_s.so.1:

Code:
ldd gntest
gntest:
    libstdc++.so.6 => /usr/local/lib/gcc9/libstdc++.so.6 (0x800823000)
    libm.so.5 => /lib/libm.so.5 (0x800c15000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800e45000)
    libc.so.7 => /lib/libc.so.7 (0x80105d000)
Code:
ldd gwtest
gwtest:
    libstdc++.so.6 => /usr/local/lib/gcc9/libstdc++.so.6 (0x800824000)
    libm.so.5 => /lib/libm.so.5 (0x800c16000)
    libgcc_s.so.1 => /usr/local/lib/gcc9/libgcc_s.so.1 (0x800e46000)
    libc.so.7 => /lib/libc.so.7 (0x80105d000)
So is it OK to just link with the system libgcc_s.so.1 or I have to link with the libgcc_s.so.1 shipped with gcc? Please let me know. Thanks.
 

mark_j

Well-Known Member

Reaction score: 172
Messages: 445

No, they're the same version just another location. In netbsd for example, we use compat_freebsd which basically does this.
 
OP
G

gh_origin

Member

Reaction score: 22
Messages: 97

No, they're the same version just another location. In netbsd for example, we use compat_freebsd which basically does this.
NetBSD uses GCC as system compiler so it's nothing surprise to know that it's the same version just another location. FreeBSD, on the other hand, users Clang as system compiler. I found this page: https://wiki.freebsd.org/GPLinBase

According to this, they are not the same thing. So incompatibility could arise.
 

mark_j

Well-Known Member

Reaction score: 172
Messages: 445

? They both expose the same symbols for the libraries, so what's the incompatibility you're wondering about? They're the same version.

Does GCC somehow compile totally different ABI to CLANG? In that case, the two would be totally incompatible and so would everything compiled/linked with gcc toolchain compared to clang's.

I'm not sure what the issue is? Enlighten me? (Or wake me up, perhaps I'm too tired... :oops:)
 
OP
G

gh_origin

Member

Reaction score: 22
Messages: 97

? They both expose the same symbols for the libraries, so what's the incompatibility you're wondering about? They're the same version.

Does GCC somehow compile totally different ABI to CLANG? In that case, the two would be totally incompatible and so would everything compiled/linked with gcc toolchain compared to clang's.

I'm not sure what the issue is? Enlighten me? (Or wake me up, perhaps I'm too tired... :oops:)
I'm a bit too careful. The binary compiled by gcc but linked with the system libgcc_s.so.1 run without problems. So at least they are partially compatible. I just wonder if this practice is recommended or not. It's the only problem through out this thread.

With different version of GCC, each of them have their own libgcc_s.so.1 and libstdc++.so.6. So it's natural to assume that there is incompatibility between them, let alone a version not developed by GCC.

BTW, I would say the version of libgcc_s.so.1 in the base system is compatible with the GCC's version or at most a drop-in replacement of it. They can't be the same version! They can only be the same version if their checksum is the same!
 

mark_j

Well-Known Member

Reaction score: 172
Messages: 445

Confusion reigns supreme... :)

Perhaps I shouldn't have said they're the same version but rather that they produce the same result. Sorry. My bad. They produce the same ABI; the same version of ABI if you like.

Ok, I am not sure of your programs, but here's the operation in a nutshell. The main libraries for your programs are libc and libm. Do they match? If yes, you have no problem. Use the system one, ie, drop the rpath.

The libgcc_s.so is internal to the compiler. It provides intrinsics, does various math operations where the host processor can't handle it and the actual machine code patterns for the cpu you're running off. CLANG produces the same as GCC, they're ABI compatible. They have to be, otherwise the kernel would have to run in compat mode for the other ABI.

Clang has compiler-rt, but still uses libgcc because, well, they're too lazy to reinvent the wheel (perhaps?)

Clear as mud?
 
OP
G

gh_origin

Member

Reaction score: 22
Messages: 97

Confusion reigns supreme... :)

Perhaps I shouldn't have said they're the same version but rather that they produce the same result. Sorry. My bad. They produce the same ABI; the same version of ABI if you like.

Ok, I am not sure of your programs, but here's the operation in a nutshell. The main libraries for your programs are libc and libm. Do they match? If yes, you have no problem. Use the system one, ie, drop the rpath.

The libgcc_s.so is internal to the compiler. It provides intrinsics, does various math operations where the host processor can't handle it and the actual machine code patterns for the cpu you're running off. CLANG produces the same as GCC, they're ABI compatible. They have to be, otherwise the kernel would have to run in compat mode for the other ABI.

Clang has compiler-rt, but still uses libgcc because, well, they're too lazy to reinvent the wheel (perhaps?)

Clear as mud?
Thank you. I understand. But I would rather pass LDFLAGS="-rpath /usr/local/lib/gcc9" to each of the software I build with GCC, to be sure.
 
Top