* Multi-arch @ 2006-05-17 9:22 Ludovic Brenta 2006-05-17 9:45 ` Multi-arch Georg Bauhaus ` (3 more replies) 0 siblings, 4 replies; 14+ messages in thread From: Ludovic Brenta @ 2006-05-17 9:22 UTC (permalink / raw) I am following up on the questions raised here about running both 32-bit and 64-bit binary code on the same machine. This is called biarch. Currently, the gcc-4.1 source package in Debian supports biarch for a few languages, but this support is maintenance-intensive and partial. Most notably, Ada does not currently support biarch (and neither does AdaCore). Furthermore, administration of a biarch system is more complex than that of a single-arch system, as not all binary packages support biarch, and some support packages are required, e.g. ia32-libs. Canonical, the company behind Ubuntu (a derivative of Debian), has written two very interesting papers about multi-arch, including an introduction, problems, and a proposed solution. Multi-arch is a generalisation of biarch, and allows mixing packages for several architectures that are compatible with a processor. For example, an Athlon or Opteron system can run binaries for all of amd64, i386, i486, i586 and i686. The proposed design would solve the current problems with biarch, at the expense of rewriting dpkg almost from scratch. http://multiarch.alioth.debian.org/ Thoughts? -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Multi-arch 2006-05-17 9:22 Multi-arch Ludovic Brenta @ 2006-05-17 9:45 ` Georg Bauhaus 2006-05-17 20:31 ` Multi-arch gshapovalov ` (2 subsequent siblings) 3 siblings, 0 replies; 14+ messages in thread From: Georg Bauhaus @ 2006-05-17 9:45 UTC (permalink / raw) Ludovic Brenta wrote: > Canonical, the company behind Ubuntu (a derivative of Debian), has > written two very interesting papers about multi-arch, IIRC, HP has always played with mounts per architecture. They also have an interesting file system standard. So I trust there is good reason to rewrite dpkg, given that only uni-arch is probably reasonably simple? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Multi-arch 2006-05-17 9:22 Multi-arch Ludovic Brenta 2006-05-17 9:45 ` Multi-arch Georg Bauhaus @ 2006-05-17 20:31 ` gshapovalov 2006-05-18 11:39 ` Multi-arch Ludovic Brenta 2006-05-18 21:24 ` Multi-arch Björn Persson 2006-05-21 13:05 ` Multi-arch Dr. Adrian Wrigley 3 siblings, 1 reply; 14+ messages in thread From: gshapovalov @ 2006-05-17 20:31 UTC (permalink / raw) Ludovic Brenta wrote: > I am following up on the questions raised here about running both > 32-bit and 64-bit binary code on the same machine. This is called > biarch. Currently, the gcc-4.1 source package in Debian supports biarch [skipped] > i586 and i686. The proposed design would solve the current problems > with biarch, at the expense of rewriting dpkg almost from scratch. > > http://multiarch.alioth.debian.org/ > > Thoughts? Biarch, multiarch, khm, whatever :). On the topic: Yes, it can be done and is very well worth it. On Gentoo it is called multilib and is supported distribution-wide, not only for x86 and amd64, but ppc and sparc have theirs multilibs too IIRC (I think both of them, but may be only sparc actually). gcc is supported, as well as Ada and most of the libs and apps (to the point where you can have wine running 32-bit Windows code on otherwise 64bit-clean system - kernel and userspace). This is regulated primarily via multilib and toolchain eclasses, which is basically the way to contain common controlling code. I recently put Ada on the same rails, so that now, on a multilib system, (that is for users who selected the multilib profile) two sets of rts libs are generated and compiler can generate 64bit or 32bit code. Although, as there were no requests so far, I haven't yet automatized switching between the multilib sub-profiles, only the usual niceties - like having FSF's 3.4.x, 4.1.x based and AdaCore's gnat-gpl compilers installed side-by-side and activated as necessary.. You can see the code here: http://www.gentoo.org/cgi-bin/viewcvs.cgi/eclass/ You would be looking for the toolchain.eclass, multilib.eclass and possibly some other eclasses. And here: http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-lang/gnat-gcc/ http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-lang/gnat-gpl/ The ebuilds and eclasses are mostly just a bash code, so should be familiar, aside from a few vars that have special meaning. Some Ada-specific implementation details and discussion can be found in this bug: https://bugs.gentoo.org/show_bug.cgi?id=111340 and you can catch me on irc,freenode.net in channels #gentoo and #gentoo-dev if you would like to discuss this further (my nick there is georges, email of course works too: george at gentoo.org), although I suppose the way it will have to be done on Debian would be quite different.. George ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Multi-arch 2006-05-17 20:31 ` Multi-arch gshapovalov @ 2006-05-18 11:39 ` Ludovic Brenta 2006-05-18 16:34 ` Multi-arch gshapovalov 0 siblings, 1 reply; 14+ messages in thread From: Ludovic Brenta @ 2006-05-18 11:39 UTC (permalink / raw) > Yes, it can be done and is very well worth it. On Gentoo it is called > multilib and is supported distribution-wide, not only for x86 and > amd64, but ppc and sparc have theirs multilibs too IIRC (I think both > of them, but may be only sparc actually). gcc is supported, as well > as Ada and most of the libs and apps (to the point where you can > have wine running 32-bit Windows code on otherwise > 64bit-clean system - kernel and userspace). Interesting. I've looked at multilib.eclass and gnat-gcc-4.1.0.ebuild. I have no detailed knowledge of the Gentoo portage system, so I can only guess, but it seems to me that the current infrastructure means that each source package builds several binary packages, one for each arch, on the machine where you build. So, for example, if you have an amd64 machine, you'd get two binaries, i386 and amd64. Furthermore, the i386 package would install libraries in /usr/lib32, whereas the same package built on a i386 machine would install libraries in /usr/lib, so the two packages would be slightly different, and incompatible, even though built for the same architecture. Debian is currently in a similar situation, except that it has not deployed this scheme distribution-wide but only in a few important packages, binutils and gcc being the most prominent ones. In the proposal, a source package would only produce one binary package for the machine doing the build; thus your amd64 box would only produce the amd64 binary. Then, if you want to install the i386 binary as well, you'd take the package built by the i386 autobuilder, modify it on the fly (this is one of the proposed changes to dpkg), and install it alongside your amd64 package. Of course, this scheme only makes sense in the context of a binary distribution like Debian, but there are several benefits: - it reduces the workload of the autobuilders - it reduces the size of the binary distribution, and load on the mirrors - it simplifies system administration - it simplifies the job of package maintainers and reduces the opportinuties for bugs >From what I understand, Gentoo people might not be very interested in these benefits, because: - Gentoo has no autobuilders, as each user recompiles the world on their machine - Gentoo has no binary distribution apart from the minimal bootstrapping system - Gentoo users seem to like system administration :) - Gentoo package maintainers seem to like difficult problems :) The proposal also hints at the LSB. I think it would be necessary to standardise the library paths across all distros. The current /usr/lib, /usr/lib32, and /usr/lib64 directories are not general enough. Consider that some HP processors can run i386, amd64, ia64, hppa *and* hppa64 binaries on the same machine :) And what about Cell processors and other future asymmetric multiprocessors? What about binaries intended to run on GPUs or other coprocessors? > you can catch me on irc,freenode.net in channels #gentoo and > #gentoo-dev if you would like to discuss this further (my nick there > is georges, email of course works too: george at gentoo.org) I'd rather keep the discussion here on c.l.a as it it not specific to Gentoo, or Debian, or any particular distribution. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Multi-arch 2006-05-18 11:39 ` Multi-arch Ludovic Brenta @ 2006-05-18 16:34 ` gshapovalov 0 siblings, 0 replies; 14+ messages in thread From: gshapovalov @ 2006-05-18 16:34 UTC (permalink / raw) Ludovic Brenta wrote: > only guess, but it seems to me that the current infrastructure means > that each source package builds several binary packages, one for each > arch, on the machine where you build. So, for example, if you have an > amd64 machine, you'd get two binaries, i386 and amd64. Furthermore, the That sums up the principle pretty well. Of course there is also a lot of glue code to hold it all together and make it "just work".. > i386 package would install libraries in /usr/lib32, whereas the same > package built on a i386 machine would install libraries in /usr/lib, so > the two packages would be slightly different, and incompatible, even > though built for the same architecture. Debian is currently in a Yes, that would have made them (incompatible) if we were distributing binary packages. As it is, everything is built locally against installed libs. So this is not an issue in our case. > In the proposal, a source package would only produce one binary package > for the machine doing the build; thus your amd64 box would only produce > the amd64 binary. Then, if you want to install the i386 binary as well, > you'd take the package built by the i386 autobuilder, modify it on the > fly (this is one of the proposed changes to dpkg), and install it > alongside your amd64 package. This is actually quite similar to what is happening in Gentoo, as it does not make sense to make two versions of *every* package. Only the principal libs (parts of glibc and gcc rts) plus compatibility libs (of these actually only the ones that are dependencies of requested packages) are produced "by default". Then user is free to mix and match in a usual fashion, although most people just stick with defaults of course :). [skipping this part, as you rightly point out, most of these issues do not apply in our case] > - Gentoo users seem to like system administration :) > - Gentoo package maintainers seem to like difficult problems :) :). Although many people claim that their system administration efforts were reduced after switching to Gentoo :). Well, as usual, this is an issue of how you think and what tools you like I guess.. > The proposal also hints at the LSB. I think it would be necessary to > standardise the library paths across all distros. The current /usr/lib, > /usr/lib32, and /usr/lib64 directories are not general enough. Consider > that some HP processors can run i386, amd64, ia64, hppa *and* hppa64 > binaries on the same machine :) And what about Cell processors and > other future asymmetric multiprocessors? What about binaries intended > to run on GPUs or other coprocessors? Definitely, this will have to be done. Unfortunately I do not see it happening *just yet* - having seen how much it takes to organize anything on a large scale :). However in 2-3 years and when we can persuade LSB people that Linux/BSD/FOSS is not limited to Red Hat.. (admittedly they are getting better at that lately). But we can start by having a discussion among Gentoo and Debian toolchain people (or what gcc/glibc "subproject" is called in Debian?) George PS Does anybody know of a public newsserver that would allow to post? I would really like to do all my email/messaging from one place (a trusty kontact :)), rather than having to browse to google groups just to post the reply.. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Multi-arch 2006-05-17 9:22 Multi-arch Ludovic Brenta 2006-05-17 9:45 ` Multi-arch Georg Bauhaus 2006-05-17 20:31 ` Multi-arch gshapovalov @ 2006-05-18 21:24 ` Björn Persson 2006-05-19 7:23 ` Multi-arch Ludovic Brenta 2006-05-21 16:03 ` Multi-arch Dr. Adrian Wrigley 2006-05-21 13:05 ` Multi-arch Dr. Adrian Wrigley 3 siblings, 2 replies; 14+ messages in thread From: Björn Persson @ 2006-05-18 21:24 UTC (permalink / raw) I understand how multi-arch is useful if you want to use proprietary binaries that are available only for certain architectures. Otherwise I don't see a reason to do it. I'd think free code would just be compiled for the "native" architecture. Is multi-arch useful in an altogether free system in some way that eludes me? -- Bj�rn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Multi-arch 2006-05-18 21:24 ` Multi-arch Björn Persson @ 2006-05-19 7:23 ` Ludovic Brenta 2006-05-19 21:16 ` Multi-arch Björn Persson 2006-05-21 16:03 ` Multi-arch Dr. Adrian Wrigley 1 sibling, 1 reply; 14+ messages in thread From: Ludovic Brenta @ 2006-05-19 7:23 UTC (permalink / raw) Björn Persson a écrit : > Is multi-arch useful in an altogether free system in some way that eludes me? Yes. Today, for example, OpenOffice works only on 32-bit architectures; if you want to run it on an amd64 machine, you need biarch or multiarch. There are probably other cases where compiling for one of the architectures in a multi-arch system is problematic. Also, 32-bit binaries use less memory than 64-bit binaries do. It makes sense to run 32-bit binaries on 64-bit machines, if those binaries do not benefit from the larger address space or 64-bit instructions. Another benefit of multiarch is that you can e.g. compile i386 binaries on an amd64 machine and run them on i386 machines. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Multi-arch 2006-05-19 7:23 ` Multi-arch Ludovic Brenta @ 2006-05-19 21:16 ` Björn Persson 2006-05-20 11:18 ` Multi-arch Ludovic Brenta 0 siblings, 1 reply; 14+ messages in thread From: Björn Persson @ 2006-05-19 21:16 UTC (permalink / raw) Ludovic Brenta skrev: > Bj�rn Persson a �crit : >> Is multi-arch useful in an altogether free system in some way that eludes me? > > Yes. > > Today, for example, OpenOffice works only on 32-bit architectures; if > you want to run it on an amd64 machine, you need biarch or multiarch. > There are probably other cases where compiling for one of the > architectures in a multi-arch system is problematic. That sounds like a defect in OpenOffice, so in that case multi-arch support functions as a workaround for a buggy program. > Also, 32-bit binaries use less memory than 64-bit binaries do. It makes > sense to run 32-bit binaries on 64-bit machines, if those binaries do > not benefit from the larger address space or 64-bit instructions. Ah. Yes, that's a good reason if the difference in memory usage is significant. (A factor two perhaps?) > Another benefit of multiarch is that you can e.g. compile i386 binaries > on an amd64 machine and run them on i386 machines. And then the compiler would also be an i386 program I presume. What are the benefits of that over an AMD64 to i386 cross compiler? -- Bj�rn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Multi-arch 2006-05-19 21:16 ` Multi-arch Björn Persson @ 2006-05-20 11:18 ` Ludovic Brenta 2006-05-20 17:51 ` Multi-arch Björn Persson 0 siblings, 1 reply; 14+ messages in thread From: Ludovic Brenta @ 2006-05-20 11:18 UTC (permalink / raw) Björn Persson <spam-away@nowhere.nil> writes: > Ludovic Brenta skrev: >> Björn Persson a écrit : >>> Is multi-arch useful in an altogether free system in some way that >>> eludes me? >> Yes. >> Today, for example, OpenOffice works only on 32-bit architectures; if >> you want to run it on an amd64 machine, you need biarch or multiarch. >> There are probably other cases where compiling for one of the >> architectures in a multi-arch system is problematic. > > That sounds like a defect in OpenOffice, so in that case multi-arch > support functions as a workaround for a buggy program. I think it's a bit more complex than that; it may well be a defect in OpenOffice, but also in the compiler or in any of the numerous libraries that OpenOffice uses. But I agree, in this case multi-arch is a workaround; this does not make multi-arch a bad idea, though. >> Also, 32-bit binaries use less memory than 64-bit binaries do. It makes >> sense to run 32-bit binaries on 64-bit machines, if those binaries do >> not benefit from the larger address space or 64-bit instructions. > > Ah. Yes, that's a good reason if the difference in memory usage is > significant. (A factor two perhaps?) A factor two for pointers and integers, yes, but not for Strings or other data structures. If you have many pointers, the increase in memory usage is quite significant. >> Another benefit of multiarch is that you can e.g. compile i386 binaries >> on an amd64 machine and run them on i386 machines. > > And then the compiler would also be an i386 program I presume. What > are the benefits of that over an AMD64 to i386 cross compiler? On the amd64 machine, you need either an amd64-to-i386 cross-compiler (gcc -m32 does just that), or a native i386 compiler. Either will do, but then you also need the i386 libraries to link against. A proper multi-arch design allows you to have these libraries alongside the amd64 libraries, in a clean way as opposed to local hacks. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Multi-arch 2006-05-20 11:18 ` Multi-arch Ludovic Brenta @ 2006-05-20 17:51 ` Björn Persson 0 siblings, 0 replies; 14+ messages in thread From: Björn Persson @ 2006-05-20 17:51 UTC (permalink / raw) Thanks for your answers, Ludovic! Canonical's proposal seems like "The Right Thing", although I can't say whether it's worth the effort. If there are people willing to do the work I certainly wouldn't try to stop them. (Not that I should have any influence over Debian.) -- Björn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Multi-arch 2006-05-18 21:24 ` Multi-arch Björn Persson 2006-05-19 7:23 ` Multi-arch Ludovic Brenta @ 2006-05-21 16:03 ` Dr. Adrian Wrigley 1 sibling, 0 replies; 14+ messages in thread From: Dr. Adrian Wrigley @ 2006-05-21 16:03 UTC (permalink / raw) On Thu, 18 May 2006 21:24:44 +0000, Bj�rn Persson wrote: > I understand how multi-arch is useful if you want to use proprietary > binaries that are available only for certain architectures. Otherwise I > don't see a reason to do it. I'd think free code would just be compiled > for the "native" architecture. Is multi-arch useful in an altogether > free system in some way that eludes me? Several reasons. I suggest that people who run a mixture of machines may want to share binaries across the network, but build them on their newest machines. People also want to avoid recompiling working code with another architecture, even if they have source code. You can't be sure it'll work exactly right without testing, which may be expensive. I found a couple of latent errors when builing for 64-bit. One was calling a C varargs function incorrectly from Ada. Another was caused by undocumented members of a C struct overwriting the Ada stack. Changing architectures is a risk. If you have written some code in assembly language, this will constrain the architecture until alternative code is available. Finally, some people store records directly in data files for various reasons. Changing architecture would need recreatoin of those files. It only takes one old architecture library to be a show-stopper, whether that is a third-party or handwritten codec, a buggy library or whatever. multi-arch eases the transition to a new architecture. -- Adrian ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Multi-arch 2006-05-17 9:22 Multi-arch Ludovic Brenta ` (2 preceding siblings ...) 2006-05-18 21:24 ` Multi-arch Björn Persson @ 2006-05-21 13:05 ` Dr. Adrian Wrigley 2006-05-21 13:41 ` Multi-arch Ludovic Brenta 3 siblings, 1 reply; 14+ messages in thread From: Dr. Adrian Wrigley @ 2006-05-21 13:05 UTC (permalink / raw) On Wed, 17 May 2006 02:22:57 -0700, Ludovic Brenta wrote: > I am following up on the questions raised here about running both > 32-bit and 64-bit binary code on the same machine. This is called > biarch. ... > Thoughts? Since I have been raising this as an issue in the past few months, I thought I'd give an update on my progress. I am now running a prototype stock trading system on an amd64 system running Fedora Core 5 (x86_64). The problem I had been trying to solve was accessing very large memory-mapped market data arrays (several GB). I had run out of addressing range on ia32 systems. Moving to amd64, however, I found I couldn't link in commercial 32-bit library code, available in binary form only. The system is based around Annex E distributed computing, with client partitions accessing server code using the 32-bit library via a Remote_Call_Interface partition. I now build the system using amd64 architecture for all the partitions except this Remote_Call_Interface partition, which is built for i386. There is no problem mixing architectures in a program as long as each partition only links in code from a permitted architecture. (note that it will build invalid binaries with mixed architecture!) The build process relies on a full i386 install of FC5 in a separate set of partitions from the x86_64. I installed a complete suite of i386 GNAT tools while running in 32-bit mode. The machine is dual-bootable, for convenience, but the build scripts use linux32 and chroot to compile 32-bit when booted as x86_64. I have the same source code checked out from cvs in two separate directories. The build script checks the architecture, and if it is x86_64, it builds all the partitions except those which need the 32-bit library. Otherwise, it builds all the partitions. I build one source tree in a 64 bit environment, the other in a 32-bit chrooted environment. I copy the 32-bit-only partition once built into the 64-bit build directory. This way, I get two complete working builds. The GtkAda component 'gate' does not seem to work on x86_64. This is invoked by the build script in a 32-bit chroot. I had experimented with -m32 in GNAT, and this produced working 32-bit .o files, but needed messing with at the linking stage, since it seemed to be looking in the wrong directories for the libraries. This might be made to work fairly easily, but I cannot get the -m32 switch passed from gnatdist as a compiler argument. This seems to be a simple bug(?). I think having two separate build directories is necessary for building a mixture of architectures, even if each partition is needed once, since some .o files are needed in both architectures (for pure partitions, for example). I haven't yet arranged it to build the binaries in side directories from the same source files. This would help ensure a consistent code base. I would like to thank Ludovic Brenta and Martin Krischik (and others) for working on these issues, providing helpful posts here at c.l.a, and for providing the necessary packages for running GNAT on these systems. The 64-bit system is still at a development stage on a test machine. I may try Debian for the production system, but I think the same build process will be needed until the issues mention above are fixed. -- Adrian ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Multi-arch 2006-05-21 13:05 ` Multi-arch Dr. Adrian Wrigley @ 2006-05-21 13:41 ` Ludovic Brenta 2006-05-21 16:07 ` Multi-arch Dr. Adrian Wrigley 0 siblings, 1 reply; 14+ messages in thread From: Ludovic Brenta @ 2006-05-21 13:41 UTC (permalink / raw) Dr. Adrian Wrigley writes: > The build process relies on a full i386 install of FC5 in a separate > set of partitions from the x86_64. I installed a complete suite of > i386 GNAT tools while running in 32-bit mode. The machine is > dual-bootable, for convenience, but the build scripts use linux32 > and chroot to compile 32-bit when booted as x86_64. > > I have the same source code checked out from cvs in two separate > directories. The build script checks the architecture, and if it is > x86_64, it builds all the partitions except those which need the > 32-bit library. Otherwise, it builds all the partitions. I guess you could have just one checkout, but two different object and executable directories. This is quite easy to set up in GNAT project files or, failing that, Makefiles. I don't know if the proposal from Canonical will be accepted or implemented, much less in what time frame. What do you think I should do in Debian? Continue supporting single-arch only (which still allows you to use a chrooted system for the other arch, like you are doing now) and wait for dpkg 2.0, or try provide multi-arch GNAT and libraries now? -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Multi-arch 2006-05-21 13:41 ` Multi-arch Ludovic Brenta @ 2006-05-21 16:07 ` Dr. Adrian Wrigley 0 siblings, 0 replies; 14+ messages in thread From: Dr. Adrian Wrigley @ 2006-05-21 16:07 UTC (permalink / raw) On Sun, 21 May 2006 15:41:49 +0200, Ludovic Brenta wrote: ... > I don't know if the proposal from Canonical will be accepted or > implemented, much less in what time frame. What do you think I should > do in Debian? Continue supporting single-arch only (which still > allows you to use a chrooted system for the other arch, like you are > doing now) and wait for dpkg 2.0, or try provide multi-arch GNAT and > libraries now? I found that I could build code with -m32 in FC5 with Martin's rpms, provided I messed around with linker commands and copied the 32-bit libraries from elsewhere. This would be OK, provided there was a "how to" document somewhere explaining it. It's what you call "local hacks" in another post. But the lack of a functioning gnatdist -m32 option, and lack of 'gate' meant I had to use the chroot method. Using chroot took a lot of time to set up, with a whole new install and 'bind' for directories in fstab, and implementing a dchroot script, needing sudo etc. If gate and gnatdist were fixed, and the -m32 linking were documented, it wouldn't be worth the effort providing multi-arch GNAT libraries at this stage. It's only people with special requirements like mine who would really benefit. Perhaps a year from now, once there are more amd64 users, and once higher priorities are addressed, looking at the problem again would be a good idea. I don't know enough about the amount and value of work needed on multi-arch GNAT to be able to be sure whether it makes sense. But I'm sure people value a streamlined robust, current and complete set of packages for each separate architecture. -- Adrian ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2006-05-21 16:07 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-05-17 9:22 Multi-arch Ludovic Brenta 2006-05-17 9:45 ` Multi-arch Georg Bauhaus 2006-05-17 20:31 ` Multi-arch gshapovalov 2006-05-18 11:39 ` Multi-arch Ludovic Brenta 2006-05-18 16:34 ` Multi-arch gshapovalov 2006-05-18 21:24 ` Multi-arch Björn Persson 2006-05-19 7:23 ` Multi-arch Ludovic Brenta 2006-05-19 21:16 ` Multi-arch Björn Persson 2006-05-20 11:18 ` Multi-arch Ludovic Brenta 2006-05-20 17:51 ` Multi-arch Björn Persson 2006-05-21 16:03 ` Multi-arch Dr. Adrian Wrigley 2006-05-21 13:05 ` Multi-arch Dr. Adrian Wrigley 2006-05-21 13:41 ` Multi-arch Ludovic Brenta 2006-05-21 16:07 ` Multi-arch Dr. Adrian Wrigley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox