Josh Coalson <xflac@yahoo.com> wrote:> Now I have done some more reading, and I don't think simply > putting the call to AM_PATH_XMMS an acinclude.m4 will help him.No, of course not. You need to put the macro _definition_, i.e. ...> This macro is defined in /usr/local/share/aclocal/xmms.m4... xmms.m4 into acinclude.m4. (Putting it into aclocal.m4 may or may not suffice, I don't know.) -- Christian "naddy" Weisgerber naddy@mips.inka.de
On Wed, 6 Jun 2001, Josh Coalson wrote:> > > my hunch is that your version of either automake or possibly > > > autoconf is not recent enough.autoconf v2.13 automake v1.4 I've upgraded to autoconf v2.50 and updated flac from cvs. The error is being generated by aclocal anyway and that's part of automake v1.4.> > No. He simply doesn't have xmms installed. That's what I mentioned > > a while ago: non-standard macros should go into acinclude.m4. > > Now I have done some more reading, and I don't think simply > putting the call to AM_PATH_XMMS an acinclude.m4 will help him. > This macro is defined in /usr/local/share/aclocal/xmms.m4Well I just installed xmms v1.2.4 and didn't get that file placed there. I copied it there manually and aclocal is now happy. $ aclocal $ autoconf configure.in:33: warning: AC_CANONICAL_HOST invoked multiple times $ automake --foreign --add-missing automake: configure.in: installing `./install-sh' automake: configure.in: installing `./mkinstalldirs' automake: configure.in: installing `./missing' configure.in: 27: required file `./ltconfig' not found $ ./configure checking for a BSD compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking whether make sets ${MAKE}... yes checking for working aclocal... found checking for working autoconf... found checking for working automake... found checking for working autoheader... found checking for working makeinfo... found checking build system type... i386-unknown-freebsd4.3 checking host system type... i386-unknown-freebsd4.3 checking for ranlib... ranlib checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for executable suffix... checking for object suffix... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for ld used by GCC... /usr/libexec/elf/ld checking if the linker (/usr/libexec/elf/ld) is GNU ld... yes checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes loading cache /dev/null within ltconfig ltconfig: you must specify a host type if you use `--no-verify' Try `ltconfig --help' for more information. configure: error: libtool configure failed I have libtool v1.3.4 installed as it's a dependancy of much of the FreeBSD ports tree. From the libtool v1.3.4 port Makefile: --- # This port has not been upgraded to 1.4 because it is used by about 30% of # the ports collection, and more testing is needed. If someone can supply a # working patch then it will be upgraded. --- Okay. You could say the FreeBSD ports maintainers should get their finger(s) out and upgrade. So I upgraded to libtool v1.4 to see if the old version was the problem. Repeated the procedure and now ./configure seems to work correctly. BTW I also tried libtool v1.3.5 and that gave the same error during the configure. On to the make: $ make Making all in src cd: can't cd to src *** Error code 1 Stop in /root/src/lame/flac. Looks like GNU make is still required: $ gmake [snipped] gcc -shared plugin.lo -Wl,--rpath -Wl,/root/src/lame/flac/src/libFLAC/.libs/.libs -Wl,--rpath -Wl,/usr/local/lib -L/root/src/lame/flac/src/libFLAC/.libs /root/src/lame/flac/src/libFLAC/.libs/.libs/libFLAC.so -L/usr/X11R6/lib -lgtk12 -lgdk12 -L/usr/local/lib -lgmodule12 -lgthread12 -lglib12 -lintl -lxpg4 -lXext -lX11 -lm -lxmms -lc -Wl,-E -Wl,-soname -Wl,libxmms-flac.so -o .libs/libxmms-flac.so gcc: /root/src/lame/flac/src/libFLAC/.libs/.libs/libFLAC.so: No such file or directory gmake[2]: *** [libxmms-flac.la] Error 1 gmake[2]: Leaving directory `/root/src/lame/flac/src/plugin_xmms' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/root/src/lame/flac/src' gmake: *** [all-recursive] Error 1 Hmmm. I've no idea how to fix this. Cheers. Mark Powell - UNIX System Administrator - The University of Salford Academic Information Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 5936 Fax: +44 161 295 5888 www.pgp.com for PGP key
Mark Powell <M.S.Powell@salford.ac.uk> wrote:> > This macro is defined in /usr/local/share/aclocal/xmms.m4 > > Well I just installed xmms v1.2.4 and didn't get that file placed there.Strange. It's part of the package list of the port. (I can't verify at the moment whether it actually gets installed, since glib is broken on FreeBSD-CURRENT/alpha.)> $ ./configure > checking build system type... i386-unknown-freebsd4.3 > checking host system type... i386-unknown-freebsd4.3checking host system type... alpha-unknown-freebsdelf5.0 checking build system type... alpha-unknown-freebsdelf5.0> loading cache /dev/null within ltconfig > ltconfig: you must specify a host type if you use `--no-verify' > Try `ltconfig --help' for more information. > configure: error: libtool configure failedWorks for me.> I have libtool v1.3.4 installedSo have I. The libtool-1.3.4 port has modifications for FreeBSD and works just fine.> Looks like GNU make is still required:Certainly, if you run automake without option --include-deps. Also, src/libFLAC/i386/Makefile is still gmake-specific. Anyway, there is a FreeBSD port for flac. Now, if that doesn't work, I'd really like to know. -- Christian "naddy" Weisgerber naddy@mips.inka.de
> > > $ aclocal && autoconf && automake -c -a -i > > > aclocal: configure.in: 45: macro `AM_PATH_XMMS' not found in > library > > > > my hunch is that your version of either automake or possibly > > autoconf is not recent enough. > > No. He simply doesn't have xmms installed. That's what I mentioned > a while ago: non-standard macros should go into acinclude.m4. >Yes, my mistake. Now I have done some more reading, and I don't think simply putting the call to AM_PATH_XMMS an acinclude.m4 will help him. This macro is defined in /usr/local/share/aclocal/xmms.m4 which is part of an XMMS installation. In other words, to *run* 'configure' you of course do not have to have XMMS installed but to *build* 'configure' you do, because we use a macro that's part of the XMMS installion to generate code to check for XMMS in our configure. This all goes back to the debate on whether you should distribute configure.in or configure, and it looks like the tools were designed for the latter. The implication here is that to build configure you have to have all the packages that any configuration might refer to already installed. So I'm not sure how to solve the problem totally. As much as I would like people to build from CVS, I also don't really want to check in all the generated files (configure, Makefile.in's, etc.) every time configure.in changes. I'm open to suggestions. Josh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
> > Now I have done some more reading, and I don't think simply > > putting the call to AM_PATH_XMMS an acinclude.m4 will help him. > > No, of course not. You need to put the macro _definition_, i.e. ... > > > This macro is defined in /usr/local/share/aclocal/xmms.m4 > > ... xmms.m4 into acinclude.m4. (Putting it into aclocal.m4 may or > may > not suffice, I don't know.) >well, I had already ruled out this option as I really don't want to start maintaining XMMS's code too. this won't really scale as the number of related programs grows. Josh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
On Thu, Jun 07, 2001 at 12:32:04AM +0000, Christian Weisgerber wrote:> Josh Coalson <xflac@yahoo.com> wrote: > > > Now I have done some more reading, and I don't think simply > > putting the call to AM_PATH_XMMS an acinclude.m4 will help him. > > No, of course not. You need to put the macro _definition_, i.e. ... > > > This macro is defined in /usr/local/share/aclocal/xmms.m4 > > ... xmms.m4 into acinclude.m4. (Putting it into aclocal.m4 may or may > not suffice, I don't know.)aclocal.m4 will be clobbered by aclocal, so no. This is the reason why acinclude.m4 exists. -- - mdz