From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>
To: ultralinux@vger.kernel.org
Subject: Re: /usr/lib64
Date: Fri, 26 Mar 1999 07:32:59 +0000 [thread overview]
Message-ID: <marc-linux-ultrasparc-92243384727364@msgid-missing> (raw)
In-Reply-To: <marc-linux-ultrasparc-92239744703556@msgid-missing>
>
> 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)
___________________________________________________________________
prev parent reply other threads:[~1999-03-26 7:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-03-25 19:25 /usr/lib64 Scott Michel
1999-03-26 4:52 ` /usr/lib64 Peter Jones
1999-03-26 7:32 ` Jakub Jelinek [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-ultrasparc-92243384727364@msgid-missing \
--to=jj@sunsite.ms.mff.cuni.cz \
--cc=ultralinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.