Re: gcc 4.7

On Jan 19, 2012, at 11:40 PM, [email protected] wrote:

>>> 
>>> The 3rd alternative (what RedHat is doing) has a pkg granularity where
>>> each pkg is either elf32 or elf64, but both elf32/elf64 are mixed in the
>>> same repositories.
>>> 
>>> Ultimately elf32 != elf64 and how one differentiates matters little. but
>>> there are huge differences in how build systems are constructed and
>>> how product is marketed and/or supported dependent on the "multilib" choice.
> 
>  I believe probably the most sane way to do it in Mandriva
> is to have 32 and 64 bit libraries split in 2 packages, but
> keep -devel packages with both, 32 and 64 bit static libraries,
> or .so symlinks. This on the sense of at first not wanting
> to break or need changes to any existing package or spec file,
> or at least if happening, only on very special cases.

Ok. The -devel packages (as used by Mandriva) have another issue
with *.so symlinks as currently implemented, but first things first.

>>> Note also that x32abi is "supported" in 3.2 kernels and presumably there
>>> will be usage cases defined soon. There already is a (rather feeble imho)
>>> patch
>>> to rpm to handle x32abi being tracked here:
>>>   https://blueprints.launchpad.net/rpm/+spec/rpm-x32abi
> 
>  Triarch x86_64! Should be a good test environment for a distro
> bootstrap, just chroot to it in your cooker computer :-)
> 

ia64 and mips are both triarch already. And ia64 in RHEL4 shipped
with all 3 arches in same repository (mips arches are mutually
exclusive usually afaik).

>>> There are some complex issues tied to ARM abi's similar to x32abi; but cooker@
>>> isn't the place
>>> for arm discussions.
>>> 
>>>> or
>>> 
>>>> 2. Split 32 and 64 bit libraries in different packages.
>>> 
>>> This is the RedHat model. There's deeper benefits here because
>>> this is/was what RPM "multilib" was designed for:
>>> 	Every package has only one of elf32 or elf64 (or x32abi) within.
>>> and so various functionalities in RPM that are currently disabled for
>>> Mandriva can just be turned on. Otherwise Newer! Better! Bestest!
>>> packaging functionality will have to be devised and discussed.
> 
>  This could require some redesign on different tools or
> repositories, for example, to have libfoo.x86_64.rpm and
> libfoo.i686.rpm in the same repository, instead of having
> lib64foo and libfoo identifiers.
> 

I suggest separate per-abi repositories, and splitting no arch
into a separate repository. But I'm sure all the packages
will be lumped together, and RPM will continue being expected
to figure out what to do with use commands like this:
	rpm -Uvh *
with duplicates, non-rpm packages, and multiple arches.

(separate repositories makes it slightly more likely that
splats Just Work).

...

> 
>>>> MDawkins has been doing some work with initrd, static
>>>> binaries and uclibc, what may be affected. What else,
>>>> eglibc, klibc, dietlibc, bionic libc?
>>> 
>>> Are all these glibc's actually needed? Perhaps the better split
>>> (than elf32 <-> elf64) would be along the usage cases for
>>> each of those glibc's instead.
> 
>  This was more to try to have some insight on possible other
> issues, or things that might break and require more than a
> rebuild to become functional again. E.g. java-1.5.0-gcj
> should only require a rebuild, while gccxml depends on
> it being updated for gcc 4.7. Anyway, most packages that
> should have build issues are c++ code.
> 

Since some of those libraries use elf32 -- but with a different
elf interpreter -- there's a need to add a dependency on the
elf interpreter as well. The dependency on the elf interpreter
is closely related to the intent of devel(..) dependencies
afaik (but none has managed to explain devel(…) intents to
me clearly enough so that I might know what is needed in RPM).

Note the RPM used to generate a dependency on an ELF interpreter
for every package. The dependency was removed because on glibc-only
systems there is only one libc and one interpreter, and one can
infer which interpreter is intended from the libc soname.

This isn't true when the same so name is in use by different libc's
that use different elf interpreters (like uclibc).

73 de Jeff