Solved unrar requires gcc46?

I just tried to upgrade gcc 4.6 to the current version 6.x, as 4.6 is now unsupported and the port will be removed in November. Installation from ports went without a problem (old gcc46 removed before installing the new version).

However, now unrar no longer works - it fails with the message

Code:
Shared object "gcc46/libgcc_s.so.1" not found, required by "unrar"

Rebuilding unrar from ports or installing the binary package did not help - which makes sense, considering that rar is a proprietary software blob. Now the question: any way around this issue without reinstalling the old gcc46? unrar is required, as no other archive software can handle the rar5 archive format.
 
I have unrar installed (from binary package) on a FreeBSD 11.1-STABLE system, no version of gcc on there at all, and it works just fine. It stills uses libgcc_s.so, but that appears to be part of the base installation, not from any port.
 
Same here in FreeBSD 11.1-RELEASE, just installed unrar-5.50b4,5 with pkg(8):
Code:
$ ldd /usr/local/bin/unrar
/usr/local/bin/unrar:
   libthr.so.3 => /lib/libthr.so.3 (0x800869000)
   libcrypto.so.8 => /lib/libcrypto.so.8 (0x800c00000)
   libc++.so.1 => /usr/lib/libc++.so.1 (0x801069000)
   libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x801330000)
   libm.so.5 => /lib/libm.so.5 (0x80154e000)
   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x801779000)
   libc.so.7 => /lib/libc.so.7 (0x801987000)
 
I should probably add that I am on FreeBSD 10.3-STABLE.

Interesting output from ldd on my machine:

Code:
# ldd /usr/local/bin/unrar
/usr/local/bin/unrar:
   libthr.so.3 => /lib/libthr.so.3 (0x800865000)
   libcrypto.so.7 => /lib/libcrypto.so.7 (0x800a89000)
   libc++.so.1 => /usr/lib/libc++.so.1 (0x800e81000)
   libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x801141000)
   libm.so.5 => /lib/libm.so.5 (0x80135e000)
   libgcc_s.so.1 => /usr/local/lib/gcc46/libgcc_s.so.1 (0x801587000)
   libc.so.7 => /lib/libc.so.7 (0x80179c000)
 
It must have been forced to build with GCC:
Code:
root@armitage:~ # ldd /usr/local/bin/unrar
/usr/local/bin/unrar:
        libthr.so.3 => /lib/libthr.so.3 (0x800864000)
        libcrypto.so.41 => /usr/local/lib/libcrypto.so.41 (0x800a89000)
        libc++.so.1 => /usr/lib/libc++.so.1 (0x800e86000)
        libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x801145000)
        libm.so.5 => /lib/libm.so.5 (0x801362000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80158b000)
        libc.so.7 => /lib/libc.so.7 (0x801799000)
root@armitage:~ # freebsd-version -u
10.3-RELEASE-p21
The /usr/local/lib/libcrypto.so.41 is due to LibreSSL.
 
It must have been forced to build with GCC:
Code:
root@armitage:~ # ldd /usr/local/bin/unrar
/usr/local/bin/unrar:
        libthr.so.3 => /lib/libthr.so.3 (0x800864000)
        libcrypto.so.41 => /usr/local/lib/libcrypto.so.41 (0x800a89000)
        libc++.so.1 => /usr/lib/libc++.so.1 (0x800e86000)
        libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x801145000)
        libm.so.5 => /lib/libm.so.5 (0x801362000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80158b000)
        libc.so.7 => /lib/libc.so.7 (0x801799000)
root@armitage:~ # freebsd-version -u
10.3-RELEASE-p21
The /usr/local/lib/libcrypto.so.41 is due to LibreSSL.


I just tried to rebuild the unrar port, after setting the following in make.conf:
Code:
OPTIONS_SET=CLANG
WITH_CLANG=yes
WITH_CLANG_EXTRAS=yes
WITH_CLANG_IS_CC=yes
WITHOUT_GCC=yes
However, the output from ldd remains unchanged. I then cleared unrar builds out of /var/pkg and installed the binary package with pkg install -f unrar. However, no change regarding the dependency on the gcc46 library.

Is there any other way to force the dependency back to stock?
 
Does the file /usr/local/lib/gcc46/libgcc_s.so.1 actually exist on your system? If not, I'm wondering if the shared library cache on your system is outdated now that gcc46 has been removed; perhaps running ldconfig (as root) is necessary.
 
Does the file /usr/local/lib/gcc46/libgcc_s.so.1 actually exist on your system? If not, I'm wondering if the shared library cache on your system is outdated now that gcc46 has been removed; perhaps running ldconfig (as root) is necessary.

libgcc_s.so.1 exists in several places, including /usr/local/lib/gcc46/ (I removed instances in /usr/obj for readability):

Code:
# locate libgcc_s.so.1
/compat/linux/lib64/libgcc_s.so.1
/lib/libgcc_s.so.1
/usr/lib32/libgcc_s.so.1
/usr/local/lib/gcc46/libgcc_s.so.1

Obviously, if I remove gcc46, it removes the library in /usr/local/lib/gcc46, which leads to the error with unrar described in my OP.

After removing gcc46 and running ldd /usr/local/bin/unrar, I see:

Code:
libthr.so.3 => /lib/libthr.so.3 (0x800865000)
        libcrypto.so.7 => /lib/libcrypto.so.7 (0x800a89000)
        libc++.so.1 => /usr/lib/libc++.so.1 (0x800e81000)
        libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x801141000)
        libm.so.5 => /lib/libm.so.5 (0x80135e000)
        libgcc_s.so.1 => not found (0)
        libc.so.7 => /lib/libc.so.7 (0x801587000)
        libgcc_s.so.1 => not found (0)
        libgcc_s.so.1 => not found (0)

Running ldconfig /lib /usr/lib /usr/local/lib does not help, only reinstalling gcc46 makes unrar run for me. I am baffled....
 
I'm baffled, too.

What about this command: ldconfig -r | grep libgcc_s (this basically dumps the shared library cache and we search for libgcc_s).
On a 10.3-STABLE system with gcc46 installed, I get
Code:
14:-lgcc_s.1 => /lib/libgcc_s.so.1
133:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1
So, unless there is some mapping set up in /etc/libmap.conf, it should pick up the libgcc_s from /lib
 
I'm baffled, too.

What about this command: ldconfig -r | grep libgcc_s (this basically dumps the shared library cache and we search for libgcc_s).
On a 10.3-STABLE system with gcc46 installed, I get
Code:
14:-lgcc_s.1 => /lib/libgcc_s.so.1
133:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1
So, unless there is some mapping set up in /etc/libmap.conf, it should pick up the libgcc_s from /lib

Thank you! The /etc/libmap.conf hint was the key. Back when that system was running FreeBSD 10.0, there was a need to force the gcc46 libraries, for whatever required it back then. I simply forgot that this was still configured. Removed and everything works as expected now.

And thanks again to everybody who helped!
 
I'm glad you solved it!
Just want to mention another possible cause of such issues: building an executable with rpath option.
You should be able to find such embedded path by running strings <your_executable> | grep <your_wrong_lib_path>.
 
Back
Top