Basically, this is a simple ebuild that takes the x86 stage1 ebuild, and copies the lib and usr/lib directories to /emul/i686, makes a symlink to /lib/ld-linux.so.2 from the emul structure (as amd64 uses /lib/ld-linux-x86-64.so.2 ). It also addes the /emul/i686/lib /emul/i686/usr/lib to the ld.so.conf (via /etc/env.d/75emul). It also updates the libc.so file as it points to the real libc library, so those paths need to change to the /emul/i686 offset. Extrace the set to /usr/portage and emerge sys-libs/emul-i686
Created attachment 18450 [details, diff] package to add emul/i686 ebuild
Created attachment 18452 [details, diff] update use stage 2 instead, as it includes libstdc++. If you emerge blackdown java (32bit), it now works after emerging this package.
Interesting ebuild ideas.. you might want to make some improvements to it. a) generate the LD_PATH thing on the fly using the script at http://dev.gentoo.org/~tester/amd64-tech-notes.html b) using the switcharch script at http://dev.gentoo.org/~tester/switcharch
As for a) that's a good idea, and wouldn't be hard to do. As for b) the goal is to eventually have a complete 64/32bit system where you can compile _and_ run 64bit and 32bit programs. I'm currently looking into compiling GCC with multilib support. Ran into a snag that appears to be an 'ld' bug though, as it won't search the whole library path for the 32bit libc. I'm currently having someone else here look into it, and I may also look into it if I get a chance. Anyhow, the good news is if we add amd64? (sys-libs/emul-i686 >= 1.0) to the dependancies of java, so the emulation stuff gets installed, java now works on amd64. (not that I actually use java, but I know a bunch of people that do)
Umm, expanding on b) what I mean by complete 32bit/64bit system is for it to act more like say Solaris Sparc works, where you don't have to chroot into another environment. It all just meshes together nicely... -B
problem is with emerge and 32/64bit interdependancies.. chrooting in the other arch allows to run emerge normally... I had another much more complex proposal at http://www.adelielinux.com/private/tester/gentoo-multilib.txt but drobbins though that a simple chroot might be easier...
Ok, read your 'proposal' thing or whatnot, and I can see why drobbins would opt against this. It is a very complex solution, more complex than it needs to be. Not every set of libraries/binaries needs to come in both 32bit and 64bit form. It would seem that all that is needed is really a way to specify a prefix to get passed to the configure scripts from the emerge stuff, so you can install to /emul/i686/usr instead of /usr . Then possibly track that in /var/db/pkg so you can install the same package multiple times, just to different locations. Obviously you'd have to reset the CFLAGS between compiles to mark as 32bit or 64bit. But for as few 32bit libraries as you need, this can be done on a case-by-case basis. But inititally here, my goal is to get up the dual environment, without migrating anything in portage really, so you can atleast grab raw source packages, and compile stuff by hand in 32bit mode, without having to chroot. Which is much like Solaris Sparc does. Also, this should not interfere with those that want to chroot, as it should be non-intrusive. Any thing you can see wrong with that (meaning not getting committed?).
I really want to avoid multilib, because I think that in the next 2 years (at the latest, probably more like 12 months,) most new systems sold will be fully 64-bit. Apple has switched to a 64-bit CPU, as has AMD. It's just a matter of months before Intel switches to 64-bit on the desktop as well. And this time, unlike 64-bit Sparc, these companies are *marketing* 64-bit as a *reason to buy* their computer. Marketing 64-bit to home users hasn't happened before, and you'll see that in the deflationary computer hardware market, 64-bit will be an important psychological benefit to market new systems to computer purchasers. Even if desktop users don't really need 64-bit as Intel claims, Intel will need a 64-bit desktop chip (with AMD64 instruction set) in order to avoid losing the marketing war. The marketing dollars of AMD, Apple, and soon Intel are/will be used to convince users that they *need* 64-bit, and that 32-bit is obsolete. This will make multilib a non-desirable thing for most users, who will want to get the most out of their new 64-bit system and not have any remaining 32-bit apps around, except for those they absolutely need. (and for Linux, that will be very few. For many users, it will be none.) Multilib is a big mess, and it is also very hard to "un-multilib" an architecture once it is multi-lib enabled. For these reasons it should be avoided in late 2003, and a chroot solution (/emul/, a la ia64) with some nice tools is a much better long-term solution.
Created attachment 18498 [details] emul-i686-0929.tar.gz adds symlinks of /lib32 and /usr/lib32 to /emul/i686 For upcoming GCC patch. GCC requires /lib32 and /usr/lib32 to exist for the libraries, so they are symlinks to the appropriate directories under /emul/i686.
I obviously don't agree with that. To assume that all applications will go 64-bit within the next year or two is obsurd. Especially when you think about stuff like wine, which I'd imagine won't have support for the Win64 stuff any time soon. But that's only one example. Besides that, to wait until everything is 64bit means you lose out on potential client base on your platform, because people want to know that a migration is going to be easy, and that their old legacy applications will still work. 32bit processors will be a round for a bit longer, and many development houses won't rush to update their code. That was the whole reasoning behind AMD keeping supurb 32bit support in their x86-64, so that there was no rush to upgrade (especially on expensive commercial program licenses [which exist in the construction and pos markets already]). Also, this architecture we're talking about here isn't Sparc, HPPA, MIPS, it's x86, the most widely distributed architecture; that makes a huge difference. I also disagree about the hard-to-seperate aspect. That's one reason I've kept the /emul/i686 structure, it keeps things nice and tidy. I'm not suggesting that portage needs to support a fully multilib architecture, but I do strongly suggest that on amd64 a 32bit environment, like this quick ebuild I wrote up is installed, and also allow gcc to build in multilib format so that people who wish to custom-compile apps outside of portage in 32bit mode (library dependancies for legacy 32bit apps, etc) can do that without having to chroot into a 32bit environment. Obviously gentoo is your baby, and the call is yours, but this is coming from someone who just spent the weekend getting this complete environment up, and is already using it (and will shortly become the main workstation). Again, I'm not suggesting we migrate portage to support multilib in general! (check out the gcc-config, binutils, and gcc patches I've posted as well, try it on your amd64 workstation, and evaluate how intrusive you believe they are before you make a decision)
I would agree with a lib32 approach... your's seems pretty simple and clean (maybe add a symlink for /usr/X11R6/lib too...)... I kind of like it more than my old proposal... Your thing has one problem tho (which I why I created a more complicated system)... You need BOTH 64bit anf 32bit glibc to build g++, so building gcc with multilib requires the 32bit emul stuff to be there... (so you need to add the dependency..)
yep, you're absolutely right. If you look at that gcc patch (bug #29952), it's already added in there. It depends on sys-libs/emul-i686 only if you have an amd64 AND have enabled 'multilib' in your USE flags. My first patch made multilib a requirement. The second one allows you to decide at compile time via the use flag. Also, assuming you have the emul-i686 ebuild in the portage tree, and the gcc-config and binutils patches in your portage tree as well, you should be able to install right from the stage1 iso all the way to a multilib environment. So the stage1 ISO should not require the 32bit libs to be included...
Brad, I think you totally misunderstood what I said. I did not say that all applications would be going 64-bit in a year or two (where did I say this?,) I said that in a year or so, the majority of systems sold will be 64-bit, and a fair number of users will only need 32-bit compatibility for the odd app or two, if that, and a significant number of users will not need 32-bit compatibility at all. For such users, it will be very good to preserve the ability to easily install a system that is purely 64-bit. Surely, in 3 or so years, the majority of users will not need 32-bit compatibility. I did not in any way suggest that 32-bit compatibility is a bad thing or will not be provided by Gentoo. Just to be clear, I don't think that "multilib" is a good solution for us to offer by default for amd64 and other 64-bit architectures. My multilib, I mean having 64-bit libs in /lib64 and 32-bit libs in /lib. I have problems with the file system heirarchy specifically, not necessarily the 32/64 functionality itself. The FS heirarchy doesn't make sense because it assumes that the user wants 32-bit support (you can't have a system without /lib,) and also labels 64-bit as the "optional/non-standard" libraries, since they aren't in /lib (default location for standard libs) but in /lib64. This worked fine for Sparc when 64-bit was something that a handful of enterprise apps took advantage of, but now that personal computers are migrating to 64-bit en masse, it really isn't an appropriate filesystem layout. 64-bit userland will soon be the default for very many users, and thus 64-bit libs should have a home in /lib, /usr/lib, etc. If your solution allows multilib to be conditionally enabled, and stores 32-bit libs in /emul/i686, this does seem like an excellent option. This way, we can offer a chroot option, or offer a multilib option that doesn't tie us down to an unpleasant and impractical directory heirarchy. Seems like the best of all worlds. And maybe something we could offer by default. My specific problem with multilib is the filesystem heirarchy aspect -- that 32-bit is the default (and one can't easily undo this choice in 3 years) and 32-bit cannot be easily removed from the FS heirarchy in the future. In other words, /lib64 is a dead-end.
Ok, I see why you were against multilib so much then. No, I worked around the issues. All 64-bit libraries go in /lib and /usr/lib (and /lib64 and /usr/lib64 are only symlinks respectively). ALL 32bit libraries reside in /emul/i686. It also makes symlinks from /emul/i686/lib and /emul/i686/usr/lib to /lib32 and /usr/lib32 respectively (binutils 'ld' requires this for now, I may be able to work around it if the symlinks bother you, but I don't think they're intrusive b/c the actual data storage is in /emul/i686). Also my gcc patches do not enable multilib by default, so there is no requirement to have the /emul/i686 structures and related symlinks at all... I do agree that it would be illogical to have /usr/lib and /lib contain 32bit binaries, and that is what I have avoided by my patches. 32bit becomes only an "emulation" set, not the "primary" libraries ;)
Created attachment 18557 [details, diff] emul-i686-0930.tar.gz update librt.so, libncurses.so, and libpthread.so ld redirect files Didn't realize that more files other than libc.so were redirecting ld .so files. Had to add updates for librt.so, libncurses.so and libpthread.so This should allow compiles to complete successfully against these libraries (assuming you have the binutils and gcc multilib patches)
done app-emulation/emul-linux-x86-baselibs app-emulation/emul-linux-x86-xlibs soon to come app-emulation/emul-linux-x86-gtklibs app-emulation/emul-linux-x86-qtlibs
what are those? pre-compiled versions? Shouldnt we just be able to compile that stuff normally inside the chroot? Otherwise your are going to end up being forced to have emul packages for all libs...
Yeah, they're precompiled. And they're only supposed to address certain apps available in binary form only. Usually apps provided in binary form only will statically link against other libraries. Read my updated technotes at http://dev.gentoo.org/~brad_mssw/amd64-tech-notes.html As it goes into a fair amount of depth on the 32bit environment run options, including the chroot() environment. Again, it's only supposed to address a small number of issues, I would hope that for which source is provided will be ported to 64bit and not have to worry about 32bit libs at all for those. I'm really only concerned with commercial binary-only programs, and that is what this addresses.
