On 26 Jun 2001 20:24:27 -0700, Adam J. Richter wrote:
>
> UPDATE: One thing that I have not noticed before is that I
> was running autoconf before ./configure. Just running "./configure" on
> the pristine sources does seem to detect the absense of libtermcap somehow.
> So, this is a more subtle bug, perhaps related to autoconf-2.50. I am
> looking into it. The rest of this response applies to doing
> "autoconf ; ./configure ; make all" on the fvwm-2.3.33 sources.
Ok, now you finaly supplied enough information for me to be able to
reproduce the problem. :-)
If I remove libtermcap, run autoconf from autoconf-2.50 package, the
resulting ./configure says "(cached) yes" for termcap, which is wrong.
But if I run autoreconf instead (which is more correct), everything is ok.
If I then run autoconf (all from 2.50), the problem appears again.
It seems for me that this is a problem in autoconf-2.50, at least this
behaviour is not compatible with autoconf-2.13.
Here is a patch that makes autoconf-2.50 happy in all situations for me:
--- acinclude.m4 2001/05/14 06:56:30 1.16
+++ acinclude.m4 2001/06/27 13:18:24
@@ -262,7 +262,7 @@
ifelse($5, , , smr_header=[$5])
smr_ARG_WITHLIB($1,$2,$3)
if test "$with_$1" != no; then
- AC_CHECK_LIB($smr_lib, $4,
+ AC_CHECK_LIB(${smr_lib}, $4,
smr_havelib=yes,
smr_havelib=no; problem_$1=": Can't find required lib$smr_lib",
ifelse($6, , ${$1_LIBS}, [${$1_LIBS} $6]))
I would not apply it before 2.4.0 unless it is really necessary.
I prefer not to risk, although it seems to work with autoconf-2.13 too.
> >> After I applied my patch, the FvwmConsole program linked correctly
> >> (with "-lreadline -lncurses" instead of "-lreadline -ltermcap"), and
> >> installed without errors.
>
> >I hope I explained why your patch seemed to work for you. It is a
> >combination of events that works on your system only.
>
> Your explanation is wrong.
I should agree with you, my explanation is not good.
Still it correctly describes that it is not portable.
Here is exactly what I said, but expressed differently.
The output with your patch on your system (without termcap) seems to be:
checking for main in -lxpm... yes
checking for main in -lrplay... yes
checking for main in -lstroke... yes
checking for main in -ltermcap... no
checking for main in -lncurses... yes
checking with ncurses... checking for main in -lreadline... yes
My output with your patch on my system (I have all libraries) is:
checking for main in -lxpm... no
checking for main in -lrplay... yes
checking for main in -lstroke... yes
checking for main in -ltermcap... no
checking for main in -lncurses... yes
checking with ncurses... checking for main in -lreadline... no
Currently I have no time to investigate why all these "no" appear after
your patch is applied.
> Using "main" as the function to check for in AC_CHECK_LIB
> causes AC_CHECK_LIB to check for the existance of the library without
> requiring a specific function, since "main" is defined in the body of the
> test program. This is the convention for achieving this result in autoconf.
> A grep of our source tree shows 202 directory trees that use it, covering
> just about every category of program you can think of (i.e., not just
> kde, gtk-based software or anything like that).
But we have an even better check later in configure, we check that
readline() call works within the library, not only main().
The problem with autoconf-2.50 is related to caching. I find that caching
(which is hard to implement both correctly and effectivelly) usually
causes more problems than solves, it only reduces time a bit.
Regards,
Mikhael.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
