Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[0.1 BTC to whoever solves this!] libgcc_s.so.1 not found?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on Alternative Architectures
View previous topic :: View next topic  
Author Message
mwhitlock
Tux's lil' helper
Tux's lil' helper


Joined: 07 Aug 2006
Posts: 75
Location: Weare, NH

PostPosted: Tue Apr 02, 2013 1:03 am    Post subject: [0.1 BTC to whoever solves this!] libgcc_s.so.1 not found? Reply with quote

I'll tip 0.1 BTC (≈10 USD) to whoever provides a solution to this problem.

This is a clean install of Gentoo on a Raspberry Pi (natively, not cross-compiled). I changed the CHOST to "armv6zk-hardfloat-linux-gnueabi" and rebuilt all packages in the system. There are no remnants of the old "armv6j-hardfloat-linux-gnueabi" anywhere, as best I can tell.

Everything was working perfectly until I tried to upgrade from sys-libs/glibc-2.16.0 to 2.17. The entire build succeeded, including installation to the staging area in /var/tmp/portage/sys-libs/glibc-2.17/image, but then Portage aborted in the middle of the merge process with:
Code:
/bin/date: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory

The system was still usable at that point. I tried the emerge again and got the same result.

The root file system of my Raspberry Pi is an NFS mount of a directory (/mnt/raspi) on my Gentoo desktop machine, so I ran this command on my desktop to get the merge to complete:
Code:
ROOT=/mnt/raspi PORTAGE_CONFIGROOT=/mnt/raspi PORTAGE_TMPDIR=/mnt/raspi/var/tmp ebuild /usr/portage/sys-libs/glibc/glibc-2.17.ebuild merge

The merge was successful, except for a bunch of ldconfig errors complaining about machine type 40, probably because all the shared objects in the /mnt/raspi tree are ARM objects, but /sbin/ldconfig is for x86_64. No big deal there. I ran "ldconfig -v" on the Raspberry Pi, and everything looked good.

But now:
Code:
raspberrypi ~ # ls
ls: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory

raspberrypi ~ # ldconfig -p | busybox grep libgcc_s.so.1
        libgcc_s.so.1 (libc6) => /usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2/libgcc_s.so.1

So which is it? The dynamic linker can't find libgcc_s.so.1, but /etc/ld.so.cache knows where it is.

Even more perplexing: if I symlink /usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2/libgcc_s.so.1 at /usr/lib/libgcc_s.so.1, then everything works, even though the ld.so.cache has libgcc_s.so.1 only in /usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2. It's almost as though the entry for libgcc_s.so.1 in ld.so.cache isn't being used at all.

Could this be a new bug in the dynamic linker in glibc 2.17?

I'm rebuilding sys-devel/gcc-4.7.2-r1 right now (with the symlink in place) just to see if that fixes it.
Back to top
View user's profile Send private message
mwhitlock
Tux's lil' helper
Tux's lil' helper


Joined: 07 Aug 2006
Posts: 75
Location: Weare, NH

PostPosted: Tue Apr 02, 2013 2:17 am    Post subject: Reply with quote

More interesting data points regarding this bizarre system state…
Code:
raspberrypi ~ # cat hello.cpp
#include <iostream>
int main() {
        std::cout << "Hello world!" << std::endl;
        return 0;
}

raspberrypi ~ # g++ -Os -o hello hello.cpp
/usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2/../../../../armv6zk-hardfloat-linux-gnueabi/bin/ld: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
collect2: error: ld returned 127 exit status

raspberrypi ~ # LD_LIBRARY_PATH=/usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2 g++ -Os -o hello hello.cpp

raspberrypi ~ # ./hello
./hello: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

raspberrypi ~ # LD_LIBRARY_PATH=/usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2 ./hello
Hello world!

raspberrypi ~ # ldd hello
        libstdc++.so.6 => not found
        libm.so.6 => /lib/libm.so.6 (0xb6e74000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb6e61000)
        libc.so.6 => /lib/libc.so.6 (0xb6d31000)
        /lib/ld-linux-armhf.so.3 (0xb6eef000)

raspberrypi ~ # LD_LIBRARY_PATH=/usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2 ldd hello
        libstdc++.so.6 => /usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2/libstdc++.so.6 (0xb6ec4000)
        libm.so.6 => /lib/libm.so.6 (0xb6e49000)
        libgcc_s.so.1 => /usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2/libgcc_s.so.1 (0xb6e36000)
        libc.so.6 => /lib/libc.so.6 (0xb6d06000)
        /lib/ld-linux-armhf.so.3 (0xb6f8f000)

