bug#10677: 24.0.93; missing pathmax.h on Solaris

bug#10677: 24.0.93; missing pathmax.h on Solaris

[Chong Yidong]

I received the following compile failure on Solaris (SunOS 5.10).

Paul, could you investigate?  Thanks.  (Keeping my fingers crossed that
the proferred solution is not going to be a Gnulib sync ;-)

--

Hi, I'm attempting to compile Emacs 24.0.93 on my work Solaris box but
pathmax.h is not found.

Uname -a reports
SunOS morocco 5.10 Generic_127111-11 sun4u sparc SUNW,Sun-Fire-V490 Solaris
I'm compiling with gcc --version
gcc (GCC) 3.4.6

I'm afraid I have no control over the system software that's installed
here...  That's why I compile into my home directory.  This exact same
machine compiled Emacs 23.3 without any problems at all.

The configuration is nothing special:
bash-4.1$ ./configure --prefix=/home/leyon/contrib
--with-x-toolkit=lucid --with-gif=no

The exact error is:
bash-4.1$ make
[ -r "/home/leyon/morocco/emacs-24.0.93/src/config.in" ] || ( cd
/home/leyon/morocco/emacs-24.0.93 && autoheader )
cd lib; make all                            \
  CC='gcc -std=gnu99' CFLAGS='-g -O2' CPPFLAGS='' \
  LDFLAGS='-L/usr/openwin/lib' MAKE='make'
make  all-am
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../src
-I/home/leyon/morocco/emacs-24.0.93/src      -g -O2 -MT stat.o -MD -MP
-MF .deps/stat.Tpo -c -o stat.o stat.c
stat.c:50:22: pathmax.h: No such file or directory
*** Error code 1
make: Fatal error: Command failed for target `stat.o'
Current working directory /home/leyon/morocco/emacs-24.0.93/lib
*** Error code 1
make: Fatal error: Command failed for target `all'
Current working directory /home/leyon/morocco/emacs-24.0.93/lib
*** Error code 1
make: Fatal error: Command failed for target `lib'

If you would like any further information I'd be happy to assist.

bug#10677: 24.0.93; missing pathmax.h on Solaris

[Paul Eggert]

I cannot reproduce the bug on my Solaris 10 box,
but I think I see the problem.  I installed a fix
into the trunk as bzr 107037; please give it a try
on your box.  Thanks.

bug#10677: [Chris Leyon] Re: bug#10677: 24.0.93; missing pathmax.h on Solaris

[Chong Yidong]

[-- Attachment #0: Type: message/rfc822, Size: 6838 bytes --]

[-- Attachment #1.1: Type: text/plain, Size: 1261 bytes --]

On Wed, Feb 1, 2012 at 03:18, Chong Yidong <cyd@gnu.org> wrote:
> Hi Chris,
>
> Could you try the following patch (from Paul Eggert) and see if it fixes
> your problem?  Please let me know whether it works or not.
>
> (You need to run autoconf again after applying this patch.)
>
> Thanks.

The patch mostly worked.  However, autoconf gave an error about a
"possibly undefined macro" for the new symbol gl_PATHMAX.  I added a
`m4_pattern_allow' command to m4/gl-comp.m4 and that made autoconf
happy.  I am attaching my diff for gl-comp.m4.


