Re: gcc 4.7

>
> On Jan 20, 2012, at 9:33 PM, [email protected] wrote:
>
>>> 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)
>>
>
> Do you want a test environment or do you wish a simpler QA matrix?
> Presumably, a simpler QA matrix, which makes perfect sense: its
> hard supporting platforms you cannot access.
>
> ?

  I could always setup a qemu environment, but building and
keeping up to date for sparc and ppc on a qemu image would
not be an easy task.

>>> Ok. The -devel packages (as used by Mandriva) have another issue
>>> with *.so symlinks as currently implemented, but first things first.
>>
>
> I suppose I should describe the issue (which "works" but isn't "correct"
> and there isn't yet a clear resolution):
> 	There's a patch to auto-generate "devel(?)" dependencies by
> 	following a *.so symlink that is based on an ancient and
> 	rejected patch to rpm.
>
> 	Nothing wrong per-se, just the patch duplicates a code
> 	path that is already rather complex, and I'd rather see
> 	a different approach; Per Oyvind disagrees and we have deadlocked.
>
>>  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.
>>
>
> Yes: rpm build is/was designed for a single arch per build and so
> using a 32 bit chroot is more robust.
>
> And yes: The expectation is to be able to build both elf32/elf64,
> just none has ever bothered to design that functionality into
> rpmbuild correctly.
>
> By correctly, I mean a stronger interface, closer to what is in gcc,
> where a cli option for arch is implemented in C code. For rpm, there's
> only the implicit configuration based on arch name that chooses
> which macros to load. That "works" but is fragile and hellish to debug.

  Assuming it did build what was expected, it should be mostly an
issue of somehow filtering and putting proper elf files in proper
packages (packages for alternate arch possibly automatically generated)
and adding the proper %_target_cpu to the rpm file name. But that
AFAIK would confuse most tools due to same name, and basically
difference being "rpm -qp --qf %{arch}".

>>  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
>
> The elf interpreter needs to be added (eventually auto generated) as a Provides:
> in glibc, and as a Requires: everywhere else, so that glib <-> uclibc have
> a dependency on the elf interpreter to use. LSB packaging also has a speshul
> elf interpreter that might benefit just like uclibc will.
>
> The (or at least my) goal is a replacement for (iirc, been ~1y) the devel(?)
> dependencies that are accomplishing the same goal (but I dislike and am
> deadlocked etc).
>
> The elf interpreter is displayed by readelf -a by inspection; the devel(?)
> dependency is more complex (than needed imho).
>
> ...
>
>>
>>
>>  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
>>
>
> I'm not sure what you are showing here: the package naming?

  Yes, package naming. Everybody uses glibc.

> Yes "libc.so.6" has been in use for all of this century; glib
> has versioned/weak symbols to permit multiple incompatible
> routines at run-time and the so name never (and never will) change.
>
>>>>>> 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.
>>
>
> Is the problem problem that prevents i686 <-> x86_64 coexistence
> file conflicts or tool brain damage?

  Issues with tools. %mklibname is expected to be used to name
non conflicting runtime libraries. But there should be plently of
issues with -devel packages.

> A loop is needed over multiple platforms.
>
> Whether iurt/jurt/ABF does the loop in a "single submit",
> or (not recommended but likely works) --target=archA,archB
> passed to rpm build, there is a loop achieved.
>
> The side effects of populating a chroot make the BS the more
> appropriate place to add the loop imho.
>
> ...
>
>>
>>  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.
>>
>
> The harder issues (than package naming) are:
> 	hiding the private interfaces in glibc
> 	getting the encoding tables installed
> 	handling the restart of sshd for the once-in-a-decade incompatibility
> 		in glibc module loading (%post -p <lua> recommende; statically
> 		linked helper also "works": the issue is that glib is a prereq
> 		of /bin/sh and so a shell script cannot be used)
>
> Dunno if a "long series" is needed: glibc dependencies are simple
> 	You miss, you die.
> and so very simple to test (even if difficult to change).

  The simple idea is to reduce, besides only for a few MB, disk
usage. If installing -devel packages, effectively would not change
anything from what there is now, and users would only need to
install 32 bit libraries if installing some binary only, and
32 bit only package.

  But at first this has a high chance of becoming a FAQ, and
users reporting that after an update their 32 bit binaries,
installed from a tarball or some .sh installer stopped working,
because there is no rpm dependency information and the 32 bit
library was not installed. And, like it or not, pretty much the
only reason to have 32 and 64 bit binaries in glibc et all is
to, now more for legacy, support for those cases.

  Anyway, first things first. Splitting library packages in
32 and 64 bit on x86_64, and generating 32 bit ix86 package
that does not conflict with the 64 bit one in x86_64 is
halfway done.

>>  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.
>>
>
> Sounds sane to me.
>
> 73 de Jeff

Paulo