flac dev - Sep 2004 - patches for flac build

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

On Wed, Jul 18, 2001 at 03:08:30PM -0700, Josh Coalson wrote:
> 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.
Right now, -fPIC is automatically used when compiling objects that will go into
the shared library (via libtool).  When --enable-shared is used, each source
file is compiled twice, one with -fPIC and one without.  This way, the objects
in the static library (and the various non-library objects) are not burdened
with the added complexity of -fPIC.

It also sets -DPIC, for the benefit of preprocessed and handwritten assembler
modules.  Unfortunately, I don't think NASM can handle everything in CFLAGS,
nor is it suitable for assembling the output of the C compiler, so if you
decide to make the assemble stuff work both PIC and non-PIC, we'll have to
work
something out there.

Speaking of CFLAGS, it looks like configure.in clobbers any existing CFLAGS in
the environment.  This can be a pain when trying to compile with a modified
CFLAGS, as the usual idiom is:

CFLAGS=... ./configure ...

thus propagating CFLAGS to all generated makefiles.  The right thing to do is
probably to prepend to CFLAGS instead of replacing it, so the user's
settings
will come later on the command line and override the defaults.

-- 
 - mdz

> Speaking of CFLAGS, it looks like configure.in clobbers any existing
> CFLAGS in
> the environment.  This can be a pain when trying to compile with a
> modified
> CFLAGS, as the usual idiom is:
> 
> CFLAGS=... ./configure ...
> 
> thus propagating CFLAGS to all generated makefiles.  The right thing
> to do is
> probably to prepend to CFLAGS instead of replacing it, so the user's
> settings
> will come later on the command line and override the defaults.
OK, I checked in a fix... does this snippet look alright?

SAVE_CFLAGS="$CFLAGS"
CFLAGS='-I./include -I $(top_srcdir)/include -Wall -W'
if test x$debug = xtrue; then
    CFLAGS="$CFLAGS -g -O0 -DDEBUG"
else
    CFLAGS="$CFLAGS -O3 -DNDEBUG"
    if test x$GCC = xyes; then
        CFLAGS="$CFLAGS -fomit-frame-pointer -funroll-loops \
        -finline-functions -Winline -DFLAC__INLINE=__inline__"
    fi
fi
CFLAGS="$CFLAGS $SAVE_CFLAGS"


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