primax: Thread: Makefile.cvs trouble

Hi,

I tried to run Makefile.cvs for the latest CVS checkout of
primax_scan. It faltered with the messages shown below.

These come from autoconf-2.53 (Redhat 8) and automake-1.6,
but automake-1.5 and 1.4 more or less cause the same
problem.

Hints anyone?

TIA,

Roel

[roel@shaun ~/src/primax/primaxcvs/primax_scan]$ ./Makefile.cvs
./missing --run autoheader
autoheader: `config.h.in' is created
./missing --run autoconf
configure.in:38: error: possibly undefined macro: AM_INIT_AUTOMAKE
configure.in:53: error: possibly undefined macro: AC_PROG_LIBTOOL
WARNING: `autoconf' is missing on your system.  You should only need it if
         you modified `configure.in'.  You might want to install the
         `Autoconf' and `GNU m4' packages.  Grab them from any GNU
         archive site.
./missing --run automake -a
configure.in:40: `automake requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER'
configure.in:38: no proper implementation of AM_INIT_AUTOMAKE was found,
configure.in:38: probably because aclocal.m4 is missing...
configure.in:38: You should run aclocal to create this file, then
configure.in:38: run automake again.
configure.in:8: installing `./config.guess'
configure.in:8: installing `./config.sub'
Makefile.am: installing `./depcomp'
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL
WARNING: `automake' is missing on your system.  You should only need it if
         you modified `Makefile.am', `acinclude.m4' or `configure.in'.
         You might want to install the `Automake' and `Perl' packages.
         Grab them from any GNU archive site.
./missing --run automake -a
configure.in:40: `automake requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER'
configure.in:38: no proper implementation of AM_INIT_AUTOMAKE was found,
configure.in:38: probably because aclocal.m4 is missing...
configure.in:38: You should run aclocal to create this file, then
configure.in:38: run automake again.
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL
WARNING: `automake' is missing on your system.  You should only need it if
         you modified `Makefile.am', `acinclude.m4' or `configure.in'.
         You might want to install the `Automake' and `Perl' packages.
         Grab them from any GNU archive site.
./missing --run aclocal

    
-- 
____________________________________________
http://www.operamail.com
Get OperaMail Premium today - USD 29.99/year


Powered by Outblaze

On Saturday 07 June 2003 17:42, Roel de Cock wrote:
> Hi,
>
> I tried to run Makefile.cvs for the latest CVS checkout of
> primax_scan. It faltered with the messages shown below.
>
> These come from autoconf-2.53 (Redhat 8) and automake-1.6,
> but automake-1.5 and 1.4 more or less cause the same
> problem.
>
> Hints anyone?

Hmmm - your aclocal.m4 seems not to be the version matching to your automake.
Please try:
$ aclocal
$ automake -a
$ autoconf
$ ./configure

Beside - this is exactly what Makefile.cvs should do. But if there is a 
aclocal.m4 file, it doesn't run aclocal. I wanted to make the Makefile 
efficient, but it has a bug so.

A fixed version is also in the CVS now.
You can get it with:
$ cvs update in the primaxscan directory.

Thanks for the help to find this bug. Please report more problems if you find 
them.

Gruss,

Andre

>
> TIA,
>
> Roel
>
> [roel@shaun ~/src/primax/primaxcvs/primax_scan]$ ./Makefile.cvs
> ./missing --run autoheader
> autoheader: `config.h.in' is created
> ./missing --run autoconf
> configure.in:38: error: possibly undefined macro: AM_INIT_AUTOMAKE
> configure.in:53: error: possibly undefined macro: AC_PROG_LIBTOOL
> WARNING: `autoconf' is missing on your system.  You should only need it if
>          you modified `configure.in'.  You might want to install the
>          `Autoconf' and `GNU m4' packages.  Grab them from any GNU
>          archive site.
> ./missing --run automake -a
> configure.in:40: `automake requires `AM_CONFIG_HEADER', not
> `AC_CONFIG_HEADER' configure.in:38: no proper implementation of
> AM_INIT_AUTOMAKE was found, configure.in:38: probably because aclocal.m4 is
> missing...
> configure.in:38: You should run aclocal to create this file, then
> configure.in:38: run automake again.
> configure.in:8: installing `./config.guess'
> configure.in:8: installing `./config.sub'
> Makefile.am: installing `./depcomp'
> /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in
> AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear
> in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not
> appear in AM_CONDITIONAL /usr/share/automake-1.6/am/lang-compile.am: AMDEP
> does not appear in AM_CONDITIONAL WARNING: `automake' is missing on your
> system.  You should only need it if you modified `Makefile.am',
> `acinclude.m4' or `configure.in'. You might want to install the `Automake'
> and `Perl' packages. Grab them from any GNU archive site.
> ./missing --run automake -a
> configure.in:40: `automake requires `AM_CONFIG_HEADER', not
> `AC_CONFIG_HEADER' configure.in:38: no proper implementation of
> AM_INIT_AUTOMAKE was found, configure.in:38: probably because aclocal.m4 is
> missing...
> configure.in:38: You should run aclocal to create this file, then
> configure.in:38: run automake again.
> /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in
> AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear
> in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not
> appear in AM_CONDITIONAL /usr/share/automake-1.6/am/lang-compile.am: AMDEP
> does not appear in AM_CONDITIONAL WARNING: `automake' is missing on your
> system.  You should only need it if you modified `Makefile.am',
> `acinclude.m4' or `configure.in'. You might want to install the `Automake'
> and `Perl' packages. Grab them from any GNU archive site.
> ./missing --run aclocal

Hi Andre,

> Hmmm - your aclocal.m4 seems not to be the version matching to your
> automake.
> 
> Please try:
> $ aclocal
> $ automake -a
> $ autoconf
> $ ./configure

As a matter of fact, I've first replaced ./missing by the one from
automake-1.6 (to make sure the 'you do not have automake' messages are
crap). Then I tried, in this order:

$ ./missing --run autoheader
$ ./missing --run aclocal
$ ./missing --run autoconf
$ ./missing --run automake -a

Which gives:

autoheader: `config.h.in' is created
configure.in:40: `automake requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER'
configure.in:8: installing `./config.guess'
configure.in:8: installing `./config.sub'
Makefile.am: installing `./depcomp'

