Re: readelf/ldconfig confused about ELF header
On Sat, Jan 05, 2008 at 04:14:59AM -0500, Mike Frysinger wrote: On Wednesday 31 October 2007, Hamish Moffatt wrote: I'm using buildroot to compile for armeb on a x86-64 (little-endian) host. please use the buildroot mailing list in the future I thought it was an ldconfig bug, but it turned out to be a problem with one of the other packages in my buildroot configuration. Patch submitted and applied to the buildroot repository already. thanks Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: error when building gcc using buildroot/toolchain
On Thu, Nov 01, 2007 at 09:42:27AM +0200, liran tal wrote: Hey Bernhard, I will update you as well as the mailing list on issues I stumble while working with your git repository. When working with gcc-4.1.2, the compilation breaks with an error of a missing file 'execinfo.h' which is referenced from toolchain_build_mipsel/gcc-4.1.2/libmudflap/mf-runtime.c (that's on my mipsel build). By commenting out line 56 for including execinfo.h the rest of the compilation process continues ok. This is fixed in buildroot's svn. The problem is that the libmudflap configure uses the host's cpp rather than the target, which then finds the host's execinfo.h at configure time, which doesn't exist at compile time when the correct tools are used. Here's the patch I supplied. Hamish Index: gcc-uclibc-3.x.mk === --- gcc-uclibc-3.x.mk (revision 20217) +++ gcc-uclibc-3.x.mk (working copy) @@ -242,6 +242,7 @@ (cd $(GCC_BUILD_DIR2); rm -rf config.cache; \ $(HOST_CONFIGURE_OPTS) \ GCC=$(TARGET_CROSS)gcc \ + CPP=$(TARGET_CROSS)cpp \ LDFLAGS_FOR_TARGET=$(patsubst %,LDFLAGS+=-Wl$(comma)%,$(TARGET_LDFLAGS)) -L$(STAGING_DIR)/lib -L$(STAGING_DIR)/usr/lib \ $(GCC_DIR)/configure \ --prefix=$(STAGING_DIR) \ @@ -267,7 +268,7 @@ touch $@ $(GCC_BUILD_DIR2)/.compiled: $(GCC_BUILD_DIR2)/.configured - PATH=$(TARGET_PATH) $(MAKE) $(HOST_CONFIGURE_OPTS) -C $(GCC_BUILD_DIR2) all + PATH=$(TARGET_PATH) $(MAKE) $(HOST_CONFIGURE_OPTS) CPP=$(TARGET_CROSS)cpp -C $(GCC_BUILD_DIR2) all touch $@ $(GCC_BUILD_DIR2)/.installed: $(GCC_BUILD_DIR2)/.compiled -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
readelf/ldconfig confused about ELF header
I'm using buildroot to compile for armeb on a x86-64 (little-endian) host. uclibc's readelf and ldconfig are giving confusing results reading the headers of compiled libraries. Programs run ok, but ldconfig decides that my target has mixed byte-order libraries and generates a wrong-endianness ld.so.conf. readelf says the right things for uClibc's own libraries: [ 5:00PM] [EMAIL PROTECTED]:europaboot/root/lib $ ../../../../build_armeb/staging_dir/usr/bin/armeb-linux-uclibcgnu-readelf -h libdl.so.0 ELF Header: Magic: 7f 45 4c 46 01 02 01 61 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI:ARM ABI Version: 0 Type: DYN (Shared object file) Machine: ARM Version: 0x1 Entry point address: 0x788 Start of program headers: 52 (bytes into file) Start of section headers: 8332 (bytes into file) Flags: 0x202, has entry point, GNU EABI, software FP Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 6 Size of section headers: 40 (bytes) Number of section headers: 16 Section header string table index: 15 (although the GNU EABI part is not correct AFAICT). However for some reason for the libraries built by ext2fsprogs, [ 5:04PM] [EMAIL PROTECTED]:europaboot/root/lib $ ../../../../build_armeb/staging_dir/usr/bin/armeb-linux-uclibcgnu-readelf -h libe2p.so ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI:UNIX - System V ABI Version: 0 Type: DYN (Shared object file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x1db0 Start of program headers: 64 (bytes into file) Start of section headers: 22704 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 5 Size of section headers: 64 (bytes) Number of section headers: 25 Section header string table index: 24 However, objdump -p says the right things for this same library, and I can run the programs linked to it ok. [ 5:05PM] [EMAIL PROTECTED]:europaboot/root/lib $ ../../../../build_armeb/staging_dir/usr/bin/armeb-linux-objdump -p libe2p.so.2.3 libe2p.so.2.3: file format elf32-bigarm Program Header: LOAD off0x vaddr 0x paddr 0x align 2**15 filesz 0x3afc memsz 0x3afc flags r-x LOAD off0x4000 vaddr 0xc000 paddr 0xc000 align 2**15 filesz 0x03ac memsz 0x05a4 flags rw- DYNAMIC off0x4014 vaddr 0xc014 paddr 0xc014 align 2**2 filesz 0x00d0 memsz 0x00d0 flags rw- Dynamic Section: NEEDED libgcc_s.so.1 NEEDED libc.so.0 SONAME libe2p.so.2 INIT0xef8 FINI0x3044 HASH0x94 STRTAB 0x7ac SYMTAB 0x2dc STRSZ 0x32f SYMENT 0x10 PLTGOT 0xc0e4 PLTRELSZ0x150 PLTREL 0x11 JMPREL 0xda8 REL 0xb98 RELSZ 0x210 RELENT 0x8 VERNEED 0xb78 VERNEEDNUM 0x1 VERSYM 0xadc RELCOUNT0x3b Version References: required from libgcc_s.so.1: 0x0b792650 0x00 02 GCC_3.0 private flags = 202: [APCS-32] [FPA float format] [software FP] [has entry point] I guess this means something is whacky in ext2fsprog's library generation? thanks Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: readelf/ldconfig confused about ELF header
On Wed, Oct 31, 2007 at 05:10:05PM +1100, Hamish Moffatt wrote: I'm using buildroot to compile for armeb on a x86-64 (little-endian) host. uclibc's readelf and ldconfig are giving confusing results reading the headers of compiled libraries. Programs run ok, but ldconfig decides that my target has mixed byte-order libraries and generates a wrong-endianness ld.so.conf. [..] I guess this means something is whacky in ext2fsprog's library generation? Yup. I was running readelf on libext2fs.so, which was a symlink to /lib/libext2fs.so.2.4 (absolute path) - the host's library, not the cross-compiled version. ldconfig was following the links and seeing different endianness in the host's libraries, thus generating a host-order ld.so.conf. Bug#1565 reported against buildroot's e2fsprogs package, with patch. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
On Mon, Sep 03, 2007 at 04:44:55PM -0500, Kevin Day wrote: Except for: 1) There is no stable uClibc, 0.9.28 is bugridden, 0.9.29 requires a number of patches only available in svn (let alone countless other bugs yet to be publicized) , and releases prior to 0.9.28 seem to have Yikes, is there a list of the known essential patches to 29? I'm using 0.9.28 and having problems with threads, so I'm attempting to upgrade to 29 as I see it includes a large libpthread update. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
arm support for new linuxthreads in 0.9.29
Hi, I'm trying to upgrade to 0.9.29 and use the new linuxthreads, but my target is arm and it won't compile due to missing sysdep-cancel.h. Attempts to drop in versions thereof from glibc's code result in successful compilation, but any threaded application segfaults during startup. Switching back to the old linuxthreads works, but I'm having problems with a multithreaded application hanging so I want to try the new library... What do I need to do to get the new version to compile? thanks Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
