[Exherbo-dev] Multilib branch now merged

David Leverton dleverton at exherbo.org
Fri Dec 30 21:03:03 GMT 2011

On 30 December 2011 20:35, David Leverton <dleverton at exherbo.org> wrote:
> Finally, thanks to everyone who's worked on multilib so far, and to
> everyone who will take this opportunity to start working on it and
> make it even better.

For anyone who wants to work on stuff but isn't sure what to do,
here's a list of potential improvements that I noticed while working
on the merge.  These are just my opinions, not anything authoritative,
and some of them are a too vague to do anything about immediately, but
I thought it would be good to get them out there and see what people

I'm not sure it's appropriate for it to be so generic across classes -
we'll have to see once someone does Python/Ruby/etc.  For one thing
this makes it harder to find a suitable place to solve the next point.

The multibuild_c: options should really be declared in an exlib,
including a restriction to make sure at least one is selected (or for
C at least, should we always force the native ABI on in the profile?)

Maybe easy-multibuild should have a `multiunpack` exparam or something
to make it easier to handle packages that don't support out-of-tree

lib* should only apply to actual object code libraries or other stuff
that's different between targets - other files that happen to be
installed in lib should stay there.

For amd64 we should probably move to having lib be for 32-bit
libraries and non-target-specific things (that for whatever reason
aren't in share) and lib64 as a separate directory (ie no symlinks
either way) for just the 64-bit libraries.  It's ugly, but it seems to
be the standard used by other distros so it makes sense to follow it.

The /usr/${CHOST} scheme assumes that ${CHOST} is different for all
targets, which isn't true on MIPS for example.  I'm also not sure how
standard this approach is - at least some configure scripts seem to
look for ${CHOST}-*-config which suggests that that would be
preferred, although it has the same problem.  Finally I don't like how
the default and non-default targets are treated differently, would be
better to handle them all the same and just symlink the default ones
to the "bare" names.  Whatever we end up doing should probably be put
in an exlib.

I think I'd prefer for -m32 to be put in CC rather than CFLAGS (maybe
because it looks funny for scripts to say "checking for
i686-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc", also the way it is
now requires it to be in LDFLAGS as well), but it would have to be
done in a way that doesn't interfere with users specifying their own

 - Not multibuild-related specifically, but we should maybe check
whether all the random FOO=${CHOST}-foo variables we set in the
profiles are appropriate.  In particular some packages apparently want
${LD} to be the C compiler, not ld itself.

The (?) used for multibuild option dependencies is questionable - if
the dependency doesn't have the multibuild options then presumably it
isn't multibuildified and therefore shouldn't be considered, surely?
(-) seems like it would be better.

More information about the Exherbo-dev mailing list