This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

libgcc_s.so


Does anyone build their own cross-gcc and use that to
cross-build a glibc-based ARM system? Or can anyone
otherwise explain to me what's happening with this
problem I have do this?

I used to use "--libdir=/usr/lib" when cross-building
glibc as part of the cross tool chain, and I use
"--prefix=/usr" for making the cross-gcc. So I get
libgcc_s.so that looks like it belongs in the target
systems /usr/lib directory. All worked OK.

I changed to use "--libdir=/lib" when cross-building
glibc, and make no change to making gcc. As I expected,
I still get libgcc_s.so that looks like it belongs in
the target systems /usr/lib directory. However, when
the ARM system boots, bash doesn't run because libgcc_s.so
can't be found. I put a symlink in /lib to
/usr/lib/libgcc_s.so and bash works. As soom as the
system run ldconfig I can remove the /lib sym link to
/usr/lib/libgcc_s.so and bash continues to work; ldd
shows the /usr/lib/libgcc_s.so if resolved.

What the heck?

Is this expected? Does the glibc configuration
of "--libdir=xxx" tell ld-2.9.so that is *the*
place to look until ldconfig runs? Did that
question even makes sense or am I all botched up?

Thanks for help or any hints.

--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]