hppa's userspace in 2004 (looking back)
Dear list-members,
A new year is here and it's time to look back and say, hey, we did a great job, hacked on many things and made parisc a better port!
============
GNU/binutils
============
Maybe someone can comment on this? Randolph was great enough to remove silly ltp relocations from static binaries. Without the loader running the ltp is never read from the DT_PLTGOT dynamic entries... so it just made sense to translate these into dp relative relocations. dlopen from static binaries still doesn't work, minor problem really.
I know that hppa is not really multi-arch? We have to have two separate binaries to do 32 and 64-bit work. Someone want a project? :)
======
GNU/cc
======
jda, you're the best person to talk about how gcc is doing. I can build kernels with 3.3.3, sadly with the anon cvs down it's messed up my usual workflow when it comes to testing.
jda, you mentioned that the libstdc++ testsuite could be examined in order to fix some of our failures.
============
GNU/debugger
============
Our gdb has no visibility upstream. I'm taking a hiatus from glibc to fix gdb. I volunteered for this like 2 years ago, but glibc took a long time to fix.
===============
ELF64 Userspace
===============
32-bit versus 64-bit signals are fixed. Along with ucontext and siginfo. A good project might be for someone to implement the set/get/make/swap context calls in userspace, takers are welcome! I will *not* be working ELF64 yet, without a working gdb it's quite hard to do *anything*. I just recently learned how to poke insns into binary files for debugging... it's not as much fun as you think ;)
I need to do similar signal hacking for ia64 or upstream may never accept my linux/kernel/* patches. Worst-case has us absorb the changes into our arch directory and nobody else benefits from the framework :(
============================
Kernel<->Usrspace Atomic ops
============================
Will work on these whilst I hack gdb. Expect a first cut in a month or so.
========
GNU/libc
========
I'm here to speak on behalf of the userspace work we have done. Glibc is in *much* better shape than before, a year ago there were so many errors I didn't know where to begin. Our current list of failures is down to:
make[2]: *** [/glibc-work/build-hppa/math/test-float.out] Error 136 make[2]: *** [/glibc-work/build-hppa/math/test-double.out] Error 1 make[2]: *** [/glibc-work/build-hppa/math/test-ifloat.out] Error 136 make[1]: *** [math/tests] Error 2
These three tests are related to the fact that we don't have long double supported properly. Waiting on HP to release the code. An alternative is a long double with only 64-bits, though this would be the *last* thing on the list of userspace problems to fix (it would cement our long double ABI at 64-bits).
make[2]: *** [/glibc-work/build-hppa/stdlib/tst-strtod.out] Error 1 make[2]: *** [/glibc-work/build-hppa/stdlib/bug-strtod.out] Error 1 make[1]: *** [stdlib/tests] Error 2
Same issue, no long double support, so string to double fails.
make[2]: *** [/glibc-work/build-hppa/dlfcn/tststatic.out] Error 139 make[1]: *** [dlfcn/tests] Error 2
The value of an address is interpreted as a function descriptor and erroneously loads the wrong stuff during the jump. This will require a bit more work to track down the particular PLABEL32 or IPLT relocation causing the problem.
The trickiest bugs to remove were all those symbol visibility bugs, which weren't related to symbol visibility at all. Infact due to our erroneous function pointer implementation we were skipping all ld.so.1 COPY relocations. I ported hppa over to use the generic function descriptor code and was finally able to process all of ld's COPY relocs. I have no idea if this was ever a problem for symbols other than _r_debug. Gdb may benefit from this.
Profiling is fixed thanks to Randolph! And I just completed the required changes to get sprof working for shared libraries. I can finally enable *other* people to track down elusive performance problems in shared library code.
Aside from that we are no longer in danger of losing glibc, a few more patches and upstream will be synchronized! I think Ulrich might be growing to accept me as the hppa maintainer :)
Cheers,
Carlos.
Quoted 7 lines
======
GNU/cc
======jda, you're the best person to talk about how gcc is doing. I can build kernels with 3.3.3, sadly with the anon cvs down it's messed up my usual workflow when it comes to testing.
The PA backend is in fairly reasonable shape. Most of the remaining PA bugs are limitations in the current implementation. We are still restricted in distance for floating point and branch on bit. Frame sizes on hppa64 are limited to < 2**36 bytes. There is a bug which causes arguments in const functions to get optimized away. There is a bug which affects constant elimination. On the 64-bit port, constants don't appear to be substituted/combined properly with if_then_else insns. As a result, some if statements don't get simplified.
2004 Projects:
1) Squash remaining bugs and limitations.
2) Finish libffi port.
3) Add PA specific stuff for java.
4) Develop TLS specification and GCC support.
5) Allow small range of floating point registers to be used for integer multiplication in kernel. This should help 64-bit kernel.
6) Thread support for ada.
As usual, I expect there will be many ups and downs in the process. So, we won't get as far as we would like.
Quoted 2 lines
jda, you mentioned that the libstdc++ testsuite could be examined in order to fix some of our failures.
Yes, these need to be looked at before 3.4 is released. Some appear to be related to long double support. Just guessing, but I think the rest are locale or glibc related.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Quoted 7 lines
======
GNU/cc
======jda, you're the best person to talk about how gcc is doing. I can build kernels with 3.3.3, sadly with the anon cvs down it's messed up my usual workflow when it comes to testing.
The PA backend is in fairly reasonable shape. Most of the remaining PA bugs are limitations in the current implementation. We are still restricted in distance for floating point and branch on bit. Frame sizes on hppa64 are limited to < 2**36 bytes. There is a bug which causes arguments in const functions to get optimized away. There is a bug which affects constant elimination. On the 64-bit port, constants don't appear to be substituted/combined properly with if_then_else insns. As a result, some if statements don't get simplified.
2004 Projects:
1) Squash remaining bugs and limitations.
2) Finish libffi port.
3) Add PA specific stuff for java.
4) Develop TLS specification and GCC support.
5) Allow small range of floating point registers to be used for integer multiplication in kernel. This should help 64-bit kernel.
6) Thread support for ada.
As usual, I expect there will be many ups and downs in the process. So, we won't get as far as we would like.
Quoted 2 lines
jda, you mentioned that the libstdc++ testsuite could be examined in order to fix some of our failures.
Yes, these need to be looked at before 3.4 is released. Some appear to be related to long double support. Just guessing, but I think the rest are locale or glibc related.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Quoted 9 lines · John David Anglin
As usual, I expect there will be many ups and downs in the process. So, we won't get as far as we would like.
Quoted 2 lines
jda, you mentioned that the libstdc++ testsuite could be examined in order to fix some of our failures.
Yes, these need to be looked at before 3.4 is released. Some appear to be related to long double support. Just guessing, but I think the rest are locale or glibc related.
Does this seem like a reasonable triage list?
a. gdb.
b. atomic kernel ops.
c. libstdc++ failures.
c.
Quoted 9 lines · John David Anglin
As usual, I expect there will be many ups and downs in the process. So, we won't get as far as we would like.
Quoted 2 lines
jda, you mentioned that the libstdc++ testsuite could be examined in order to fix some of our failures.
Yes, these need to be looked at before 3.4 is released. Some appear to be related to long double support. Just guessing, but I think the rest are locale or glibc related.
Does this seem like a reasonable triage list?
a. gdb.
b. atomic kernel ops.
c. libstdc++ failures.
c.
Quoted 5 lines
Does this seem like a reasonable triage list?
a. gdb.
b. atomic kernel ops.
c. libstdc++ failures.
I expect GCC 3.4 is coming in 2-3 months, although there isn't a definite timeline yet. Would you like to try to get atomic kernel ops in 2.6.x? How important is the kernel timeline for this work? We missed gdb 6.0. A couple of quick hacks allow 6.0 to build for hppa-linux. Bug fixes are another matter.
Probably, the v3 issues involve doing enough research to file a PR if the problem is generic, fix the problem if it is GCC hppa specific. If a problem turns out to be glibc/kernel related, we can wait for a fix ;)
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Quoted 5 lines
Does this seem like a reasonable triage list?
a. gdb.
b. atomic kernel ops.
c. libstdc++ failures.
I expect GCC 3.4 is coming in 2-3 months, although there isn't a definite timeline yet. Would you like to try to get atomic kernel ops in 2.6.x? How important is the kernel timeline for this work? We missed gdb 6.0. A couple of quick hacks allow 6.0 to build for hppa-linux. Bug fixes are another matter.
Probably, the v3 issues involve doing enough research to file a PR if the problem is generic, fix the problem if it is GCC hppa specific. If a problem turns out to be glibc/kernel related, we can wait for a fix ;)
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Quoted 11 lines · John David Anglin
Quoted 5 lines
Does this seem like a reasonable triage list?
a. gdb.
b. atomic kernel ops.
c. libstdc++ failures.I expect GCC 3.4 is coming in 2-3 months, although there isn't a definite timeline yet. Would you like to try to get atomic kernel ops in 2.6.x? How important is the kernel timeline for this work? We missed gdb 6.0. A couple of quick hacks allow 6.0 to build for hppa-linux. Bug fixes are another matter.
No timeline, just icing.
Quoted 4 lines
Probably, the v3 issues involve doing enough research to file a PR if the problem is generic, fix the problem if it is GCC hppa specific. If a problem turns out to be glibc/kernel related, we can wait for a fix ;)
I can interleave b,c in order to help you out? :)
80% gdb.
10% atomic ops.
10% libstc++ failures.
c.
Quoted 11 lines · John David Anglin
Quoted 5 lines
Does this seem like a reasonable triage list?
a. gdb.
b. atomic kernel ops.
c. libstdc++ failures.I expect GCC 3.4 is coming in 2-3 months, although there isn't a definite timeline yet. Would you like to try to get atomic kernel ops in 2.6.x? How important is the kernel timeline for this work? We missed gdb 6.0. A couple of quick hacks allow 6.0 to build for hppa-linux. Bug fixes are another matter.
No timeline, just icing.
Quoted 4 lines
Probably, the v3 issues involve doing enough research to file a PR if the problem is generic, fix the problem if it is GCC hppa specific. If a problem turns out to be glibc/kernel related, we can wait for a fix ;)
I can interleave b,c in order to help you out? :)
80% gdb.
10% atomic ops.
10% libstc++ failures.
c.
Quoted 2 lines · Carlos O'Donell
A new year is here and it's time to look back and say, hey, we did a great job, hacked on many things and made parisc a better port!
Carlos, thank you for all the work you've put in over the last year and more. We would be significantly worse off without your efforts. I'm sure many people who read this aren't aware just how much work you've put in to make PA/Linux as good as it is -- and that's a compliment.
Quoted 4 lines
============
GNU/binutils
============
Quoted 8 lines
Maybe someone can comment on this? Randolph was great enough to remove silly ltp relocations from static binaries. Without the loader running the ltp is never read from the
DT_PLTGOTdynamic entries... so it just made sense to translate these into dp relative relocations. dlopen from static binaries still doesn't work, minor problem really.I know that hppa is not really multi-arch? We have to have two separate binaries to do 32 and 64-bit work. Someone want a project? :)
I have an unfinished project to get all the remnants of (%sr0,xx) right from 2-bit sr fields. I think I can do quite a simplification here, but I haven't got round to finishing it off. I'll take another look in February.
Quoted 7 lines
============
GNU/debugger
============Our gdb has no visibility upstream. I'm taking a hiatus from glibc to fix gdb. I volunteered for this like 2 years ago, but glibc took a long time to fix.
The bounty is currently set at one bottle of single malt (in the 10-20 year old range, not the 50 year old range ;-)
Quoted 11 lines
===============
ELF64 Userspace
===============32-bit versus 64-bit signals are fixed. Along with ucontext and siginfo. A good project might be for someone to implement the set/get/make/swap context calls in userspace, takers are welcome! I will *not* be working ELF64 yet, without a working gdb it's quite hard to do *anything*. I just recently learned how to poke insns into binary files for debugging... it's not as much fun as you think ;)
Quoted 3 lines
I need to do similar signal hacking for ia64 or upstream may never accept my linux/kernel/* patches. Worst-case has us absorb the changes into our arch directory and nobody else benefits from the framework :(
There's certainly enthusiasm for these changes -- the more 32-bit-emulation code we can share, the better. If you don't have time for this, I can take this on. But as I said, not till February.
Signature · 6 lines
"Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain
Quoted 2 lines · Carlos O'Donell
A new year is here and it's time to look back and say, hey, we did a great job, hacked on many things and made parisc a better port!
Carlos, thank you for all the work you've put in over the last year and more. We would be significantly worse off without your efforts. I'm sure many people who read this aren't aware just how much work you've put in to make PA/Linux as good as it is -- and that's a compliment.
Quoted 4 lines
============
GNU/binutils
============
Quoted 8 lines
Maybe someone can comment on this? Randolph was great enough to remove silly ltp relocations from static binaries. Without the loader running the ltp is never read from the
DT_PLTGOTdynamic entries... so it just made sense to translate these into dp relative relocations. dlopen from static binaries still doesn't work, minor problem really.I know that hppa is not really multi-arch? We have to have two separate binaries to do 32 and 64-bit work. Someone want a project? :)
I have an unfinished project to get all the remnants of (%sr0,xx) right from 2-bit sr fields. I think I can do quite a simplification here, but I haven't got round to finishing it off. I'll take another look in February.
Quoted 7 lines
============
GNU/debugger
============Our gdb has no visibility upstream. I'm taking a hiatus from glibc to fix gdb. I volunteered for this like 2 years ago, but glibc took a long time to fix.
The bounty is currently set at one bottle of single malt (in the 10-20 year old range, not the 50 year old range ;-)
Quoted 11 lines
===============
ELF64 Userspace
===============32-bit versus 64-bit signals are fixed. Along with ucontext and siginfo. A good project might be for someone to implement the set/get/make/swap context calls in userspace, takers are welcome! I will *not* be working ELF64 yet, without a working gdb it's quite hard to do *anything*. I just recently learned how to poke insns into binary files for debugging... it's not as much fun as you think ;)
Quoted 3 lines
I need to do similar signal hacking for ia64 or upstream may never accept my linux/kernel/* patches. Worst-case has us absorb the changes into our arch directory and nobody else benefits from the framework :(
There's certainly enthusiasm for these changes -- the more 32-bit-emulation code we can share, the better. If you don't have time for this, I can take this on. But as I said, not till February.
Signature · 6 lines
"Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain
Quoted 8 lines · Matthew Wilcox
Quoted 2 lines · Carlos O'Donell
A new year is here and it's time to look back and say, hey, we did a great job, hacked on many things and made parisc a better port!
Carlos, thank you for all the work you've put in over the last year and more. We would be significantly worse off without your efforts. I'm sure many people who read this aren't aware just how much work you've put in to make PA/Linux as good as it is -- and that's a compliment.
Full ACK !
Thanks Carlos and JDA !
Helge
Quoted 8 lines · Matthew Wilcox
Quoted 2 lines · Carlos O'Donell
A new year is here and it's time to look back and say, hey, we did a great job, hacked on many things and made parisc a better port!
Carlos, thank you for all the work you've put in over the last year and more. We would be significantly worse off without your efforts. I'm sure many people who read this aren't aware just how much work you've put in to make PA/Linux as good as it is -- and that's a compliment.
Full ACK !
Thanks Carlos and JDA !
Helge
Quoted 6 lines
Quoted 6 lines
Carlos, thank you for all the work you've put in over the last year and more. We would be significantly worse off without your efforts. I'm sure many people who read this aren't aware just how much work you've put in to make PA/Linux as good as it is -- and that's a compliment.
Same here; there are still a lot of issues with my C3000, but that does not mean it's not great; the machine runs and is stable, even with the USB and frame buffer issues. Totally stable. I am VERY PLEASED with the progress that has been made on HPPA linux; this machine is now one I depend on, because I know I can.
Thanks for all the work.
-Chris
Quoted 7 lines · Christopher Strong
Same here; there are still a lot of issues with my C3000, but that does not mean it's not great; the machine runs and is stable, even with the USB and frame buffer issues. Totally stable. I am VERY PLEASED with the progress that has been made on HPPA linux; this machine is now one I depend on, because I know I can.
Thanks for all the work.
Thanks guys! The learning process is worth it's weight in gold :) I'm always glad to hear people rely on their parisc-linux machines to get work done. Hey, my c3k runs all the home accounts in the lab!
c.
Hi Carlos,
Quoted 8 lines
========
GNU/libc
========I'm here to speak on behalf of the userspace work we have done. Glibc is in *much* better shape than before, a year ago there were so many errors I didn't know where to begin. Our current list of failures is down to:
Quoted 7 lines
make[2]: *** [/glibc-work/build-hppa/math/test-float.out] Error 136 make[2]: *** [/glibc-work/build-hppa/math/test-double.out] Error 1 make[2]: *** [/glibc-work/build-hppa/math/test-ifloat.out] Error 136 make[1]: *** [math/tests] Error 2
These three tests are related to the fact that we don't have long double supported properly. Waiting on HP to release the code.
Looking for something similar, some time ago, I figure out that Paul released some interesting hp lib stuff in gcc snapshot (the futur 3.4) into gcc/config/pa
as milli64.S (optimized div, mul, ....), ... (my last cvs update was dated
of dec 2003 and it seems that this feature was dated of Aug 2003 so I trust that last debian package gcc-snapshot should also contain this material)
I just don't yet reach to rebuild it (gcc-snapshot) following toolchain process (but I don't much retry because of gnu pserver cvs pb; in the mean time I read that new anonymous access would be with ssh, even though last weekend it was not yet operational?) because I much work on 3.3.3.
hth,
Joel
-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 €/mois! L'Internet rapide, c'est pour tout le monde.
http://reg.tiscali.be/default.asp?lg=fr
Hi Carlos,
Quoted 8 lines
========
GNU/libc
========I'm here to speak on behalf of the userspace work we have done. Glibc is in *much* better shape than before, a year ago there were so many errors I didn't know where to begin. Our current list of failures is down to:
Quoted 7 lines
make[2]: *** [/glibc-work/build-hppa/math/test-float.out] Error 136 make[2]: *** [/glibc-work/build-hppa/math/test-double.out] Error 1 make[2]: *** [/glibc-work/build-hppa/math/test-ifloat.out] Error 136 make[1]: *** [math/tests] Error 2
These three tests are related to the fact that we don't have long double supported properly. Waiting on HP to release the code.
Looking for something similar, some time ago, I figure out that Paul released some interesting hp lib stuff in gcc snapshot (the futur 3.4) into gcc/config/pa
as milli64.S (optimized div, mul, ....), ... (my last cvs update was dated
of dec 2003 and it seems that this feature was dated of Aug 2003 so I trust that last debian package gcc-snapshot should also contain this material)
I just don't yet reach to rebuild it (gcc-snapshot) following toolchain process (but I don't much retry because of gnu pserver cvs pb; in the mean time I read that new anonymous access would be with ssh, even though last weekend it was not yet operational?) because I much work on 3.3.3.
hth,
Joel
-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 €/mois! L'Internet rapide, c'est pour tout le monde.
http://reg.tiscali.be/default.asp?lg=fr
Joel Soete wrote:
[snip]
Quoted 3 lines
(but I don't much retry because of gnu pserver cvs pb; in the mean time I read that new anonymous access would be with ssh, even though last weekend it was not yet operational?)
[snip]
CVSROOT=":ext:[email protected]:/cvsroot/gcc"
seems to be operational now with CVS_RSH="ssh"
hth,
Joel
Hi Carlos,
Here is finaly the pb I encounter when I try to rebuild the toolchain with
gcc-snapshot at the time of glibc build:
[snip]
/Develop/parisc-linux/xc/bin/hppa-linux-gcc -nostdlib -nostartfiles -o /Develop/parisc-linux/build/glibc/iconv/iconvconfig
-Wl,-dynamic-linker=/opt/palinux/hppa-linux/lib/ld.so.1 /Develop/parisc-linux/build/glibc/csu/crt1.o
/Develop/parisc-linux/build/glibc/csu/crti.o `/Develop/parisc-linux/xc/bin/hppa-linux-gcc
--print-file-name=crtbegin.o` /Develop/parisc-linux/build/glibc/iconv/iconvconfig.o
/Develop/parisc-linux/build/glibc/iconv/strtab.o /Develop/parisc-linux/build/glibc/iconv/xmalloc.o
/Develop/parisc-linux/build/glibc/iconv/hash-string.o -Wl,-rpath-link=/Develop/parisc-linux/build/glibc:/Develop/parisc-linux/build/glibc/math:/Develop/parisc-linux/build/glibc/elf:/Develop/parisc-linux/build/glibc/dlfcn:/Develop/parisc-linux/build/gl ibc/nss:/Develop/parisc-linux/build/glibc/nis:/Develop/parisc-linux/build/glibc/rt:/Develop/parisc-linux/build/glibc/resolv:/Develop/parisc-linux/build/glibc/crypt:/Develop/parisc-linux/build/glibc/linuxthreads /Develop/parisc-linux/build/glibc/libc.so.6 /Develop/parisc-linux/build/glibc/libc_nonshared.a
-lgcc /Develop/parisc-linux/xc/bin/hppa-linux-gcc --print-file-name=crtend.o
/Develop/parisc-linux/build/glibc/csu/crtn.o
/Develop/parisc-linux/build/glibc/elf/ld.so.1: undefined reference to `set_dp'
collect2: ld returned 1 exit status
make[2]: *** [/Develop/parisc-linux/build/glibc/iconv/iconvconfig] Error
1
make[2]: Leaving directory `/Develop/parisc-linux/sources/glibc/iconv'
make[1]: *** [iconv/others] Error 2
make[1]: Leaving directory `/Develop/parisc-linux/sources/glibc'
make: *** [all] Error 2
the glibc src cames from last debian pkg with patches applied and configured with following options:
# unset LD_LIBRARY_PATH; unset LD_RUN_PATH; export CC=/Develop/parisc-linux/xc/bin/hppa-linux-gcc; export CLFAGS="-O2 -g"; export PATH="/Develop/parisc-linux/xc/bin:$PATH"; /Develop/parisc-linux/sources/glibc/configure --target=hppa-linux --host=hppa-linux --build=hppa-linux --prefix=/opt/palinux/hppa-linux --without-cvs --disable-profile --enable-hacker-mode --enable-add-ons=linuxthreads --with-headers=/Develop/parisc-linux/sources/linux/include
and the gcc-snapshot sources cames from the latest gcc-scnapshot-20040110 debian pkg and the 'preliminary x compiler' is configured with following options:
# export PATH="/Develop/parisc-linux/xc/bin:$PATH"; /Develop/parisc-linux/sources/gcc/configure --target=hppa-linux --host=hppa-linux --build=hppa-linux --prefix=/Develop/parisc-linux/xc --disable-shared --disable-nls --enable-languages=c
Any idea?
Thanks in advance,
Joel
Quoted 9 lines
-- Original Message --
Date: Fri, 09 Jan 2004 20:37:07 +0000
From: Joel Soete <[email protected]>
To: Carlos O'Donell <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)Joel Soete wrote:
[snip]
Quoted 1 line
(but I don't much retry because of gnu pserver cvs pb; in the mean time
I
Quoted 2 lines
read that new anonymous access would be with ssh, even though last weekend it was not yet operational?)
[snip]
CVSROOT=":ext:anoncvs@subve
Quoted 1 line
sions.gnu.org:/cvsroot/gcc"
seems to be operational now with CVS_RSH="ssh"
hth,
Joel
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listi
Quoted 1 line
fo/parisc-linux
-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 €/mois! L'Internet rapide, c'est pour tout le monde.
http://reg.tiscali.be/default.asp?lg=fr
Hi Carlos,
Here is finaly the pb I encounter when I try to rebuild the toolchain with
gcc-snapshot at the time of glibc build:
[snip]
/Develop/parisc-linux/xc/bin/hppa-linux-gcc -nostdlib -nostartfiles -o /Develop/parisc-linux/build/glibc/iconv/iconvconfig
-Wl,-dynamic-linker=/opt/palinux/hppa-linux/lib/ld.so.1 /Develop/parisc-linux/build/glibc/csu/crt1.o
/Develop/parisc-linux/build/glibc/csu/crti.o `/Develop/parisc-linux/xc/bin/hppa-linux-gcc
--print-file-name=crtbegin.o` /Develop/parisc-linux/build/glibc/iconv/iconvconfig.o
/Develop/parisc-linux/build/glibc/iconv/strtab.o /Develop/parisc-linux/build/glibc/iconv/xmalloc.o
/Develop/parisc-linux/build/glibc/iconv/hash-string.o -Wl,-rpath-link=/Develop/parisc-linux/build/glibc:/Develop/parisc-linux/build/glibc/math:/Develop/parisc-linux/build/glibc/elf:/Develop/parisc-linux/build/glibc/dlfcn:/Develop/parisc-linux/build/gl ibc/nss:/Develop/parisc-linux/build/glibc/nis:/Develop/parisc-linux/build/glibc/rt:/Develop/parisc-linux/build/glibc/resolv:/Develop/parisc-linux/build/glibc/crypt:/Develop/parisc-linux/build/glibc/linuxthreads /Develop/parisc-linux/build/glibc/libc.so.6 /Develop/parisc-linux/build/glibc/libc_nonshared.a
-lgcc /Develop/parisc-linux/xc/bin/hppa-linux-gcc --print-file-name=crtend.o
/Develop/parisc-linux/build/glibc/csu/crtn.o
/Develop/parisc-linux/build/glibc/elf/ld.so.1: undefined reference to `set_dp'
collect2: ld returned 1 exit status
make[2]: *** [/Develop/parisc-linux/build/glibc/iconv/iconvconfig] Error
1
make[2]: Leaving directory `/Develop/parisc-linux/sources/glibc/iconv'
make[1]: *** [iconv/others] Error 2
make[1]: Leaving directory `/Develop/parisc-linux/sources/glibc'
make: *** [all] Error 2
the glibc src cames from last debian pkg with patches applied and configured with following options:
# unset LD_LIBRARY_PATH; unset LD_RUN_PATH; export CC=/Develop/parisc-linux/xc/bin/hppa-linux-gcc; export CLFAGS="-O2 -g"; export PATH="/Develop/parisc-linux/xc/bin:$PATH"; /Develop/parisc-linux/sources/glibc/configure --target=hppa-linux --host=hppa-linux --build=hppa-linux --prefix=/opt/palinux/hppa-linux --without-cvs --disable-profile --enable-hacker-mode --enable-add-ons=linuxthreads --with-headers=/Develop/parisc-linux/sources/linux/include
and the gcc-snapshot sources cames from the latest gcc-scnapshot-20040110 debian pkg and the 'preliminary x compiler' is configured with following options:
# export PATH="/Develop/parisc-linux/xc/bin:$PATH"; /Develop/parisc-linux/sources/gcc/configure --target=hppa-linux --host=hppa-linux --build=hppa-linux --prefix=/Develop/parisc-linux/xc --disable-shared --disable-nls --enable-languages=c
Any idea?
Thanks in advance,
Joel
Quoted 9 lines
-- Original Message --
Date: Fri, 09 Jan 2004 20:37:07 +0000
From: Joel Soete <[email protected]>
To: Carlos O'Donell <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)Joel Soete wrote:
[snip]
Quoted 1 line
(but I don't much retry because of gnu pserver cvs pb; in the mean time
I
Quoted 2 lines
read that new anonymous access would be with ssh, even though last weekend it was not yet operational?)
[snip]
CVSROOT=":ext:anoncvs@subve
Quoted 1 line
sions.gnu.org:/cvsroot/gcc"
seems to be operational now with CVS_RSH="ssh"
hth,
Joel
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listi
Quoted 1 line
fo/parisc-linux
-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 €/mois! L'Internet rapide, c'est pour tout le monde.
http://reg.tiscali.be/default.asp?lg=fr
Joel Soete wrote:
[snip]
Quoted 3 lines
(but I don't much retry because of gnu pserver cvs pb; in the mean time I read that new anonymous access would be with ssh, even though last weekend it was not yet operational?)
[snip]
CVSROOT=":ext:[email protected]:/cvsroot/gcc"
seems to be operational now with CVS_RSH="ssh"
hth,
Joel