raspberrypi ~ # cat /etc/ld.so.conf
# ld.so.conf autogenerated by env-update; make all changes to
# contents of /etc/env.d directory
/lib
/usr/lib
/usr/local/lib
include ld.so.conf.d/*.conf
/usr/lib/opengl/xorg-x11/lib
/opt/vc/lib

raspberrypi ~ # cat /etc/ld.so.conf.d/*.conf
/usr/armv6zk-hardfloat-linux-gnueabi/lib
/usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2

raspberrypi ~ # ldconfig -p | fgrep libstdc++
        libstdc++.so.6 (libc6) => /usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2/libstdc++.so.6
        libstdc++.so (libc6) => /usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2/libstdc++.so

Weird, right? It's like ld.so.cache is being ignored.
Back to top
View user's profile Send private message
mwhitlock
Tux's lil' helper
Tux's lil' helper


Joined: 07 Aug 2006
Posts: 75
Location: Weare, NH

PostPosted: Wed Apr 03, 2013 4:07 pm    Post subject: Re: [0.1 BTC to whoever solves this!] libgcc_s.so.1 not foun Reply with quote

mwhitlock wrote:
I'm rebuilding sys-devel/gcc-4.7.2-r1 right now (with the symlink in place) just to see if that fixes it.

The build finished. The problem persists.
Back to top
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1551

PostPosted: Wed Apr 03, 2013 7:08 pm    Post subject: Re: [0.1 BTC to whoever solves this!] libgcc_s.so.1 not foun Reply with quote

mwhitlock wrote:
I'll tip 0.1 BTC (≈10 USD) to whoever provides a solution to this problem.

This is a clean install of Gentoo on a Raspberry Pi (natively, not cross-compiled). I changed the CHOST to "armv6zk-hardfloat-linux-gnueabi" and rebuilt all packages in the system. There are no remnants of the old "armv6j-hardfloat-linux-gnueabi" anywhere, as best I can tell.


Why exactly did you change the CHOST from the default listed on the Raspberry Pi article of our Wiki which the embedded herd has contributed to?

They also found that armv6zk yields worse optimization flags than armv6j, there should therefore be no need to change; you're more likely to make it worse than better.
Back to top
View user's profile Send private message
mwhitlock
Tux's lil' helper
Tux's lil' helper


Joined: 07 Aug 2006
Posts: 75
Location: Weare, NH

PostPosted: Wed Apr 03, 2013 7:18 pm    Post subject: Re: [0.1 BTC to whoever solves this!] libgcc_s.so.1 not foun Reply with quote

TomWij wrote:
Why exactly did you change the CHOST from the default listed on the Raspberry Pi article of our Wiki which the embedded herd has contributed to?

They also found that armv6zk yields worse optimization flags than armv6j, there should therefore be no need to change; you're more likely to make it worse than better.

The SoC in the Raspberry Pi is a BCM2835, which contains an ARM1176JZFS with a VFP coprocessor. [source]
This page says the arm1176jzf-s core should use a CHOST of "armv6zk-hardfloat-linux-gnueabi" for hardfp.

I'm aware of the benchmarking that was done of armv6j versus armv6zk, and the results were mixed and equivocal in my opinion. I chose to use armv6zk because it is the canonically correct choice for the actual CPU on the board. Gentoo is about choice, is it not? I followed Gentoo's CHOST migration guide, and I'm not a bumbling newb; I've been using Gentoo since about 2005.

So while I appreciate your trying to get me the best performance possible out of Gentoo on my Raspberry Pi, you haven't answered any of my questions or solved my problem.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32166
Location: 56N 3W

PostPosted: Wed Apr 03, 2013 7:23 pm    Post subject: Reply with quote

mwhitlock,

Do the files listed in the error mesages exist or do you have a dynamic linker problem?

On my Pi, the dynamic linker is called ld-2.16.so with a symlink ld-linux-armhf.so.3 that points to it.
My cross compiled packages on an amd64 host, need the symlink ld-linux.so.3 to run on the Pi.

I'm wondering if you need another symlink or have lost the ld-linux-armhf.so.3 symlink?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1551

PostPosted: Wed Apr 03, 2013 7:37 pm    Post subject: Re: [0.1 BTC to whoever solves this!] libgcc_s.so.1 not foun Reply with quote

mwhitlock wrote:
I chose to use armv6zk because it is the canonically correct choice for the actual CPU on the board. Gentoo is about choice, is it not? ... So while I appreciate your trying to get me the best performance possible out of Gentoo on my Raspberry Pi, you haven't answered any of my questions or solved my problem.


Why exactly is this choice the correct one? As far as you seem to care, your choice seems quite uneducated. The only real benefit I think you could get are security extensions, but since you did not mention them you are likely not going to use them; therefore what you really achieve is just a cut in performance. I was just making sure that you're not pursuing the wrong goal, because you haven't told me the right goal; after all, you're changing the CHOST to a target for which you seem not to know if it gains you in a positive or negative way. Therefore you're stating a X-Y problem here that needs to be clarified, but if you really just want to be blind then go ahead and fix the problem and enjoy what is likely to be a slower security extended Raspberry Pi; the missing piece is:

Code:
LD_LIBRARY_PATH=/usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2 gcc-config armv6zk-hardfloat-linux-gnueabi && . /etc/profile


If you changed too much apart from the guide, you may have broken this approach too. Also, you may want to build the toolchain once again...

PS: I am running a Raspberry Pi myself and find changing the CHOST something interesting to look into, therefore I was wondering whether you knew of an actual positive benefit other than the security extensions.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32166
Location: 56N 3W

PostPosted: Wed Apr 03, 2013 8:03 pm    Post subject: Reply with quote

TomWij,

... the CHOST only affects the build of the toolchain. It has no impact on the code emitted by that toolchain.

The CHOST changing guide dates from glibc dropping support for the i386 and a large number of users had i386 CHOS installs on i686 hardware, this were unable t update glibc.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1551

PostPosted: Wed Apr 03, 2013 8:11 pm    Post subject: Reply with quote

NeddySeagoon wrote:
It has no impact on the code emitted by that toolchain.


Thanks for re-affirming, so this would mean that all this would do is make the toolchain itself slower (and provide support for building security extensions into it, if the toolchain at all supports that).
Back to top
View user's profile Send private message
mwhitlock
Tux's lil' helper
Tux's lil' helper


Joined: 07 Aug 2006
Posts: 75
Location: Weare, NH

PostPosted: Wed Apr 03, 2013 8:36 pm    Post subject: Re: [0.1 BTC to whoever solves this!] libgcc_s.so.1 not foun Reply with quote

NeddySeagoon wrote:
Do the files listed in the error mesages exist or do you have a dynamic linker problem?

The files exist:
Code:
-rw-r--r-- 1 root root   135 Apr  3 10:16 /usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2/libgcc_s.so
-rw-r--r-- 1 root root 41052 Apr  3 10:17 /usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2/libgcc_s.so.1

NeddySeagoon wrote:
On my Pi, the dynamic linker is called ld-2.16.so with a symlink ld-linux-armhf.so.3 that points to it.

Mine is similar but newer:
Code:
-rwxr-xr-x 1 root root 134236 Apr  1 18:53 /lib/ld-2.17.so
lrwxrwxrwx 1 root root     10 Apr  1 18:59 /lib/ld-linux-armhf.so.3 -> ld-2.17.so


TomWij wrote:
mwhitlock wrote:
I chose to use armv6zk because it is the canonically correct choice for the actual CPU on the board. Gentoo is about choice, is it not? ... So while I appreciate your trying to get me the best performance possible out of Gentoo on my Raspberry Pi, you haven't answered any of my questions or solved my problem.

Why exactly is this choice the correct one?

Why would Gentoo say "The following list describes the appropiate [sic] CHOSTs for specific ARM cores" if the CHOSTs in the table were not in fact the appropriate CHOSTs for the specific ARM cores listed? I try to be as specific and accurate as possible about how I describe my target CPU to GCC. I trust GCC to make correct decisions about which instructions and instruction sequences will execute fastest on the target. And moreover, I trust that future improvements to GCC will improve my performance if I'm correctly specifying my CPU but could actually hurt my performance if I'm incorrectly specifying my CPU.

In the end, my whole objective in all of this is to squeeze every last bit of speed I can out of the Pi. So, to appease my curiosity, I ran nbench with four different sets of CFLAGS:
  • CFLAGS="-Ofast -pipe -march=armv6j -mfpu=vfp -mfloat-abi=hard"
  • CFLAGS="-Ofast -pipe -march=armv6j -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard"
  • CFLAGS="-Ofast -pipe -march=armv6zk -mtune=arm1136jf-s -mfpu=vfp -mfloat-abi=hard"
  • CFLAGS="-Ofast -pipe -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard"

CFLAGS="-Ofast -pipe -march=armv6j -mfpu=vfp -mfloat-abi=hard"
Code:
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :             228  :       5.85  :       1.92
STRING SORT         :          31.564  :      14.10  :       2.18
BITFIELD            :      8.4718e+07  :      14.53  :       3.04
FP EMULATION        :          46.944  :      22.53  :       5.20
FOURIER             :          1953.1  :       2.22  :       1.25
ASSIGNMENT          :          2.6487  :      10.08  :       2.61
IDEA                :          713.15  :      10.91  :       3.24
HUFFMAN             :             419  :      11.62  :       3.71
NEURAL NET          :           2.842  :       4.57  :       1.92
LU DECOMPOSITION    :          82.967  :       4.30  :       3.10
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 11.934
FLOATING-POINT INDEX: 3.519
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 :
L2 Cache            :
OS                  : Linux 3.6.11+
C compiler          : armv6zk-hardfloat-linux-gnueabi-gcc
libc                :
MEMORY INDEX        : 2.587
INTEGER INDEX       : 3.309
FLOATING-POINT INDEX: 1.952
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

CFLAGS="-Ofast -pipe -march=armv6j -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard"
Code:
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :           235.2  :       6.03  :       1.98
STRING SORT         :          31.491  :      14.07  :       2.18
BITFIELD            :      5.9134e+07  :      10.14  :       2.12
FP EMULATION        :          45.382  :      21.78  :       5.02
FOURIER             :          2029.8  :       2.31  :       1.30
ASSIGNMENT          :          2.6355  :      10.03  :       2.60
IDEA                :          701.75  :      10.73  :       3.19
HUFFMAN             :          423.57  :      11.75  :       3.75
NEURAL NET          :          2.7767  :       4.46  :       1.88
LU DECOMPOSITION    :          81.296  :       4.21  :       3.04
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 11.312
FLOATING-POINT INDEX: 3.513
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 :
L2 Cache            :
OS                  : Linux 3.6.11+
C compiler          : armv6zk-hardfloat-linux-gnueabi-gcc
libc                :
MEMORY INDEX        : 2.290
INTEGER INDEX       : 3.303
FLOATING-POINT INDEX: 1.949
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

CFLAGS="-Ofast -pipe -march=armv6zk -mtune=arm1136jf-s -mfpu=vfp -mfloat-abi=hard"
Code:
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :           227.6  :       5.84  :       1.92
STRING SORT         :          31.619  :      14.13  :       2.19
BITFIELD            :      8.4459e+07  :      14.49  :       3.03
FP EMULATION        :          46.962  :      22.53  :       5.20
FOURIER             :          2012.1  :       2.29  :       1.29
ASSIGNMENT          :          2.6475  :      10.07  :       2.61
IDEA                :          713.72  :      10.92  :       3.24
HUFFMAN             :          418.99  :      11.62  :       3.71
NEURAL NET          :          2.8409  :       4.56  :       1.92
LU DECOMPOSITION    :          80.927  :       4.19  :       3.03
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 11.930
FLOATING-POINT INDEX: 3.524
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 :
L2 Cache            :
OS                  : Linux 3.6.11+
C compiler          : armv6zk-hardfloat-linux-gnueabi-gcc
libc                :
MEMORY INDEX        : 2.586
INTEGER INDEX       : 3.309
FLOATING-POINT INDEX: 1.955
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

CFLAGS="-Ofast -pipe -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard"
Code:
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          235.92  :       6.05  :       1.99
STRING SORT         :          31.562  :      14.10  :       2.18
BITFIELD            :      5.9244e+07  :      10.16  :       2.12
FP EMULATION        :          45.309  :      21.74  :       5.02
FOURIER             :          2021.7  :       2.30  :       1.29
ASSIGNMENT          :          2.5753  :       9.80  :       2.54
IDEA                :          701.75  :      10.73  :       3.19
HUFFMAN             :          423.89  :      11.75  :       3.75
NEURAL NET          :          2.7701  :       4.45  :       1.87
LU DECOMPOSITION    :          79.728  :       4.13  :       2.98
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 11.285
FLOATING-POINT INDEX: 3.483
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 :
L2 Cache            :
OS                  : Linux 3.6.11+
C compiler          : armv6zk-hardfloat-linux-gnueabi-gcc
libc                :
MEMORY INDEX        : 2.275
INTEGER INDEX       : 3.305
FLOATING-POINT INDEX: 1.932
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

So it seems the -march flag doesn't have much of an impact here (maybe because GCC doesn't do anything with TrustZone?). The significant difference is attributable to the -mtune flag, and it seems that tuning for the arm1176jzf-s, although that is the actual core in the Raspberry Pi, results in slower performance (especially on the bitfield test) than tuning for the arm1136jf-s.

TomWij wrote:
Code:
LD_LIBRARY_PATH=/usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2 gcc-config armv6zk-hardfloat-linux-gnueabi && . /etc/profile

Thanks. I'll try that to see if it solves this dynamic linkage problem. If it does, I'll pay you the bounty. Do you have a Bitcoin address? (If you don't yet have one, now's a good time to make one.)

Regardless of whether that solves the linkage problem, I'll be switching my CHOST back to "armv6j-hardfloat-linux-gnueabi", as that's tied for the best of the bunch and is the present recommendation from the embedded group.
Back to top
View user's profile Send private message
mwhitlock
Tux's lil' helper
Tux's lil' helper


Joined: 07 Aug 2006
Posts: 75
Location: Weare, NH

PostPosted: Wed Apr 03, 2013 8:44 pm    Post subject: Re: [0.1 BTC to whoever solves this!] libgcc_s.so.1 not foun Reply with quote

mwhitlock wrote:
TomWij wrote:
Code:
LD_LIBRARY_PATH=/usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2 gcc-config armv6zk-hardfloat-linux-gnueabi && . /etc/profile

Thanks. I'll try that to see if it solves this dynamic linkage problem.

The GCC profile name appears to be "armv6zk-hardfloat-linux-gnueabi-4.7.2", not "armv6zk-hardfloat-linux-gnueabi".

The command you gave appears to be equivalent to running "gcc-config 1" (where 1 is the index of armv6zk-hardfloat-linux-gnueabi-4.7.2 in `gcc-config -l`). I had already switched my profile and recompiled both gcc and glibc under the new profile.

Are you running glibc 2.17 on your Raspberry Pi yet? I'm really thinking they changed something in the dynamic linker that broke it.
Back to top
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1551

PostPosted: Wed Apr 03, 2013 9:09 pm    Post subject: Re: [0.1 BTC to whoever solves this!] libgcc_s.so.1 not foun Reply with quote

mwhitlock wrote:
Are you running glibc 2.17 on your Raspberry Pi yet? I'm really thinking they changed something in the dynamic linker that broke it.


No, installed it last year and I barely upgrade it as long as it does its media job fine.

If that exact line (adapted to use the -4.7.2 difference you noticed) doesn't work then I have no idea for a direct fix, I saw this mentioned in one or another guide.

You may be onto something with that dynamic linker bug, for which there may likely be no direct fix but you'll surely want to report it at http://bugs.gentoo.org such that the toolchain herd is aware of it.

Hmm... What about starting from a lower stage than stage3 such that you don't have to change the CHOST and can start from the right CHOST right away? Not sure how reasonable this approach is on a RPi, though...
Back to top
View user's profile Send private message
UNIXoid
n00b
n00b


Joined: 04 Apr 2013
Posts: 1

PostPosted: Thu Apr 04, 2013 7:08 am    Post subject: Reply with quote

I have the same problem on RPi with the latest updates but CHOST=armv6j-hardfloat-linux-gnueabi and not changed.
Back to top
View user's profile Send private message
mwhitlock
Tux's lil' helper
Tux's lil' helper


Joined: 07 Aug 2006
Posts: 75
Location: Weare, NH

PostPosted: Thu Apr 04, 2013 7:10 am    Post subject: Reply with quote

UNIXoid wrote:
I have the same problem on RPi with the latest updates but CHOST=armv6j-hardfloat-linux-gnueabi and not changed.

Glad to know I'm not the only one. I'm still rebuilding back to armv6j-hardfloat-linux-gnueabi. (The Pi ain't exactly a race horse. I do use distcc, but that doesn't help the second stage of the GCC build.)
Back to top
View user's profile Send private message
mwhitlock
Tux's lil' helper
Tux's lil' helper


Joined: 07 Aug 2006
Posts: 75
Location: Weare, NH

PostPosted: Thu Apr 04, 2013 1:58 pm    Post subject: Reply with quote

Bug 454200

Upstream glibc has a fix in trunk and is backporting it to the 2.17 series.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on Alternative Architectures All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum