On Sun, 11 Jan 2004, James Finnall wrote:
>
> Thank you for your reply Stephen. I have installed autoconf 2.5.9,
> automake 1.8 and libtool 1.5.
Oh, automake 1.8 is available? I hadn't checked since installing
1.7.9
> I originally did install them using the defaults, but then I went and
> rebuilt them with the proper prefix, --prefix=/usr. Today I was still having
> problem with them seeking in /usr/local so I ran "make uninstall" from
Hmmm, that would tell me that the version installed into /usr was
not the one actually being used.
> in /usr/local. WHen I search for them using "whereis" it only reports the
> /usr/local/bin/programs. When I run the commands with --version
> it reports the proper version.
Ah, ok - good.
> I had to copy the contents of /usr/share/aclocal down to the
> /usr/local/share/aclocal location to remove the beginning errors
> The glib.m4 file is in the /usr/local/share/aclocal location as well.
>
> Also, on the automake program, it creates another directory named automake-1.8
> and aclocal-1.8 as well as the others. Don't know if that makes a difference
> but thought I would mention it.
Aieee - yes, that can make a difference and thanks for mentioning it.
I do not know at which version of automake the appending of the
version number to the directory started (it was not always like that)
but to resolve some issues I was having I removed 'aclocal' and
created a symlink:
cd /usr/local/share
rm -r aclocal
ln -s aclocal-1.7.9 aclocal
(in your case it'd be 1.8 instead of 1.7.9)
> `./autogen.sh' command line.
>
> processing .
> Running libtoolize...
> You should add the contents of `/usr/local/share/aclocal/libtool.m4' to `aclocal.m4'.
That's fine - so libtoolize did its job.
> Running aclocal ...
> /usr/local/share/aclocal/xmms.m4:17: warning: underquoted definition of
> XMMS_TEST_VERSION
> run info '(automake)Extending aclocal'
> or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal
> /usr/local/share/aclocal/xmms.m4:62: warning: underquoted definition of AM_PATH_XMMS
it seems that automake 1.8 is much more picky/verbose about the
quoting in the .m4 files - they're warnings though and do not stop
the processing.
> aclocal: configure.in: 380: macro `AM_PATH_SDL' not found in library
There's the cause of the remaining errors. For whatever reason
automake (and aclocal is part of automake) is bailing out and _NOT_
creating the aclocal.m4 file.
Not having a valid aclocal.m4 leads to a cascade of errors
> Running autoheader...
> Running automake --gnu ...
> configure.in: no proper invocation of AM_INIT_AUTOMAKE was found.
AM_INIT_AUTOMAKE is indeed present in configure.in
> configure.in: You should verify that configure.in invokes AM_INIT_AUTOMAKE,
> configure.in: that aclocal.m4 is present in the top-level directory,
> configure.in: and that aclocal.m4 was recently regenerated (using aclocal).
automake is saying it doesn't have an aclocal.m4 file
> lavtools/Makefile.am:14: HAVE_V4L does not appear in AM_CONDITIONAL
> lavtools/Makefile.am:20: HAVE_V4L_OR_SDL does not appear in AM_CONDITIONAL
that is false - those (and all the others) are indeed present.
No sense going on - the rest of the errors were triggered by aclocal
exiting without creating an aclocal.m4 file.
So, despite the 'ifdef([AM_PATH_SDL], ...' logic 'automake/aclocal'
is adamant that 'sdl.m4' exist.
Thing to do is install the SDL (and the -devel) package. Then make
sure that 'sdl.m4' is present in the aclocal-1.8/ directory and
give ./autogen.sh another try.
Good Luck.
Steven Schultz
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
