multiarch header file wrappers and ARM
by Lennert Buytenhek
Hi,
A number of packages have multilib header file wrappers such as
this one (blkid_types.h from e2fsprogs):
/* This file is here to prevent a file conflict on multiarch systems. A
* conflict will occur because blkid_types.h has arch-specific definitions.
*
* DO NOT INCLUDE THE NEW FILE DIRECTLY -- ALWAYS INCLUDE THIS ONE INSTEAD. */
#if defined(__i386__)
#include "blkid_types-i386.h"
#elif defined(__ia64__)
#include "blkid_types-ia64.h"
#elif defined(__powerpc64__)
#include "blkid_types-ppc64.h"
#elif defined(__powerpc__)
#include "blkid_types-ppc.h"
#elif defined(__s390x__)
#include "blkid_types-s390x.h"
#elif defined(__s390__)
#include "blkid_types-s390.h"
#elif defined(__x86_64__)
#include "blkid_types-x86_64.h"
#elif defined(__alpha__)
#include "blkid_types-alpha.h"
#else
#error "This e2fsprogs-devel package does not work your architecture?"
#endif
It seems that most of such header files are (directly or indirectly)
copied from some original example that didn't test for ARM, and so,
a couple of examples in the distro right now lack the proper definitions
for ARM, causing ARM to end up with unusable -devel packages.
On ARM, the preprocessor symbol __arm__ is defined, and %{_arch} is
set to 'arm', so something like this will work:
#if defined(__i386__)
#include "blkid_types-i386.h"
+#elif defined(__arm__)
+#include "blkid_types-arm.h"
#elif defined(__ia64__)
#include "blkid_types-ia64.h"
#elif defined(__powerpc64__)
If you have such a construct in your package, please consider adding
the relevant __arm__ bits.
thanks,
Lennert
16 years, 1 month
Firefox dependency
by Rabeeh Khoury
Hi,
I had an issue when installing Firefox that it strangely required
ld-linux.so.3(4000002:) and other strange dependencies.
After digging inside I found that the problem seem to be an ARM specific
problem.
In the FireFox build there is a call for the RPM script find-requires
(part of the RPM package).
This script goes over all binaries and extracts the libraries (and other
things) from each binary using the 'objdump -p' command.
Doing so for an example binary provides the following output -
main: file format elf32-littlearm
Program Header:
0x70000001 off 0x00000d5c vaddr 0x00008d5c paddr 0x00008d5c align
2**2
filesz 0x00000018 memsz 0x00000018 flags r--
........
Version References:
required from libgcc_s.so.1:
0x0b792655 0x00 03 GCC_3.5
required from libc.so.6:
0x0d696914 0x00 02 GLIBC_2.4
private flags = 4000002: [Version4 EABI] [has entry point]
And the problem is actually in the "private flags" line where the script
mistakenly thinks its part of the dependency.
I fixed that temporarily in the find-requires file and I'm now
rebuilding firefox --> tomorrow I'll let you know if it finally fixed
this problem.
The patch for fixing find-requires is -
--- /usr/lib/rpm/redhat/find-requires.orig 2007-10-03
02:58:19.000000000 +0200
+++ /usr/lib/rpm/redhat/find-requires 2007-10-03 03:13:14.000000000
+0200
@@ -95,7 +95,7 @@
[ -r $f ] || continue
lib64=`if file -L $f 2>/dev/null | \
grep "ELF 64-bit" >/dev/null; then echo "$mark64"; fi`
- $OBJDUMP -p $f | awk 'BEGIN { START=0; LIBNAME="";
needed='$needed'; }
+ $OBJDUMP -p $f | grep -v "private flags =" | awk 'BEGIN { START=0;
LIBNAME=""; needed='$needed'; }
/^$/ { START=0; }
/^Dynamic Section:$/ { START=1; }
(START==1) && /NEEDED/ {
Regards,
Rabeeh
16 years, 1 month
Distributed CC
by Rabeeh Khoury
Hi,
Lately I'v tried building boost package in two different methods while
measuring the time it consumes.
The first using Orion-2 system and running completely native build using
the FC-8 RPMs.
The second is using Orion-2 that has distcc client that calls through
fast Ethernet to a Core 2 duo x86 machine that has the FC-8
cross-compiler environment with distcc daemon.
The total build time using the distcc for boost was 5X faster (complete
build with archiving).
The question is can we use this as an addition to Koji build system to
make building from scratch faster?
I know about the efforts to make everything cross-build, but until that
becomes ready the distributed build can be very attractive.
Note that for the build I didn't need to change anything in RPM specs,
or RPM macros and configuration; only installed distcc and changed the
path.
Regards,
Rabeeh
16 years, 2 months