Subject: Re: PATCH: fvwm-2.3.33/acinclude.m4 smr_ARG_WITHLIB needs to check existence of library

From: "Adam J. Richter" <[email-masked]>
Date: Tue, 26 Jun 2001 20:24:27 -0700

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.

>> 	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 did not respond to it initially
because I thought my clarification of the problem made it irrelevant.
Here is a response to your explanation:

| [The patch] only "works" for you because:
|
|  1) your libtermcap does not contain "main" function

	I have no libtermcap library on this system.

|  2) your libncurses does contain "main" function
|  3) your libreadline does contain "main" function

	Wrong.  See:
	
	baldur[510] nm /usr/lib/libreadline.* | egrep main
	baldur[511] nm /usr/lib/libncurses.* | egrep main
	baldur[512] 

	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).

>Add this line to your fvwmrc and press Alt-F12 (after restarting):

>  Key F12 A M Module FvwmConsole

	Thanks.  That works fine with my change.

>> 	I believe that ncurses can be configured to install a symlink
>> from /usr/lib/libtermcap.a to /usr/lib/ncurses.a, or at least that older
>> verions of ncurses could, and that this may have hidden the problem before.

>Yes, this may be a problem. Please investigate whether you have good
>libtermcap.a and/or libtermcap.so.

	As I said, there is no termcap library on this system.  The symlink
was on some other older systems, not the one where I tried the build.

[...]

>What build error do you get?

	From doing "autoconf ; ./configure ; make all" on the pristine
fvwm-2.3.33 sources:

gcc  -g -O2  -o FvwmConsole  FvwmConsole.o -L../../libs -lfvwm -lreadline -ltermcap  
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.0/../../../../i686-pc-linux-gnu/bin/ld: cannot find -ltermcap
collect2: ld returned 1 exit status

>BTW, which mailer do you use, it does not add References: and In-Reply-To:
>headers, so threads are not preserved...

	/usr/bin/mail (sometimes called "Berkeley mail", or "mailx").

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
[email-masked]     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

--
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-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 27 Jun 2001 14:07:12 +0000

> "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.

> 	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.

> 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.