--- Matt Zimmerman <mdz@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. > >... > > 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?I thought about shipping the 1.4 files as you had described, then having a Makefile2.{am,in} in libFLAC and libFLAC/ia32 with Ben's version that users can copy in if the regular ones break, plus a note in the README file. Kind of kludgey. I am dreading a flood of mails to the list like 'flac won't compile!'. Josh __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
> 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.Good work! I checked out the latest CVS. autogen.sh and configure ran fine. The top level Makefile crapped out in the man/ subdirectory because I do not have docbook-to-man installed. The rest of flac built flawlessly on my system. Surprise! :) Ben
On Sun, Jul 22, 2001 at 12:28:52AM -0700, Josh Coalson wrote:> 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.Ah, I missed that there was a local bitbuffer.h. In that case, what I should have done was add bitbuffer.h to test_unit_SOURCES.> 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.Everything works except for VPATH builds. One thing that got lost was the addition of -I $(srcdir)/ to the NASM command line, which means nasm.h isn't found when building outside of srcdir. Also, since ordinals.h is autogenerated, we need to add -I $(top_builddir)/include to CFLAGS so it can be found. For the same reason, the headers need to use #include <FLAC/blah.h> instead of #include "blah.h", since they will not necessarily be in the same directory. Right now, this only matters for ordinal.h, of course, but for consistency's sake they should all work this way. None of this is important enough to delay the release, really. I've attached a patch for the first two items which you can apply or not as you see fit.> 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.Everything works when I build in the source tree, which is probably what >99% of users will do. If you want to release, I don't object. -- - mdz -------------- next part -------------- Index: configure.in ==================================================================RCS file: /cvsroot/flac/flac/configure.in,v retrieving revision 1.25 diff -u -r1.25 configure.in --- configure.in 2001/07/22 07:27:45 1.25 +++ configure.in 2001/07/22 09:40:32 @@ -136,7 +136,7 @@ AC_SUBST(FLaC__USIZE64) SAVE_CFLAGS="$CFLAGS" -CFLAGS='-I$(srcdir)/include -I $(top_srcdir)/include -Wall -W' +CFLAGS='-I$(top_builddir)/include -I$(srcdir)/include -I$(top_srcdir)/include -Wall -W' if test x$debug = xtrue; then CFLAGS="$CFLAGS -g -O0 -DDEBUG" else Index: src/libFLAC/ia32/Makefile.am ==================================================================RCS file: /cvsroot/flac/flac/src/libFLAC/ia32/Makefile.am,v retrieving revision 1.7 diff -u -r1.7 Makefile.am --- src/libFLAC/ia32/Makefile.am 2001/07/22 07:26:58 1.7 +++ src/libFLAC/ia32/Makefile.am 2001/07/22 09:40:35 @@ -21,7 +21,7 @@ STRIP_FPIC = sh $(top_srcdir)/strip_fPIC.sh .nasm.lo: - $(LIBTOOL) --mode=compile $(STRIP_FPIC) $(NASM) -f $(OBJ_FORMAT) -d OBJ_FORMAT_$(OBJ_FORMAT) $< -o $@ + $(LIBTOOL) --mode=compile $(STRIP_FPIC) $(NASM) -f $(OBJ_FORMAT) -d OBJ_FORMAT_$(OBJ_FORMAT) -I $(srcdir)/ $< -o $@ noinst_LTLIBRARIES = libFLAC-asm.la libFLAC_asm_la_SOURCES = \
--- Matt Zimmerman <mdz@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/
Josh Coalson <xflac@yahoo.com> wrote:> Try the latest CVS.===> Building for flac-1.0 Making all in doc Making all in . Making all in images Making all in ru Making all in include Making all in FLAC Making all in man Using $< in a non-suffix rule context is a GNUmake idiom (line 257 of Makefile) *** Error code 1 Either go with a real suffic rule or use something like this: --- Makefile.am.orig Sun Jul 22 17:41:39 2001 +++ Makefile.am Sun Jul 22 17:45:15 2001 @@ -16,7 +16,7 @@ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. flac.1: flac.sgml - docbook-to-man $< > $@ || docbook2man $< > $@ + docbook-to-man $? > $@ || docbook2man $? > $@ man_MANS = flac.1 -- Christian "naddy" Weisgerber naddy@mips.inka.de
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? -- - mdz