Re: x32 “half”arrived… now what?
Am 11.06.2013 16:09, schrieb Thorsten Glaser: Daniel Schepler dschepler at gmail.com writes: (Sorry about the lack of threading... for some reason I'm unable to find the links to download mbox archives for replying to the messages.) https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/getarticle?rev=HEAD Just call that with either the Message-ID sans , or the GMane group and article number (separated with / like in URIs from GMane also works), and it’ll append to the unix-format mailbox in ~/mail/x which you can just reply to with Pine. In response to Adam's comments about debootstrap not working because findutils FTBFS: Yes, I'm aware of that, and for now you have to include unreleased as Well, that’s normal for Debian-Ports, nothing to apologise for. For the reason we still have multilib packages instead of relying on multiarch, see the thread starting at http://lists.debian.org/debian-devel/2013/05/msg00692.html . (The one good argument there IMO is that dropping libc6-i386 in favor of libc6:i386 could cause difficulties autobuilding gcc-multilib when e.g. libgcc1:i386 and Why is gcc built multi-lib anyway? because developers expect to work it. there is a lot of code which just uses -m32/-m64 which should not deliberately broken. I see *no* benefit there that wouldn’t also be possible with Multi-Arch on the users’ system or is discriminatory (e.g. why should gdb:amd64 support natively debugging i386 binaries but not e.g. armhf binaries). I never understood multilib and still wonder why it’s around. Maybe there’s a good reason, but other than a desire to keep it, I’ve missed anything about that yet… Multi-Arch isn't there yet. And even if it is, the multilib builds should be kept for some more releases. There is a lot to do on the Debian side, and on the upstream side. So maybe it helps your understanding to get the required patches upstream to get multilib working with a multiarch setup. On the contrary, i386 sid users’ systems now end up with this: -rw--- 1 root root 159744 Jun 6 10:23 core /core: ELF 32-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/libx32/ld-linux-x32.so.2' This file is generated quite often, along with the aforementioned kernel messages. I think this is not acceptable. but now this would be discriminatory, you get these for other architectures as well. just set up a cross build environment. Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b82a63.7070...@debian.org
Re: x32 “half”arrived… now what?
Matthias Klose wrote: Multi-Arch isn't there yet. And even if it is, the multilib builds should be kept for some more releases. There is a lot to do on the Debian side, and on the upstream side. So maybe it helps your understanding to get the required patches upstream to get multilib working with a multiarch setup. OK, maybe this weekend I'll work on creating patches to the gcc packaging to allow gcc-multilib to use multiarch libraries. My basic idea right now would be something like: * Both lib32gcc1:amd64 and libgcc1:i386 provide an alternative for /usr/lib/gcc/i386-linux-gnu/libgcc_s.so pointing to its version of libgcc_s.so.*, with libgcc1:i386 having the higher priority. * The gcc-4.8 packaging (for lib32gcc-4.8-dev:amd64) makes /usr/lib/gcc/x86_64-linux-gnu/4.8/32/libgcc_s.so a symlink to /usr/lib/gcc/i386-linux-gnu/libgcc_s.so. * Then the rest is just adjusting dependencies on lib32gcc1 to alternatives libgcc1:i386 | lib32gcc1, etc. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2985791.MzHV9NCblm@frobozz
Re: x32 “half”arrived… now what?
On Wed, Jun 12, 2013 at 09:59:31AM +0200, Matthias Klose wrote: Why is gcc built multi-lib anyway? because developers expect to work it. there is a lot of code which just uses -m32/-m64 which should not deliberately broken. This explains i386/amd64 multilib, which, while an ugly thing that needs to die, can be indeed used by old build systems. This does not provide a reason to introduce x32 multilib, though. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130612171853.ga1...@angband.pl
Re: x32 “half”arrived… now what?
On Wed, Jun 12, 2013 at 09:45:21AM -0700, Daniel Schepler wrote: Matthias Klose wrote: Multi-Arch isn't there yet. And even if it is, the multilib builds should be kept for some more releases. There is a lot to do on the Debian side, and on the upstream side. So maybe it helps your understanding to get the required patches upstream to get multilib working with a multiarch setup. OK, maybe this weekend I'll work on creating patches to the gcc packaging to allow gcc-multilib to use multiarch libraries. My basic idea right now would be something like: * Both lib32gcc1:amd64 and libgcc1:i386 provide an alternative for /usr/lib/gcc/i386-linux-gnu/libgcc_s.so pointing to its version of libgcc_s.so.*, with libgcc1:i386 having the higher priority. Wouldn't it be easier to have lib32gcc1:amd64 merely depend on libgcc1:i386? It'd save a massive amount of complexity. For things that build-depend on lib32, we could mandate that amd64 buildds must have i386 multiarch enabled. This is ugly special-casing, but so less ugly than status quo. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130612172539.gb1...@angband.pl
Re: x32 “half”arrived… now what?
Adam Borowski wrote: Wouldn't it be easier to have lib32gcc1:amd64 merely depend on libgcc1:i386? It'd save a massive amount of complexity. But that reintroduces the problem which convinced me there's a reason to keep lib32gcc1 in the first place: suppose libgcc1:i386 and libgcc1:amd64 get out of sync. That makes it impossible to autobuild gcc on the out-of-date architecture to correct the situation. (That's probably more of an issue on other slower architectures like mips/mipsel.) -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2939148.PGM52SdYmI@frobozz
Re: x32 “half”arrived… now what?
Am 12.06.2013 19:18, schrieb Adam Borowski: On Wed, Jun 12, 2013 at 09:59:31AM +0200, Matthias Klose wrote: Why is gcc built multi-lib anyway? because developers expect to work it. there is a lot of code which just uses -m32/-m64 which should not deliberately broken. This explains i386/amd64 multilib, which, while an ugly thing that needs to die, can be indeed used by old build systems. this is your opinion, which I don't share. multiarch was proposed a decade ago, yet it is not there as a replacement. it is there to provide buildabilty of our 64bit kernels for s390, sparc, powerpc, mips. So we do rely on this feature, and calling it ugly is your opinion. This does not provide a reason to introduce x32 multilib, though. it's good to have a working toolchain to run some tests, benchmarks and other stuff for x32. having x32 as a foreign architecture is almost impossible as long as x32 is not in the archive. Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b8bb97.7060...@debian.org
Re: x32 “half”arrived… now what?
Am 12.06.2013 19:25, schrieb Adam Borowski: On Wed, Jun 12, 2013 at 09:45:21AM -0700, Daniel Schepler wrote: Matthias Klose wrote: Multi-Arch isn't there yet. And even if it is, the multilib builds should be kept for some more releases. There is a lot to do on the Debian side, and on the upstream side. So maybe it helps your understanding to get the required patches upstream to get multilib working with a multiarch setup. OK, maybe this weekend I'll work on creating patches to the gcc packaging to allow gcc-multilib to use multiarch libraries. My basic idea right now would be something like: * Both lib32gcc1:amd64 and libgcc1:i386 provide an alternative for /usr/lib/gcc/i386-linux-gnu/libgcc_s.so pointing to its version of libgcc_s.so.*, with libgcc1:i386 having the higher priority. Wouldn't it be easier to have lib32gcc1:amd64 merely depend on libgcc1:i386? It'd save a massive amount of complexity. For things that build-depend on lib32, we could mandate that amd64 buildds must have i386 multiarch enabled. This is ugly special-casing, but so less ugly than status quo. I didn't see you working on the toolchain in the past, neither upstream nor in Debian. As Daniel pointed out, your proposals are a bit half-baked, so please come up with something working and/or tested. thanks, Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b8bc6c.5020...@debian.org
Re: x32 “half”arrived… now what?
Daniel Schepler dschepler at gmail.com writes: (Sorry about the lack of threading... for some reason I'm unable to find the links to download mbox archives for replying to the messages.) https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/getarticle?rev=HEAD Just call that with either the Message-ID sans , or the GMane group and article number (separated with / like in URIs from GMane also works), and it’ll append to the unix-format mailbox in ~/mail/x which you can just reply to with Pine. In response to Adam's comments about debootstrap not working because findutils FTBFS: Yes, I'm aware of that, and for now you have to include unreleased as Well, that’s normal for Debian-Ports, nothing to apologise for. For the reason we still have multilib packages instead of relying on multiarch, see the thread starting at http://lists.debian.org/debian-devel/2013/05/msg00692.html . (The one good argument there IMO is that dropping libc6-i386 in favor of libc6:i386 could cause difficulties autobuilding gcc-multilib when e.g. libgcc1:i386 and Why is gcc built multi-lib anyway? I see *no* benefit there that wouldn’t also be possible with Multi-Arch on the users’ system or is discriminatory (e.g. why should gdb:amd64 support natively debugging i386 binaries but not e.g. armhf binaries). I never understood multilib and still wonder why it’s around. Maybe there’s a good reason, but other than a desire to keep it, I’ve missed anything about that yet… On the contrary, i386 sid users’ systems now end up with this: -rw--- 1 root root 159744 Jun 6 10:23 core /core: ELF 32-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/libx32/ld-linux-x32.so.2' This file is generated quite often, along with the aforementioned kernel messages. I think this is not acceptable. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130611t160404-...@post.gmane.org
Re: x32 “half” arrived… now what?
On 06/06/13 21:10, Adam Borowski wrote: On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote: Be aware that x32 has sizeof(time_t) sizeof(long), so you should expect SUBSTANTIAL porting of packages to be required. Particularly since that arrangement is explicitly unsupported by the GNU coding standards: Similarly, don't make any effort to cater to the possibility that `long' will be smaller than predefined types like `size_t'. It was the case in old versions of gnulib, but appears to be no more. Too bad, quite a few packages ship embedded copies of ancient gnulib. I just submitted a patch in one such case (#711412), it might possibly apply elsewhere. It was Linus' decree that no new ABI is allowed to suffer from the Y2k38 bug even if its word size is 32 bit, and I'd say he's right. This means that this problem will bite us the next time another 32 bit arch comes, so there's no excuse to use this as an argument against x32. Would a better solution not have been to make long 64 bits? This is a perfectly reasonable thing to do on a 32 bit arch, it would avoid the above problem and since the widespread adoption of 64 bit systems most of the cases of software expecting long to be 32 bits should have been fixed. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ueck8a-po6@silverstone.rilynn.me.uk
Re: x32 “half” arrived… now what?
On Tue, 2013-06-11 at 21:04 +0100, Roger Lynn wrote: On 06/06/13 21:10, Adam Borowski wrote: On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote: Be aware that x32 has sizeof(time_t) sizeof(long), so you should expect SUBSTANTIAL porting of packages to be required. Particularly since that arrangement is explicitly unsupported by the GNU coding standards: Similarly, don't make any effort to cater to the possibility that `long' will be smaller than predefined types like `size_t'. It was the case in old versions of gnulib, but appears to be no more. Too bad, quite a few packages ship embedded copies of ancient gnulib. I just submitted a patch in one such case (#711412), it might possibly apply elsewhere. It was Linus' decree that no new ABI is allowed to suffer from the Y2k38 bug even if its word size is 32 bit, and I'd say he's right. This means that this problem will bite us the next time another 32 bit arch comes, so there's no excuse to use this as an argument against x32. Would a better solution not have been to make long 64 bits? This is a perfectly reasonable thing to do on a 32 bit arch, it would avoid the above problem and since the widespread adoption of 64 bit systems most of the cases of software expecting long to be 32 bits should have been fixed. sizeof(long) != sizeof(void *) will break *lots* of code. Ben. -- Ben Hutchings If God had intended Man to program, we'd have been born with serial I/O ports. signature.asc Description: This is a digitally signed message part
Re: x32 “half” arrived… now what?
On Tue, Jun 11, 2013 at 10:36:48PM +0100, Ben Hutchings wrote: On Tue, 2013-06-11 at 21:04 +0100, Roger Lynn wrote: On 06/06/13 21:10, Adam Borowski wrote: On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote: Be aware that x32 has sizeof(time_t) sizeof(long), so you should expect SUBSTANTIAL porting of packages to be required. Particularly since that arrangement is explicitly unsupported by the GNU coding standards: Similarly, don't make any effort to cater to the possibility that `long' will be smaller than predefined types like `size_t'. It was the case in old versions of gnulib, but appears to be no more. Too bad, quite a few packages ship embedded copies of ancient gnulib. I just submitted a patch in one such case (#711412), it might possibly apply elsewhere. It was Linus' decree that no new ABI is allowed to suffer from the Y2k38 bug even if its word size is 32 bit, and I'd say he's right. This means that this problem will bite us the next time another 32 bit arch comes, so there's no excuse to use this as an argument against x32. Would a better solution not have been to make long 64 bits? This is a perfectly reasonable thing to do on a 32 bit arch, it would avoid the above problem and since the widespread adoption of 64 bit systems most of the cases of software expecting long to be 32 bits should have been fixed. sizeof(long) != sizeof(void *) will break *lots* of code. Odd, you'd have thought that people would have learnt from their mistakes after fixing their sizeof(int) == sizeof(void*) assumptions. faith_in_humanity--; -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: x32 “half” arrived… now what?
On Fri, Jun 7, 2013 at 11:03 PM, Daniel Schepler wrote: (Sorry about the lack of threading... for some reason I'm unable to find the links to download mbox archives for replying to the messages.) The Debian HTML archives list message-ids and have mailto: reply links that include References/In-Reply-To headers that include them. So, just click the appropriate reply link and it will work fine as long as you have an MUA that supports mailto: links. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6ghtphvftgfey+-kwz8-r2zafdsm2rpokzfzxve6bj...@mail.gmail.com
Re: x32 “half”arrived… now what?
Russ Allbery rra at debian.org writes: Be aware that x32 has sizeof(time_t) sizeof(long), so you should expect So has MirBSD/i386 (since 2004-06-19) and NetBSD (since roughly a year). Most frequent thing is format specifiers when struct tm.tm_year is time_t instead of long (which is a requirement for time_t to be able to round-trip through struct tm, which is required by quite some software). I did lose one of my PGP keys though – pgp-2.6.3in didn’t cope with the change and had the binary keyring format differ (and I haven’t found the floppy on which the backup was). Other than that, most things work. @Philipp: true about the stability-before-inclusion statement, but if I get x32 ldconfig run on an i386 system (not all of these run amd64 kernels anyway), things could use some polishing. The kernel thing… I guess the option just needs to be enabled at some point, though x32 *is* on dpo already, and the other dpo architectures are also supported… but the main “weird” thing right now is the presence of x32 stuff on a pure i386 system. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130607t114138-...@post.gmane.org
Re: x32 “half” arrived… now what?
(Sorry about the lack of threading... for some reason I'm unable to find the links to download mbox archives for replying to the messages.) In response to Adam's comments about debootstrap not working because findutils FTBFS: Yes, I'm aware of that, and for now you have to include unreleased as well using multistrap with the instructions at http://wiki.debian.org/X32Port . (And apologies for the inconvenience... That will also get you a newer version of binutils:x32 which makes elf32_x86_64 the default target -- which is really only important if your source package is using ld -r or otherwise running ld manually.) For the reason we still have multilib packages instead of relying on multiarch, see the thread starting at http://lists.debian.org/debian-devel/2013/05/msg00692.html . (The one good argument there IMO is that dropping libc6-i386 in favor of libc6:i386 could cause difficulties autobuilding gcc-multilib when e.g. libgcc1:i386 and libgcc1:amd64 get out of sync because of buildd delays. I still don't see any good reason to keep the other multilib packages like lib32gmp10.) In answer to Russ's concerns about sizeof(time_t) sizeof(long): that hasn't really been a major concern in my experience (the biggest impact is that it causes gobject-introspection to FTBFS -- #699024). The bigger porting concerns are code using x86_64 asm, and the fact that x32 doesn't support the sysctl(2) interface. On the latter point, I get the feeling that might be a result of another of Linus' decrees (new architectures shall not support this interface which was obsolete from the moment it was introduced), though that's just a pure guess. Oh, and then there's the multitude of build failures because of the package's copy of libtool being out of date. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2694027.5QWCrBo70u@frobozz
x32 “half” arrived… now what?
Hi! The latest sid upgrades produce dependencies on: ii libc6-dev-x322.17-5 i386 Embedded GNU C Library: X32 ABI Development Libraries for AMD64 ii libc6-x322.17-5 i386 Embedded GNU C Library: X32 ABI Shared libraries for AMD64 However, this leads to: [172219.469374] do_general_protection: 110 callbacks suppressed [172219.469451] traps: ld-linux-x32.so[2157] general protection ip:f7781e9d sp:fff7e5c8 error:0 in ld-2.17.so[f776b000+21000] [172219.485949] traps: ld-linux-x32.so[2183] general protection ip:f77b8e9d sp:ffc809b8 error:0 in ld-2.17.so[f77a2000+21000] [172219.777357] traps: ld-linux-x32.so[2655] general protection ip:f7774e9d sp:ffcd64e8 error:0 in ld-2.17.so[f775e000+21000] [172219.782583] traps: ld-linux-x32.so[2663] general protection ip:f77b7e9d sp:ffbb3868 error:0 in ld-2.17.so[f77a1000+21000] [172219.787692] traps: ld-linux-x32.so[2671] general protection ip:f7775e9d sp:ff8547b8 error:0 in ld-2.17.so[f775f000+21000] [172219.792750] traps: ld-linux-x32.so[2679] general protection ip:f7743e9d sp:ffef1328 error:0 in ld-2.17.so[f772d000+21000] [172219.797867] traps: ld-linux-x32.so[2687] general protection ip:f77c0e9d sp:ffdfa628 error:0 in ld-2.17.so[f77aa000+21000] [172219.802868] traps: ld-linux-x32.so[2695] general protection ip:f775ee9d sp:ffb47588 error:0 in ld-2.17.so[f7748000+21000] [172219.808083] traps: ld-linux-x32.so[2703] general protection ip:f7767e9d sp:ffe4ba18 error:0 in ld-2.17.so[f7751000+21000] [172219.813304] traps: ld-linux-x32.so[2711] general protection ip:f77b1e9d sp:fff23938 error:0 in ld-2.17.so[f779b000+21000] Also: tglase@tglase:~ $ fgrep X32 /boot/config-3.9-1-amd64 # CONFIG_X86_X32 is not set No idea whether this is deliberate or a bug, and if so, in which package… also, why is multilib stuff still installed when we have multiarch? I thought we could, finally, get rid of that? Never, ever, saw the need for it, either. No complaints against x32 per sé, I want to crossgrade there once it’s in, but for as long as it’s broken like this, it doesn’t make it look good. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.10.1306061020120.25...@tglase.lan.tarent.de
Re: x32 ???half??? arrived??? now what?
On Thu, Jun 06, 2013 at 10:23:14AM +0200, Thorsten Glaser wrote: tglase@tglase:~ $ fgrep X32 /boot/config-3.9-1-amd64 # CONFIG_X86_X32 is not set See http://wiki.debian.org/X32Port and http://lists.debian.org/debian-devel/2013/05/msg00355.html Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130606092715.ga27...@alf.mars
Re: x32 ???half??? arrived??? now what?
Helmut Grohne helmut at subdivi.de writes: http://lists.debian.org/debian-devel/2013/05/msg00355.html Ah okay. That one got lost in GMane’s threading because the original mail wasn’t posted in this newsgroup. I still think it schizo that x32 is only halfway in and the Linux kernel Debian team mostly sends signals that it wants to block the architecture altogether. And the multilibs thing… nobody seems to have commented on it either. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130606t153325-...@post.gmane.org
Re: x32 ???half??? arrived??? now what?
On Thu, Jun 06, 2013 at 11:27:15AM +0200, Helmut Grohne wrote: On Thu, Jun 06, 2013 at 10:23:14AM +0200, Thorsten Glaser wrote: tglase@tglase:~ $ fgrep X32 /boot/config-3.9-1-amd64 # CONFIG_X86_X32 is not set See http://wiki.debian.org/X32Port and http://lists.debian.org/debian-devel/2013/05/msg00355.html While I hope there will be reasons to enable this flag soon, the port isn't really ready yet. While with packages from the unofficial repository (less official than -ports, that is), a significant part of the archive has been autobuilt, using only packages from unstable is not even enough to debootstrap. Today, if you try: debootstrap --arch=x32 unstable . http://ftp.debian-ports.org/debian it will fail because of findutils. As of findutils, we have: * 4.4.2 in unstable, FTBFSes on x32 * 4.5.11 in experimental, works. I guess everyone assumed 4.5.11 will go to unstable soon and thus didn't bother patching the old version, but it's currently blocked at least by #704879 -- there's a long-deprecated extension that finally went away after some refactoring, and some things may still be using it. So if the port doesn't even debootstrap without jumping through extra hoops, having to recompile the kernel is not a big obstacle. Let's put some more work before bothering our kernel guys again. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130606153641.ga20...@angband.pl
Re: x32 ???half??? arrived??? now what?
On 2013-06-06 15:35, Thorsten Glaser wrote: I still think it schizo that x32 is only halfway in and the Linux kernel Debian team mostly sends signals that it wants to block the architecture altogether. And the multilibs thing… nobody seems to have commented on it either. Sometimes it helps if everything is stable before a new port is pushed. See armhf's linker location change that happened after we had it in the archive already. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aabfef17adc6b8c91334785a2368a...@hub.kern.lc
Re: x32 “half” arrived… now what?
Thorsten Glaser t.gla...@tarent.de writes: No complaints against x32 per sé, I want to crossgrade there once it’s in, but for as long as it’s broken like this, it doesn’t make it look good. Be aware that x32 has sizeof(time_t) sizeof(long), so you should expect SUBSTANTIAL porting of packages to be required. Particularly since that arrangement is explicitly unsupported by the GNU coding standards: Similarly, don't make any effort to cater to the possibility that `long' will be smaller than predefined types like `size_t'. Note that most of these problems will not show up as build failures, but as (generally silent) runtime corruption or crashes. It's not quite as bad as the porting required for large file support, but the consequences of not porting are worse. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ppvzch2f@windlord.stanford.edu
Re: x32 “half” arrived… now what?
On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote: Thorsten Glaser t.gla...@tarent.de writes: No complaints against x32 per sé, I want to crossgrade there once it’s in, but for as long as it’s broken like this, it doesn’t make it look good. Be aware that x32 has sizeof(time_t) sizeof(long), so you should expect SUBSTANTIAL porting of packages to be required. Particularly since that arrangement is explicitly unsupported by the GNU coding standards: Similarly, don't make any effort to cater to the possibility that `long' will be smaller than predefined types like `size_t'. It was the case in old versions of gnulib, but appears to be no more. Too bad, quite a few packages ship embedded copies of ancient gnulib. I just submitted a patch in one such case (#711412), it might possibly apply elsewhere. It was Linus' decree that no new ABI is allowed to suffer from the Y2k38 bug even if its word size is 32 bit, and I'd say he's right. This means that this problem will bite us the next time another 32 bit arch comes, so there's no excuse to use this as an argument against x32. It's not quite as bad as the porting required for large file support, but the consequences of not porting are worse. How come? I don't think runtime bugs that are not some kind of a Y2k38 bug are likely, and unlike i386 and the rest, they're actually fixable now. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130606200148.gc20...@angband.pl
Re: x32 “half” arrived… now what?
On Thu, Jun 6, 2013 at 22:01:48 +0200, Adam Borowski wrote: It was Linus' decree that no new ABI is allowed to suffer from the Y2k38 bug even if its word size is 32 bit, and I'd say he's right. This means that this problem will bite us the next time another 32 bit arch comes, so there's no excuse to use this as an argument against x32. And I'd say there's no excuse to introduce new 32bit archs, so I'm hoping there won't be a next time. Cheers, Julien signature.asc Description: Digital signature
Re: x32 “half” arrived… now what?
Adam Borowski kilob...@angband.pl writes: On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote: It's not quite as bad as the porting required for large file support, but the consequences of not porting are worse. How come? I don't think runtime bugs that are not some kind of a Y2k38 bug are likely, and unlike i386 and the rest, they're actually fixable now. Because when you store a 64-bit quantity in a 32-bit hole, the result is very frequently a security vulnerability or a runtime crash, and when you assume 64 bits of data on the stack is actually 32 bits, you get corruption when you read the next item on the stack. Consider stdargs functions that pass in a time_t and read back a long, or programs that use pointers to time_t and pointers to long interchangeably. If it were just data truncation, I would agree with you, and that's the case when the compiler knows all of the types involved and can do implicit or explicit casts. But the C type system has a ton of holes in them (in fact, implementing generic data structures generally requires punching holes in the type system), at which point the exact number of bits matters, and a lot of code has been written assuming sizeof(time_t) == sizeof(long). I agree that assumption is *wrong*, and it looks like NetBSD is ahead of us here and may be flushing out some of the problems already, but expect to find a lot of broken code. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hahb9dfc@windlord.stanford.edu
Re: x32 “half” arrived… now what?
On Thu, 2013-06-06 at 22:40 +0200, Julien Cristau wrote: On Thu, Jun 6, 2013 at 22:01:48 +0200, Adam Borowski wrote: It was Linus' decree that no new ABI is allowed to suffer from the Y2k38 bug even if its word size is 32 bit, and I'd say he's right. This means that this problem will bite us the next time another 32 bit arch comes, so there's no excuse to use this as an argument against x32. And I'd say there's no excuse to introduce new 32bit archs, so I'm hoping there won't be a next time. Brace yourself for arm32... Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers signature.asc Description: This is a digitally signed message part