After applying the patch & running autoconf, configure, make, the
compilation proceeds further but unfortunately now encounters an error
on the statement `verify (INT_MAX <= PTRDIFF_MAX)'.

gcc -std=gnu99 -c  -Demacs -DHAVE_CONFIG_H  -I.
-I/home/leyon/morocco/emacs-24.0.93/src -I../lib
-I/home/leyon/morocco/emacs-24.0.93/src/../lib
-I/usr/openwin/include     -I/usr/include/libxml2
-Wimplicit-function-declaration -Wold-style-definition
-Wdeclaration-after-statement  -g -O2 alloc.c
alloc.c:766: error: negative width in bit-field `_gl_verify_error_if_negative'
gmake[1]: *** [alloc.o] Error 1
gmake[1]: Leaving directory `/home/leyon/morocco/emacs-24.0.93/src'
gmake: *** [src] Error 2

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: gl-comp.m4.diff --]
[-- Type: text/x-patch; name=gl-comp.m4.diff, Size: 2342 bytes --]

diff -u /home/leyon/morocco/emacs-24.0.93/m4/gl-comp.m4.\~1\~ /home/leyon/morocco/emacs-24.0.93/m4/gl-comp.m4
--- /home/leyon/morocco/emacs-24.0.93/m4/gl-comp.m4.~1~	2011-10-13 20:40:36.000000000 -0400
+++ /home/leyon/morocco/emacs-24.0.93/m4/gl-comp.m4	2012-02-01 10:15:21.056039600 -0500
@@ -65,6 +65,8 @@
   # Code from module mktime:
   # Code from module multiarch:
   # Code from module nocrash:
+  # Code from module pathmax:
+  m4_pattern_allow([^gl_PATHMAX$])
   # Code from module pthread_sigmask:
   # Code from module readlink:
   # Code from module signal-h:
@@ -217,6 +219,7 @@
 gl_UNISTD_H
   gl_gnulib_enabled_dosname=false
   gl_gnulib_enabled_be453cec5eecf5731a274f2de7f2db36=false
+  gl_gnulib_enabled_pathmax=false
   gl_gnulib_enabled_sigprocmask=false
   gl_gnulib_enabled_stat=false
   gl_gnulib_enabled_strtoll=false
@@ -236,6 +239,13 @@
       gl_gnulib_enabled_be453cec5eecf5731a274f2de7f2db36=true
     fi
   }
+  func_gl_gnulib_m4code_pathmax ()
+  {
+    if ! $gl_gnulib_enabled_pathmax; then
+gl_PATHMAX
+      gl_gnulib_enabled_pathmax=true
+    fi
+  }
   func_gl_gnulib_m4code_sigprocmask ()
   {
     if ! $gl_gnulib_enabled_sigprocmask; then
@@ -262,6 +272,9 @@
         func_gl_gnulib_m4code_dosname
       fi
       if test $REPLACE_STAT = 1; then
+        func_gl_gnulib_m4code_pathmax
+      fi
+      if test $REPLACE_STAT = 1; then
         func_gl_gnulib_m4code_verify
       fi
     fi
@@ -326,6 +339,7 @@
   m4_pattern_allow([^gl_GNULIB_ENABLED_])
   AM_CONDITIONAL([gl_GNULIB_ENABLED_dosname], [$gl_gnulib_enabled_dosname])
   AM_CONDITIONAL([gl_GNULIB_ENABLED_be453cec5eecf5731a274f2de7f2db36], [$gl_gnulib_enabled_be453cec5eecf5731a274f2de7f2db36])
+  AM_CONDITIONAL([gl_GNULIB_ENABLED_pathmax], [$gl_gnulib_enabled_pathmax])
   AM_CONDITIONAL([gl_GNULIB_ENABLED_sigprocmask], [$gl_gnulib_enabled_sigprocmask])
   AM_CONDITIONAL([gl_GNULIB_ENABLED_stat], [$gl_gnulib_enabled_stat])
   AM_CONDITIONAL([gl_GNULIB_ENABLED_strtoll], [$gl_gnulib_enabled_strtoll])
@@ -502,6 +516,7 @@
   lib/md5.h
   lib/mktime-internal.h
   lib/mktime.c
+  lib/pathmax.h
   lib/pthread_sigmask.c
   lib/readlink.c
   lib/sha1.c
@@ -552,6 +567,7 @@
   m4/mktime.m4
   m4/multiarch.m4
   m4/nocrash.m4
+  m4/pathmax.m4
   m4/pthread_sigmask.m4
   m4/readlink.m4
   m4/sha1.m4

Diff finished.  Wed Feb  1 10:15:34 2012

bug#10677: [Chris Leyon] Re: bug#10677: 24.0.93; missing pathmax.h on Solaris

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]

On 02/01/2012 10:43 AM, Chris Leyon wrote:
> autoconf gave an error about a
> "possibly undefined macro" for the new symbol gl_PATHMAX.

These symptoms suggest that autoconf was run without
aclocal -I m4 being run beforehand.  Or perhaps a buggy
set of autotools was used; I would not trust the old tools
shipped with Solaris 10.

Chris, can you please run the distribution tarball that
I just generated from the latest trunk (bzr 107054)?
I used the latest tools, so this should avoid any problems
with old Solaris autotools.  The tarball is temporarily at:

http://cs.ucla.edu/~eggert/emacs-24.0.93-107054.tar.gz

You should be able to untar it and type these commands:

  ./configure --with-x-toolkit=lucid --with-gif=no
  make
  uname -a
  gcc --version
  cat config.log

I just now did this on a Solaris 10 host, and it
worked for me; please see the attached shell transcript.
If it doesn't work for you, please run the same commands
and compare your transcript to mine.

> I added a `m4_pattern_allow' command to m4/gl-comp.m4
> and that made autoconf happy.

