From owner-freebsd-amd64@FreeBSD.ORG Mon Feb 6 19:43:20 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB4D616A423 for ; Mon, 6 Feb 2006 19:43:20 +0000 (GMT) (envelope-from cokane@mail.cokane.org) Received: from smtp3.fuse.net (mail-out3.fuse.net [216.68.8.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48CBD43D49 for ; Mon, 6 Feb 2006 19:43:19 +0000 (GMT) (envelope-from cokane@mail.cokane.org) Received: from gx4.fuse.net ([72.49.90.188]) by smtp3.fuse.net (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20060206194318.UIUA25315.smtp3.fuse.net@gx4.fuse.net> for ; Mon, 6 Feb 2006 14:43:18 -0500 Received: from mail.cokane.org ([72.49.90.188]) by gx4.fuse.net (InterMail vG.1.02.00.02 201-2136-104-102-20041210) with ESMTP id <20060206194318.LIGH14894.gx4.fuse.net@mail.cokane.org> for ; Mon, 6 Feb 2006 14:43:18 -0500 Received: (qmail 17497 invoked by uid 1000); 6 Feb 2006 14:45:32 -0500 Date: Mon, 6 Feb 2006 14:45:32 -0500 From: Coleman Kane To: Peter Jeremy Message-ID: <20060206194532.GA17347@pint.candc.home> References: <346a80220602032210o71367220v74033da94e3d83bb@mail.gmail.com> <346a80220602051652u5b5f59fdx5fc715c22b84d133@mail.gmail.com> <20060206184111.GE699@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060206184111.GE699@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.5.11 Cc: freebsd-amd64@freebsd.org Subject: Re: 32-bit X libs? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2006 19:43:20 -0000 On Tue, Feb 07, 2006 at 05:41:11AM +1100, Peter Jeremy wrote: > On Sun, 2006-Feb-05 19:52:30 -0500, Coleman Kane wrote: > >Alright. I like the /usr/compat/ia32 idea as well. > > It would be even nicer if it was totally transparent so no compat > hierarchy was needed. The name should probably be /usr/compat/i386 in > keeping with the FreeBSD naming convention. One difficulty in > handling /usr/compat/ia32 is applications like mozilla and > OpenOffice.org which have front ends comprising to twisty maze of > shell scripts with the actual executables buried elsewhere. (And in > the case of mozilla, it may be reasonable to have both 32-bit and > 64-bit versions installed). Problem is this: all your 32-bit apps require 32-bit library counterparts for everything that they link against. For instance, lets pretend that firefox wouldn't work on amd64. Firefox links in a nice 37 .so's on my system. Just because libX11.so.6, libXrender.so.1, libexpat.so.6, etc.., etc... have native 64-bit versions installed doesn't mean that I can use them with firefox 32-bit. I actually need to go through and build all of these for a 32-bit system to install firefox into. The reason you can still use the 64-bit version of du, or sh in your programs is basically because the rtld is re-issued these commands to create a new process space (and there is a barrier between your 32-bit program and the process loaded by execve, system, etc...). Right now, we put the 32bit FreeBSD libs into 'lib32' counterparts to our 'lib's. This is basically the same idea, but instead puts every thing under a '32-bit' root and adjusts the search-paths accordingly when the kernel realizes 'I am in ia32 and not amd64 space'. > > >How about this... I will personally compile a list of needs for this > >project. > > - Re-mapping the rtld name on 32-bit executables > - Re-mapping the shared library paths This is already done with the lib --> lib32 builds. > - Support installation of i386 ports > - Support building of i386 ports (if I try to build a port that is only > for i386 or not for amd64 then it will automatically build as a i386) I recommend this being a make option. Perhaps a general BUILD_ARCHS that has a list of architectures to build? This way, the system could be ported to FreeBSD/alpha, where i386 ports could be built by doing: BUILD_ARCHS="alpha i386" That would build the alpha and i386 versions of ports, while allowing you to build the i386 version of i386 only ports, and the alpha version of alpha-only ports. As you can see, the system would translate to amd64 quite well. Revisiting my earlier comment, we'd also need to maintain seperate /var/db/pkg trees as well. You only want to have the necessary libs build in 32bit to support your chosen set of 32bit ports. You'll need a seperate pkgdb to keep track of them all. > - allow me to mount FreeBSD/i386 filesystems and execute programs in them. Correct me if I am wrong, but there is no such thing as a "FreeBSD/i386 filesystem". The Berkeley FFS is the same across i386, amd64, alpha, sparc64, ppc, and whatever else. The only thing there is is a "FreeBSD FFS with i386 programs on it", which would fall under the same sort of rules that the linuxulator uses right now. That is, the linuxulator first prepends /compat/linux to the search path for any filesystem operation. My further thoughts -- ------- -------- I think that it would be worthwhile to have the ability for a system admin to connect ports up to buildworld (if we want to allow such things!). Perhaps allow ports to install to /usr/local/src (via a make.conf option), and then make buildworld has a systematic way of building add-ons from there via the make system. This way, a emulators/compat-ia32 could be put together to install a /usr/local/src/emulators/compat-ia32 tree that would build the latest /usr/src for IA32 when buildworld was made. This could also be transmitted to things like emulators/rtc, graphics/dri, security/openssl, security/openssh when the admin wishes to tie these ports in (and they might have depedencies on the system that get borked when tracking a non-release CVS branch). This is especially helpful in the cases where *_OVERWRITE_BASE has been chosen. Sounds complicated? of course it does. On the ports side of things... -- --- ----- ---- -- --------- I think that we want to offer two options: 1) Allow someone to build for all of the architectures specified in a list 2) Allow someone to specify a list of architectures to step through, and build the first architecture that the port allows This solves the problems of not wasting a bunch of space and time building every architecture for every port. But, it will allow some people (like those who want ia32 and amd64 firefox). Libraries, libraries... ---------- ------------ I have an idea how infeasible this is, but it would be cool to be able to specify library mappings from 32-bit land to 64-bit land. Say, for instance, the amd64-bit versions of the libc string functions are faster than the 32-bit libc ones. Allowing the built 32bit libc to be a shell that implements 32-bit versions of "non-substitutable functions" and calls through to the 64-bit libc.so for the "substitutable functions", all defined at build time. If I am not mistaken, the 64 bit code should be able to address the 32-bit code's memory, but not the other way around, which is why things like 32-bit flash in firefox/amd64 is much more difficult than you would first think, considering we have linux-flash working in firefox/i386. Oh yeah... there's likely more that I haven't covered. > > -- > Peter Jeremy -- Coleman Kane