arm October 2007

arm@lists.fedoraproject.org

2 participants
3 discussions

multiarch header file wrappers and ARM
by Lennert Buytenhek 24 Oct '07

24 Oct '07

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

1 0

Firefox dependency
by Rabeeh Khoury 22 Oct '07

22 Oct '07

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

2 2

Distributed CC
by Rabeeh Khoury 01 Oct '07

01 Oct '07

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

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm October 2007