You can run configure now, but make blows up with:

  cd . && /bin/sh /home/roel/src/primax/primaxcvs/primax_scan/missing --run autoheader
  autoheader: `config.h.in' is updated
  touch ./config.h.in
  cd . && /bin/sh ./config.status config.h
  config.status: creating config.h
  make  all-am
  make[1]: Entering directory `/home/roel/src/primax/primaxcvs/primax_scan'
  source='libsane-primax.c' object='libsane-primax.lo' libtool=yes \
  depfile='.deps/libsane-primax.Plo' tmpdepfile='.deps/libsane-primax.TPlo' \
  depmode=gcc3 /bin/sh ./depcomp \
  /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c -o \
  libsane-primax.lo `test -f 'libsane-primax.c' || echo './'`libsane-primax.c
  ./libtool: line 1: s%^.*/%%: No such file or directory
  ./libtool: line 1: -e: command not found

  [etc., repeats 15 times or so]

  : compile: cannot determine name of library object from `'
  make[1]: *** [libsane-primax.lo] Error 1
  make[1]: Leaving directory `/home/roel/src/primax/primaxcvs/primax_scan'
  make: *** [all] Error 2

(Why the heck does make try to rerun autoheader??)

I then cleaned up the mess and tried to add
AM_CONFIG_HEADER([config.h]) in configure.in directly after
AC_CONFIG_HEADERS, but that yields the same result.

Acknowledgedly, automake/autoconf is my blind spot :-)

Hope you can help out anyway.

Roel

-- 
____________________________________________
http://www.operamail.com
Get OperaMail Premium today - USD 29.99/year


Powered by Outblaze

On Monday 09 June 2003 22:32, Roel de Cock wrote:
> Hi Andre,
> ...
>
> As a matter of fact, I've first replaced ./missing by the one from
> automake-1.6 (to make sure the 'you do not have automake' messages are
> crap). Then I tried, in this order:
>
> $ ./missing --run autoheader
> $ ./missing --run aclocal
> $ ./missing --run autoconf
> $ ./missing --run automake -a
>
> Which gives:
>
> autoheader: `config.h.in' is created
> configure.in:40: `automake requires `AM_CONFIG_HEADER', not
> `AC_CONFIG_HEADER' configure.in:8: installing `./config.guess'
> configure.in:8: installing `./config.sub'
> Makefile.am: installing `./depcomp'

<quote>
`AM_CONFIG_HEADER'
     Automake will generate rules to automatically regenerate the config
     header.  This obsolete macro is a synonym of `AC_CONFIG_HEADERS'
     today (*note Optional::).
</quote>

This option is obolete since automake 1.7. I'm using  version 1.7 so I used 
AC_CONFIG_HEADERS.
But as it seems this was not the best idea since most distributions still use 
1.6.

I changed this back in the CVS version.
For me it still works.

> I then cleaned up the mess and tried to add
> AM_CONFIG_HEADER([config.h]) in configure.in directly after
> AC_CONFIG_HEADERS, but that yields the same result.

Hmm - don't add the line, REPLACE it.

It's modified in the CVS now.

Please try again after
$ cvs update

Gruss,

Andre

Hi again again Andre,

> This option is obolete since automake 1.7. I'm using  version 1.7 so I used 
> AC_CONFIG_HEADERS.
> But as it seems this was not the best idea since most distributions still use 
> 1.6.
[...]
> Hmm - don't add the line, REPLACE it.

I'd already found out if you _replace_ the line autoheader
gets unhappy:

  autoheader: error: AC_CONFIG_HEADERS not found in
  configure.in

