On Fri, Oct 27, 2006 at 09:48:43AM -0400, Camm Maguire wrote:
> > FWIW, after tracking down the last header problem on alpha I let the test
> > build continue on through to see if there were any other problems. Aside
> > from taking a long time to build, it now seems to be getting stuck in an
> > infinite loop running raw_pcl_gcl -- according to strace, trying to call a
> > syscall #513 which AFAIK does not exist on alpha, which then fails
> > repeatedly with errno 103 (ECONNABORTED). I have no idea what any of this
> > is -- I /could/ give it to the buildd to try, but I really don't have any
> > reason to believe it will build any better there.
> > Do you have any idea what this syscall is supposed to be? Are we looking at
> > a glibc bug here?
> This is my guess. If I could get access to a system, I could provide
> more information. Any idea of when sid chroots on escher (or other)
> might become available again?
No, sorry; though I'm currently working on getting some kernel patches in
that would let Debian support another class of higher-end alphas, which
might help us get a faster (and accessible) porter system.
Does gcl make any syscalls itself? That would be a significant pointer in
the direction of glibc if it doesn't.
> This code built quite recently on alpha. I'm particularly interested
> in mips and alpha, as they test new bfd object relocation code put
> into gcl recently. I'd like to make sure there is no regression here,
> though I suspect none.
> If there were a problem here, you would see it before raw_pcl_gcl.
> There is noting this binary does but run some very simple
> initialization code, and then dump its image with unexec. saved_gcl
> and saved_mod_gcl, already produced, use the same dumping code, so I
> don't suspect anything here either.
> It appears that some constant specifying the syscall has gotten messed
> up on alpha.
> If I can get access, I'd be happy to test. Otherwise, here is what
> needs doing:
> ./configure --enable-ansi -enable-debug && make
This just gives me a build failure.
gcc -c -g -fsigned-char -pipe -Wall -g -mieee
-I/home/devel/release/gclcvs-2.7.0/o -I../h -I../gcl-tk sfasl.c
In file included from sfaslbfd.c:175,
from sfasl.c:43:
sfaslbfd_alpha.c: In function ‘alphaelf_install_patches’:
sfaslbfd_alpha.c:162: error: assignment of read-only location
sfaslbfd_alpha.c:168: error: assignment of read-only location
sfaslbfd_alpha.c:173: error: assignment of read-only location
sfaslbfd_alpha.c:178: error: assignment of read-only location
sfaslbfd_alpha.c: In function ‘alphaelf_init_got_info’:
sfaslbfd_alpha.c:232: error: too few arguments to function ‘bfd_hash_table_init’
make[1]: *** [sfasl.o] Error 1
make[1]: Leaving directory `/home/devel/release/gclcvs-2.7.0/o'
make: *** [unixport/saved_pre_gcl] Error 2
> Come to think of it, this bug might have just appeared on alpha too:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387498
No, it's not the same bug; the test case for system() works fine on my alpha
when compiling with -pg.
Here's the full cycle from a current strace:
fork() = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
sigreturn() = ? (mask now [CHLD])
syscall_513(0x200006816e8, 0x80000, 0x11f269038, 0x1, 0, 0x1223400f0,
0xfffffc0001aa4000, 0x200005b6a30, 0x8, 0x1fd, 0x20000557c58, 0, 0x7b0a75b,
0x20000689740, 0x11f268fa0, 0, 0x4082904a484b2a29, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0x3fe0000000000000, 0x154e, 0x40b54ee660000000, 0x40b54e6660000000, 0,
0x3fe6666660000000 <unfinished ...>
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
<... syscall_513 resumed> ) = 0x67
[repeat ad infinitum]
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
