Solved ld-elf.so.1 reports missing shared object library but the file exists

byrnejb

byrnejb

I have this program working on FreeBSD-12.3 running on metal.
Code: 
freebsd-version
12.3-RELEASE-p2

Code: 
[root@vhost01 ~ (master)]# !ldd
ldd /usr/local/bin/gpcl6 | sort
    libICE.so.6 => /usr/local/lib/libICE.so.6 (0x801c46000)
    libSM.so.6 => /usr/local/lib/libSM.so.6 (0x801c3c000)
. . .
    libstdc++.so.6 => /usr/local/lib/gcc10/libstdc++.so.6 (0x80201a000)
. . .

[root@vhost01 ~ (master)]# ls -l /usr/local/lib/gcc10/libstdc++.so.6
lrwxr-xr-x  1 root  wheel  19 Nov 23 01:14 /usr/local/lib/gcc10/libstdc++.so.6 -> libstdc++.so.6.0.28

[root@vhost01 ~ (master)]# ls -l /usr/local/lib/gcc10/libstdc++.so.6.0.28
-rwxr-xr-x  1 root  wheel  1977216 Nov 23 01:14 /usr/local/lib/gcc10/libstdc++.so.6.0.28

However, on another system running FreeBSD-12.3p2 in a Jail

Code: 
[root@sshpipe-2 ~]# freebsd-version
12.3-RELEASE-p2

The same binary reports a missing library:
Code: 
g[root@sshpipe-2 ~]# lpcl6 -h
ld-elf.so.1: Shared object "libstdc++.so.6" not found, required by "gpcl6"

ldd reports this:
Code: 
[root@sshpipe-2 ~]# ldd /usr/local/bin/gpcl6 | sort
    libICE.so.6 => /usr/local/lib/libICE.so.6 (0x801c46000)
    libSM.so.6 => /usr/local/lib/libSM.so.6 (0x801c3c000)
. . .
    libstdc++.so.6 => not found (0)
. . .
[/CODE}

But, as far as I can tell, that library is present in the same location as that on the first system.
[CODE]
ls -l /usr/local/lib/gcc10/libstdc++.so.6
lrwxr-xr-x  1 root  wheel  19 Feb 18 17:24 /usr/local/lib/gcc10/libstdc++.so.6 -> libstdc++.so.6.0.28

[root@sshpipe-2 ~]# ls -l /usr/local/lib/gcc10/libstdc++.so.6.0.28
-rwxr-xr-x  1 root  wheel  1977216 Feb 18 17:16 /usr/local/lib/gcc10/libstdc++.so.6.0.28
Any ideas of what I have tripped over? Is this somehow related to the second host being in a Jail?
 
libstdc++.so.6
byrnejb said:
I have this program working on FreeBSD-12.3 running on metal.
Code: 
freebsd-version
12.3-RELEASE-p2

Code: 
[root@vhost01 ~ (master)]# !ldd
ldd /usr/local/bin/gpcl6 | sort
    libICE.so.6 => /usr/local/lib/libICE.so.6 (0x801c46000)
    libSM.so.6 => /usr/local/lib/libSM.so.6 (0x801c3c000)
. . .
    libstdc++.so.6 => /usr/local/lib/gcc10/libstdc++.so.6 (0x80201a000)
. . .

[root@vhost01 ~ (master)]# ls -l /usr/local/lib/gcc10/libstdc++.so.6
lrwxr-xr-x  1 root  wheel  19 Nov 23 01:14 /usr/local/lib/gcc10/libstdc++.so.6 -> libstdc++.so.6.0.28

[root@vhost01 ~ (master)]# ls -l /usr/local/lib/gcc10/libstdc++.so.6.0.28
-rwxr-xr-x  1 root  wheel  1977216 Nov 23 01:14 /usr/local/lib/gcc10/libstdc++.so.6.0.28

However, on another system running FreeBSD-12.3p2 in a Jail

Code: 
[root@sshpipe-2 ~]# freebsd-version
12.3-RELEASE-p2

The same binary reports a missing library:
Code: 
g[root@sshpipe-2 ~]# lpcl6 -h
ld-elf.so.1: Shared object "libstdc++.so.6" not found, required by "gpcl6"