and thus no config.h.in is generated. I even upgraded to
autoconf 2.57 (since autoheader is part of it) but to no
avail.

So I also upgraded to automake 1.7.5, changed configure.in back to use AC_CONFIG_HEADERS, ran Makefile.cvs and got

  configure.in:38: error: possibly undefined macro:
  AM_INIT_AUTOMAKE
  If this token and others are legitimate, please use
  m4_pattern_allow.
  See the Autoconf documentation.

  configure.in:56: error: possibly undefined macro:
  AC_PROG_LIBTOOL

Running the 4 tools by hand again creates a Makefile that
gives the earlier mentioned libtool errors.

Sorry for bothering you again- I'll keep trying. What could
possibly be the difference between your and my setup, using
autoconf 2.57 and automake 1.7, that causes all this?

Roel

-- 
____________________________________________
http://www.operamail.com
Get OperaMail Premium today - USD 29.99/year


Powered by Outblaze

> > Hmm - don't add the line, REPLACE it.
>
> I'd already found out if you _replace_ the line autoheader
> gets unhappy:

But you have to replace it as only one one of them should be used.

>   autoheader: error: AC_CONFIG_HEADERS not found in
>   configure.in
> 
> and thus no config.h.in is generated. I even upgraded to
> autoconf 2.57 (since autoheader is part of it) but to no
> avail.
>
> So I also upgraded to automake 1.7.5, changed configure.in back to use
> AC_CONFIG_HEADERS, ran Makefile.cvs and got
>
>   configure.in:38: error: possibly undefined macro:
>   AM_INIT_AUTOMAKE
>   If this token and others are legitimate, please use
>   m4_pattern_allow.
>   See the Autoconf documentation.
>
>   configure.in:56: error: possibly undefined macro:
>   AC_PROG_LIBTOOL
>
> Running the 4 tools by hand again creates a Makefile that
> gives the earlier mentioned libtool errors.

This is because libtool is generated by automake.

> Sorry for bothering you again- I'll keep trying. What could
> possibly be the difference between your and my setup, using
> autoconf 2.57 and automake 1.7, that causes all this?
>
> Roel


$ aclocal --version
aclocal (GNU automake) 1.7.5

Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Written by Tom Tromey ####@####.####

$ autoconf --version
Autoconf version 2.13

$ automake --version
automake (GNU automake) 1.7.5
Written by Tom Tromey ####@####.####

Copyright 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ autoheader --version
Autoconf version 2.13

Please make sure that you run the aclocal version that corespondes to your 
automake version and autoheader must match with autocoonf.

Okay - I'm a little bit confused, too. All this tools....

Could you please make a clean session.
This means:
Do a new cvs checkout.
And than type BY HAND.

$ aclocal
$ automake -a
$ autoconf
$ autoheader

and send the output.
Maybe I can than better get the point, where the problem is.

Gruss

Andre

Andre Herms ####@####.#### wrote:

> This is because libtool is generated by automake.

That's more or less what I thought- until I found out that Redhat does have the packages libtool and libtool-libs. I upgraded these from Rawhide and now compilation works!

So, in summary:
  autoconf-1.57
  automake-1.7.5
  libtool-1.5.2
  libtool-libs-1.5.2
is a recipe for succes.

> Okay - I'm a little bit confused, too. All this tools....

Second that :-P

BTW I did run:
> $ aclocal
> $ automake -a
> $ autoconf
> $ autoheader
by hand, I'd have to try to see if Makefile.cvs runs fine.

Vielen Dank for the assistance. The next step is getting
SANE to believe me there is a DM 99,- Network Scanny (==Colorado Direct 300) at my parallel port (all this effort was just because I'm too thick too shell out money for other hardware if my old stuff is working just fine). I put primax in dll.conf and even quickly hacked a primax.conf, but xsane etc. refuse to recognise it. Primax_scan does.

Roel

-- 
____________________________________________
http://www.operamail.com
Get OperaMail Premium today - USD 29.99/year


Powered by Outblaze

On Friday 13 June 2003 11:14, Roel de Cock wrote:
> Andre Herms ####@####.#### wrote:
> > This is because libtool is generated by automake.
>
> That's more or less what I thought- until I found out that Redhat does have
> the packages libtool and libtool-libs. I upgraded these from Rawhide and
> now compilation works!

Great to hear that. *smile*

> Vielen Dank for the assistance. The next step is getting
> SANE to believe me there is a DM 99,- Network Scanny (==Colorado Direct
> 300) at my parallel port (all this effort was just because I'm too thick
> too shell out money for other hardware if my old stuff is working just
> fine).
You shouldn't buy a new scanner as the new one are most USB devices. For this 
there are nearly no SANE drivers. So you couldn't use it.

> I put primax in dll.conf and even quickly hacked a primax.conf, but
> xsane etc. refuse to recognise it. Primax_scan does.
You could copy the .libs/libsane-primax.so to the directory where the other 
libsane-*.so files are. 

This could do it if the installation went wrong.

Gruss,

Andre