From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 7 18:36:16 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 61CFE16A422 for ; Tue, 7 Feb 2006 18:36:16 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from mail19.syd.optusnet.com.au (mail19.syd.optusnet.com.au [211.29.132.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3389F43D5D for ; Tue, 7 Feb 2006 18:36:14 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail19.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k17Ia9JI014844 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Feb 2006 05:36:10 +1100 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k17Ia9uj003009; Wed, 8 Feb 2006 05:36:09 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k17Ia8b9003008; Wed, 8 Feb 2006 05:36:08 +1100 (EST) (envelope-from peter) Date: Wed, 8 Feb 2006 05:36:08 +1100 From: Peter Jeremy To: Coleman Kane Message-ID: <20060207183608.GC699@turion.vk2pj.dyndns.org> References: <346a80220602032210o71367220v74033da94e3d83bb@mail.gmail.com> <346a80220602051652u5b5f59fdx5fc715c22b84d133@mail.gmail.com> <20060206184111.GE699@turion.vk2pj.dyndns.org> <20060206194532.GA17347@pint.candc.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060206194532.GA17347@pint.candc.home> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc 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: Tue, 07 Feb 2006 18:36:16 -0000 On Mon, 2006-Feb-06 14:45:32 -0500, Coleman Kane wrote: >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. I'm aware of that. I expressed myself very poorly. What I meant to say was that that it would be nice if the kernel and rtld could automatically map between .../lib and .../lib32 depending on the ELF type, rather than requiring that all 32-bit code lived in .../compat/ia32. We also need the ability for a 32-bit app to exec a 64-bit app (whereas I believe the Linux compatibility layer required that an exec'd process always be inside the .../compat/linux tree). A (Linux enthusiast) friend was mentioning that Linux has .../lib and .../lib64 in its amd64 variant. Solaris does much the same. I suspect that one reason for naming things this was round is that it vastly simplifies handling compatibility issues - basically, 32-bit apps just run (because they always point to the 32-bit RTLD and libraries), whilst 64-bit apps get compiled to point to the 64-bit versions. It's too late now, but this probably should have been done on FreeBSD as well. (The downside is that it makes the 'native' architecture look like 32-bits, with 64-bits as an addon). OTOH, a 32-bit app is always going to be smaller and, with less memory footprint, possibly faster - therefore is makes a degree of sense to only use 64-bits where it is needed (eg accessing lots of memory, doing lots of multi-precision integer arithmetic). >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. Good point. But it gets nastier when dealing with dependencies. LIB_DEPENDS will (always, I think) need to be the same ARCH. BUILD_DEPENDS and RUN_DEPENDS may or may not need to be the same ARCH. Things like {d,g,i}make, gm4 etc don't care whether they are being used to build 32-bit or 64-bit apps. Perl is messier - if perl is just being used to run configuration or installation scripts, its ARCH doesn't matter. If you're building a perl module it probably doesn't matter, unless the module itself contains some binary component that isn't ARCH-independent. >> - 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. Yes. > 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. This is what I was referring to. It I mount my FreeBSD/i386 filesystems on my FreeBSD/amd64 box, then they mostly fail to load the correct shared libraries (though I think I need to re-evaluate this - the ldconfig32 hooks I thought I had are only in my -current FS and I was testing on -stable). >I think that it would be worthwhile to have the ability for a system >admin to connect ports up to buildworld I think this is work for much later. >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. AFAIK, this won't work. amd64 and i386 code is not compatible. The amd64 CPU can be told that a particular process (task descriptor) is to be executed in "compatibility mode" but I don't believe it's possible to switch between them at runtime. -- Peter Jeremy