As discussed briefly on IRC tonight, I've written up a ROUGH DRAFT of
some thoughts on this stuff. I think I've at least mentioned a few of
the main use cases.
Anywho:
http://dev.exherbo.org/~pioto/abi-ideas.html
So, please mention what else I'm missing.
I'm not at all tied to the syntax for anything.
--
Mike Kelly
<!--
vim: set tw=100 ft=mkd spell spelllang=en sw=4 sts=4 et :
-->
Some ABI Ideas
==============
## Table of Contents
* This will become a table of contents (this text will be scraped).
{:toc}
## DRAFT
THIS IS STILL A DRAFT.
## Overview
Most current Linux distributions that support 64-bit processors also support
running 32-bit code
under a 64-bit kernel. This is part of what gcc calls "multilib". On Gentoo,
support for this is
enabled by using a multilib profile, and the multilib USE flag.
While the multilib USE flag does "get the job done", there should be a better
way. For example, we
should be able to specify which ABI, or ABIs, we need to build against. ABIs
also shouldn't just be
limited to the 64-bit/32-bit or 64-bit-only combinations given w/ the multilib
flag, and they
shouldn't just be limited to representing the C ABI; it could also represent
the needed python ABI,
etc.
Stephen Bennett (spb) has already outlined some of this in his [labels
writeup][labels].
## ABI naming
Since ABIs appear in dependency labels, they can only have a limited set of
characters if we want to
be able to parse them. ABI values can only contain `[0-9a-zA-Z._]`.
The default ABI, as selected by the `any`, `mine`, and `primary` labels, is
stored in the `ABI`
variable.
ABIs can have multiple values. Those values are colon separated. The `primary`
supported ABI is the
first one listed.
## Providing an ABI
The default ABI for a package will come from the profiles. For example, the
default ABI for x86
would be "32"; for amd64, it would be "64". Packages can also specify, via the
`ABI` metadata
variable, which values for ABI they provide.
## Depending on a package with a specific ABI
To depend on a package with a given ABI, you specify it as part of the
dependency labels for a
package. The default is `mine`, which means that the ABIs provided by packages
must include all of
the ABIs provided by the current package.
You can also depend upon all currently installed ABIs for the chosen package,
using the `all`
keyword. This is for when your package installs libraries for all of the
possible ABIs at once.
## Alternative ABIs
There are other sorts of ABIs out there besides the basic C/C++ linkage ABI.
For example, python,
ruby, perl.
In the past, when you installed a package for one of these languages, you
usually just ended up with
the package compiled and installed for the most recent SLOT of that package.
For example, if you
have both python:2.4 and python:2.5 installed, and you install mysql-python, it
would just be
installed for python:2.5.
However, it would be very desirable to install the same package for all
currently available ABIs for
these dynamic languages. This is where alternative ABI types come in.
Specifying an alternative ABI
will likely require a combination of supporting files in the profiles, as well
as additional
metadata variables in the packages.
Back to the example of python, any given slot of python will provide a
different python ABI.
Then, python packages can use the dep label `ABI_PYTHON=all`. The python
package will then be
expected to install a version of the itself for all available python ABIs.
(e.g. `python-2.4
setup.py; python-2.5 setup.py`).
Most likely, the package manager should provide some way to reinstall a package
when the available
set of python ABIs no longer matches the set used when this package was used.
For example, if you
install python-2.6, you should reinstall all your python packages.
In order to do this, there will probably have to be some additional exheres
functions, or available
variables, that let packages iterate over all the ABIs provided by a given
package.
## Examples
Here are some short examples of some ways in which these ABI labels will need
to be used.
### gcc
gcc built with multilib support on amd64 provides both 32-bit and 64-bit ABIs.
# gcc.exlib
# ...
if option arch:x86 ; then
ABI="32"
elif option arch:amd64 ; then
if option multilib ; then
ABI="64:32"
else
ABI="64"
fi
fi
*TODO:* we might not actually want to have a `multilib` option at all.
### nspluginwrapper
nspluginwrapper provides a way for 32-bit browser plugins to work with a 64-bit
browser. (Well, it
lets you run a linux plugin on a FreeBSD browser, too, but we don't care about
that).
In order to compile, it needs both a 32-bit and a 64-bit toolchain.
# nspluginwrapper-1.0.0.exheres-0
PLATFORMS="~amd64 -x86"
DEPENDENCIES="
( build+run,ABI=32+ABI=64:
sys-devel/gcc )
build+run:
dev-libs/xulrunner
"
### python
Python has an ABI which changes with every major version.
# python-2.5.exheres-0
SLOT="2.5"
ABI_PYTHON="${SLOT}"
# This will use the primary system ABI, but also the special PYTHON ABI.
# python.exlib
# for python packages
DEPENDENCIES="
build+run,ABI_PYTHON=all:
dev-lang/python
"
src_compile() {
for py_abi in $(eabi all dev-lang/python); do
python-${py_abi} ./setup.py build_dir=build_${py_abi}
done
}
*TODO:* These sort of packages will most likely need to support building
outside of the source tree
one way or another in order for this to work properly within the current
src_compile/install
framework. Alternatively, we could call src_{configure,compile,test,install}
multiple times, setting
some magic env vars. Not sure which would be easier.
## References
- [Dependency Labels][labels]
[labels]: http://dev.exherbo.org/~spb/labels.txt "Dependency Labels"
_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
