>From nobody Sat Apr 3 11:58:58 1999 X-From-Line: owner-ultralinux-outgoing@vger.rutgers.edu Fri Mar 26 02:34:09 1999 Return-Path: Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by sargasso.cse.msu.edu (8.8.8/8.8.8) with ESMTP id CAA08362 for ; Fri, 26 Mar 1999 02:34:09 -0500 (EST) Received: by vger.rutgers.edu via listexpand id <161404-221>; Fri, 26 Mar 1999 02:31:14 -0500 Received: by vger.rutgers.edu id <161430-221>; Fri, 26 Mar 1999 02:31:01 -0500 Received: from sunsite.ms.mff.cuni.cz ([195.113.19.66]:2565 "EHLO sunsite.mff.cuni.cz" ident: "jj") by vger.rutgers.edu with ESMTP id <161404-221>; Fri, 26 Mar 1999 02:30:33 -0500 Received: (from jj@localhost) by sunsite.mff.cuni.cz (8.8.7/8.8.7) id IAA17921; Fri, 26 Mar 1999 08:33:01 +0100 From: Jakub Jelinek Message-Id: <199903260733.IAA17921@sunsite.mff.cuni.cz> Subject: Re: /usr/lib64 To: pjones@redhat.com (Peter Jones) Date: Fri, 26 Mar 1999 08:32:59 +0100 (CET) Cc: ultralinux@vger.rutgers.edu In-Reply-To: from "Peter Jones" at Mar 25, 99 11:52:33 pm Content-Type: text Sender: owner-ultralinux@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu X-Orcpt: rfc822;ultralinux-outgoing Lines: 49 Xref: test2 lists.ultra:668 > > It isn't. There's no 64-bit userland, and no 64-bit libraries. The > kernel is all that runs in 64-bit mode. > > Now, having no 64-bit libraries, you don't really need a directory for > them... ;) Well, to be honest, there is such a 64bit glibc, but it is quite old and you need to downgrade your kernel to something as of Sep/Oct 97 to be able to run it. (see ftp://ultra.linux.cz/OS/Linux/Sparc/local/sparc64/). But /usr/lib64 is prepared in spec files, so that once we support it (I'm not going to say a date here, as it depends on many things), current binutils/gcc will work with it. The general layout we plan is to put 64bit shared libraries into /lib64 /usr/lib64 /usr/local/lib64 /usr/X11R6/lib64 and have gcc/binutils take libraries from there first. Include files should be solved in the same way we do solve /usr/include/asm right now, ie. it is a directory full of header stubs, which for 64bit compilation goes to /usr/include/asm-sparc64 and for 32bit compilation goes into /usr/include/asm-sparc. AFAIK in glibc there is just a couple of sparc32/sparc64 specific headers, plus a couple of wordsize-32/wordsize-64 headers. All those will have to be stubbed (the sparc64 headers in an obvious way and probably create wordsize-3264 directory with combined wordsize headers). Then you can use /usr/include just fine for both kinds of compilation. The remaining issue is how to teach rpm new things which will be desirable in such an environment, as you should be able to install the same package twice (once for 32bit, once for 64bit), provided one of these installations installs only libraries (both shared and static). Then you could choose e.g. if you want binaries of that program 32 or 64bit but allow development to be done with that package for both 32 and 64bit target. Cheers, Jakub ___________________________________________________________________ Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz Administrator of SunSITE Czech Republic, MFF, Charles University ___________________________________________________________________ UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/ Linux version 2.2.4 on a sparc64 machine (3958.37 BogoMips) ___________________________________________________________________