Why are arm libs branded as SYSV?

Ian Lepore ian at FreeBSD.org
Tue Oct 7 17:30:00 UTC 2014


On Tue, 2014-10-07 at 18:16 +0100, Andrew Turner wrote:
> On Tue, 07 Oct 2014 09:45:01 -0600
> Ian Lepore <ian at FreeBSD.org> wrote:
> 
> > On Tue, 2014-10-07 at 16:34 +0100, Andrew Turner wrote:
> > > On Tue, 07 Oct 2014 16:56:49 +0200
> > > "Ronald Klop" <ronald-lists at klop.ws> wrote:
> > > 
> > > > 
> > > > On my ARM Sheevaplug:
> > > > # file /usr/local/lib/libpcre.so.3
> > > > /usr/local/lib/libpcre.so.3: ELF 32-bit LSB shared object, ARM,
> > > > EABI5 version 1 (SYSV), dynamically linked, stripped
> > > > 
> > > > On my amd64 computer:
> > > > file /usr/local/lib/libpcre.so.3
> > > > /usr/local/lib/libpcre.so.3: ELF 64-bit LSB shared object, x86-64,
> > > > version 1 (FreeBSD), dynamically linked, stripped
> > > > 
> > > > Because of this I can not run ldd on a shared library on my ARM
> > > > system. # ldd -a /usr/local/lib/libpcre.so.3
> > > > ldd: /usr/local/lib/libpcre.so.3: not a FreeBSD ELF shared object
> > > > 
> > > > 
> > > > Is that on purpose? I am curious why that is.
> > > 
> > > Because the EI_OSABI field, where this value comes from, is
> > > documented to be zero in the ARM AAELF spec.
> > > 
> > > Andrew
> > 
> > Does this imply we have to update our elf tools to recognize the
> > freebsd-ness of arm eabi objects in some other way?
> 
> The only one we had issues with was gdb. It inspects the elf notes to
> find which target operating system to handle. This was added early last
> year, with a fix earlier this year for armeb.
> 

Well there's also the trouble quoted at the top of this email. :)

-- Ian




More information about the freebsd-arm mailing list