Re: gcc 4.7

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

  First a proposal to avoid letting it pass unnoticed. Notice
that the gcc package does not have the %build_cross stuff for
almost a year now, and another approach was used for building
a cross toolchain for armv7. So, what I think is reasonably
to do:

o Remove %build_minimal and %build_cross macros to drastically
  simplify the package build; this also removes the %isarch
  macro, and then, use only %ifarch/%ifnarch
o Not so happy doing it, but lack of test environment probably
  have rendered these very broken, so, remove sparc and ppc
  logic from spec, keep mips and arm (arm builds have been
  exercised recently)

>>>> 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.

  It is also expected, besides I do not exercise it, to be able to
rebuild 32 bit packages on x86_64. I myself use a 32 bit chroot for
that.

  I was considering to split binaries and libraries from the glibc
package, but naming consistency may be tricky. First I do not think
it is wise to split libraries with %mklibname, too much possible
problems. So, best candidate probably would be something like
%mklibname c 6
that would not really contain only one library, and only one soname:

$ for f in `rpm -ql glibc | egrep '^/lib64'`; do objdump -p $f | grep SONAME |
sed -e 's/[[:space:]]*SONAME[[:space:]]*//'; done | sort -u
ld-linux-x86-64.so.2
libanl.so.1
libBrokenLocale.so.1
libcidn.so.1
libcrypt.so.1
libc.so.6
libdl.so.2
libm.so.6
libnsl.so.1
libnss_compat.so.2
libnss_db.so.2
libnss_dns.so.2
libnss_files.so.2
libnss_hesiod.so.2
libnss_nisplus.so.2
libnss_nis.so.2
libpthread.so.0
libresolv.so.2
librt.so.1
libSegFault.so
libthread_db.so.1
libutil.so.1

  Looking for whatprovides libc.so.6 I see:

http://rpmfind.net/linux/rpm2html/search.php?query=libc.so.6

and a similar approach is what Debian uses:

http://packages.debian.org/search?suite=all&section=all&arch=any&searchon=names&keywords=libc

>>>> 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).

  I would be really happy if anybody proved me wrong, but I do
not think it would work if having both, in the x86_64 repository
glibc-2.15-1.x86_64.rpm and glibc-2.15-1.i686.rpm
but if repository tools, urpmi, etc can handle it properly,
better. Also, if somehow can actually generate these in the
buildsystem in a single package submit.

>>>> 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

  So, what I am considering, but feedback welcome of course, (and
anything submitted only after a long series of tests...) is to split
libraries in a lib64c6 and libc6, binaries in the glibc package
(that requires the arch specific library one), and -devel package
requiring 32 and 64 bit libraries.

  In the worst case, it should at least make it easier to, in the
future do another approach where 32 and 64 bit are split, or if
required for some reason, merge them back.

Paulo