Most likely that merely masked the real problem.

> After applying the patch & running autoconf, configure, make, the
> compilation proceeds further but unfortunately now encounters an error
> on the statement `verify (INT_MAX <= PTRDIFF_MAX)'.

If INT_MAX > PTRDIFF_MAX, there's something very wrong with the setup,
and it's a good thing alloc.c caught it.  I expect the above procedure
will help us narrow the problem down.

[-- Attachment #2: transcript.txt.gz --]
[-- Type: application/x-gzip, Size: 53128 bytes --]

bug#10677: [Chris Leyon] Re: bug#10677: 24.0.93; missing pathmax.h on Solaris

[Chris Leyon]

[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]

On Wed, Feb 1, 2012 at 23:52, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 02/01/2012 10:43 AM, Chris Leyon wrote:
>> autoconf gave an error about a
>> "possibly undefined macro" for the new symbol gl_PATHMAX.
>
> These symptoms suggest that autoconf was run without
> aclocal -I m4 being run beforehand.  Or perhaps a buggy
> set of autotools was used; I would not trust the old tools
> shipped with Solaris 10.

It is true I did not run aclocal beforehand, I merely ran autoconf
again.  I had installed and was using automake 1.11.3 and autoconf
2.68.

> Chris, can you please run the distribution tarball that
> I just generated from the latest trunk (bzr 107054)?
> I just now did this on a Solaris 10 host, and it
> worked for me; please see the attached shell transcript.
> If it doesn't work for you, please run the same commands
> and compare your transcript to mine.
>
> If INT_MAX > PTRDIFF_MAX, there's something very wrong with the setup,
> and it's a good thing alloc.c caught it.  I expect the above procedure
> will help us narrow the problem down.

On the code from your new tarball I downloaded, the compilation
produces the same error about INT_MAX > PTRDIFF_MAX as before.  I
suspect these lines from the configure output are relevant:

checking for bit size of ptrdiff_t... unknown
checking for bit size of size_t... unknown
checking for bit size of sig_atomic_t... unknown
checking for bit size of wchar_t... unknown
checking for bit size of wint_t... unknown

I am attaching the full output log of the commands you requested.

Regards,
Chris

[-- Attachment #2: emacs-24.0.93-107054.typescript.gz --]
[-- Type: application/x-gzip, Size: 50707 bytes --]

bug#10677: [Chris Leyon] Re: bug#10677: 24.0.93; missing pathmax.h on Solaris

[Chong Yidong]

Chris Leyon <cleyon@gmail.com> writes:

> On the code from your new tarball I downloaded, the compilation
> produces the same error about INT_MAX > PTRDIFF_MAX as before.  I
> suspect these lines from the configure output are relevant:
>
> checking for bit size of ptrdiff_t... unknown
> checking for bit size of size_t... unknown
> checking for bit size of sig_atomic_t... unknown
> checking for bit size of wchar_t... unknown
> checking for bit size of wint_t... unknown
>
> I am attaching the full output log of the commands you requested.

Hi Chris,

Could you check if the latest pretest at

ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.94.tar.gz

still has the same problem?  Thanks.

bug#10677: [Chris Leyon] Re: bug#10677: 24.0.93; missing pathmax.h on Solaris

[Chris Leyon]

[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]

On Mon, Feb 27, 2012 at 04:05, Chong Yidong <cyd@gnu.org> wrote:
> Hi Chris,
> Could you check if the latest pretest at
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.94.tar.gz
> still has the same problem?  Thanks.

Yes, 24.0.94 still exhibits the same problem.  I have looked more
closely into the output of configure (attached as
typescript.configure.gz and config.log.gz).  It appears to me that the
problem has to do with (n)curses: when configure is attempting to
determine which library contains tputs(3), it decides on ncurses (see
config.log:8457, configure:14331).  If you notice, the -lncurses
sticks around on various gcc lines for the rest of the configure run.

However on my system, what apparently happens is that gcc can
successfully compile a program with -lncurses but when the loader
attempts to actually run such an executable, ld.so is not able to open
the libncurses.so object and crashes.  See config.log:8655 for the
first instance of this, but it occurs many other times following.

It seems that some times configure compiles a test program (conftest)
with -lncurses and other times it omits this library.  Some times
configure merely checks the return status of gcc, and other times it
actually tries to run conftest, which may or may not fail.  Thus I get
a really screwed up configuration, and this crashing of conftest
results in "unknown" bit sizes.

FYI, Emacs 23 does not try to use ncurses, it links to
/usr/lib/libcurses.so.1, as demonstrated in the ldd.emacs23.gz
attachment.  Just in case something had changed in my libraries
recently, I configured and compiled a vanilla 23.3 Emacs....  It
configured, compiled, and runs just fine.

Chris

[-- Attachment #2: typescript.configure.gz --]
[-- Type: application/x-gzip, Size: 4669 bytes --]

[-- Attachment #3: config.log.gz --]
[-- Type: application/x-gzip, Size: 40483 bytes --]

[-- Attachment #4: ldd.emacs23.gz --]
[-- Type: application/x-gzip, Size: 384 bytes --]

bug#10677: [Chris Leyon] Re: bug#10677: 24.0.93; missing pathmax.h on Solaris

[Paul Eggert]

Thanks for diagnosing the problem.  The ncurses 'configure' stuff
changed recently, and it continues to be a mess (with comments
indicating that it's a mess, sigh), but I see two things that cause
your problem.  First, 'configure' modifies LIBS for the tputs link
test and then never sets it back, which is normally a no-no (and is a
no-no here); and second, 'configure' assumes that if you can
successfully link to tputs then tputs will work but (as you've found)
this does not always work with dynamic linking.

I can reproduce the problem on my Solaris 10 host when I configure with

   configure --with-x-toolkit=lucid --with-gif=no \
     LDFLAGS=-L/opt/sfw/lib \
     CPPFLAGS=-I/opt/sfw/include

and the following patch fixes it for me.  Can you give it a try?  It
will mean you'll need full set of build tools (which Solaris doesn't
have), so you may need to apply the patch on an up-to-date Linux box,
do a 'make', then 'make distclean', then copy the result to Solaris 10
and run it there.  If that's too much to ask, I suppose I could install
it into the trunk and let you try the next pretest.

2012-03-03  Paul Eggert  <eggert@cs.ucla.edu>

	configure: fix ncurses 'configure' issue on Solaris 10 (Bug#10677)
	* configure.in (LIBS_TERMCAP): Default this to the result of
	the tputs library search.  Do a run-time test for the linkability
	of tputs unless cross-compiling, as that's more reliable if the
	link flags and libraries are messed up.  Don't change LIBS as
	a result of the test, as that may mess up later tests.

=== modified file 'configure.in'
--- configure.in	2012-02-27 03:20:00 +0000
+++ configure.in	2012-03-03 02:20:34 +0000
@@ -2784,11 +2784,43 @@
 # It's better to believe a function is not available
 # than to expect to find it in ncurses.
 # Also we need tputs and friends to be able to build at all.
-have_tputs_et_al=true
+AC_MSG_CHECKING([for library containing tputs])
+# Run a test program that contains a call to tputs, a call that is
+# never executed.  This tests whether a pre-'main' dynamic linker
+# works with the library.  It's too much trouble to actually call
+# tputs in the test program, due to portability hassles.  When
+# cross-compiling, assume the test program will run if it links.
+AC_DEFUN([tputs_link_source], [
+  AC_LANG_SOURCE(
+     [[extern void tputs (const char *, int, int (*)(int));
+       int main (int argc, char **argv)
+       {
+	  if (argc == 10000)
+	    tputs (argv[0], 0, 0);
+	  return 0;
+       }]])
+])
 # Maybe curses should be tried earlier?
 # See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9736#35
-AC_SEARCH_LIBS(tputs, [ncurses terminfo termcap curses], , have_tputs_et_al=false)
-if test "$have_tputs_et_al" != true; then
+for tputs_library in '' ncurses terminfo termcap curses; do
+  OLIBS=$LIBS
+  if test -z "$tputs_library"; then
+    LIBS_TERMCAP=
+    msg='none required'
+  else
+    LIBS_TERMCAP=-l$tputs_library
+    msg=$LIBS_TERMCAP
+    LIBS="$LIBS_TERMCAP $LIBS"
+  fi
+  AC_RUN_IFELSE([tputs_link_source], [], [msg=no],
+    [AC_LINK_IFELSE([tputs_link_source], [], [msg=no])])
+  LIBS=$OLIBS
+  if test "X$msg" != Xno; then
+    break
+  fi
+done
+AC_MSG_RESULT([$msg])
+if test "X$msg" = Xno; then
   AC_MSG_ERROR([The required function `tputs' was not found in any library.
 These libraries were tried: libncurses, libterminfo, libtermcap, libcurses.
 Please try installing whichever of these libraries is most appropriate
