gfa
Mar 18, 2009, 8:32 AM
Post #3 of 3
(2511 views)
Permalink
|
nice, thanks for the information
i compiled socat in 64 bit just to try if the toolchain is working fine. i just plan to have mysql on 64bit, anything else will be 32bit
thanks
----- Original Message -----
From: "Friedrich Oslage" <bluebird [at] gentoo>
To: gentoo-sparc [at] lists
Sent: Saturday, March 7, 2009 12:46:40 PM (GMT-0300) Auto-Detected
Subject: Re: [gentoo-sparc] libraries on multilib profile
Access to this information requires level 4 clearance!
Nah, just kidding, but with the information in this mail you could
seriously break your system, use it carefully.
There's very little documentation about how multilib works (in general
and in Gentoo), most of it you'll find in mailing list archives.
You understood the basics correctly, for multilib a library must be
compiled twice, once in 32 bit(with -m32 cflag) and once in 64 bit(with
- -m64 cflag).
However glibc is a bad example since it's not a "normal" library. To get
glibc to compile for a specific bitness you have to pass different
configure-hosts.
2.8 has these configure-hosts:
UltraSPARC CPus:
sparcv9-*-linux-gnu: 32 bit
sparc64-*-linux-gnu: 64 bit
UltraSPARC III CPUs:
sparcv9b-*-linux-gnu: 32 bit
sparc64b-*-linux-gnu: 64 bit
UltraSPARC T1 CPUs:
sparcv9v-*-linux-gnu: 32bit
sparc64v-*-linux-gnu: 64bit
UltraSPARC T2 CPUs:
sparcv9v2-*-linux-gnu: 32bit
sparc64v2-*-linux-gnu: 64bit
The glibc ebuild determines which to use according to your -mcpu cflag.
For instance if you have "-mcpu=ultrasparc" a non multilib glibc would
be compiled like this:
configure --host=sparcv9-unknown-linux-gnu
make
make install
And a multilib one would be compiled like this:
configure --host=sparcv9-unknown-linux-gnu
make
make install
configure --host=sparc64-unknown-linux-gnu
make
make install
A "normal" library doesn't really care about bitness, it just trusts the
compiler to do it's job right.
So a non multilib ncurses would be compiled like this
export CFLAGS="${CFLAGS} -m32"
configure
make
make install
and a multilib one like this:
export CFLAGS="${CFLAGS} -m32"
configure
make
make install
export CFLAGS="${CFLAGS} -m64"
configure
make
make install
Ok so much about general multilib stuff, now how Gentoo does it:
The examples above only work if the library's Makefile respects the
user's cflags. Sadly, not all Makefiles do that.
Therefore Gentoo's gcc contains a hack to allow one to pass cflags which
are _always_ respected, no matted how messed up the Makefile is.
If you excute
gcc foo.c
it really is
`eval echo gcc \$CFLAGS_$ABI foo.c`
for instance
export ABI="sparc64"
export CFLAGS_sparc64="-m64"
gcc foo.c
will have the same effect as
gcc -m64 foo.c
These variables are set in your profile, if you execute emerge --info
- --verbose you'll see:
CFLAGS_sparc32="" # -m32 it the default, no need to set it
CFLAGS_sparc64="-m64"
ABI="sparc32"
You may also have noted these variables which are also set in the profile:
DEFAULT_ABI="sparc32"
KERNEL_ABI="sparc64"
MULTILIB_ABIS="sparc32 sparc64" # non multilib profiles have "sparc32"
As you can guess a multilib enabled ebuild would need to do:
for ABI in ${MULTILIB_ABIS}; do
compile_and_install
done
But that means the ebuild would have to be rewritten to do that, only
very few ebuils are written like that.
There's also bug #145737 [0] to add native support for this to portage
directly and eluminate the need to rewrite the ebuilds but it's far from
beeing implemented ;)
Back to topic: That means if you want a 64 bit mysql you have 2 options:
- - rewrite the mysql ebuild and all ebuilds it depends on
Don't do it. It's way to much work and it would never get into the tree.
- - use what you learned above and portage's ROOT support to make portage
create a /opt/mysql64 dir containing a 64 bit mysql and the 64 bit libraries
With the ROOT environment variable you can tell portage to use a ROOT
other than /, in this case something like /opt/mysql64. Sort of a
second, smaller Gentoo installation.
(This is similar to what the Gentoo Prefix project [1] does)
export ROOT="/opt/mysql64"
Use the ABI environment variable to use the sparc64 ABI.
export DEFAULT_ABI="sparc64"
export ABI="${DEFAULT_ABI}"
And merge mysql:
emerge mysql
Which will fail because gcc won't find the required 64 bit libraries.
You need to tell gcc(and glibc's loader) to also search in
/opt/mysql64/lib64 and /opt/mysql64/usr/lib64 for libraries and
/opt/mysql64/usr/include for headers, like this:
CFLAGS_sparc64="-m64" # keep this
CFLAGS_sparc64="${CFLAGS_sparc64} -L/opt/mysql64/lib64"
CFLAGS_sparc64="${CFLAGS_sparc64} -L/opt/mysql64/usr/lib64"
CFLAGS_sparc64="${CFLAGS_sparc64} -Wl,-rpath=/opt/mysql64/lib64"
CFLAGS_sparc64="${CFLAGS_sparc64} -Wl,-rpath=/opt/mysql64/usr/lib64"
CFLAGS_sparc64="${CFLAGS_sparc64} -I/opt/mysql64/usr/include"
export CFLAGS_sparc64
So much for now.
Please note that I didn't really test this, it may not even compile, let
alone run.
But considering that MySQL works on Linux/SPARC(32 bit) and Linux/AMD64
and Solaris/SPARC(32 and 64 bit) chances are quite good.
Just keep in mind that your are probably the only one using a
configuration like this so when you hit a bug you may find that nobody
is able (or willing) to help you.
Ps: Is there a reason you compiled socat in 64 bit? Or just for
testing/learning purpose? Afaik the only packages we have in the tree
which could benefit from beeing compile in 64 bit are mysql and postgresql.
Cheers,
Friedrich
[0] http://bugs.gentoo.org/show_bug.cgi?id=145737
[1] http://www.gentoo.org/proj/en/gentoo-alt/prefix/
Gustavo Panizzo <gfa> schrieb:
> Hi all
> i'm using multilib profile (default/linux/sparc/experimental/multilib)
>
> when i compile something simple, like socat, i'm able to have it on 32 or 64 bit
> but i don't found a way to have libraries on 32 AND 64 bit (lib32 and lib64)
>
> for example
> if i want a 64bit mysql, i need a 64bit ncurses, and so on
>
> if i add -m64 to CFLAGS, portage will refuse to install it to lib32 due to multilib-strict FEATURE (which i think is correct)
>
> anybody has any workaround for this? i took a look to glibc ebuild, but it wasn't much help
>
>
> thanks
>
>
|
