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] |
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] |