[Flac-dev] patches for flac build

[Matt Zimmerman]

On Mon, Jul 16, 2001 at 11:35:28AM -0700, Josh Coalson wrote:

> > The functions themselves, as far as I can tell, only reference data on the
> > stack as you say.  It is the entry points which are not
> > position-independent (though they are relocatable).
> > 
> > I confess to not quite being a wizard at this (yet), but as I understand
> > it, shared library code should be position-independent (using relative
> > addresses) rather than just relocatable (which could mean that some
> > addresses must be patched by the runtime linker).  For the calls to be PIC,
> > they must be made through an offset stored in the GOT.
> > 
> > There is a section in the NASM manual (8.2 in my copy), titled "Writing
> > NetBSD/FreeBSD/OpenBSD and Linux/ELF Shared Libraries" that seems to
> > explain how to write position-independent code with NASM.
> 
> I'm still not too clear on all this stuff either.  It looks like the only
> relevant section of the manual is 8.2.4;  I could export the function entry
> points that way.  But I don't get why this is necessary if the functions are
> private to the library.
> 
> Matt, do you think this would be enough to make it work?  What kind of errors
> (linker?) do you get with the current code?

What originally led me to investigate this was that lintian (a tool to check
Debian packages for possible problems) reported this error:

E: libflac0: shlib-with-non-pic-code usr/lib/libFLAC.so.0.0.0
N:
N:   The listed shared libraries contain object code that was compiled
N:   without -fPIC. All object code in shared libraries should be
N:   recompiled separately from the static libraries with the -fPIC option.
N:   Another common mistake that causes this problem is linking with ``gcc
N:   -Wl,-shared'' instead of ``gcc -shared''.
N:   Refer to Policy Manual, section 11.2 for details.
N:

This is triggered by the presence of a rel.text section in the shared object
as reported by objdump -h:

  5 .rel.text     00000020  000030f4  000030f4  000030f4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA

Whereas the rest of the code lives in a plain old .text section.  If you look
at other shared libraries, like libc, you see no rel.text section, only .text.
I believe the rationale for this is that relocation causes the library not to
be shared in memory, because different relocations will be necessary when the
library is loaded at different locations.  This isn't much of an issue for FLAC
currently, due to the small number of applications that use it, but it seems
like good practice.  It is up to you whether or not you feel this is
worthwhile; I will deal with the policy compliance issue.

As I understand it, non-PIC shared library code doesn't work on other
architectures, notably IA64 and PA-RISC, which Debian is currently porting
to[0].  This isn't an issue for FLAC, since the ia32 assembler won't be used,
but I guess it's something to be kept in mind when writing assembler for other
architectures.

I'm trying to find other projects which build a shared library using
multiplatform assembly to see how they deal with this, but the only one I can
find is glibc.  They use the GNU assembler, and everything is so tied up in
macros that I don't know what's going on yet.

[0] By the way, flac seems to segfault early on IA64.  When built with
--enable-debug, I get a failed assertion:

flac 0.10, Copyright (C) 2000,2001 Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

options: -P 0 -b 4608 -m -l 8 -q 0 -r 3,3 -R 0 -V
/home/mdz/english.wav:
@@@ FLAC__CPU_UNKNOWN
lt-flac: stream_decoder.c:173: FLAC__stream_decoder_init: Assertion `decoder->guts->cpuinfo.use_asm' failed.
Aborted

-- 
 - mdz