@@ -2807,7 +2839,6 @@
 ## freebsd < 40000, ms-w32, msdos, netbsd < 599002500, and
 ## darwin|gnu without ncurses.
 TERMINFO=no
-LIBS_TERMCAP=
 case "$opsys" in
   ## cygwin: Fewer environment variables to go wrong, more terminal types.
   ## hpux10-20: Use the system provided termcap(3) library.
@@ -2872,10 +2903,6 @@
 TERMCAP_OBJ=tparam.o
 if test $TERMINFO = yes; then
   AC_DEFINE(TERMINFO, 1, [Define to 1 if you use terminfo instead of termcap.])
-
-  ## Default used to be -ltermcap.  Add a case above if need something else.
-  test "x$LIBS_TERMCAP" = "x" && LIBS_TERMCAP="-lcurses"
-
   TERMCAP_OBJ=terminfo.o
 fi
 AC_SUBST(LIBS_TERMCAP)

bug#10677: [Chris Leyon] Re: bug#10677: 24.0.93; missing pathmax.h on Solaris

[Chris Leyon]

On Fri, Mar 2, 2012 at 22:29, Paul Eggert <eggert@cs.ucla.edu> wrote:
> Thanks for diagnosing the problem.  The ncurses 'configure' stuff
> changed recently, and it continues to be a mess (with comments
> indicating that it's a mess, sigh) [...]

Paul, your patch to configure.in worked on Solaris.  The new configure
script detected -ltermcap for tputs, ncurses was not referenced at all
on the linklines, and the pointer sizes were successfully detected.
There were no errors encountered during compilation (there were some
warnings, of course), but an executable was created which runs fine.
Thanks for all your help in fixing this problem.


And now I would like to report an incompatible change to the Lisp
reader which I did not see documented in etc/NEWS but might be worth
mentioning (or fixing).  In Emacs 23, the following syntax for
specifying the key C-, is accepted:
  (global-set-key [(control ,)] 'my-command)
In Emacs 24, this generates an error: "Invalid read syntax: )"

bug#10677: [Chris Leyon] Re: bug#10677: 24.0.93; missing pathmax.h on Solaris

[Paul Eggert]

On 03/03/2012 09:07 AM, Chris Leyon wrote:

> Paul, your patch to configure.in worked on Solaris.

Thanks.  Chong, OK if I install that?

> And now I would like to report an incompatible change to the Lisp
> reader which I did not see documented in etc/NEWS but might be worth
> mentioning (or fixing).  In Emacs 23, the following syntax for
> specifying the key C-, is accepted:
>   (global-set-key [(control ,)] 'my-command)
> In Emacs 24, this generates an error: "Invalid read syntax: )"

Could you please send a separate email to bug-gnu-emacs@gnu.org
about that, with an informative "Subject:" line?  It's a separate
problem so should have separate tracking and resolution.  Thanks.

bug#10677: [Chris Leyon] Re: bug#10677: 24.0.93; missing pathmax.h on Solaris

[Chong Yidong]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 03/03/2012 09:07 AM, Chris Leyon wrote:
>
>> Paul, your patch to configure.in worked on Solaris.
>
> Thanks.  Chong, OK if I install that?

Please do, thanks.

bug#10677: [Chris Leyon] Re: bug#10677: 24.0.93; missing pathmax.h on Solaris

[Paul Eggert]

On 03/04/2012 01:48 AM, Chong Yidong wrote:
> Paul Eggert <eggert@cs.ucla.edu> writes:
> 
>> On 03/03/2012 09:07 AM, Chris Leyon wrote:
>>
>>> Paul, your patch to configure.in worked on Solaris.
>>
>> Thanks.  Chong, OK if I install that?
> 
> Please do, thanks.

Thanks, I did that, and I'm marking this Solaris bug as done.