[Flac-dev] patches for flac build

[Josh Coalson]

> > > 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.

I'm not still not sure how to fix this with nasm either.
The code is declared in the .text segment, and emitted
to the .text segment in the .o file, but upon linking
ends up in .rel.text.  I think I will put this off until
after 1.0.

One thing I did noticed is that the CFLAGS are not
specifying -fPIC right now.  Matt, are you planning
to build a C-only version of the shared library?
In this case it would make sense to add -fPIC to
the options.

Josh


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/