GNU bug report logs -
#10677
24.0.93; missing pathmax.h on Solaris
Previous Next
Reported by: Chong Yidong <cyd <at> gnu.org>
Date: Tue, 31 Jan 2012 07:18:02 UTC
Severity: normal
Found in version 24.0.93
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10677 in the body.
You can then email your comments to 10677 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
cleyon <at> gmail.com, bug-gnu-emacs <at> gnu.org:
bug#10677; Package
emacs.
(Tue, 31 Jan 2012 07:18:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Chong Yidong <cyd <at> gnu.org>:
New bug report received and forwarded. Copy sent to
cleyon <at> gmail.com, bug-gnu-emacs <at> gnu.org.
(Tue, 31 Jan 2012 07:18:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10677; Package
emacs.
(Wed, 01 Feb 2012 06:12:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 10677 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10677; Package
emacs.
(Thu, 02 Feb 2012 01:51:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 10677 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (message/rfc822, inline)]
[Message part 2 (text/plain, inline)]
On Wed, Feb 1, 2012 at 03:18, Chong Yidong <cyd <at> 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
[gl-comp.m4.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10677; Package
emacs.
(Thu, 02 Feb 2012 04:54:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 10677 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[transcript.txt.gz (application/x-gzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10677; Package
emacs.
(Mon, 06 Feb 2012 00:15:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 10677 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Feb 1, 2012 at 23:52, Paul Eggert <eggert <at> 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
[emacs-24.0.93-107054.typescript.gz (application/x-gzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10677; Package
emacs.
(Mon, 27 Feb 2012 09:09:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 10677 <at> debbugs.gnu.org (full text, mbox):
Chris Leyon <cleyon <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10677; Package
emacs.
(Fri, 02 Mar 2012 22:36:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 10677 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Feb 27, 2012 at 04:05, Chong Yidong <cyd <at> 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
[typescript.configure.gz (application/x-gzip, attachment)]
[config.log.gz (application/x-gzip, attachment)]
[ldd.emacs23.gz (application/x-gzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10677; Package
emacs.
(Sat, 03 Mar 2012 03:31:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 10677 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10677; Package
emacs.
(Sat, 03 Mar 2012 17:10:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 10677 <at> debbugs.gnu.org (full text, mbox):
On Fri, Mar 2, 2012 at 22:29, Paul Eggert <eggert <at> 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: )"
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10677; Package
emacs.
(Sun, 04 Mar 2012 03:00:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 10677 <at> debbugs.gnu.org (full text, mbox):
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 <at> gnu.org
about that, with an informative "Subject:" line? It's a separate
problem so should have separate tracking and resolution. Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10677; Package
emacs.
(Sun, 04 Mar 2012 09:50:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 10677 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> 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.
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Sun, 04 Mar 2012 18:12:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Chong Yidong <cyd <at> gnu.org>:
bug acknowledged by developer.
(Sun, 04 Mar 2012 18:12:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 10677-done <at> debbugs.gnu.org (full text, mbox):
On 03/04/2012 01:48 AM, Chong Yidong wrote:
> Paul Eggert <eggert <at> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 02 Apr 2012 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 32 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.