dony wrote:
In fact, I have posted ALL howtos (not brief howtos) that I have done when compiling the cross-compile environment. And
these are all stealed from CrossGcc FAQ. See http://www.objsw.com.
I do these successfully on SuSE linux (European version), kernel 2.2.13. But the same steps on Redhat linux cannot work
and some errors occur. I don't know why and are checking these.
Since Redhat linux is widely used by most linux fans, I will research some effective and stable steps on this. I will
post to this mail list later when I succeed on Redhat linux.
I am using RedHat-5.2 and I don't have any problems. There might be some problems with RedHad-6.0 and/or RedHat-6.1. I
have heard of some people having problems with RedHat-6.x but I think that might be with RTEMS. Anyway, RedHat-5.2 works
for me.
quoted
He is using egcs-1.1.2, glibc-2.1 and binutils-2.9.1.0.19a.
I have just managed to cross-compile glibc-2.1.1 and glibc-2.1.2 with egcs-1.1.2. I haven't tested them out yet but
will do it this week. I am running with the embedded-2.2.5.tgz kernel and should upgrade to mpc8xx-2.2.13.tgz
kernel. I assume things should still work with the 2.2.5 kernel and I will let you know soon.
I couldn't get glibc-2.1.1 nor glibc-2.1.2 to compile using the cpu=860 flag. I was setting CC="powerpc-linux-gcc
-mcpu=860".
I think maybe you should use "export CC=powerpc-linux-gcc" and not use "-mcpu=860". I don't know why, but I do this and
succeed.
Yes. I have successfully built glibc-2.1.1 and glibc-2.1.2 with egcs-1.1.2 and binutils-2.9.1.0.19a.
I have copied all the shared libraries to my nfs root filesystem under /lib. I still get segmentation faults when I try to
run the dynamic application. Arghh !!! This is so annoying.
I'm using embedded-2.2.5 sourece. Maybe I should try mpc8xx-2.2.13 or linux-2.2.14 ?
Dony, have you modified any of the kernel source code ?
Does any body out there in linuxppc-embedded land have a clue as to what could be causing the segfaults ?
Can someone suggest a way of getting more debugging information. I'm using nfsd with "-F -d" call options at the moment.
I can see the ld.so.1 gets called which causes lots of reads from ld-2.1.2.so and then that's it. I would expect to get
calls to libc.so.6 but it never gets that far.
quoted
I also tried with the --nfp configure flag but I couldn't get any combination to work.
I don't know this option , so not use it.
It is "supposed" to exclude generation of hardware floating point code.
I imagine this should work better in the next release of glibc (whenever that is) as all the fpu code is in a seperate fpu
directory for the powerpc target.
Brendan Simon.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Brendan J Simon wrote:
dony wrote:
quoted
In fact, I have posted ALL howtos (not brief howtos) that I have done when compiling the cross-compile environment. And
these are all stealed from CrossGcc FAQ. See http://www.objsw.com.
I do these successfully on SuSE linux (European version), kernel 2.2.13. But the same steps on Redhat linux cannot work
and some errors occur. I don't know why and are checking these.
Since Redhat linux is widely used by most linux fans, I will research some effective and stable steps on this. I will
post to this mail list later when I succeed on Redhat linux.
I am using RedHat-5.2 and I don't have any problems. There might be some problems with RedHad-6.0 and/or RedHat-6.1. I
have heard of some people having problems with RedHat-6.x but I think that might be with RTEMS. Anyway, RedHat-5.2 works
for me.
Yes, I have problems with Redhat-6.0.
quoted
quoted
He is using egcs-1.1.2, glibc-2.1 and binutils-2.9.1.0.19a.
I have just managed to cross-compile glibc-2.1.1 and glibc-2.1.2 with egcs-1.1.2. I haven't tested them out yet but
will do it this week. I am running with the embedded-2.2.5.tgz kernel and should upgrade to mpc8xx-2.2.13.tgz
kernel. I assume things should still work with the 2.2.5 kernel and I will let you know soon.
I couldn't get glibc-2.1.1 nor glibc-2.1.2 to compile using the cpu=860 flag. I was setting CC="powerpc-linux-gcc
-mcpu=860".
I think maybe you should use "export CC=powerpc-linux-gcc" and not use "-mcpu=860". I don't know why, but I do this and
succeed.
Yes. I have successfully built glibc-2.1.1 and glibc-2.1.2 with egcs-1.1.2 and binutils-2.9.1.0.19a.
I have copied all the shared libraries to my nfs root filesystem under /lib. I still get segmentation faults when I try to
run the dynamic application. Arghh !!! This is so annoying.
Hi, Brendan:
Here are some notes:
1 Make sure you copy all your libraries under $(prefix)/$(target)/lib and $(prefix)/lib/gcc-lib to your target's root
filesystem /lib.
2 Make sure you keep their property unchangeable. i.e, if a library is symbol link , you must keep it unchangeable
after copying. Especially, libc.so.6 is a symbol link pointing to libc-2.1.so .
3 Make sure all these libraries you are copying are generated when buiding your cross-compile environment.
4 When cross-compiling your test app, you can specify its running share libraries path using "-Wl,--rpath,/lib".
i.e:
powerpc-linux-gcc -O2 -mcpu=860 -Wl,--rpath,lib -o mytest mytest.c
An easyest way to test this is to replace your target NFS root filesystem's /bin/sh with the above "mytest" and
reset your board. And running "rpc.nfsd -F -d call" on your x86 host to monitor whether it can run correctly. If not, what file
it cannot find? In my case , First , it can not find "/etc/ld.so.preload" and "/etc/ld.so.cache". then I run "touch
/tftpboot/etc/{ld.so.preload,ld.so.cache}". Then reset. And continue monitoring.
In my case, this time it cannot find some libraries under /usr/local/lib.Copy all the files it cannot find to its proper
place(where rpc.nfsd reports). In fact you can specify its running share libraries path using "-Wl, --rpath, /lib" to avoid
these.
Keep patient and you will find you are succeeding at this moment.
I'm using embedded-2.2.5 sourece. Maybe I should try mpc8xx-2.2.13 or linux-2.2.14 ?
I use mpc8xx-2.2.13. But I think it makes no difference.
Dony, have you modified any of the kernel source code ?
No.
Does any body out there in linuxppc-embedded land have a clue as to what could be causing the segfaults ?
Can someone suggest a way of getting more debugging information. I'm using nfsd with "-F -d" call options at the moment.
I think this is enough to debug your problem. This is what I use.
I can see the ld.so.1 gets called which causes lots of reads from ld-2.1.2.so and then that's it. I would expect to get
calls to libc.so.6 but it never gets that far.
Then where does it go after it accesses ld.so.1?
dony
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/