Re: Where is sparc64-linux-ld?
On Sun, Sep 05, 1999 at 11:38:47PM +0200, Eric Delaunay wrote: > Not really useful (could be ln -s /usr/sparc-linux . ?) > In effect, ld on sparc32 arch tries to create sparc32 binaries, not sparc64 > ones unless "-m elf64_sparc" is provided on the command line. > The makefiles in linux kernel sources tree don't call ld like above but just > sparc64-linux-ld. Therefore I have had to replace the link with a script to > put the -m argument in front of the command line. I'm using kernel-package and the only thing I have linked is /usr/sparc-linux to "." else when supplying elf64_sparc, it can't find the linker scripts (bug in binutils IMO). The names of the bintutils that the kernel looks for for sparc64 is just a side affect of how the people doing the development had their systems setup (which is why kernel-package passes args to the make to overrride the defaults so that it works properly, except for the sparc-linux link). However on my system, even the standard kernel make adds -melf64_sparc to the linker command line. > I could say this a bug because sparc64-linux-ld should always create sparc64 > binaries, not sparc32 ones by default, unless -m elf32_sparc is provided on > the > command line. > I don't know however where to fix it: no package provide sparc64-linux-xxx > alternatives yet (good candidate could be egcs64). Once I get this gcc setup, egcs64 will soon become obsolete. Until then it should serve to build sparc64 kernels (using the sparc-linux link and kernel-package). Ben
Re: Where is sparc64-linux-ld?
Ben Collins wrote: > On Sun, Sep 05, 1999 at 05:27:03PM +0200, Eric Delaunay wrote: > > Ben Collins wrote: > > > On Fri, Aug 13, 1999 at 08:51:35PM +0200, Samuel Tardieu wrote: > > > > When recompiling a kernel with "make-kpkg --arch sparc64 ..." on an > > > > Ultra5: > > > > > > > > sparc64-linux-ld -r -o kernel.o signal.o ksyms.o sched.o dma.o fork.o > > > > exec_domain.o panic.o printk.o sys.o module.o exit.o itimer.o info.o > > > > time.o softirq.o resource.o sysctl.o acct.o capability.o kmod.o > > > > make[3]: sparc64-linux-ld: Command not found > > > > > > > > Where can I find it? > > > > > > as root: > > > ln -s ld /usr/bin/sparc64-linux-ld > > > ln -s as /usr/bin/sparc64-linux-as > > > > The next one is ar. > > The actual fix for ld is to symlink /usr/sparc-linux to . > > ln -s . /usr/sparc-linux > > This allows ld to find the correct linker scripts. Not really useful (could be ln -s /usr/sparc-linux . ?) In effect, ld on sparc32 arch tries to create sparc32 binaries, not sparc64 ones unless "-m elf64_sparc" is provided on the command line. The makefiles in linux kernel sources tree don't call ld like above but just sparc64-linux-ld. Therefore I have had to replace the link with a script to put the -m argument in front of the command line. I could say this a bug because sparc64-linux-ld should always create sparc64 binaries, not sparc32 ones by default, unless -m elf32_sparc is provided on the command line. I don't know however where to fix it: no package provide sparc64-linux-xxx alternatives yet (good candidate could be egcs64). Regards. PS: I forgot nm -> sparc64-linux-nm in the list above. -- Eric Delaunay | "La guerre justifie l'existence des militaires. [EMAIL PROTECTED] | En les supprimant." Henri Jeanson (1900-1970)
Re: Pthread brokenness
On 5 Sep 1999, Mark W. Eichin wrote: > hmm, I updated a months-old unstable sparc SS1+, and now sshd spins, > apt-get spins sometimes (rolling back to slink apt-get helped some, > but not enough; for now, I just run it under (limit cputime 2min) so > it dies and I run it again :-) The latest sparc APT 0.3.12 should not use pthreads and advoid this little problem.. Nobody quite knows what it is, only happens on some kind of sparcs. Jason
Re: Bug in dynamic linker
Ben Collins <[EMAIL PROTECTED]> writes: > On Sun, Sep 05, 1999 at 08:21:19PM +0100, [EMAIL PROTECTED] wrote: > > > > Thanks Alex that ld works for me too. Can we have on offical rebuild > > anybody? > > > > Sorry, but we can't have an ld that does not have sparc64 in it. > exactly, that's why we need a rebuild. it took about 12 hours to compile binutils on my ipx and i don't plan to do it again. however i will gladly test a binutils package with sparc64 enabled. it shouldn't take too long to compile on a real machine. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
pb compiling kernel 2.2.12 on SparcClassic
I get the following error while compiling the kernel 2.2.12 for sparc64 on a sparc32 arch : sparc64-linux-gcc -D__KERNEL__ -I/home/tmp/linux-2.2.12/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 -fcall-used-g5 -fcall-used-g7 -Wno-sign-compare -c -o 3c59x.o 3c59x.c ../../gcc/config/sparc/sparc.c:1174: Internal compiler error in function sparc_emit_set_const32 cpp: output pipe has been closed My system is running 2.0.35 on a SparcClassic with 24MB RAM, 64MB swap, full slink except latest egcs64 19980921-3. Any help appreciated. Regards. PS: I can provide you strace of the program if you need. -- Eric Delaunay | "La guerre justifie l'existence des militaires. [EMAIL PROTECTED] | En les supprimant." Henri Jeanson (1900-1970)
Re: Bug in dynamic linker
On Sun, Sep 05, 1999 at 08:21:19PM +0100, [EMAIL PROTECTED] wrote: > > Alex Romosan wrote: > >i took the redhat binutils package and coverted it with alien. then i > >recompiled binutils on my system. you can get the recompiled debian > >package by anonymous ftp from ftp://caliban.lbl.gov/pub/debian/sparc. > >it doesn't have the spar64 emulation though. but at least i can link > >programs again. > > Thanks Alex that ld works for me too. Can we have on offical rebuild anybody? > > Scott Sorry, but we can't have an ld that does not have sparc64 in it. I am working on glibc 2.1.2 right now, so be patient. Ben
Re: Bug in dynamic linker
Alex Romosan wrote: >i took the redhat binutils package and coverted it with alien. then i >recompiled binutils on my system. you can get the recompiled debian >package by anonymous ftp from ftp://caliban.lbl.gov/pub/debian/sparc. >it doesn't have the spar64 emulation though. but at least i can link >programs again. Thanks Alex that ld works for me too. Can we have on offical rebuild anybody? Scott talk21 your FREE portable and private address on the net at http://www.talk21.com
Re: Pthread brokenness
hmm, I updated a months-old unstable sparc SS1+, and now sshd spins, apt-get spins sometimes (rolling back to slink apt-get helped some, but not enough; for now, I just run it under (limit cputime 2min) so it dies and I run it again :-) This is with a 2.2.1 kernel; 2.2.9 'made things worse' but I don't see anything newer on the debian.midco.net rsync mirror at least.
Re: Bug in dynamic linker
[EMAIL PROTECTED] writes: > This looks like the problem I'm having. > I sent an strace of it to the list a while back. > Can someone who has a working ld make it available somewhere. > Without a working ld is difficult to build a working ld ;-) > i took the redhat binutils package and coverted it with alien. then i recompiled binutils on my system. you can get the recompiled debian package by anonymous ftp from ftp://caliban.lbl.gov/pub/debian/sparc. it doesn't have the spar64 emulation though. but at least i can link programs again. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
Re: Where is sparc64-linux-ld?
On Sun, Sep 05, 1999 at 05:27:03PM +0200, Eric Delaunay wrote: > Ben Collins wrote: > > On Fri, Aug 13, 1999 at 08:51:35PM +0200, Samuel Tardieu wrote: > > > When recompiling a kernel with "make-kpkg --arch sparc64 ..." on an > > > Ultra5: > > > > > > sparc64-linux-ld -r -o kernel.o signal.o ksyms.o sched.o dma.o fork.o > > > exec_domain.o panic.o printk.o sys.o module.o exit.o itimer.o info.o > > > time.o softirq.o resource.o sysctl.o acct.o capability.o kmod.o > > > make[3]: sparc64-linux-ld: Command not found > > > > > > Where can I find it? > > > > as root: > > ln -s ld /usr/bin/sparc64-linux-ld > > ln -s as /usr/bin/sparc64-linux-as > > The next one is ar. The actual fix for ld is to symlink /usr/sparc-linux to . ln -s . /usr/sparc-linux This allows ld to find the correct linker scripts.
Re: Where is sparc64-linux-ld?
Ben Collins wrote: > On Fri, Aug 13, 1999 at 08:51:35PM +0200, Samuel Tardieu wrote: > > When recompiling a kernel with "make-kpkg --arch sparc64 ..." on an > > Ultra5: > > > > sparc64-linux-ld -r -o kernel.o signal.o ksyms.o sched.o dma.o fork.o > > exec_domain.o panic.o printk.o sys.o module.o exit.o itimer.o info.o time.o > > softirq.o resource.o sysctl.o acct.o capability.o kmod.o > > make[3]: sparc64-linux-ld: Command not found > > > > Where can I find it? > > as root: > ln -s ld /usr/bin/sparc64-linux-ld > ln -s as /usr/bin/sparc64-linux-as The next one is ar. > The ld that comes with binutils will handle elf64, but for some reason, > the kernel looks for ld with the sparc64-linux- prefix. Hmm, on sparc32 arch, after I made the appropriate link, ld is giving me the following error. sparc64-linux-ld -r -o kernel.o signal.o ksyms.o sched.o dma.o fork.o exec_domain.o panic.o printk.o sys.o module.o exit.o itimer.o info.o time.o softirq.o resource.o sysctl.o acct.o capability.o kmod.o sparc64-linux-ld: warning: sparc:v9 architecture of input file `signal.o' is incompatible with sparc output sparc64-linux-ld: warning: sparc:v9 architecture of input file `ksyms.o' is incompatible with sparc output sparc64-linux-ld: warning: sparc:v9a architecture of input file `sched.o' is incompatible with sparc output ... make[3]: *** [kernel.o] Segmentation fault I have had to replace sparc64-linux-ld with this script to work: #!/bin/sh ld -m elf64_sparc -b elf64-sparc "$@" Note that I just installed egcs64 from potato on a slink machine. I didn't upgrade binutils. It could be the problem here. > NOTE: if you want to build sparc64 kernels with kernel-package, use this > format: > > make-kpkg --subarch=sun4u --arch_in_name ... But you need kernel-package from potato. Slink is still using the old style. Regards -- Eric Delaunay | "La guerre justifie l'existence des militaires. [EMAIL PROTECTED] | En les supprimant." Henri Jeanson (1900-1970)
Re: Bug in dynamic linker
This looks like the problem I'm having. I sent an strace of it to the list a while back. Can someone who has a working ld make it available somewhere. Without a working ld is difficult to build a working ld ;-) Scott talk21 your FREE portable and private address on the net at http://www.talk21.com
Re: xserver-sun* breakage.
On Sun, Sep 05, 1999 at 01:03:18AM -0400, Branden Robinson wrote: > Can someone check into this for me? > > 1) Does installing xfonts-pex make this problem go away? > > 2) Can the PEX fonts be served from a font server? 1 is no, 2 I cannot verify. I can tell you that an strace some one produced show's PEX actually opening the font it claims is missing, reading from it twice, closing, and the claiming it could not read it. Ben
Re: xserver-sun* breakage.
On Sat, Sep 04, 1999 at 10:57:39PM -0700, Alex Romosan wrote: > Branden Robinson <[EMAIL PROTECTED]> writes: > > > Can someone check into this for me? > > > > 1) Does installing xfonts-pex make this problem go away? > > > > no, it doesn't. the crash has nothing to do with not finding the > fonts. i ran the server under the debugger, and it crashed when it was > trying to free some memory, presumably because of a bad pointer. > anyway, as i said in a different message on this list, i got the xsun > server to run by installing a new version of glibc which i compiled > myself. i think the problem is in glibc actually. maybe the old egcs > compiler used to compile the version currently in the sparc > distribution produced some bad code. i wonder if recompiling it with > gcc 2.95.1 will make the problem go away. Sorry, I don't track debian-sparc so I was unaware of that message. -- G. Branden Robinson | Debian GNU/Linux |"Bother," said Pooh, as he was [EMAIL PROTECTED] |assimilated by the Borg. cartoon.ecn.purdue.edu/~branden/ | pgpISJ5X8yp8Y.pgp Description: PGP signature
Re: xserver-sun* breakage.
Branden Robinson <[EMAIL PROTECTED]> writes: > Can someone check into this for me? > > 1) Does installing xfonts-pex make this problem go away? > no, it doesn't. the crash has nothing to do with not finding the fonts. i ran the server under the debugger, and it crashed when it was trying to free some memory, presumably because of a bad pointer. anyway, as i said in a different message on this list, i got the xsun server to run by installing a new version of glibc which i compiled myself. i think the problem is in glibc actually. maybe the old egcs compiler used to compile the version currently in the sparc distribution produced some bad code. i wonder if recompiling it with gcc 2.95.1 will make the problem go away. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
Re: xserver-sun* breakage.
On Thu, Sep 02, 1999 at 07:18:08PM -0400, Ben Collins wrote: > Try installing the package xfonts-pex. > > Branden, isn't the X upgrade supposed to handle depending on the correct > fonts? What is it the actually is using the PEX fonts? Here's my theory for what's going on: * XFree86 servers have some of their dynamically loaded modules, like PEX, separate from the server binary; for them, the PEX extension is in the "xext" package. * The Xsun servers compile all their extensions right into the binary and don't dynamically load any. At the very least, they don't dynamically load PEX. * XFree86 servers give a warning, but do not die, if they load the PEX extension module but cannot find the sample fonts, which we keep in xfonts-pex. (Read the package description of xfonts-pex). Can someone check into this for me? 1) Does installing xfonts-pex make this problem go away? 2) Can the PEX fonts be served from a font server? It is important to have both of these questions answered before I can act. If 1) is yes but 2) is no, then the xserver-xsun* packages must Depend: on xfonts-pex. If both 1) and 2) are yes, then it's just going to have to be a point of information for Xsun server users and I will update documentation to reflect this, including the package descriptions. If both 1) and 2) are no, then we in fact have a more serious problem and my theory is totally wrong. Two things to keep in mind: *) I can't claim a dependency on "working-font-server" for obvious reasons. There have been many complaining bugs filed against the XFree86 packages because the packaging system people shoot themselves in the foot by not installing any fonts at all and not pointing the X server to a font server. This is a user education issue. *) I don't know how actively maintained the Xsun servers are. Please be sure to CC the bug number in my CC line above with any substantive information on this bug. -- G. Branden Robinson |Communism is just one step on the long Debian GNU/Linux |road from capitalism to capitalism. [EMAIL PROTECTED] |-- Russian saying cartoon.ecn.purdue.edu/~branden/ | pgpRO0a5xRQ3n.pgp Description: PGP signature
corrupt iproute_990630-1.deb
I am removing dists/potato/main/binary-sparc/net/iproute_990630-1.deb as it is corrupt: $ dpkg-deb --contents iproute_990630-1.deb | tar tf - dpkg-deb (subprocess): unexpected end of file in member data in iproute_990630-1.deb gzip: stdin: unexpected end of file tar: Archive - EOF not on block boundary tar: Error is not recoverable: exiting now dpkg-deb: subprocess tar returned error exit status 2 tar: Archive - EOF not on block boundary tar: Error is not recoverable: exiting now [status 2]
