[Flac-dev] 1.0 candidate checked in

[Josh Coalson]

--- Matt Zimmerman <mdz at debian.org> wrote:
> On Sat, Jul 21, 2001 at 04:06:14PM -0400, Matt Zimmerman wrote:
> 
> > Argh.  Maybe libtool will have to get involved after all.  I'll
> work on it
> > this afternoon.
> 
> I think I give up.  automake and libtool assume that the compiler
> will be able
> to assemble stuff, and compilers don't generally understand NASM
> input.  I
> don't like the strip_fPIC bit, since just about anything that could
> go in
> CFLAGS might be passed by libtool, and nasm doesn't understand
> compiler flags.
> 
> However, I can't come up with anything better at the moment, and this
> seems to
> work for SDL, so I guess we go back to src/libFLAC/ia32/Makefile.am
> version 1.5
> (plus my automake patch).  The libtool command line needs to be
> modified to
> use "-o $@", otherwise libtool gives the error:
> 
> /bin/sh ../../../libtool --mode=compile \
>         sh ../../../strip_fPIC.sh nasm -f elf -d OBJ_FORMAT_elf
> cpu_asm.nasm
> libtool: compile: cannot determine name of library object from
> `cpu_asm.nasm'
> make: *** [cpu_asm.lo] Error 1
> 
> Changing the rule to:
> 
> 	$(LIBTOOL) --mode=compile \
> 		$(STRIP_FPIC) $(NASM) -f $(OBJ_FORMAT) -d OBJ_FORMAT_$(OBJ_FORMAT)
> -o $@ $<
> 
> fixes that, but we still have the issue of --tag with libtool > 1.4. 
> The
> way I see it, we have two options:
> 
> 1. Ship with libtool 1.4b.  This is pre-release software, and I don't
> know what
>    issues might be associated with it.
> 
> 2. Ship with libtool 1.4.  Users who want to use a later version on
> i386 will
>    have to make a small patch to the ia32 makefile.
> 
> The good news is, libtool 1.4b seems to support enable/disable of
> shared
> library building at runtime, so we won't need that awful
> libtool-disable-static
> bit anymore.  We can just use --tag=disable-shared once we ship that
> version.
> Also, I think it should be possible to create a tagged configuration
> for NASM
> so we don't have to worry about the -fPIC issue.
> 
> I like what I see in libtool 1.4b, but I don't know if its widespread
> use is
> recommended yet.  Ideas?

OK, attempting one more convergence on all this, here's
what I did:

1. Reverted back to rev 1.5 of src/libFLAC/ia32/Makefile.am
2. Applied Matt's last cleanup patch of 8 files.  I did not
apply the patch to src/test_unit/main.c since it looks wrong.
main.c is supposed to include the local bitbuffer.h, not
src/libFLAC/private/bitbuffer.h; I think the current version
is correct.
3. Copied src/libFLAC/ia32/Makefile.am to
src/libFLAC/ia32/Makefile.am.libtool-1.4b.  The only difference
is that Makefile.am.libtool-1.4b has --tag=CC and Makefile.am
does not.
4. Added the check 'test -d $(BINS_PATH) || exit 77' to
test/test_bins.sh
5. Generated all the Makefile.ins, and including a
src/libFLAC/ia32/Makfile.in.libtool-1.4b.
6. 'Improved' the flac.sgml rule to fall back to docbook2man
if there's no docbook-to-man (this should really be handled
in configure.in).

I hope this is all correct!  I had do go back and reread
the last 40 mails to make sure.  Everything is checked in
to CVS.  Now I need Matt's and Ben's help again.  Try the
latest CVS.  I am guessing it will work for Matt and
break for Ben.  If it breaks, try using
Makefile.in.libtool-1.4b and let me know if that works.

If getting the CVS tree is too much pain, I checked in a
new tarball in the same place:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/flac/junk/flac-1.0-src-candidate.tar.bz2

Hopefully we're getting closer because within the next
couple of days I am going to get busy with other things
and probably won't be able to put a lot of time into
this for a few weeks.  I wasn't expecting libtool to
blow up in my face... it was working so well for a
while.

Josh


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/