State of multilib development update

[Hans de Goede]

Hi all,

Some time ago I send the message below, I've now filed bugs left and
right and I'm posting this again with the BZ url's for those interested.

---

Yesterday I tried to build i386 rpms on my x86_64 using the new
multilib-devel packages instead of resorting to an i386 chroot.

Although we have come a long way to making this possible there are still
a few issues which makes doing this very hard:

1) gcc ignores setarch
======================

"gcc -o hello helloworld.c", creates an x86_64 elf file on my x86_64
system as expected however, "setarch i386 gcc -o hello helloworld.c"
also creates an x86_64 elf file instead of an i386 one, to get an i386
one I must do: "gcc -m32 -o hello helloworld.c".

This is unfortunate, because even though rpmbuild adds -m32 to the
*FLAGS environment variables things still don't for many packages,
because they for example often ignore LDFLAGS, thus not specifying -m32
when linking, causing things to fail.

A work around is to create shell script wrappers for gcc, g++ and ld
which always add -m32, put these somewhere outside the standard $PATH
and add the location to PATH when you want to build i386 binaries.

BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212520
(which got closed as not a bug, as I was already afraid).


2) rpmbuild ignores setarch
===========================

"setarch i386 rpmbuild -bb foo.spec" Still tries to build an x86_64 foo,
I know "rpmbuild --target i386" works better but still has issues, for
example libdir is still set to /usr/lib64, this is already in bugzilla.

BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194123


3) pkgconfig ignores setarch
============================
I thought that pkgconfig was supposed to get this right and hence it was
used to implement verious replacement foo-config scripts, but pkgconfig
doesn't get this right. When testing I had only libpng-devel.i386
installed not the x86_64 version:
---
[hans@shalem ~]$ pkg-config --cflags libpng
Package libpng was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpng.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libpng' found
---
Behaves as expected, since it searches /usr/lib64/pkgconfig where there
is no libpng.pc
---
[hans@shalem ~]$ setarch i386 pkg-config --cflags libpng
Package libpng was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpng.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libpng' found
[hans@shalem ~]$ ls -l /usr/lib/pkgconfig/libpng.pc
lrwxrwxrwx 1 root root 11 Oct 15 18:50 /usr/lib/pkgconfig/libpng.pc ->
libpng12.pc
---
Does not behave as expected, it should search /usr/lib/pkgconfig and
find libpng.pc

This can be worked around by doing a "export
PKG_CONFIG_PATH=/usr/lib/pkgconfig"

BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212522


4) rpmbuild lets x86_64 packages satisfy BR's when building for i386
====================================================================

The subject says most of it, when doing an rpmbuild --target=i386 I
don't want libXt-devel.x86_64 to satisfy a BR: libXt-devel .

I know things aren't that easy because with something like BR:
desktop-file-utils, the x86_64 version will do fine.

Suggestion: make rpmbuild check the arch of BR's who's name ends with
-devel.

BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212523


5) xxx-devel.arch should require xxx.arch not just xxx
======================================================

When I install libXt-devel.i386 I expect it to drag in libXt.i386 and
not to be happy with the already installed libXt.x86_64 .

This will also stop some polution with i386 packages of x86_64 system,
because currently we have the following scenario:

libXt-1.0.2-3.fc6.x86_64 is installed

Users does "yum install libXt-devel.x86_64"

Yum finds libXt-devel-1.0.2-3.1.fc6.x86_64,
which needs libXt-1.0.2-3.1.fc6.x86_64 yum does decides to update the
x86_64 version of libXt and as an added bonus also install the i386
version since both match the requirement of libXt-devel-1.0.2-3.1.fc6.x86_64

BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212524


Let me know what you think & Regards,

Hans

[Ralf Corsepius]

On Fri, 2006-10-27 at 10:38 +0200, Hans de Goede wrote:
>  Hi all, 
>  "gcc -o hello helloworld.c", creates an x86_64 elf file on
> my x86_64
>  system as expected however, "setarch i386 gcc -o hello helloworld.c"
>  also creates an x86_64 elf file instead of an i386 one, to get an i386
>  one I must do: "gcc -m32 -o hello helloworld.c".
>  
>  This is unfortunate,  
GCC's -m<flags> are the actual origin of multilibs
(NOTE: multilibs ==
building for architecture variants; not multiarch'ing == running
different architectures in the same run-time environment !).

>  because even though rpmbuild adds -m32 to the
>  *FLAGS environment variables things still don't for many packages,
>  because they for example often ignore LDFLAGS, 
It is controversial if
-m<flags> should be part of CFLAGS or LDFLAGS
etc.

Some people consider it to be a mistake, because -m<flags> can comprise
effects on various components of a toolchain, not only the compiler
(E.g. there exist targets from whom -m<flags> set CPP defines).

>   thus not specifying -m32
>  when linking, causing things to fail. 
Adding -m<flags> directly to CC, CXX
etc. is an alternative approach.

Ralf

[Rob Andrews]

On 27-Oct-2006 09:38.02 (BST), Hans de Goede wrote:
>  1) gcc ignores setarch
>  "gcc -o hello helloworld.c", creates an x86_64 elf file on my x86_64
>  system as expected however, "setarch i386 gcc -o hello helloworld.c"
>  also creates an x86_64 elf file instead of an i386 one, to get an i386
>  one I must do: "gcc -m32 -o hello helloworld.c". 
Should gcc pay heed to the uname-specified architecture? You wouldn't expect
setarch i386 to affect the behaviour of a cross compiler. rpmbuild already
does The Right Thing(tm) with selecting -m32 when performing --target=i386
builds, it's just a shame it doesn't get %{_lib} and %{_libdir} correct.

-- 
rob andrews                       :: pgp 0x01e00563 :: rob(a)choralone.org

[Ralf Corsepius]

On Fri, 2006-10-27 at 14:40 +0100, Rob Andrews wrote:
>  On 27-Oct-2006 09:38.02 (BST), Hans de Goede wrote:
>   > 1) gcc ignores setarch
>   > "gcc -o hello helloworld.c", creates an x86_64 elf file on my x86_64
>   > system as expected however, "setarch i386 gcc -o hello helloworld.c"
>   > also creates an x86_64 elf file instead of an i386 one, to get an i386
>   > one I must do: "gcc -m32 -o hello helloworld.c".
>  
>  Should gcc pay heed to the uname-specified architecture?  
Definitely no.

Rpm could do so, if it really wants.

>  You wouldn't expect
>  setarch i386 to affect the behaviour of a cross compiler. rpmbuild already
>  does The Right Thing(tm) with selecting -m32 when performing --target=i386
>  builds, it's just a shame it doesn't get %{_lib} and %{_libdir} correct.
Right, this one of the many bugs in redhat-rpm-config and rpm (For real
rpm cross building the culprit is redhat-rpm-config).

Ralf

[dragoran]

I would like to add this:
i386-devel packages do not create the symlinks needed by ld to find a lib.
ld -lX11 will search for libX11.so
If you have libX11-devel.x86_64 installed there will be a symlink 
/usr/lib64/libX11.so -> /usr/lib64/libX11.so.6.2.0 which is ok and works.
But if you have installed libX11-devel.i386 there is no symlink which 
results into ld is unable to find the lib.
libX11 was just an example, this happens with ALL i386-devel packages.