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