ldd reports this:
Code: 
[root@sshpipe-2 ~]# ldd /usr/local/bin/gpcl6 | sort
    libICE.so.6 => /usr/local/lib/libICE.so.6 (0x801c46000)
    libSM.so.6 => /usr/local/lib/libSM.so.6 (0x801c3c000)
. . .
    libstdc++.so.6 => not found (0)
. . .
[/CODE}

But, as far as I can tell, that library is present in the same location as that on the first system.
[CODE]
ls -l /usr/local/lib/gcc10/libstdc++.so.6
lrwxr-xr-x  1 root  wheel  19 Feb 18 17:24 /usr/local/lib/gcc10/libstdc++.so.6 -> libstdc++.so.6.0.28

[root@sshpipe-2 ~]# ls -l /usr/local/lib/gcc10/libstdc++.so.6.0.28
-rwxr-xr-x  1 root  wheel  1977216 Feb 18 17:16 /usr/local/lib/gcc10/libstdc++.so.6.0.28
Any ideas of what I have tripped over? Is this somehow related to the second host being in a Jail?
Click to expand...

you would have to get, libstdc++.so.6 and see library compatibility
.
libstdc++.so.6 => /usr/local/lib/gcc10/libstdc++.so.6 (0x80201a000)

you've seen his memory position, see return of this library. ldd is not enough, as I am kernel developer, I understand, that these library, is requesting but a library.
 
Short answer: /usr/local/lib/gcc10 is missing in your library search path. Installing the gcc10 port should add it automatically. To add it manually, run ldconfig /usr/local/lib/gcc10.

Long answer: GCC is not FreeBSD's system compiler. If a software really needs it, you must install it from ports/packages. Some support/runtime libs (including the standard C++ library) needed by code compiled with GCC are actually part of GCC. As ports aren't designed to build multiple packages from a single source project, you must have GCC installed for running any binary compiled with it.

In theory, one problem is that these library names are not necessarily unique. If you have multiple versions of GCC installed, this turns into a practical problem, as both will for example offer a libstdc++.so.6. The newer one will contain some additional features/symbols. As it's still backwards compatible, it's fine the major version (6) is still the same. But if a binary compiled with the newer GCC accidentally finds the older libstdc++.so.6 first, it just won't work.

That's why software compiled with GCC for FreeBSD should always have an rpath hardcoded, telling the dynamic linker to look in a specific directory first for shared libs before considering the library search path. Ports of software requiring GCC do this automatically, they just set USE_GCC= yes and the ports framework adds the necessary linker flags. So if you built your binary from a port, that port seems to have a bug.

If you're building yourself *), add this flag to the linker step: -Wl,-rpath,/usr/local/lib/gcc10 (put the gcc version used there).

As a cheap workaround, you can also install sysutils/patchelf and patch the rpath into the binary with patchelf --set-rpath /usr/local/lib/gcc10 lpcl6.

---
*) (edit) well, if you build it yourself, first double-check it really needs GCC. Try building it with FreeBSD's native toolchain (based on llvm/clang) instead, avoiding a huge dependency and the problems described above.
 
the way, that I work with it, let's go with the Russian way, of the whole thing, analyze the elements, of libraries

# objdump -T /usr/local/lib/gcc10/libstdc++.so.6|grep -F '*UND*'

has libraries that are provided by the FreeBSD kernel in particular. I want you to see it, buddy. your behavior, that's not going to be a problem for you anymore, fellow American.

see the gcc libraries, this can happen, inside a jail, or if you have a binary compatibility No FreeBSD
 
Thank you both. I was afraid that it was something like that. The fundamental requirement is that I have a working copy of gpcl6 that I can distribute to systems with a minimum of dependencies. If it was possible, and I knew how to do it, I would prefer a static build of just that tool.

To build the version I have I had to compile from source obtained from the ghostscript site. As distributed this uses gcc. Reconsrtructing the entire build tree to use clang increases the workload far beyond what I can afford to devote to it.

I will install gcc and hope for the best.
 
see this
forums.freebsd.org

Solved - OpenMSX issue

I'm the maintainer of emulators/openmsx. I've adopted this port some time ago (I don't remember) and 0.17 was working fine. But as the lack of time that pests all of us, it was some time I've didn't run openmsx, turns out I had that time and I realized that the openmsx can't run anymore. Said...
forums.freebsd.org forums.freebsd.org
 
You must log in or register to reply here.
Back
Top