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.

…

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

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

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