Re: uname: build problem on win32
On Mon, Aug 10, 2009 at 6:26 PM, Bruno Haible wrote: > Sam Steingold wrote: >> the bottom line is: >> if I add -I build/gnulib/ to module CFLAGS, then include_next will >> make build/gnulib/unistd.h supersede build/syscalls/gnulib/unistd.h, >> which is no good. >> if I do NOT add -I build/gnulib/ to module CFLAGS, then >> regexp/gnulib/regex.c will not find build/gnulib/alloca.h > > Indeed, this is still somewhat weird. The include_next should work as expected > if you massage the inclusion guard identifiers of the two unistd.h files > so that they become different: On one of these, do a > sed -e s/_GL_UNISTD_H/_GL_UNISTD_H_2/ you seem to imply that after all the solution is to add -I build/gnulib/ to module CFLAGS, but to somehow uniquify those guards so that _all_ the generated unistd.h files are included one by one and none is bypassed. 1. are you sure this is safe? (i.e., they cannot step on each others toes) 2. you can use the --macro-prefix gnulib-too argument to augment the guards. i.e., whenever you generate a header, modify the guards according to the prefix. thanks! -- Sam Steingold <http://sds.podval.org>
Re: uname: build problem on win32
On Sat, Aug 8, 2009 at 3:14 AM, Bruno Haible wrote: > It would be worth trying to not --avoid=unistd in the modules subdirectories. > This should lead to a different being generated for the module > subdirectory than for the clisp core, but a more complete one. > > More generally, you want to use --avoid for modules which generate code, > and where duplicate functions in different .o files would lead to linker > errors. But you may want to omit --avoid for modules which only provide > autoconf macros and header files. the bottom line is: if I add -I build/gnulib/ to module CFLAGS, then include_next will make build/gnulib/unistd.h supersede build/syscalls/gnulib/unistd.h, which is no good. if I do NOT add -I build/gnulib/ to module CFLAGS, then regexp/gnulib/regex.c will not find build/gnulib/alloca.h I can, of course, add -I build/gnulib/ to module CFLAGS on a per-module basis, but what if a module wants both unistd.h and alloca?! -- Sam Steingold <http://sds.podval.org>
Re: close_used_without_requesting_gnulib_module_close
On Mon, Aug 10, 2009 at 3:29 PM, Paolo Bonzini wrote: > On 08/10/2009 09:02 PM, Sam Steingold wrote: >> >> What does this mean? >> I did not request the close module, and it is not clear why I should. >> >> (in fact, I don't see why pulling uname should change the semantics of >> close. >> yes, uname requires gethostname, which requires sockets &c, so I see the >> dependency chain, but I think what I see is a dependency *creep*, which >> I have been complaining about ever since I started using gnulib). > > No, gethostname does not require sockets &c, it just requires sys/socket.h. then I do not see why close has to be redefined. > IIRC, something like this: > > diff --git a/lib/unistd.in.h b/lib/unistd.in.h > index 93edb48..733c8b6 100644 > --- a/lib/unistd.in.h > +++ b/lib/unistd.in.h > @@ -137,7 +137,7 @@ > # define close rpl_close > extern int close (int); > # endif > -#elif @UNISTD_H_HAVE_WINSOCK2_H@ > +#elif @UNISTD_H_HAVE_WINSOCK2_H@ &&(@GNULIB_SOCKET@ || @GNULIB_ACCEPT@) > # undef close > # define close close_used_without_requesting_gnulib_module_close > #elif defined GNULIB_POSIXCHECK > > was not considered safe (?), but I would like to have something like this > indeed. well, maybe it is time to apply your patch... -- Sam Steingold <http://sds.podval.org>
strftime does not support %F and %T
strftime on linux supports %F and %T which are, I guess, extensions. any plans to support it in gnulib/strftime?
Re: uname: build problem on win32
On Mon, Aug 10, 2009 at 2:22 PM, Sam Steingold wrote: > I followed your instructions, so now I have unistd.h both in the above > and in build/gllib/unistd.h > the former comes first on the gcc -I list, but, apparently, #include > next discards it and only the latter is actually used. ... and when I remove build/gllib/ from the -I list, regexp stops working because it needs alloca.h in build/gllib/. -- Sam Steingold <http://sds.podval.org>
close_used_without_requesting_gnulib_module_close
What does this mean? I did not request the close module, and it is not clear why I should. (in fact, I don't see why pulling uname should change the semantics of close. yes, uname requires gethostname, which requires sockets &c, so I see the dependency chain, but I think what I see is a dependency *creep*, which I have been complaining about ever since I started using gnulib). at any rate, what am I supposed to do now? just import "close"?
Re: uname: build problem on win32
On Sat, Aug 8, 2009 at 3:14 AM, Bruno Haible wrote: > Sam Steingold wrote: >> In file included from >> /cygdrive/c/sds/dev/current/modules/syscalls/gllib/gethostname.c:83: >> /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h: In function >> `set_winsock_errno': >> /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h:34: warning: >> implicit declaration of function `WSAGetLastError' >> /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h:35: warning: >> implicit declaration of function `WSASetLastError' >> /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h:40: error: >> `WSA_INVALID_HANDLE' undeclared (first use in this function) > > For comparison, when I do > ./gnulib-tool --create-testdir --dir=/tmp/testdir mktime strftime strptime > uname > and build the resulting testdir on mingw, the compilation of gethostname.c > works > fine, because the generated unistd.h contains these lines: > > #if 1 > /* Get all possible declarations of gethostname(). */ > # if 1 > # include yes, this is what I now have in build/syscalls/gllib/unistd.h and I get the exact same error. I wonder what the #include_next does. I followed your instructions, so now I have unistd.h both in the above and in build/gllib/unistd.h the former comes first on the gcc -I list, but, apparently, #include next discards it and only the latter is actually used. -- Sam Steingold <http://sds.podval.org>
Re: no-c++
On Mon, Aug 10, 2009 at 10:12 AM, Simon Josefsson wrote: > Sam Steingold writes: > >> Some packages are compilable with both C (production) and C++ (extra >> compilation time type checking and run-time verification for >> debugging). >> when such a package uses code from gnulib, it wants to compile it with >> the compiler ($(CC)) it uses for the rest of the package, i.e., when >> compiling with CC=C, it compiles the imported gnulib code with C, ahen >> compiling with CC=C++, it compiles the imported gnulib code with with >> C++. >> when the imported gnulib code cannot be compiled with C++ (e.g., >> regexp), this causes problems. > > I don't see how CC=c++ would ever work generally as C and C++ are > different languages. well, they are similar enough that their common part, if you wish (i.e., the code that would compile with both) is large enough for a package to be written in. after all C++ was designed as an extension to C, i.e., originally it was a superset thereof. > Instead of CC=c++, why not use a configure parameter like > --with-cxx-compiler that makes the project build the parts of the > project that is known to be compilable as C++ using the system's C++ > compiler, and use a C compiler for the rest (i.e., gnulib code)? With > this approach, you can use normal AC_PROG_CXX etc checks for the C++ > stuff and don't have to hack around autoconf/automake. what is --with-cxx-compiler? how do I enable it? >>> Compiling C code with a C++ compiler seems like a good recipe for >>> problems, and I don't think it is something gnulib should force on users >>> unless there is a compelling use-case. >> >> the "forcing" goes the other way around. >> the user of gnulib forces C++ on gnulib code, and gnulib should use >> no-cxx (when necessary) to cope with it. > > I don't follow the analogy. If a user attempts CC=python gnulib will > break. I did not know python was designed as a superset of C. > Is there a wide class of projects or operating systems that recommends > or suggests use of CC=c++ that I've missed? I'm trying to understand > the origins of the CC=c++ notion. Learning that may help me understand > the bigger picture. http://clisp.cons.org/impnotes/gc-safety.html#gc-alloccount -- Sam Steingold <http://sds.podval.org>
Re: no-c++
On Mon, Aug 10, 2009 at 6:28 AM, Simon Josefsson wrote: > Bruno Haible writes: > >> Should the 'regex' module (and possibly other modules which require C >> syntax) depend on the 'no-c++' module? We can open a poll on it. > > I don't understand the rationale for the no-c++ module, let alone making > any other modules depend on it. > > What is the issue with compiling C code with a C compiler and C++ code > with a C++ compiler? That seems to be me the proper solution. Some packages are compilable with both C (production) and C++ (extra compilation time type checking and run-time verification for debugging). when such a package uses code from gnulib, it wants to compile it with the compiler ($(CC)) it uses for the rest of the package, i.e., when compiling with CC=C, it compiles the imported gnulib code with C, ahen compiling with CC=C++, it compiles the imported gnulib code with with C++. when the imported gnulib code cannot be compiled with C++ (e.g., regexp), this causes problems. > Compiling C code with a C++ compiler seems like a good recipe for > problems, and I don't think it is something gnulib should force on users > unless there is a compelling use-case. the "forcing" goes the other way around. the user of gnulib forces C++ on gnulib code, and gnulib should use no-cxx (when necessary) to cope with it. -- Sam Steingold <http://sds.podval.org>
Re: no-c++
> * Bruno Haible [2009-08-08 11:47:01 +0200]: > > Sam Steingold wrote: >> modules which cannot be compiled with c++ (regex, gettimeofday) should depend >> on no-c++ > > This cannot be implemented as you wish. The ability to compile in C mode when > CC="g++" is done through a variable NO_CXX that has to be added to the > compiler > flags. But modifying compiler flags can, in a Makefile.am, only be done on a > per-program or per-library basis, not on a per-compilation-unit basis. > > So, you have to add $(NO_CXX) to the compilation flags for your library > yourself. fine. my suggestion eliminates two expensive steps: now: import the non-C++ module regenerate all autoconf files try to compile with c++, fail import no-c++ regenerate all autoconf files add NO_CXX to gnulib CFLAGS with my suggestion: import the non-C++ module; no-c++ is automatically included regenerate all autoconf files try to compile with c++, fail add NO_CXX to gnulib CFLAGS import & autoconf regeneration are expensive in both that they take time (and may require Internet access) and require digging around - it is not obvious that no-c++ module exists and does what you want. -- Sam Steingold (http://sds.podval.org/) on Ubuntu 9.04 (jaunty) http://mideasttruth.com http://memri.org http://www.memritv.org http://openvotingconsortium.org http://dhimmi.com http://thereligionofpeace.com The software said it requires Windows 3.1 or better, so I installed Linux.
Re: PACKAGE, VERSION, & PACKAGE_VERSION
On Fri, Aug 7, 2009 at 4:33 PM, Bruno Haible wrote: >> why do I get a warning for them (but not for PACKAGE_*)? > Because redefinitions of C macros warrant maintainer attention. yes, but why am I not getting the warnings about PACKAGE_*? -- Sam Steingold <http://sds.podval.org>
uname: build problem on win32
make[4]: Entering directory `/cygdrive/c/sds/dev/current/build-mingw-1/syscalls/ gllib' gcc -mno-cygwin -DHAVE_CONFIG_H -I. -I/cygdrive/c/sds/dev/current/modules/syscal ls/gllib -I.. -I/cygdrive/c/sds/top/include -Ic:/sds/dev/current/build-mingw-1 /gllib -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -W missing-declarations -Wno-sign-compare -Wno-format-nonliteral -falign-functions= 4 -D_WIN32 -g -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DUN ICODE -DNO_TERMCAP_NCURSES -DDYNAMIC_FFI -DDYNAMIC_MODULES -DNO_GETTEXT -I. -fPI C -Ic:/sds/dev/current/build-mingw-1/linkkit/.. -MT close-hook.o -MD -MP -MF .de ps/close-hook.Tpo -c -o close-hook.o /cygdrive/c/sds/dev/current/modules/syscall s/gllib/close-hook.c /cygdrive/c/sds/dev/current/modules/syscalls/gllib/close-hook.c:1: warning: -fPI C ignored for target (all code is position independent) mv -f .deps/close-hook.Tpo .deps/close-hook.Po gcc -mno-cygwin -DHAVE_CONFIG_H -I. -I/cygdrive/c/sds/dev/current/modules/syscal ls/gllib -I.. -I/cygdrive/c/sds/top/include -Ic:/sds/dev/current/build-mingw-1 /gllib -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -W missing-declarations -Wno-sign-compare -Wno-format-nonliteral -falign-functions= 4 -D_WIN32 -g -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DUN ICODE -DNO_TERMCAP_NCURSES -DDYNAMIC_FFI -DDYNAMIC_MODULES -DNO_GETTEXT -I. -fPI C -Ic:/sds/dev/current/build-mingw-1/linkkit/.. -MT sockets.o -MD -MP -MF .deps/ sockets.Tpo -c -o sockets.o /cygdrive/c/sds/dev/current/modules/syscalls/gllib/s ockets.c /cygdrive/c/sds/dev/current/modules/syscalls/gllib/sockets.c:1: warning: -fPIC i gnored for target (all code is position independent) mv -f .deps/sockets.Tpo .deps/sockets.Po gcc -mno-cygwin -DHAVE_CONFIG_H -I. -I/cygdrive/c/sds/dev/current/modules/syscal ls/gllib -I.. -I/cygdrive/c/sds/top/include -Ic:/sds/dev/current/build-mingw-1 /gllib -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -W missing-declarations -Wno-sign-compare -Wno-format-nonliteral -falign-functions= 4 -D_WIN32 -g -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DUN ICODE -DNO_TERMCAP_NCURSES -DDYNAMIC_FFI -DDYNAMIC_MODULES -DNO_GETTEXT -I. -fPI C -Ic:/sds/dev/current/build-mingw-1/linkkit/.. -MT gethostname.o -MD -MP -MF .d eps/gethostname.Tpo -c -o gethostname.o /cygdrive/c/sds/dev/current/modules/sysc alls/gllib/gethostname.c /cygdrive/c/sds/dev/current/modules/syscalls/gllib/gethostname.c:1: warning: -fP IC ignored for target (all code is position independent) In file included from /cygdrive/c/sds/dev/current/modules/syscalls/gllib/gethost name.c:83: /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h: In function `set_w insock_errno': /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h:34: warning: implic it declaration of function `WSAGetLastError' /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h:35: warning: implic it declaration of function `WSASetLastError' /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h:40: error: `WSA_INV ALID_HANDLE' undeclared (first use in this function) /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h:40: error: (Each un declared identifier is reported only once /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h:40: error: for each function it appears in.) /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h:43: error: `WSA_NOT _ENOUGH_MEMORY' undeclared (first use in this function) /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h:46: error: `WSA_INV ALID_PARAMETER' undeclared (first use in this function) /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h:49: error: `WSAEWOU LDBLOCK' undeclared (first use in this function) /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h:52: error: `WSAENAM ETOOLONG' undeclared (first use in this function) /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h:55: error: `WSAENOT EMPTY' undeclared (first use in this function) In file included from ./sys/socket.h:111, from /cygdrive/c/sds/dev/current/modules/syscalls/gllib/sockets .h:37, from /cygdrive/c/sds/dev/current/modules/syscalls/gllib/gethost name.c:85: /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../include/w32api/winsock2.h: At top level: /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../include/w32api/winsock2.h:593: er ror: conflicting types for 'WSASetLastError' /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h:35: error: previous implicit declaration of 'WSASetLastError' was here /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../include/w32api/winsock2.h:594: er ror: conflicting types for 'WSAGetLastError' /cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h:34: error: previous implicit declaration of 'WSAGetLastError' was here /cygdrive/c/sds/dev/current/modules/syscalls/gllib/gethostname.c:91: warning: no previous declaration for 'rpl_gethos
PACKAGE, VERSION, & PACKAGE_VERSION
Hi, I have the following setup: main package (with its own configure.in[1]) which imports stuff from gnulib ~20 sub-packages (each with its own configure.in[2]) of which 3 import stuff from gnulib. sub-packages include the main package's config.h before their own config.h. Every single config.h has PACKAGE_VERSION (and a few other PACKAGE_*) defines and this has never been a problem - I have never seen any warnings about, say, PACKAGE_VERSION being redefined (even though each sub-package does defined them _differently_ from the main package, just compare [1] and [2]). However, now I have a problem with the 3 sub-packages which use gnulib. their config.h defines PACKAGE (same as PACKAGE_NAME) and VERSION (same as PACKAGE_VERSION) and I now do get the warning: In file included from wildcard.c:4: config.h:72:1: warning: "PACKAGE" redefined In file included from wildcard.c:1: /home/ssteingold/src/clisp/current/build-g-dynmod/linkkit/clisp.h:164:1: warning: this is the location of the previous definition In file included from wildcard.c:4: config.h:93:1: warning: "VERSION" redefined In file included from wildcard.c:1: /home/ssteingold/src/clisp/current/build-g-dynmod/linkkit/clisp.h:194:1: warning: this is the location of the previous definition (clisp.h is derived from the main package config.h). So, my question is: where do PACKAGE and VERSION come from? why do I get a warning for them (but not for PACKAGE_*)? how do I avoid these warnings? thanks Sam [1]http://clisp.cvs.sourceforge.net/viewvc/*checkout*/clisp/clisp/src/configure.in [2]http://clisp.cvs.sourceforge.net/viewvc/*checkout*/clisp/clisp/modules/wildcard/configure.in
Re: new module 'uname'
Bruno Haible wrote: configure.ac: gl_FUNC_UNAME gl_SYS_UTSNAME_MODULE_INDICATOR([uname]) just curious, since I will be using uname for clisp/syscalls: what is gl_SYS_UTSNAME_MODULE_INDICATOR? why does it take an argument? thanks. Sam.
no-c++
modules which cannot be compiled with c++ (regex, gettimeofday) should depend on no-c++
Re: gnulib-tool --avoid problems
On Tue, Aug 4, 2009 at 2:24 AM, Bruno Haible wrote: > Sam Steingold wrote: >> configure.in: no proper invocation of AM_INIT_AUTOMAKE was found. >> configure.in: You should verify that configure.in invokes AM_INIT_AUTOMAKE, >> configure.in: that aclocal.m4 is present in the top-level directory, >> configure.in: and that aclocal.m4 was recently regenerated (using aclocal). > > This message is clear: Try adding AM_INIT_AUTOMAKE to > modules/regexp/configure.in. OH COME ON! if I did not have it there, I could not have generated modules/regexp/gllib/Makefile.in! of COURSE it's there! the problem turned out to be that I do not have aclocal.m4 in modules/regexp/ (it's in src/) and automake does not allow me to specify the path to it (if an automake maintainer is reading this, please consider this a feature request), so, to create modules/regexp/gllib/Makefile.in I have to create a symlink. to src/aclocal.m4. make in modules/regexp/gllib/ wants to regenerate its Makefile, so it checks Makefile.in for being up-to-date wrt Makefile.am and aclocal.m4, does not find the latter, and invokes automake which dies with the above message. thus the workaround is to invoke make in gllib as $(MAKE) ACLOCAL_M4="Makefile.am" >> is it an invitation to send you the tarball? > > If there is no other way to find the cause of the earlier problem with > , yes. 1. cd clisp 2. cvs up 3. rm -rf src/gl* modules/regexp/gl* modules/wildcard/gl* 4. edit Makefile.devel and remove 'string' from GNULIB_MODULES 5. make -f Makefile.devel gnulib-imported src/gllib/Makefile.in 6. observe broken src/gllib/Makefile.in -- Sam Steingold <http://sds.podval.org>
Re: gnulib-tool --avoid problems
On Mon, Aug 3, 2009 at 4:11 PM, Bruno Haible wrote: > Sam Steingold wrote: >> so I added 'string' to GNULIB_MODULES and now... >> [all fine] >> - why do I have to do that? > > I have no idea why you had a half, not working 'string' module earlier. > Without a tarball with all files included, I can't tell. is it an invitation to send you the tarball? meanwhile, regexp/gllib/libgnu.a fails to build because make tries to invoke automake: make[1]: Entering directory `/home/sds/src/clisp/current/build-O/regexp' rm -f libgnu_rx.a mkdir -p gllib test -f gllib/Makefile || sh config.status gllib/Makefile depfiles cd gllib; make; ln libgnu.a ../libgnu_rx.a make[2]: Entering directory `/home/sds/src/clisp/current/build-O/regexp/gllib' cd .. && make am--refresh make[3]: Entering directory `/home/sds/src/clisp/current/build-O/regexp' make[3]: Nothing to be done for `am--refresh'. make[3]: Leaving directory `/home/sds/src/clisp/current/build-O/regexp' cd /home/sds/src/clisp/current/modules/regexp && /bin/sh /home/sds/src/clisp/current/src/build-aux/missing --run automake-1.10 --gnits gllib/Makefile configure.in: no proper invocation of AM_INIT_AUTOMAKE was found. configure.in: You should verify that configure.in invokes AM_INIT_AUTOMAKE, configure.in: that aclocal.m4 is present in the top-level directory, configure.in: and that aclocal.m4 was recently regenerated (using aclocal). gllib/Makefile.am:18: library used but `RANLIB' is undefined gllib/Makefile.am:18: The usual way to define `RANLIB' is to add `AC_PROG_RANLIB' gllib/Makefile.am:18: to `configure.in' and run `autoconf' again. gllib/Makefile.am: required file `./depcomp' not found gllib/Makefile.am: `automake --add-missing' can install `depcomp' /usr/share/automake-1.10/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL /usr/share/automake-1.10/am/depend2.am: The usual way to define `am__fastdepCC' is to add `AC_PROG_CC' /usr/share/automake-1.10/am/depend2.am: to `configure.in' and run `aclocal' and `autoconf' again. /usr/share/automake-1.10/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.10/am/depend2.am: The usual way to define `AMDEP' is to add one of the compiler tests /usr/share/automake-1.10/am/depend2.am: AC_PROG_CC, AC_PROG_CXX, AC_PROG_CXX, AC_PROG_OBJC, /usr/share/automake-1.10/am/depend2.am: AM_PROG_AS, AM_PROG_GCJ, AM_PROG_UPC /usr/share/automake-1.10/am/depend2.am: to `configure.in' and run `aclocal' and `autoconf' again. make[2]: *** [/home/sds/src/clisp/current/modules/regexp/gllib/Makefile.in] Error 1 make[2]: Leaving directory `/home/sds/src/clisp/current/build-O/regexp/gllib' ln: accessing `libgnu.a': No such file or directory make[1]: *** [libgnu_rx.a] Error 1 make[1]: Leaving directory `/home/sds/src/clisp/current/build-O/regexp' make: *** [regexp] Error 2 -- Sam Steingold <http://sds.podval.org>
Re: gnulib-tool --avoid problems
Hi Bruno, On Sun, Aug 2, 2009 at 5:01 AM, Bruno Haible wrote: > Sam Steingold wrote: >> ./string.h:54:5: error: #if with no expression > > The 'string' module occurs as dependency of the 'memchr' module or 'mbsrtowcs' > modules. so I added 'string' to GNULIB_MODULES and now... > Somehow a bunch of AC_SUBSTed variables (such as NEXT_STRING_H) > are not correctly substituted. You should verify that > 1) gllib/Makefile.in contains the line > NEXT_STRING_H = @NEXT_STRING_H@ yes > 2) config.status contains the line > S["NEXT_STRING_H"]="" yes > 3) configure contains the lines > NEXT_STRING_H > and > NEXT_STRING_H=$gl_cv_next_string_h yes still - why do I have to do that? - m4 duplication is yuky; shares glm4 would be nice. thanks! -- Sam Steingold <http://sds.podval.org>
Re: gnulib-tool --avoid problems
Hi Bruno,
On Sun, Aug 2, 2009 at 5:01 AM, Bruno Haible wrote:
> Sam Steingold wrote:
>> alas, there is still some duplication between
>> modules/regexp/glm4 and src/glm4, specifically:
>> codeset.m4
>> locale-fr.m4
>> locale-ja.m4
>> locale-zh.m4
>> mbrtowc.m4
>> mbstate_t.m4
>> unistd_h.m4
>
> Duplication between .m4 files is harmless.
but _extremely_ unaesthetic.
there should be a way around.
the best way, IMO, is to enable a _shared_ glm4 between src, regexp
and wildcard.
>> and between modules/regexp/gllib and src/gllib, specifically:
>> unistd.in.h
>
> You should be able to fix this by adding 'unistd' to your GNULIB_CORE
> variable.
thanks, it worked.
>> also, build-dir/gllib no longer builds:
>>
>> $ make gllib
>> mkdir -p gllib
>> if test ! -f gllib/Makefile; then sh config.status gllib/Makefile depfiles;
>> fi
>> config.status: creating gllib/Makefile
>> config.status: executing depfiles commands
>> cd gllib && make CFLAGS="-W -Wswitch -Wcomment -Wpointer-arith -Wimplicit
>> -Wreturn-type -Wmissing-declarations -Wno-sign-compare
>> -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4
>> -DUNICODE -DDYNAMIC_FFI -I. "
>> make[1]: Entering directory `/home/sds/src/clisp/current/build-O/gllib'
>> ...
>> rm -f string.h-t string.h
>> { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */' && \
>> sed -e 's|@''INCLUDE_NEXT''@|include_next|g' \
>> -e 's|@''PRAGMA_SYSTEM_HEADER''@|#pragma GCC system_header|g' \
>> -e 's|@''NEXT_STRING_H''@||g' \
>> -e 's|@''GNULIB_MBSLEN''@||g' \
>> -e 's|@''GNULIB_MBSNLEN''@||g' \
>> ...
>> ./string.h:27:15: error: #include_next expects "FILENAME" or
>> ./string.h:54:5: error: #if with no expression
>
> The 'string' module occurs as dependency of the 'memchr' module or 'mbsrtowcs'
> modules. Somehow a bunch of AC_SUBSTed variables (such as NEXT_STRING_H)
> are not correctly substituted. You should verify that
> 1) gllib/Makefile.in contains the line
> NEXT_STRING_H = @NEXT_STRING_H@
nope:
$ grep NEXT_STRING_H src/gllib/Makefile.in
-e 's|@''NEXT_STRING_H''@|$(NEXT_STRING_H)|g' \
> 2) config.status contains the line
> S["NEXT_STRING_H"]=""
nope, does not contain NEXT_STRING_H at all.
> 3) configure contains the lines
> NEXT_STRING_H
> and
> NEXT_STRING_H=$gl_cv_next_string_h
nope, no NEXT_STRING_H either.
> If 1) is not fulfilled, you should look at the automake invocation that
> you issued after the autoconf invocation after the gnulib-tool invocations.
$ make -f Makefile.devel src/gllib/Makefile.in
cd src/gllib && cd .. && automake gllib/Makefile
$
no diagnostics.
> If 3) is not fulfilled, it's time to look at your autoconf and m4 versions.
autoconf (GNU Autoconf) 2.63
m4 (GNU M4) 1.4.11
> If 2) is not fulfilled but 3) is, what are your versions of sh (bash?) and
> awk (gawk)?
GNU Awk 3.1.6
GNU bash, version 3.2.48(1)-release
--
Sam Steingold <http://sds.podval.org>
gnulib-tool --avoid problems
tion of GL_LINK_WARNING/r
../../src/src/build-aux/link-warning.h' \
< ../../src/gllib/string.in.h; \
} > string.h-t
mv string.h-t string.h
rm -f unistd.h-t unistd.h
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
sed -e 's|@''HAVE_UNISTD_H''@|1|g' \
-e 's|@''INCLUDE_NEXT''@|include_next|g' \
-e 's|@''PRAGMA_SYSTEM_HEADER''@|#pragma GCC system_header|g' \
-e 's|@''NEXT_UNISTD_H''@||g' \
-e 's|@''GNULIB_CHOWN''@|0|g' \
-e 's|@''GNULIB_CLOSE''@|0|g' \
-e 's|@''GNULIB_DUP2''@|0|g' \
-e 's|@''GNULIB_ENVIRON''@|0|g' \
-e 's|@''GNULIB_EUIDACCESS''@|0|g' \
-e 's|@''GNULIB_FCHDIR''@|0|g' \
-e 's|@''GNULIB_FSYNC''@|0|g' \
-e 's|@''GNULIB_FTRUNCATE''@|0|g' \
-e 's|@''GNULIB_GETCWD''@|0|g' \
-e 's|@''GNULIB_GETDOMAINNAME''@|0|g' \
-e 's|@''GNULIB_GETDTABLESIZE''@|0|g' \
-e 's|@''GNULIB_GETHOSTNAME''@|0|g' \
-e 's|@''GNULIB_GETLOGIN_R''@|0|g' \
-e 's|@''GNULIB_GETPAGESIZE''@|1|g' \
-e 's|@''GNULIB_GETUSERSHELL''@|0|g' \
-e 's|@''GNULIB_LCHOWN''@|0|g' \
-e 's|@''GNULIB_LINK''@|0|g' \
-e 's|@''GNULIB_LSEEK''@|0|g' \
-e 's|@''GNULIB_READLINK''@|0|g' \
-e 's|@''GNULIB_SLEEP''@|0|g' \
-e 's|@''GNULIB_UNISTD_H_SIGPIPE''@|0|g' \
-e 's|@''GNULIB_WRITE''@|0|g' \
-e 's|@''HAVE_DUP2''@|1|g' \
-e 's|@''HAVE_EUIDACCESS''@|1|g' \
-e 's|@''HAVE_FSYNC''@|1|g' \
-e 's|@''HAVE_FTRUNCATE''@|1|g' \
-e 's|@''HAVE_GETDOMAINNAME''@|1|g' \
-e 's|@''HAVE_GETDTABLESIZE''@|1|g' \
-e 's|@''HAVE_GETHOSTNAME''@|1|g' \
-e 's|@''HAVE_GETPAGESIZE''@|1|g' \
-e 's|@''HAVE_GETUSERSHELL''@|1|g' \
-e 's|@''HAVE_LINK''@|1|g' \
-e 's|@''HAVE_READLINK''@|1|g' \
-e 's|@''HAVE_SLEEP''@|1|g' \
-e 's|@''HAVE_DECL_ENVIRON''@|1|g' \
-e 's|@''HAVE_DECL_GETLOGIN_R''@|1|g' \
-e 's|@''HAVE_OS_H''@|0|g' \
-e 's|@''HAVE_SYS_PARAM_H''@|0|g' \
-e 's|@''REPLACE_CHOWN''@|0|g' \
-e 's|@''REPLACE_CLOSE''@|0|g' \
-e 's|@''REPLACE_DUP2''@|0|g' \
-e 's|@''REPLACE_FCHDIR''@|0|g' \
-e 's|@''REPLACE_GETCWD''@|0|g' \
-e 's|@''REPLACE_GETPAGESIZE''@|0|g' \
-e 's|@''REPLACE_LCHOWN''@|0|g' \
-e 's|@''REPLACE_LSEEK''@|0|g' \
-e 's|@''REPLACE_WRITE''@|0|g' \
-e 's|@''UNISTD_H_HAVE_WINSOCK2_H''@|0|g' \
-e '/definition of GL_LINK_WARNING/r
../../src/src/build-aux/link-warning.h' \
< ../../src/gllib/unistd.in.h; \
} > unistd.h-t
mv unistd.h-t unistd.h
make all-recursive
make[2]: Entering directory `/home/sds/src/clisp/current/build-O/gllib'
make[3]: Entering directory `/home/sds/src/clisp/current/build-O/gllib'
depbase=`echo localcharset.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -DHAVE_CONFIG_H -I. -I../../src/gllib -I.. -I../intl -W -Wswitch
-Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations
-Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations
-falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. -MT localcharset.o -MD -MP -MF
$depbase.Tpo -c -o localcharset.o ../../src/gllib/localcharset.c &&\
mv -f $depbase.Tpo $depbase.Po
In file included from ../../src/gllib/localcharset.c:28:
./string.h:27:15: error: #include_next expects "FILENAME" or
./string.h:54:5: error: #if with no expression
./string.h:69:5: error: #if with no expression
./string.h:89:5: error: #if with no expression
./string.h:103:5: error: #if with no expression
./string.h:119:5: error: #if with no expression
./string.h:133:5: error: #if with no expression
./string.h:147:5: error: #if with no expression
./string.h:173:5: error: #if with no expression
./string.h:187:5: error: #if with no expression
./string.h:204:5: error: #if with no expression
./string.h:223:5: error: #if with no expression
./string.h:250:5: error: #if with no expression
./string.h:313:5: error: #if with no expression
./string.h:333:5: error: #if with no expression
./string.h:356:5: error: #if with no expression
./string.h:400:5: error: #if with no expression
./string.h:425:5: error: #if with no expression
./string.h:431:5: error: #if with no expression
./string.h:437:5: error: #if with no expression
./string.h:446:5: error: #if with no expression
./string.h:455:5: error: #if with no expression
./string.h:463:5: error: #if with no expression
./string.h:473:5: error: #if with no expression
./string.h:486:5: error: #if with no expression
./string.h:499:5: error: #if with no expression
./string.h:508:5: error: #if with no expression
./string.h:517:5: error: #if with no expression
./string.h:526:5: error: #if with no expression
./string.h:535:5: error: #if with no expression
./string.h:553:5: error: #if with no expression
./string.h:574:5: error: #if with no expression
./string.h:588:5: error: #if with no expression
./string.h:603:5: error: #if with no expression
../../src/gllib/localcharset.c: In function 'get_charset_aliases':
../../src/gllib/localcharset.c:133: warning: implicit declaration of function
'strlen'
../../src/gllib/localcharset.c:133: warning: incompatible implicit declaration
of built-in function 'strlen'
../../src/gllib/localcharset.c:139: warning: implicit declaration of function
'memcpy'
../../src/gllib/localcharset.c:139: warning: incompatible implicit declaration
of built-in function 'memcpy'
../../src/gllib/localcharset.c:181: warning: incompatible implicit declaration
of built-in function 'strlen'
../../src/gllib/localcharset.c:202: warning: implicit declaration of function
'strcpy'
../../src/gllib/localcharset.c:202: warning: incompatible implicit declaration
of built-in function 'strcpy'
../../src/gllib/localcharset.c: In function 'locale_charset':
../../src/gllib/localcharset.c:484: warning: incompatible implicit declaration
of built-in function 'strlen'
../../src/gllib/localcharset.c:485: warning: implicit declaration of function
'strcmp'
make[3]: *** [localcharset.o] Error 1
make[3]: Leaving directory `/home/sds/src/clisp/current/build-O/gllib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/sds/src/clisp/current/build-O/gllib'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/sds/src/clisp/current/build-O/gllib'
make: *** [gllib] Error 2
any insight?
--
Sam Steingold (http://sds.podval.org/) on Ubuntu 9.04 (jaunty)
http://iris.org.il http://palestinefacts.org http://mideasttruth.com
http://www.memritv.org http://honestreporting.com http://thereligionofpeace.com
Live free or die.
mbrtowc.m4 bug in c++
Hi, when a CC=g++, tests in mbrtowc.m4 fail with error: 'mbtowc' was not declared in this scope since 'mbtowc' is declared in stdlib.h, I think this patch is in order: 2009-06-15 Sam Steingold * mbrtowc.m4 (gl_MBRTOWC_SANITYCHECK): include for the mbtowc declaration --- mbrtowc.m4.~1.2.~ 2009-06-15 14:19:48.0 -0400 +++ mbrtowc.m4 2009-06-25 15:50:44.002471000 -0400 @@ -155,6 +155,7 @@ changequote(,)dnl changequote([,])dnl if test $LOCALE_ZH_CN != none; then AC_TRY_RUN([ +#include #include #include #include
Re: gl_LIBSIGSEGV is broken
On Wed, Jun 24, 2009 at 6:18 AM, Bruno Haible wrote: > Sam Steingold wrote: >> if I remove the explicit call to gt_LC_MESSAGES >> (which is called by AM_INTL_SUBDIR >> which is called by AM_GNU_GETTEXT which we call explicitly) >> then config.h.in no longer contains >> #undef HAVE_LC_MESSAGES >> >> why? > > This is indeed unexpected. I believe it must be related to the way > 'autoheader' > is invoked within clisp. what's wrong with the way clisp calls autoheader?! AUTOHEADER = autoheader $(CONFIG_H_IN) : %/config.h.in : %/configure.in $(AUTOCONF_FILES) cd $* && $(AUTOHEADER) --include=$(CURDIR)/src -- Sam Steingold <http://sds.podval.org>
Re: gl_LIBSIGSEGV is broken
On Mon, Jun 22, 2009 at 4:31 AM, Bruno Haible wrote:
>
> You can safely remove those gl_* macro invocations from configure.{ac,in}
> for which you have explicitly requested the corresponding gnulib module -
> because then it is guaranteed that gl_INIT will invoke that macro.
if I remove the explicit call to gt_LC_MESSAGES
(which is called by AM_INTL_SUBDIR
which is called by AM_GNU_GETTEXT which we call explicitly)
then config.h.in no longer contains
#undef HAVE_LC_MESSAGES
why?
also, the comment for
#undef HAVE_LIBSIGSEGV
now reads "Define if you have the lib[]sigsegv library." which looks bizarre.
--
Sam Steingold <http://sds.podval.org>
Re: gl_LIBSIGSEGV is broken
On Thu, Jun 18, 2009 at 5:31 AM, Bruno Haible wrote: > Sam Steingold wrote: >> >> after: >> >> $ grep -i sigsegv config.status >> >> S["LIBSIGSEGV_PREFIX"]="" >> >> S["LTLIBSIGSEGV"]="" >> >> S["LIBSIGSEGV"]="" >> >> S["HAVE_LIBSIGSEGV"]="yes" >> >> D["HAVE_LIBSIGSEGV"]=" 1" >> >> D["HAVE_LIBSIGSEGV"]=" 1" >> >> >> ... >> > $ ls -l /usr/include/sigsegv* /usr/lib*/libsigsegv* >> >> >> 8 -rw-r--r-- 1 root root 5802 Sep 17 2008 /usr/include/sigsegv-x86_64.h >> 4 -rw-r--r-- 1 root root 733 Aug 15 2008 /usr/include/sigsegv.h >> 0 lrwxrwxrwx 1 root root 19 Jun 15 17:35 /usr/lib64/libsigsegv.so >> -> libsigsegv.so.0.0.0* >> 0 lrwxrwxrwx 1 root root 19 Jun 15 17:34 /usr/lib64/libsigsegv.so.0 >> -> libsigsegv.so.0.0.0* >> 12 -rwxr-xr-x 1 root root 9440 Sep 17 2008 /usr/lib64/libsigsegv.so.0.0.0* > > Hmm. I cannot reproduce. I am not alone. <http://thread.gmane.org/gmane.lisp.clisp.devel/20175> > I suspect it has something to do with the autoconf infrastructure of your > package. Can you provide a complete tarball of it? (The clisp cvs still has > libsigsegv.m4 serial 3.) I reverted back to serial 3 so that my users can build. try "cvs up -D 2009-06-16" -- Sam Steingold <http://sds.podval.org>
getpagesize on mingw
Hi, updating gnulib files in clisp pulled in getpagesize.m4 and getpagesize.m4, so I decided to use them instead of the traditional clisp code. my question is: where is the prototype for the replacement getpagesize()? it would make sense to include unistd.h, but it is not generated on win32. also, mingw already comes with a unistd.h (but it does not prototype getpagesize there) - which is why gnulib does not generate the replacement unistd.h. so, I guess, I must somehow tell the build process to generate build/unistd.h out of the already present gllib/unistd_h.in. so, how do I do that? actually, maybe getpagesize.m4 should do that automatically? thanks Sam.
Re: gl_LIBSIGSEGV is broken
On Mon, Jun 15, 2009 at 6:52 PM, Bruno Haible wrote: > Sam Steingold wrote: >> I just upgraded clisp to libsigsegv.m4 serial 4 > > Did you do a "make distclean; ./configure" after doing so? yes, of course. >> and now LIBSIGSEGV is not set right: >> >> config.status: >> >> before: >> $ grep -i sigsegv config.status >> S["LIBSIGSEGV"]="-lsigsegv" >> S["LTLIBSIGSEGV"]="-lsigsegv" >> D["HAVE_LIBSIGSEGV"]=" 1" >> D["HAVE_LIBSIGSEGV"]=" 1" >> >> after: >> $ grep -i sigsegv config.status >> S["LIBSIGSEGV_PREFIX"]="" >> S["LTLIBSIGSEGV"]="" >> S["LIBSIGSEGV"]="" >> S["HAVE_LIBSIGSEGV"]="yes" >> D["HAVE_LIBSIGSEGV"]=" 1" >> D["HAVE_LIBSIGSEGV"]=" 1" >> >> libsigsegv is installed system-wide (in /usr). > > Can you tell something about the kind of platform (OS, CPU, gcc target)? Linux nyc-qws-005 2.6.29.2jane3 #1 SMP Mon May 4 12:42:56 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux > Also can you please show the result of > > $ ls -l /usr/include/sigsegv* /usr/lib*/libsigsegv* 8 -rw-r--r-- 1 root root 5802 Sep 17 2008 /usr/include/sigsegv-x86_64.h 4 -rw-r--r-- 1 root root 733 Aug 15 2008 /usr/include/sigsegv.h 0 lrwxrwxrwx 1 root root 19 Jun 15 17:35 /usr/lib64/libsigsegv.so -> libsigsegv.so.0.0.0* 0 lrwxrwxrwx 1 root root 19 Jun 15 17:34 /usr/lib64/libsigsegv.so.0 -> libsigsegv.so.0.0.0* 12 -rwxr-xr-x 1 root root 9440 Sep 17 2008 /usr/lib64/libsigsegv.so.0.0.0* -- Sam Steingold <http://sds.podval.org>
gl_LIBSIGSEGV is broken
I just upgraded clisp to libsigsegv.m4 serial 4 and now LIBSIGSEGV is not set right: config.status: before: $ grep -i sigsegv config.status S["LIBSIGSEGV"]="-lsigsegv" S["LTLIBSIGSEGV"]="-lsigsegv" D["HAVE_LIBSIGSEGV"]=" 1" D["HAVE_LIBSIGSEGV"]=" 1" after: $ grep -i sigsegv config.status S["LIBSIGSEGV_PREFIX"]="" S["LTLIBSIGSEGV"]="" S["LIBSIGSEGV"]="" S["HAVE_LIBSIGSEGV"]="yes" D["HAVE_LIBSIGSEGV"]=" 1" D["HAVE_LIBSIGSEGV"]=" 1" libsigsegv is installed system-wide (in /usr).
Re: abort() traceability
Ben Pfaff wrote: Bruno Haible writes: What do the others think? Should we possibly extend stdlib.in.h so that abort() becomes a macro that produces a detailed error message, similar to what assert() does? Just changing abort() to assert(0) would improve the diagnostics significantly. Sounds good. Actually, assert(foo()) instead of if (!foo()) assert(0) wil probably produce an even better error message.
Re: dropping setuid/setgid privileges, round 2
Bruno Haible wrote: * Regarding abort() vs. "return -1" - hi Sam! -, they say: "But while reporting failure through return values is possible, we advise against it, as it might leave the identity in an inconsistent state. Thus, when an identity change fails in the middle, programmers should either abort, or really know what they’re doing." You ain't listening. I am not saying that abort() is wrong. I am saying that it must be accompanied by a meaningful message. E.g, "Gnulib.drop_privileges_permanently: failed to drop privileges". Or just "Error A23Z51DT97". Then the user can google for the message and see what has happened, instead of filing a bug, identical (in essence) to 100s of already filed bugs - one for each package which uses this gnulib feature. Sam
Re: dropping setuid/setgid privileges
On Tue, Jun 9, 2009 at 5:07 AM, Bruno Haible wrote: > Sam Steingold wrote: >> >> down with the nannies! >> let us assume that I threw in the anti-totalitarian-programming >> diatribe here. :-) > > I call it collaborative programming: I program something, and users report > bugs, until the code gets better. :-) this has nothing to do with collaboration and everything to do with forcing inappropriate behavior on the users of your code. >> you could easily make it suitable for libraries too by returning an >> exit code > > The point is not the return code. It's about the amount of things that > you have to check in order to be sure that you are not distributing a > security vulnerability. > > For the idpriv-drop module the doc says (thanks James!): > > Note: There may still be security issues if the privileged task puts > sensitive data into the process memory or opens communication channels > to restricted facilities. > > For the idpriv-droptemp module it's even worse: > > there are additionally the dangers that > - Any bug in the non-privileged part of the program may be used to > create invalid data structures that will trigger security > vulnerabilities in the privileged part of the program. > - Code execution exploits in the non-privileged part of the program may > be used to invoke the function that restores high privileges and then > execute additional arbitrary code. > > In the situation of a library you cannot foresee, not even check, the > possible interactions of the sensitive data structures and the code outside - > because by definition, the code outside is not limited to your source > repository. > > That's why these two modules make sense only in executables, and the second > one only in *small* executables which you completely overlook. blah-blah-blah. so, you are _intentionally_ making your code useless to me because you _think_ it is not appropriate for me to use it. the net result is that I will be using a worse piece of code instead of your good code, and my users will be _less_ secure as a result of your grandstanding. -- Sam Steingold <http://sds.podval.org>
Re: dropping setuid/setgid privileges
On Mon, Jun 8, 2009 at 8:19 PM, Bruno Haible wrote:
> Sam Steingold wrote:
>
>> I urge you to avoid abort in favor of returning an error code and
>> document that aborting on certain errors is the right behavior.
>
> If I did this, the risk that a bug does not get reported would be too
down with the nannies!
let us assume that I threw in the anti-totalitarian-programming
diatribe here. :-)
(I am too lazy to actually do it).
> high. For the average user, abort() is acceptable. (Note the module
> is not suitable for use in libraries.)
then it is not suitable for clisp either.
you could easily make it suitable for libraries too by returning an
exit code from the foo_low function and adding
int foo () {
if (foo_low() == NEED_ABORT) {
fprintf(stderr,"life sucks\n");
abort();
}}
or something.
--
Sam Steingold <http://sds.podval.org>
Re: dropping setuid/setgid privileges
Bruno, The generous usage of abort() in these modules makes them unusable for CLISP. While I understand your reasons for using abort() instead of returning an error code, I do not think it is right for CLISP to die without a useful message. I urge you to avoid abort in favor of returning an error code and document that aborting on certain errors is the right behavior. -- Sam Steingold <http://sds.podval.org>
Re: gnulib update broke clisp
On Thu, Jan 15, 2009 at 8:09 PM, Eric Blake wrote: > AC_REQUIRE([AC_CONFIG_AUX_DIR], [AC_CONFIG_AUX_DIR([$1])]) This did the trick. Thanks! -- Sam Steingold
Re: gnulib update broke clisp
On Thu, Jan 15, 2009 at 3:49 PM, Paolo Bonzini wrote: > Sam Steingold wrote: >> are you saying that AC_CONFIG_HEADERS calls AC_CANONICAL_BUILD?! > > No, that CL_MODULE_COMMON_CHECKS calls something that *requires* > AC_CANONICAL_BUILD. Required stuff is always expand before the > outermost call so you are saying that I cannot call AC_CONFIG_AUX_DIR($1) in CL_MODULE_COMMON_CHECKS because other things required there must run after it. why can't I do AC_REQUIRE([AC_CONFIG_AUX_DIR($1)]) ?? I get this: warning: AC_CONFIG_AUX_DIR(../../../src/build-aux) is m4_require'd but not m4_defun'd -- Sam Steingold
Re: gnulib update broke clisp
On Thu, Jan 15, 2009 at 2:51 PM, Paolo Bonzini wrote: > >> I decided to move AC_CONFIG_AUX_DIR($1) up: > > Move it reelll up. Just after AC_CONFIG_SRCDIR or if you don't > have it, after AC_INIT. My configure.in is: == configure.in AC_PREREQ(2.57) AC_INIT(i18n, 1.0, clisp-list) AC_CONFIG_SRCDIR(i18n.lisp) AC_CONFIG_HEADERS(config.h) RSE_BOLD BOLD_MSG([I18N (Common)]) CL_MODULE_COMMON_CHECKS(../../src/build-aux) == configure.in are you saying that AC_CONFIG_HEADERS calls AC_CANONICAL_BUILD?! thanks! -- Sam Steingold
gnulib update broke clisp
ompiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... (cached) o checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking how to run the C preprocessor... (cached) gcc -E configure: error: cannot run /bin/sh /config.sub make: *** [i18n] Error 1 I am lost. Any suggestions? Sam.
Re: choice of implementation language
Mike Frysinger wrote: On Wednesday 07 January 2009 09:39:06 Sam Steingold wrote: Bruno Haible wrote: If gnulib-tool was to be rewritten in another programming language than shell + sed, what would be the good choices? a popularity contest is not the way to choose a language. and why aren't you even considering lisp? clisp comes with all linux distributions. every decent CS program provides at least some lisp exposure, so it is not completely unfamiliar to most people. things like perl/python/ruby, defined by their unique implementations, enforce the "throwaway code" approach. lisp interpreters are far from common, and no one does real work in lisp. the simple fact that you use the word "interpreter" in the above sentence betrays your utter ignorance on the subject.
Re: choice of implementation language
Bruno Haible wrote: If gnulib-tool was to be rewritten in another programming language than shell + sed, what would be the good choices? a popularity contest is not the way to choose a language. and why aren't you even considering lisp? clisp comes with all linux distributions. every decent CS program provides at least some lisp exposure, so it is not completely unfamiliar to most people. things like perl/python/ruby, defined by their unique implementations, enforce the "throwaway code" approach.
how do I check that an FD is open?
How do I figure out if the fd (specifically, stdin=0) is open? apparently it is closed when the application is run by nohup. the only thing I could figure out so far is fstat: when 0 is open, st_mode is 8592, when it is closed it is 8630... PS. Sorry about asking here, this is the most knowlegeable unix forum I know... -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.10 (intrepid) http://thereligionofpeace.com http://honestreporting.com http://ffii.org http://mideasttruth.com http://palestinefacts.org There's always free cheese in a mouse trap.
gettimeofday does not link with g++
The error I get is: g++ -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wno-sign-compare -Wno-format-nonliteral -Wno-invalid-offsetof -falign-functions=4 -g -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DDEBUG_GCSAFETY -DUNICODE -DDYNAMIC_FFI -I. gllib/uniwidth/width.o gllib/uniname/uniname.o gllib/localcharset.o gllib/gettimeofday.o spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o funarg.o array.o hashtabl.o list.o package.o record.o weak.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o foreign.o unixaux.o built.o modules.o -lreadline -lncurses -ldl /home/sds/src/top/lib/libavcall.a /home/sds/src/top/lib/libcallback.a -lsigsegv -o lisp.run time.o: In function `get_real_time(internal_time_t*)': /home/sds/src/clisp/current/build-gxx-g/../src/time.d:75: undefined reference to `rpl_gettimeofday(timeval*, void*)' time.o: In function `C_sleep()': /home/sds/src/clisp/current/build-gxx-g/../src/time.d:503: undefined reference to `rpl_gettimeofday(timeval*, void*)' /home/sds/src/clisp/current/build-gxx-g/../src/time.d:529: undefined reference to `rpl_gettimeofday(timeval*, void*)' collect2: ld returned 1 exit status nm gllib/gettimeofday.o U gettimeofday T rpl_gettimeofday note that the error message lists the arglist of rpl_gettimeofday. when I remove gllib/uniwidth/width.o from the command line, I get charstrg.o: In function `char_width(chart)': /home/sds/src/clisp/current/build-gxx-g/../src/charstrg.d:324: undefined reference to `uc_width' without the arglist of uc_width. any ideas? -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.10 (intrepid) http://honestreporting.com http://israelunderattack.slide.com http://jihadwatch.org http://truepeace.org http://palestinefacts.org C combines the power of assembler with the portability of assembler.
Re: module request: execname
Bruno, 2 weeks ago I requested a module: Sam Steingold wrote: As mentioned in <http://article.gmane.org/gmane.comp.lib.gnulib.bugs/15446>, I would like to request a new module execname which would export 2 functions: char *get_executable_name (void); int find_executable (const char * program_name); you already have all the necessary code in gnulib/lib/progreloc.c (apparently lifted with changes from clisp/src/execname.c), so all you need to do is extract the module and avoid the dependency creep. There have been no reply so far. Sam.
Re: code/module request: undo setuid
Ben Pfaff wrote: You might find the following paper on the topic interesting: http://www.usenix.org/events/sec02/full_papers/chen/chen.pdf the code in this paper is a perfect candidate for a gnulib module.
Re: gnulib: cond & spinlocks
Bruno Haible wrote: Regarding clisp's xthread.d: The first thing I would do now is to ditch the conditional code for POSIXOLD_THREADS, SOLARIS_THREADS, C_THREADS. You don't need these APIs any more. And with pthreads-win32 you don't need WIN32_THREADS either. my whole point was that I want to _remove_ xthread.d and _replace_ it with some gnulib module (or combination thereof). I think that xthread.d fits the gnulib mandate perfectly, so, if no current module (combination?) provides that functionality, xthread.d should be included in gnulib. Sam.
gnulib: cond & spinlocks
Bruno, would it be possible to make gnulib cond allocate on stack? would it be possible to use fast clisp spinlocks in gnulib lock? Thanks. Vladimir Tzankov wrote: On Nov 17, 2008, at 9:28 PM, Sam Steingold wrote: I plan to create the thread2 branch after I switch to gnulib threadlib/lock/cond to get solaris and win32 "for free". Not real objections - but few concerns. The xmutex_t should be recursive (for consistency - critical section on Win32 are recursive - and gnulib uses them as well). The cond implementation in gnulib uses malloc() while the current clisp implementation uses the stack. In a long running process this may cause unexpected behavior. Also this is especially true for SPVW_PURE - where the malloc-ed areas can easily mix with the lisp heap (looks to me). I just looked on the gnulib and do not see "realy fast" spinlocks (may be I am wrong - have not looked too hard). In the current clisp spinlocks are inlined assembly instructions. Every heap allocation is guarded with a spinlock - so any overhead may cause significant decrease in performance. SAm.
dependency creep: cond
Hi, why does the cond module depend on errno stdbool time gettimeofday I expected it to be similar to threadlib and lock in that it unifies the existing system functionality under a uniform API, and it turns out that it pulls in 4(!) packages. is it possible to have a package condlib similar to threadlib which will not pull anything extra? Thanks Sam.
Re: code/module request: undo setuid
Bruno Haible wrote: Sam Steingold wrote: Please see the discussion here: https://sourceforge.net/forum/message.php?msg_id=5611456 The discussion is here: http://news.gmane.org/gmane.lisp.clisp.general/cutoff=12548 http://article.gmane.org/gmane.lisp.clisp.general/12533 Please don't recommend URLs to https://sourceforge.net/forum/ any more - I refuse to read discussions in an advertisement loaded environment. if you login to SF (which is required to reply), you do not see any ads. at least I don't (with FF/ABP/easylist). In that discussion, - Fare says that he has some Lisp-based executables that are setuid root, - You insist on having an option that, given a Lisp-based executable, allows to get into a REP loop for that executable. Taken together, it means that every setuid Lisp-based executable allows every user to take control of the machine. no, because before dumping the image I remove the suid bit. All I can do is to revert setuid for a dangerous operation. Is the REP loop above the "dangerous operation" you are talking about? yes. If so, the magic is /* This is for executables that have the setgid bit set. */ #if HAVE_SETREGID setregid (getgid (), getgid ()); #else setegid (getgid ()); #endif /* This is for executables that have the setuid bit set. */ #if HAVE_SETREUID setreuid (getuid (), getuid ()); #else seteuid (getuid ()); #endif looks simple enough. nevertheless, could you please add an "unsuid" module? thanks Sam.
Re: code/module request: undo setuid
> * Bruno Haible <[EMAIL PROTECTED]> [2008-11-11 02:24:10 +0100]: > > Sam Steingold wrote: >> Suppose one has an application which is installed setuid root. >> Suppose also the application has a feature (e.g., spawn an >> interactive user shell) which should NOT be run as root - but as an >> unprivileged user instead. I suppose this is a fairly common >> operation ... > > The general opinion, among security aware developers, already for 10 > years, is that the amount of code which is executed with setuid root > permissions should be minimal. this is all nice, but this does not answer my question. I agree that that it is not a good idea to run a large application setuid root, but this is NOT for me to decide. Please see the discussion here: https://sourceforge.net/forum/message.php?msg_id=5611456 All I can do is to revert setuid for a dangerous operation. advice? -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.04 (hardy) http://memri.org http://mideasttruth.com http://ffii.org http://palestinefacts.org http://iris.org.il http://honestreporting.com will write code that writes code that writes code for food
code/module request: undo setuid
Hi,
Suppose one has an application which is installed setuid root.
Suppose also the application has a feature (e.g., spawn an interactive user
shell) which should NOT be run as root - but as an unprivileged user instead.
I suppose this is a fairly common operation (e.g., nethack is probably
installed setgid games and I think it can spawn a shell), and it is probably
done thus:
if (0 == fork()) { /* child */
magic incantations to restore gid;
exec("/bin/bash");
} else ...
So, what are those "magic incantations"?
do they go beyond
setreuid(getuid(), getuid());
??
Yes, I can probably hunt them down myself, but I would rather have an expert
opinion.
Also, if the magic goes beyond 1-2 lines, I think it would be a good idea to
add it to gnulib.
thanks.
Sam.
module request: execname
Bruno, As mentioned in <http://article.gmane.org/gmane.comp.lib.gnulib.bugs/15446>, I would like to request a new module execname which would export 2 functions: char *get_executable_name (void); int find_executable (const char * program_name); you already have all the necessary code in gnulib/lib/progreloc.c (apparently lifted with changes from clisp/src/execname.c), so all you need to do is extract the module and avoid the dependency creep. Thanks. Sam.
Re: cannot recreate gllib
Hi Ralf, Ralf Wildenhues wrote: Reproducible with a small example, see below. Workaround: use ./config.status gllib/Makefile depfiles instead of --file=gllib/Makefile. thanks a lot for the workaround, it does solve the problem. Sam.
Re: cannot recreate gllib
Hi Ralf, > * Ralf Wildenhues <[EMAIL PROTECTED]> [2008-10-26 09:52:39 +0100]: > > * Sam Steingold wrote on Sun, Oct 26, 2008 at 04:13:39AM CET: >> the gnulib code is in the gllib subdirectory of the build directory. >> >> it all started with a very ordinary make (in the same build directory): >> > [...] >> gcc -DHAVE_CONFIG_H -I. -I../../src/gllib -I.. -I../intl >> -I/home/sds/src/top/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit >> -Wreturn-type -Wmissing-declarations -Wno-sign-compare -falign-functions=4 >> -g -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DUNICODE >> -DDYNAMIC_FFI -I. -MT localcharset.lo -MD -MP -MF .deps/localcharset.Tpo -c >> ../../src/gllib/localcharset.c -fPIC -DPIC -o .libs/localcharset.o >> In file included from ../../src/gllib/localcharset.c:29: >> ./stdlib.h:20: error: stray '@' in program >> ./stdlib.h:20: error: stray '@' in program >> In file included from /usr/include/stdlib.h:43, >> from ./stdlib.h:34, >> from ../../src/gllib/localcharset.c:29: >> /usr/include/bits/waitstatus.h:67: error: expected '=', ',', ';', 'asm' or >> '__attribute__' before 'union' >> In file included from ../../src/gllib/localcharset.c:29: >> ./stdlib.h:41:5: error: token "@" is not valid in preprocessor expressions > > Does this happen in a pristine build tree, too? no, fresh top-level configure works just fine. alas: $ rm -rf gllib/ $ make gllib mkdir -p gllib if test ! -f gllib/Makefile; then sh config.status --file=gllib/Makefile depfiles; fi config.status: creating gllib/Makefile config.status: executing depfiles commands sed: can't read 'gllib/Makefile': No such file or directory cd gllib && make CFLAGS="-W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. " make[1]: Entering directory `/home/sds/src/clisp/current/build-O/gllib' Makefile:513: .deps/alloca.Plo: No such file or directory Makefile:514: .deps/alloca.Plo: No such file or directory Makefile:515: .deps/fnmatch.Plo: No such file or directory Makefile:516: .deps/fnmatch_loop.Plo: No such file or directory Makefile:517: .deps/localcharset.Plo: No such file or directory Makefile:518: .deps/malloc.Plo: No such file or directory Makefile:519: .deps/regcomp.Plo: No such file or directory Makefile:520: .deps/regex.Plo: No such file or directory Makefile:521: .deps/regex_internal.Plo: No such file or directory Makefile:522: .deps/regexec.Plo: No such file or directory Makefile:523: uniname/.deps/uniname.Plo: No such file or directory Makefile:524: uniwidth/.deps/width.Plo: No such file or directory make[1]: *** No rule to make target `uniwidth/.deps/width.Plo'. Stop. make[1]: Leaving directory `/home/sds/src/clisp/current/build-O/gllib' make: *** [gllib] Error 2 >> the usual trick which worked before: >> "rm -rf gllib; make gllib" now fails: > >> $ ./config.status --file=gllib/Makefile depfiles >> config.status: creating gllib/Makefile >> config.status: executing depfiles commands >> sed: can't read 'gllib/Makefile': No such file or directory >> >> this is most confusing: gllib/Makefile IS present. >> >> I did remake all configure scripts. > > Interesting. Which Autoconf and Automake versions do you use? $ grep 'Generated by GNU Autoconf' configure # Generated by GNU Autoconf 2.62 for GNU CLISP 2.47+ (2008-10-24). $ grep "generated automatically by aclocal" ../src/aclocal.m4 # generated automatically by aclocal 1.10.1 -*- Autoconf -*- > Can you show output of the above config.status command line with > set -x > > added as second line in the script? > (If that's very large, then please consider gzip'ing or so.) $ ./config.status --file=gllib/Makefile depfiles > 1 2>2 config.status: creating gllib/Makefile config.status: executing depfiles commands + set -x + debug=false + ac_cs_recheck=false + ac_cs_silent=false + SHELL=/bin/sh + DUALCASE=1 + export DUALCASE + test -n + as_cr_letters=abcdefghijklmnopqrstuvwxyz + as_cr_LETTERS=ABCDEFGHIJKLMNOPQRSTUVWXYZ + as_cr_Letters=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ + as_cr_digits=0123456789 + as_cr_alnum=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 + as_nl= + export as_nl + as_echo=\\\ + as_echo=\\\
Re: cannot recreate gllib
> * Simon Josefsson <[EMAIL PROTECTED]> [2008-10-26 09:43:24 +0100]:
>
> Sam Steingold <[EMAIL PROTECTED]> writes:
>
>> rm -f stdlib.h-t stdlib.h
>> { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */' && \
>>sed -e 's/@''INCLUDE_NEXT''@/include_next/g' \
>>-e 's|@''NEXT_STDLIB_H''@||g' \
>>-e 's|@''GNULIB_MALLOC_POSIX''@|1|g' \
>>-e 's|@''GNULIB_REALLOC_POSIX''@|0|g' \
>>-e 's|@''GNULIB_CALLOC_POSIX''@|0|g' \
>>-e 's|@''GNULIB_GETSUBOPT''@|0|g' \
>>-e 's|@''GNULIB_MKDTEMP''@|0|g' \
>>-e 's|@''GNULIB_MKSTEMP''@|0|g' \
>>-e 's|@''GNULIB_PUTENV''@|0|g' \
>>-e 's|@''GNULIB_RPMATCH''@|0|g' \
>>-e 's|@''GNULIB_SETENV''@|0|g' \
>>-e 's|@''GNULIB_STRTOD''@|0|g' \
>>-e 's|@''GNULIB_UNSETENV''@|0|g' \
>>-e 's|@''HAVE_CALLOC_POSIX''@|1|g' \
>>-e 's|@''HAVE_GETSUBOPT''@|1|g' \
>>-e 's|@''HAVE_MALLOC_POSIX''@|1|g' \
>>-e 's|@''HAVE_MKDTEMP''@|1|g' \
>>-e 's|@''HAVE_REALLOC_POSIX''@|1|g' \
>>-e 's|@''HAVE_RPMATCH''@|1|g' \
>>-e 's|@''HAVE_SETENV''@|1|g' \
>>-e 's|@''HAVE_STRTOD''@|1|g' \
>>-e 's|@''HAVE_UNSETENV''@|1|g' \
>>-e 's|@''REPLACE_MKSTEMP''@|0|g' \
>>-e 's|@''REPLACE_PUTENV''@|0|g' \
>>-e 's|@''REPLACE_STRTOD''@|0|g' \
>>-e 's|@''VOID_UNSETENV''@|0|g' \
>>-e '/definition of GL_LINK_WARNING/r
>> ../../src/src/build-aux/link-warning.h' \
>>< ../../src/gllib/stdlib.in.h; \
>> } > stdlib.h-t
>> mv stdlib.h-t stdlib.h
>
> This is missing a fair bit of stuff from the current modules/stdlib
> file, are you sure you have updated the makefile when you updated
> stdlib.in.h?
yes, gnulib-tool updated gllib/Makefile.am and automake update
gllib/Makefile.in.
--
Sam Steingold (http://sds.podval.org/) on Ubuntu 8.04 (hardy)
http://thereligionofpeace.com http://camera.org http://memri.org
http://jihadwatch.org http://palestinefacts.org
My name is Deja Vu. Have we met before?
Re: dependency creep
Hi Bruno, > * Bruno Haible <[EMAIL PROTECTED]> [2008-10-26 14:36:46 +0200]: > >> I updated gnulib files in clisp and threadlib.m4 was pulled in by >> gettext 0.17. >> Are you sure this is really truly necessary? > > It is necessary for packages that use > AM_GNU_GETTEXT > but it is not necessary for packages that use > AM_GNU_GETTEXT([external]) > > In the latter case, I thought that 'aclocal' will determine that the file > threadlib.m4 is not needed, not include it from aclocal.m4, and thus > "make dist" will create a tarball without this file. No? we have AM_GNU_GETTEXT([external], [need-ngettext]) whatever that means. threadlib was pulled in. I am sure you have the clisp cvs tree somewhere - do "cvs up". You can see that I use aclocal 1.10 and autoconf 2.62. >> I thought of replacing clisp/src/execname.c (158 lines which determine >> the truename of the current executable) and discovered that to do that I, >> apparently, need the relocatable-prog-wrapper module (17 C and H files! > > Determining the truename of the current executable is not yet a supported > functionality of its own. You found some uses of this functionality in the > relocatable-prog-wrapper module, which does many more things. > > So, would you like to propose a module that determines the truename of the > current executable? This would be a new API, because neither POSIX nor > glibc have this API. yes. I think the API currently used by clisp (clisp/src/execname.c) is good enough: /* find and save the executable name from argv[0] */ int find_executable (const char * program_name); /* access the stored executable name */ char *get_executable_name (void); >> So, what is the point of gnulib again? > > The point of gnulib is to allow you to program with reference to POSIX > or the glibc documentation, using the same includes that work on glibc > platforms, and then fix a maximum of portability programs by telling > gnulib-tool to import the relevant cross-platform support. > Additionally, it provides generally useful utility functions. good - so I thought. >> Why not just distribute gnu libc with every application? > > 1) Because glibc is not ported to OSes from AIX to Windows. There was once a >port of glibc to AIX, but it became quickly unmaintained (after IBM stopped >paying for it). > 2) Because gnulib does more than glibc: It does not override the functionality >of the system that is present and works. Like two gear wheels fit together, >gnulib adapts to the shape of the system's gear wheel. the sad part is that you apparently did not notice my sarcasm. what if I said >> Why not just distribute the whole gnulib with every application? at any rate, as a gnulib user, I would like to humbly request that you pay more attention to minimization of the amount of the overridden functionality. -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.04 (hardy) http://israelunderattack.slide.com http://pmw.org.il http://mideasttruth.com http://thereligionofpeace.com http://ffii.org Linux - find out what you've been missing while you've been rebooting Windows.
cannot recreate gllib
_SYS_PARAM_H''@|0|g' \ -e 's|@''REPLACE_CHOWN''@|0|g' \ -e 's|@''REPLACE_FCHDIR''@|0|g' \ -e 's|@''REPLACE_GETCWD''@|0|g' \ -e 's|@''REPLACE_GETPAGESIZE''@|0|g' \ -e 's|@''REPLACE_LCHOWN''@|0|g' \ -e 's|@''REPLACE_LSEEK''@|0|g' \ < ../../src/gllib/unistd.in.h; \ } > unistd.h-t mv unistd.h-t unistd.h make all-am make[2]: Entering directory `/home/sds/src/clisp/current/build-64-g/gllib' make[3]: Entering directory `/home/sds/src/clisp/current/build-64-g' make[3]: Nothing to be done for `am--refresh'. make[3]: Leaving directory `/home/sds/src/clisp/current/build-64-g' make[3]: Entering directory `/home/sds/src/clisp/current/build-64-g' make[3]: Nothing to be done for `am--refresh'. make[3]: Leaving directory `/home/sds/src/clisp/current/build-64-g' depbase=`echo localcharset.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../src/gllib -I.. -I../intl -I/home/sds/src/top/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -falign-functions=4 -g -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DUNICODE -DDYNAMIC_FFI -I. -MT localcharset.lo -MD -MP -MF $depbase.Tpo -c -o localcharset.lo ../../src/gllib/localcharset.c &&\ mv -f $depbase.Tpo $depbase.Plo gcc -DHAVE_CONFIG_H -I. -I../../src/gllib -I.. -I../intl -I/home/sds/src/top/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -falign-functions=4 -g -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DUNICODE -DDYNAMIC_FFI -I. -MT localcharset.lo -MD -MP -MF .deps/localcharset.Tpo -c ../../src/gllib/localcharset.c -fPIC -DPIC -o .libs/localcharset.o In file included from ../../src/gllib/localcharset.c:29: ./stdlib.h:20: error: stray '@' in program ./stdlib.h:20: error: stray '@' in program In file included from /usr/include/stdlib.h:43, from ./stdlib.h:34, from ../../src/gllib/localcharset.c:29: /usr/include/bits/waitstatus.h:67: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'union' In file included from ../../src/gllib/localcharset.c:29: ./stdlib.h:41:5: error: token "@" is not valid in preprocessor expressions ./stdlib.h:112:5: error: token "@" is not valid in preprocessor expressions ./stdlib.h:127:5: error: token "@" is not valid in preprocessor expressions ./stdlib.h:221:5: error: token "@" is not valid in preprocessor expressions ./stdlib.h:313:5: error: token "@" is not valid in preprocessor expressions ./stdlib.h:334:5: error: token "@" is not valid in preprocessor expressions make[2]: *** [localcharset.lo] Error 1 make[2]: Leaving directory `/home/sds/src/clisp/current/build-64-g/gllib' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/sds/src/clisp/current/build-64-g/gllib' make: *** [gllib] Error 2 oops. the usual trick which worked before: "rm -rf gllib; make gllib" now fails: $ ./config.status --file=gllib/Makefile depfiles config.status: creating gllib/Makefile config.status: executing depfiles commands sed: can't read 'gllib/Makefile': No such file or directory this is most confusing: gllib/Makefile IS present. I did remake all configure scripts. -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.04 (hardy) http://palestinefacts.org http://dhimmi.com http://mideasttruth.com http://openvotingconsortium.org http://camera.org http://pmw.org.il A man paints with his brains and not with his hands.
dependency creep
I updated gnulib files in clisp and threadlib.m4 was pulled in by gettext 0.17. Are you sure this is really truly necessary? OK - this is just m4, so it does not affect the executable size - just configuration time. I thought of replacing clisp/src/execname.c (158 lines which determine the truename of the current executable) and discovered that to do that I, apparently, need the relocatable-prog-wrapper module (17 C and H files! + an unknown number of files which come from 8 dependencies). Are you sure this is really truly necessary? So, what is the point of gnulib again? Why not just distribute gnu libc with every application? -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.04 (hardy) http://memri.org http://jihadwatch.org http://iris.org.il http://dhimmi.com http://openvotingconsortium.org http://palestinefacts.org Booze is the answer. I can't remember the question.
Re: lib vs. lib64 on bi-arch systems
Hi, Bruno Haible wrote: Sam Steingold wrote: I get the following output from ./configure --with-libsigsegv-prefix=/home/sds/src/top CC='gcc -m64' build-O --with-module=rawsock on Linux ada 2.6.24-1-sparc64-smp: INCSIGSEGV= gl_save_CPPFLAGS= CPPFLAGS= checking for libsigsegv... (cached) no, consider installing GNU libsigsegv even though I do have libsigsegv installed: $ ls -R /home/sds/src/top /home/sds/src/top: total 8 4 include/ 4 lib/ /home/sds/src/top/include: total 8 8 sigsegv.h /home/sds/src/top/lib: total 48 44 libsigsegv.a 4 libsigsegv.la* On Linux bi-arch systems, such as yours, the 64-bit libraries are searched for in $prefix/lib64, not in $prefix/lib. You can either - make a symlink lib64 -> lib in that directory, or - don't use --with-libsigsegv-prefix and instead set CPPFLAGS=-I/home/sds/src/top/include LDFLAGS=-L/home/sds/src/top/lib before the configuration. And on Solaris bi-arch systems, it would be in $prefix/lib/64, not in $prefix/lib. I know this is suboptimal. But we have two conflicting conventions here: - Your system is built with the convention that 64-bit libraries go in $prefix/lib64, - Your libsigsegv installation is built with the convention that all libraries go in $prefix/lib. These are the GNU defaults. The only reasonable solution I can see would be that the GNU defaults get changed to match the convention on the particular platform. so this boils down to a bug in libsigsegv (coming from autconf): make install should install it in lib64, not lib, right?
libsigsegv.m4: --with-libsigsegv-prefix is ignored
with the clisp/src/configure file, generated from libsigsegv.m4 serial 2 and
the following patch:
===
RCS file: /cvsroot/clisp/clisp/src/configure,v
retrieving revision 1.221
diff -u -w -p -r1.221 configure
--- src/configure 12 Aug 2008 20:47:51 - 1.221
+++ src/configure 9 Sep 2008 18:53:44 -
@@ -31691,6 +31691,9 @@ fi
fi
done
+echo INCSIGSEGV=$INCSIGSEGV
+echo gl_save_CPPFLAGS=$gl_save_CPPFLAGS
+echo CPPFLAGS=$CPPFLAGS
{ $as_echo "$as_me:$LINENO: checking for libsigsegv" >&5
$as_echo_n "checking for libsigsegv... " >&6; }
===
I get the following output from
./configure --with-libsigsegv-prefix=/home/sds/src/top CC='gcc -m64' build-O
--with-module=rawsock
on Linux ada 2.6.24-1-sparc64-smp:
INCSIGSEGV=
gl_save_CPPFLAGS=
CPPFLAGS=
checking for libsigsegv... (cached) no, consider installing GNU libsigsegv
even though I do have libsigsegv installed:
$ ls -R /home/sds/src/top
/home/sds/src/top:
total 8
4 include/ 4 lib/
/home/sds/src/top/include:
total 8
8 sigsegv.h
/home/sds/src/top/lib:
total 48
44 libsigsegv.a 4 libsigsegv.la*
Sam.
Re: gethostname
Ben Pfaff wrote: Sam Steingold <[EMAIL PROTECTED]> writes: Ben Pfaff wrote: Sam Steingold <[EMAIL PROTECTED]> writes: 1. is this module ever needed on a unix system? i.e., are there any unix systems still in use that lack gethostname? 2. are there any unix systems still in use that lack uname? Among the platforms represented in Bruno Haible's collection of library symbols, only mingw and nsk-G06 lack either one (and they lack both of them). Solaris has gethostname in libnsl, BeOS has it in libnet, and other platforms have it in libc. BeoS has uname in libnet, and other platforms have it in libc. but this makes the gethostname module completely useless, doesn't it? To me, it looks like it has limited value: on mingw and nsk-G06 it provides a gethostname function that is otherwise missing. I don't think it will ever fall back on uname on the systems that we know about, though, except possibly on Solaris (because the m4 code doesn't check for gethostname in libnsl). so the logical approach would be to either drop the C code altogether or implement it for nsk-G06 (whatever that might be). note: woe32 does have gethostname, so mingw is fully covered. Probably gethostname.m4 should check for gethostname in libnsl and in libnet? sounds good.
Re: gethostname
Simon Josefsson wrote: Sam Steingold <[EMAIL PROTECTED]> writes: Simon Josefsson wrote: Sam Steingold <[EMAIL PROTECTED]> writes: 1. why aren't you testing for HAVE_SYS_UTSNAME_H instead? 2. are there really systems without uname & , given that these are in posix? http://www.opengroup.org/onlinepubs/009695399/functions/uname.html I think the right solution here should be to apply the patch below. If there are problems on any system caused by that, the solution to that problem should be to create a module for sys/utsname.h and uname. The gethostname module shouldn't depend on such modules, they need to be added manually by maintainers who want compatibility with non-POSIX systems. Thoughts? note that gethostname is just as posix as uname, http://www.opengroup.org/onlinepubs/009695399/functions/gethostname.html so the gethostname module is only needed for non-posix systems. Indeed, so I am less sure my patch is the right thing. Could you explain why the current code causes problems for you? no problems - just questions: 1. is this module ever needed on a unix system? i.e., are there any unix systems still in use that lack gethostname? 2. are there any unix systems still in use that lack uname? Ben answered those questions. Even if the code may not be optimal for some platform we aren't aware of, until we know of a real problem with it I think we could leave the code as-is. Please name the platform(s) which can benefit from this module. Ben's answer suggests that the set is empty.
Re: gethostname
Ben Pfaff wrote: Sam Steingold <[EMAIL PROTECTED]> writes: 1. is this module ever needed on a unix system? i.e., are there any unix systems still in use that lack gethostname? 2. are there any unix systems still in use that lack uname? Among the platforms represented in Bruno Haible's collection of library symbols, only mingw and nsk-G06 lack either one (and they lack both of them). Solaris has gethostname in libnsl, BeOS has it in libnet, and other platforms have it in libc. BeoS has uname in libnet, and other platforms have it in libc. but this makes the gethostname module completely useless, doesn't it?
Re: gethostname
Simon Josefsson wrote: Sam Steingold <[EMAIL PROTECTED]> writes: 1. why aren't you testing for HAVE_SYS_UTSNAME_H instead? 2. are there really systems without uname & , given that these are in posix? http://www.opengroup.org/onlinepubs/009695399/functions/uname.html I think the right solution here should be to apply the patch below. If there are problems on any system caused by that, the solution to that problem should be to create a module for sys/utsname.h and uname. The gethostname module shouldn't depend on such modules, they need to be added manually by maintainers who want compatibility with non-POSIX systems. Thoughts? note that gethostname is just as posix as uname, http://www.opengroup.org/onlinepubs/009695399/functions/gethostname.html so the gethostname module is only needed for non-posix systems. Indeed, so I am less sure my patch is the right thing. Could you explain why the current code causes problems for you? no problems - just questions: 1. is this module ever needed on a unix system? i.e., are there any unix systems still in use that lack gethostname? 2. are there any unix systems still in use that lack uname?
Re: gethostname
> * Simon Josefsson <[EMAIL PROTECTED]> [2008-08-11 23:23:24 +0200]: > > Sam Steingold <[EMAIL PROTECTED]> writes: > >> gnulib/lib/gethostname.c says: >> >> #ifdef HAVE_UNAME >> # include >> #endif >> >> 1. why aren't you testing for HAVE_SYS_UTSNAME_H instead? >> >> 2. are there really systems without uname & , given >> that these are in posix? >> http://www.opengroup.org/onlinepubs/009695399/functions/uname.html > > I think the right solution here should be to apply the patch below. > If there are problems on any system caused by that, the solution to > that problem should be to create a module for sys/utsname.h and uname. > The gethostname module shouldn't depend on such modules, they need to > be added manually by maintainers who want compatibility with non-POSIX > systems. Thoughts? note that gethostname is just as posix as uname, http://www.opengroup.org/onlinepubs/009695399/functions/gethostname.html so the gethostname module is only needed for non-posix systems. -- Sam Steingold (http://sds.podval.org/) on Fedora release 9 (Sulphur) http://israelunderattack.slide.com http://camera.org http://memri.org http://jihadwatch.org http://mideasttruth.com Are you smart enough to use Lisp?
gethostname
gnulib/lib/gethostname.c says: #ifdef HAVE_UNAME # include #endif 1. why aren't you testing for HAVE_SYS_UTSNAME_H instead? 2. are there really systems without uname & , given that these are in posix? http://www.opengroup.org/onlinepubs/009695399/functions/uname.html
Re: new module 'libffcall'
[A private ping elicited a response]
Hi Bruno
>> http://article.gmane.org/gmane.comp.lib.gnulib.bugs:14103
>
> Sorry I didn't have time to formulate a detailed response.
> In one sentence, my main objection against this patch
> is that while clisp needs only avcall + callback from libffcall,
> other packages might want to use vacall or trampoline;
> this is not reflected in the autoconf macros that you posted.
aha - so what we need is a macro
gl_FFCALL(libs)
which will take one argument - a list of sublibs to check and clisp will
do gl_FFCALL([avcall],[callback]) and others will list the libraries
they want.
right?
to do this, I need to iterate through the macro arguments in m4, not in
shell:
m4_define([avcall_func],[__builtin_avcall])
m4_define([callback_func],[__vacall_r])
m4_define([trampoline_func],[alloc_trampoline])
m4_define([vacall_func],[__vacall])
m4_define([check_ffcall_libs],[
m4_ifelse($1,[],return(?!))
AC_LIB_FROMPACKAGE($1,libffcall)
AC_LIB_LINKFLAGS($1)
AC_CHECK_HEADERS($1.h)
AC_SEARCH_LIBS($1_func)
m4_define([ffcall_test],ffcall_test [ -a "$ac_cv_header_]$1[_h" = yes
-a "$ac_cv_search_]$1_func[" != no])
check_ffcall_libs(shift(@*))])
AC_DEFINE([gl_FFCALL],[
check_ffcall_libs($*)
AC_CACHE_CHECK([whether libffcall is installed],[cl_cv_have_ffcall],
[if test ffcall_test
then cl_cv_have_ffcall=yes
else cl_cv_have_ffcall=no
fi])
if test $cl_use_ffcall = yes -a $cl_cv_have_ffcall = no; then
if [ "$ac_cv_build" = "$ac_cv_host" ]; then host_arg="";
else host_arg=" --host=$ac_cv_host";
fi
FFCALL=ffcall-1.8
AC_MSG_ERROR([despite --with-ffcall, FFCALL was not found
Either call configure without --with-ffcall or do
mkdir tools; cd tools; prefix=`pwd`/${ac_cv_host}
wget http://ftp.gnu.org/pub/gnu/ffcall/${FFCALL}.tar.gz
tar xfz ${FFCALL}.tar.gz
cd ${FFCALL}
./configure$host_arg --prefix=\${prefix} && make && make check &&
make install
cd ../..
./configure --with-libffcall-prefix=\${prefix} [$]*])
fi
fi;])])
Re: new module 'libffcall'
Sam Steingold wrote: Bruno Haible wrote: Sam Steingold wrote: OK - I am both proposing a patch AND asking a particular person (Bruno Haible). OK, but please keep bug-gnulib in CC. OK. looks like Ben's advice worked wonders, so I will try that again: I am both proposing a patch AND asking a particular person (Bruno Haible). looks like this time it did not work - a whole week passed without a reply. So, what would it take to get the module added? I wrote the patch. I asked a particular person (Bruno Haible). <http://article.gmane.org/gmane.comp.lib.gnulib.bugs/14064> What else do I need to do to get something included?! Sam.
new module 'libffcall'
Bruno Haible wrote: Sam Steingold wrote: OK - I am both proposing a patch AND asking a particular person (Bruno Haible). OK, but please keep bug-gnulib in CC. OK. looks like Ben's advice worked wonders, so I will try that again: I am both proposing a patch AND asking a particular person (Bruno Haible). the new module 'libffcall' should help the packages using libffcall detect it in a uniform way. packages using libffcall include at least gnu clisp and gnu smalltalk. 2008-07-14 Sam Steingold <[EMAIL PROTECTED]> New module libffcall. * modules/libffcall: New file. * m4/libffcall.m4: New file, from GNU clisp ffcall.m4. * MODULES.html.sh: Mention new module. --- MODULES.html.sh.~1.262.~2008-07-14 10:52:42.0 -0400 +++ MODULES.html.sh 2008-07-14 11:27:47.000364000 -0400 @@ -2963,6 +2963,7 @@ func_all_modules () func_module mktempd func_module useless-if-before-free func_module vc-list-files + func_module libffcall func_end_table element="Misc" files modules/libffcall & m4/libffcall.m4 are attached. I believe that I have the fsf copyright assignment for _all_ my contributions to fsf-owned projects. libffcall.m4 Description: application/m4 Description: Foreign function call libraries. Files: m4/libffcall.m4 Depends-on: havelib configure.ac: gl_LIBFFCALL Makefile.am: Include: #if HAVE_LIBFFCALL # include # include #endif Link: $(LTLIBAVCALL) $(LTLIBCALLBACK) when linking with libtool, $(LIBAVCALL) $(LIBCALLBACK) otherwise License: GPL Maintainer: Bruno Haible
Re: module request: longlong
> * Ben Pfaff <[EMAIL PROTECTED]> [2008-07-13 11:13:38 -0700]: > > Sam Steingold <[EMAIL PROTECTED]> writes: > >>> * Ben Pfaff <[EMAIL PROTECTED]> [2008-07-12 20:57:11 -0700]: >>> That is pretty easy, so I went ahead and wrote up a patch. >>> Please try out the following and see if it does what you want: >>> >>> commit a012b399fc9ec00d3f27ffcfd25729053791d42f >>> Author: Ben Pfaff <[EMAIL PROTECTED]> >>> Date: Sat Jul 12 20:56:44 2008 -0700 >>> >>> New module 'longlong'. >> >> looks good, but I don't see this in the cvs yet. > > That is because I wanted to know whether it did what you wanted > before I committed it. > > It is now pushed to gnulib's Git repository. Thanks! -- Sam Steingold (http://sds.podval.org/) on Fedora release 9 (Sulphur) http://ffii.org http://mideasttruth.com http://truepeace.org http://pmw.org.il http://jihadwatch.org http://palestinefacts.org Don't use force -- get a bigger hammer.
Re: module request: longlong
> * Ben Pfaff <[EMAIL PROTECTED]> [2008-07-12 20:57:11 -0700]: > > Sam Steingold <[EMAIL PROTECTED]> writes: > >> Hello? is anyone there? do you only talk to each other? > > You would probably get better results by proposing a patch or by > asking a particular person. OK - I am both proposing a patch AND asking a particular person (Bruno Haible). 2008-07-13 Sam Steingold <[EMAIL PROTECTED]> Add sigsegv module. * modules/sigsegv, m4/sigsegv.m4: New files. === --- MODULES.html.sh 13 Jul 2008 13:38:33 -0400 1.260 +++ MODULES.html.sh 13 Jul 2008 13:53:32 -0400 @@ -1744,6 +1744,7 @@ func_all_modules () func_module fatal-signal func_module raise func_module strsignal + func_module sigsegv func_end_table element="Command-line arguments" === 2 files are attached: Description: Check for presence of libsigsegv. Files: m4/sigsegv.m4 configure.ac: AC_REQUIRE([gl_SIGSEGV]) License: GPL Maintainer: Bruno Haible dnl -*- Autoconf -*- dnl Copyright (C) 2002-2008 Free Software Foundation, Inc. dnl This file is free software, distributed under the terms of the GNU dnl General Public License. As a special exception to the GNU General dnl Public License, this file may be distributed as part of a program dnl that contains a configuration script generated by Autoconf, under dnl the same distribution terms as the rest of that program. dnl From Bruno Haible, Sam Steingold. AC_PREREQ(2.61) AC_DEFUN([gl_SIGSEGV], [dnl dnl Prerequisites of AC_LIB_LINKFLAGS_BODY. AC_REQUIRE([AC_LIB_PREPARE_PREFIX]) AC_REQUIRE([AC_LIB_RPATH]) dnl Search for libsigsegv and define LIBSIGSEGV, LTLIBSIGSEGV and INCSIGSEGV dnl accordingly. AC_LIB_LINKFLAGS_BODY([sigsegv]) dnl Add $INCSIGSEGV to CPPFLAGS before performing the following checks, dnl because if the user has installed libsigsegv and not disabled its use dnl via --without-libsigsegv-prefix, he wants to use it. gl_save_CPPFLAGS="$CPPFLAGS" AC_LIB_APPENDTOVAR([CPPFLAGS], [$INCSIGSEGV]) AC_CACHE_CHECK(for libsigsegv, gl_cv_lib_sigsegv, [dnl gl_cv_lib_sigsegv="no, consider installing GNU libsigsegv" gl_save_LIBS="$LIBS" LIBS="$LIBS $LIBSIGSEGV" AC_LINK_IFELSE([AC_LANG_PROGRAM([#include ], [sigsegv_deinstall_handler();])], [gl_cv_lib_sigsegv=yes]) LIBS="$gl_save_LIBS" ]) if test "$gl_cv_lib_sigsegv" = yes; then AC_DEFINE(HAVE_SIGSEGV, 1, [Define if you have the libsigsegv library.]) AC_MSG_CHECKING([how to link with libsigsegv]) AC_MSG_RESULT([$LIBSIGSEGV]) else dnl If $LIBSIGSEGV didn't lead to a usable library, we don't need dnl $INCSIGSEGV either. CPPFLAGS="$gl_save_CPPFLAGS" LIBSIGSEGV= LTLIBSIGSEGV= fi AC_SUBST(LIBSIGSEGV) AC_SUBST(LTLIBSIGSEGV) ]) >>> * Sam Steingold <[EMAIL PROTECTED]> [2008-07-03 10:53:43 -0400]: >>> >>> longlong.m4 is available via many modules, but not alone. >>> it would be nice if a longlong module were availbale. >>> offering one single file: longlong.m4 > > That is pretty easy, so I went ahead and wrote up a patch. > Please try out the following and see if it does what you want: > > commit a012b399fc9ec00d3f27ffcfd25729053791d42f > Author: Ben Pfaff <[EMAIL PROTECTED]> > Date: Sat Jul 12 20:56:44 2008 -0700 > > New module 'longlong'. looks good, but I don't see this in the cvs yet. -- Sam Steingold (http://sds.podval.org/) on Fedora release 9 (Sulphur) http://dhimmi.com http://ffii.org http://truepeace.org http://jihadwatch.org http://camera.org http://openvotingconsortium.org Whom computers would destroy, they must first drive mad.
Re: module request: longlong
Hello? is anyone there? do you only talk to each other? > * Sam Steingold <[EMAIL PROTECTED]> [2008-07-03 10:53:43 -0400]: > > longlong.m4 is available via many modules, but not alone. > it would be nice if a longlong module were availbale. > offering one single file: longlong.m4 > > thanks. > > ps. "gnulib/gnulib-tool: line 1512: echo: write error: Broken pipe" > problem is still there -- Sam Steingold (http://sds.podval.org/) on Fedora release 9 (Sulphur) http://iris.org.il http://jihadwatch.org http://israelunderattack.slide.com http://honestreporting.com http://palestinefacts.org http://pmw.org.il An elephant is a mouse with an operating system.
new user: libffcall
please add libffcall https://savannah.gnu.org/projects/libffcall/ to the users file. thanks.
module request: longlong
longlong.m4 is available via many modules, but not alone. please create a longlong module offering one single file: longlong.m4 thanks. ps. "gnulib/gnulib-tool: line 1512: echo: write error: Broken pipe" problem is still there
Re: gnulib/gnulib-tool: line 1512: echo: write error: Broken pipe
Hi Bruno, > * Bruno Haible <[EMAIL PROTECTED]> [2008-06-30 00:09:55 +0200]: > >> gnulib/gnulib-tool --import --source-base=src/gllib \ >> --m4-base=src/glm4 --aux-dir=src/build-aux --no-changelog \ >> stdint stdbool regex fnmatch-gnu havelib gettext localcharset \ >> uniwidth/width streq uniname/uniname unitypes link-follow >> gnulib/gnulib-tool: line 1512: echo: write error: Broken pipe > > Can you please show > - line 1512 of your copy of gnulib-tool? (The newest one reads > inmodules=`echo "$handledmodules" | LC_ALL=C join -v 2 - > "$tmp"/queued-modules` > and it looks improbable that 'join' would terminate before it has consumed > all its input.) indeed, that is the line 1512 (as you know, Makefile.devel does "cvs up" before running gnulib-tool). > - Your OS version, $ uname -a Linux loiso 2.6.22.7-57.fc6 #1 SMP Fri Sep 21 20:23:24 EDT 2007 i686 athlon i386 GNU/Linux > - the shell you are using (most probably: echo $BASH_VERSION). $ echo $BASH_VERSION 3.2.33(1)-release -- Sam Steingold (http://sds.podval.org/) on Fedora release 9 (Sulphur) http://palestinefacts.org http://pmw.org.il http://truepeace.org http://thereligionofpeace.com http://memri.org http://openvotingconsortium.org Microsoft: announce yesterday, code today, think tomorrow.
gnulib/gnulib-tool: line 1512: echo: write error: Broken pipe
I just run gnulib/gnulib-tool and got this error: gnulib/gnulib-tool --import --source-base=src/gllib \ --m4-base=src/glm4 --aux-dir=src/build-aux --no-changelog \ stdint stdbool regex fnmatch-gnu havelib gettext localcharset \ uniwidth/width streq uniname/uniname unitypes link-follow gnulib/gnulib-tool: line 1512: echo: write error: Broken pipe Module list with included dependencies: alloca alloca-opt configmake extensions fnmatch fnmatch-gnu gettext gettext-h havelib include_next link-follow link-warning localcharset malloc malloc-posix regex ssize_t stdbool stdint stdlib streq uniname/base uniname/uniname unistd unitypes uniwidth/base uniwidth/width wchar wctype gnulib/gnulib-tool: line 1512: echo: write error: Broken pipe Notice from module localcharset: If your package's tests make use of the locale_charset() function directly or indirectly, you may need to define the CHARSETALIASDIR environment variable, so that "make check" works before "make install". In Makefile.am syntax: TESTS_ENVIRONMENT += @LOCALCHARSET_TESTS_ENVIRONMENT@ File list: ... -- Sam Steingold (http://sds.podval.org/) on Fedora release 9 (Sulphur) http://israelunderattack.slide.com http://dhimmi.com http://jihadwatch.org http://memri.org http://honestreporting.com http://truepeace.org cogito cogito ergo cogito sum
Re: libsigsegv questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruno Haible wrote: | 1) Putting the sigsegv.m4 macro from GNU clisp into gnulib, incorporating | it into the c-stack module. please put it into a separate module, because I do not want to pull the whole c-stack module into clisp when all I want is sigsegv.m4. same for ffcall.m4 - please move it from clisp into a separate gnulib module. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFISUD+Pp1Qsf2qnMcRAtZ/AJUWJk3dSXmmbYKPhxJQt5ueUdffAJ4qdLEy QzpA7gMR1AarM7BhgayCzQ== =gh0T -END PGP SIGNATURE-
Re: [PATCH] split AC_LIB_LINKFLAGS_BODY for multi-library packages
>From [EMAIL PROTECTED] Wed Mar 12 22:38:18 2008
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Forwarded-To: [EMAIL PROTECTED]
X-Forwarded-For: [EMAIL PROTECTED] [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Forwarded-To: [EMAIL PROTECTED]
X-X-Forwarded-For: [EMAIL PROTECTED] [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Received-SPF: neutral (google.com: 140.186.70.10 is neither permitted nor
denied by best guess record for domain of [EMAIL PROTECTED])
client-ip=140.186.70.10;
Authentication-Results: mx.google.com; spf=neutral (google.com: 140.186.70.10
is neither permitted nor denied by best guess record for domain of [EMAIL
PROTECTED]) [EMAIL PROTECTED]
X-RZG-CLASS-ID: mo07
X-RZG-AUTH: gMysVb8JT2gB+rFDu0PuvnPihAP8oFdePhw95HsIrI3FAWzVjXQh+Q==
From: Bruno Haible <[EMAIL PROTECTED]>
To: Sam Steingold <[EMAIL PROTECTED]>
Subject: Re: [PATCH] split AC_LIB_LINKFLAGS_BODY for multi-library packages
Date: Thu, 13 Mar 2008 03:38:00 +0100
User-Agent: KMail/1.5.4
Cc: bug-gnulib@gnu.org
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-detected-kernel: by monty-python.gnu.org: Solaris 10 (beta)
Bruno wrote:
>Sam Steingold wrote:
>> | *** m4/lib-link.m4.orig2008-03-12 05:46:15.0 +0100
>> | --- m4/lib-link.m4 2008-03-12 05:44:50.0 +0100
>> | ***
>> | *** 1,4
>> | ! # lib-link.m4 serial 14 (gettext-0.18)
>> please add "# -*- Autoconf -*-" here.
>We have several hundred *.m4 files. I won't add particular markers for Emacs
>to each of them. You should better find a way to customize your Emacs
>accordingly. Something like this probably (untested):
> (setq auto-mode-alist (cons '("\\.m4\\'" . autoconf-mode) auto-mode-alist))
this would make _all_ m4 files autoconf which is not right.
some files are plain m4.
Re: [PATCH] split AC_LIB_LINKFLAGS_BODY for multi-library packages
Bruno Haible wrote: AC_LIB_FROMPACKAGE(avcall, ffcall) AC_LIB_FROMPACKAGE(vacall, ffcall) you mean AC_LIB_FROMPACKAGE(avcall, libffcall) right? *** m4/lib-link.m4.orig 2008-03-12 05:46:15.0 +0100 --- m4/lib-link.m4 2008-03-12 05:44:50.0 +0100 this adds extra 8 blank lines to each configure which uses AC_LIB_LINKFLAGS. intentional?
Re: [PATCH] split AC_LIB_LINKFLAGS_BODY for multi-library packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruno Haible wrote: | Sam Steingold wrote: |> some packages (e.g., GNU libffcall) install multiple libraries, so |> AC_LIB_LINKFLAGS_BODY is insufficient for detecting them. |> this patch splits AC_LIB_LINKFLAGS_BODY into two parts: for adding a |> -with-libname-prefix command line switch and for searching for |> libraries. | | This patch is not complete: lib-link.m4 has 3 entry points | AC_LIB_LINKFLAGS, AC_LIB_HAVE_LINKFLAGS, AC_LIB_LINKFLAGS_BODY, and | your patch splits only one of the three. | | Actually I don't want to split these three macros, because the user | should | have to write a single macro call, not two. Also, I don't want to add | an extra 'package' argument to the macros, because it would complicate | the calling conventions of the macros for a rare usecase. | | Instead, I'm adding a separate macro AC_LIB_FROMPACKAGE, with which | you can declare which library comes from which package. Like this: | |AC_LIB_FROMPACKAGE(avcall, ffcall) |AC_LIB_FROMPACKAGE(vacall, ffcall) |AC_LIB_LINKFLAGS(avcall) |AC_LIB_LINKFLAGS(vacall) does this create two new options - --with-libavcall-prefix and - --with-libvacall-prefix instead of one option - --with-libffcall-prefix as in my patch? | *** m4/lib-link.m4.orig 2008-03-12 05:46:15.0 +0100 | --- m4/lib-link.m42008-03-12 05:44:50.0 +0100 | *** | *** 1,4 | ! # lib-link.m4 serial 14 (gettext-0.18) please add "# -*- Autoconf -*-" here. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH19vzPp1Qsf2qnMcRAlAjAKCTV1ANwekKFbsm5AEju5S79xqNrQCePOpc yn4vtF3GTlguDizeYaq+Fys= =7p5c -END PGP SIGNATURE-
[PATCH] split AC_LIB_LINKFLAGS_BODY for multi-library packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
some packages (e.g., GNU libffcall) install multiple libraries, so
AC_LIB_LINKFLAGS_BODY is insufficient for detecting them.
this patch splits AC_LIB_LINKFLAGS_BODY into two parts: for adding a
- -with-libname-prefix command line switch and for searching for libraries.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH1vPuPp1Qsf2qnMcRAtCPAJ9r/WeIulADigqePSIeQFKHuxmYDgCfUt/D
LRoJkt/WNm7u35bQ3SuRjSM=
=XY/d
-END PGP SIGNATURE-
Index: ChangeLog
===
RCS file: /srv/git/gnulib.git/HEAD/ChangeLog,v
retrieving revision 1.2186
diff -w -p -u ChangeLog
--- ChangeLog revision 1.2186
+++ ChangeLog working copy
@@ -1,3 +1,10 @@
+2007-11-29 Sam Steingold <[EMAIL PROTECTED]>
+
+ * m4/lib-link.m4 (AC_LIB_LINKFLAGS_BODY): split into ...
+ (AC_LIB_LINKFLAGS_ADD): adds -with-libname-prefix command line switch
+ (AC_LIB_LINKFLAGS_SEARCH): searches for libname and the libraries
+ corresponding to explicit and implicit dependencies
+
2007-11-18 Jim Meyering <[EMAIL PROTECTED]>
Pull my changes from coreutils:
Index: m4/lib-link.m4
===
RCS file: /srv/git/gnulib.git/HEAD/m4/lib-link.m4,v
retrieving revision 1.21
diff -w -p -u m4/lib-link.m4
--- m4/lib-link.m4 revision 1.21
+++ m4/lib-link.m4 working copy
@@ -1,4 +1,5 @@
# lib-link.m4 serial 13 (gettext-0.17)
+dnl -*- Autoconf -*-
dnl Copyright (C) 2001-2007 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -136,13 +137,8 @@
:, enable_rpath=yes)
])
-dnl AC_LIB_LINKFLAGS_BODY(name [, dependencies]) searches for libname and
-dnl the libraries corresponding to explicit and implicit dependencies.
-dnl Sets the LIB${NAME}, LTLIB${NAME} and INC${NAME} variables.
-dnl Also, sets the LIB${NAME}_PREFIX variable to nonempty if libname was found
-dnl in ${LIB${NAME}_PREFIX}/$acl_libdirstem.
-AC_DEFUN([AC_LIB_LINKFLAGS_BODY],
-[
+dnl AC_LIB_LINKFLAGS_ADD(name) adds -with-libname-prefix command line switch
+AC_DEFUN([AC_LIB_LINKFLAGS_ADD],[dnl
AC_REQUIRE([AC_LIB_PREPARE_MULTILIB])
define([NAME],[translit([$1],[abcdefghijklmnopqrstuvwxyz./-],
[ABCDEFGHIJKLMNOPQRSTUVWXYZ___])])
@@ -171,9 +167,18 @@
additional_libdir="$withval/$acl_libdirstem"
fi
fi
-])
+])])
+
+dnl AC_LIB_LINKFLAGS_SEARCH(name [, dependencies]) searches for libname and
+dnl the libraries corresponding to explicit and implicit dependencies.
+dnl Sets the LIB${NAME}, LTLIB${NAME} and INC${NAME} variables.
+dnl Also, sets the LIB${NAME}_PREFIX variable to nonempty if libname was found
+dnl in ${LIB${NAME}_PREFIX}/$acl_libdirstem.
+AC_DEFUN([AC_LIB_LINKFLAGS_SEARCH],[dnl
dnl Search the library and its dependencies in $additional_libdir and
dnl $LDFLAGS. Using breadth-first-seach.
+ define([NAME],[translit([$1],[abcdefghijklmnopqrstuvwxyz./-],
+ [ABCDEFGHIJKLMNOPQRSTUVWXYZ___])])
LIB[]NAME=
LTLIB[]NAME=
INC[]NAME=
@@ -611,6 +616,16 @@
fi
])
+dnl AC_LIB_LINKFLAGS_BODY(name [, dependencies]) searches for libname and
+dnl the libraries corresponding to explicit and implicit dependencies.
+dnl Sets the LIB${NAME}, LTLIB${NAME} and INC${NAME} variables.
+dnl Also, sets the LIB${NAME}_PREFIX variable to nonempty if libname was found
+dnl in ${LIB${NAME}_PREFIX}/$acl_libdirstem.
+AC_DEFUN([AC_LIB_LINKFLAGS_BODY],[
+AC_LIB_LINKFLAGS_ADD($1)dnl
+AC_LIB_LINKFLAGS_SEARCH($1,$2)dnl
+])
+
dnl AC_LIB_APPENDTOVAR(VAR, CONTENTS) appends the elements of CONTENTS to VAR,
dnl unless already present in VAR.
dnl Works only for CPPFLAGS, not for LIB* variables because that sometimes
patch for lib-link.m4:AC_LIB_LINKFLAGS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
2007-11-29 Sam Steingold <[EMAIL PROTECTED]>
* m4/lib-link.m4 (AC_LIB_LINKFLAGS_BODY): split into ...
(AC_LIB_LINKFLAGS_ADD): adds -with-libname-prefix command line switch
(AC_LIB_LINKFLAGS_SEARCH): searches for libname and the libraries
corresponding to explicit and implicit dependencies
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHTy6XPp1Qsf2qnMcRAq1hAJ4hEuoTndL55n3oPZmATkbSRdWIAwCgn7np
QL1vb4m5YWFkCcIfP9CCLWw=
=/9lq
-END PGP SIGNATURE-
Index: src/glm4/lib-link.m4
===
RCS file: /cvsroot/clisp/clisp/src/glm4/lib-link.m4,v
retrieving revision 1.2
diff -u -w -p -r1.2 lib-link.m4
--- src/glm4/lib-link.m419 Nov 2007 15:06:22 - 1.2
+++ src/glm4/lib-link.m429 Nov 2007 21:23:39 -
@@ -1,4 +1,5 @@
# lib-link.m4 serial 13 (gettext-0.17)
+dnl -*- Autoconf -*-
dnl Copyright (C) 2001-2007 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -136,13 +137,8 @@ AC_DEFUN([AC_LIB_RPATH],
:, enable_rpath=yes)
])
-dnl AC_LIB_LINKFLAGS_BODY(name [, dependencies]) searches for libname and
-dnl the libraries corresponding to explicit and implicit dependencies.
-dnl Sets the LIB${NAME}, LTLIB${NAME} and INC${NAME} variables.
-dnl Also, sets the LIB${NAME}_PREFIX variable to nonempty if libname was found
-dnl in ${LIB${NAME}_PREFIX}/$acl_libdirstem.
-AC_DEFUN([AC_LIB_LINKFLAGS_BODY],
-[
+dnl AC_LIB_LINKFLAGS_ADD(name) adds -with-libname-prefix command line switch
+AC_DEFUN([AC_LIB_LINKFLAGS_ADD],[dnl
AC_REQUIRE([AC_LIB_PREPARE_MULTILIB])
define([NAME],[translit([$1],[abcdefghijklmnopqrstuvwxyz./-],
[ABCDEFGHIJKLMNOPQRSTUVWXYZ___])])
@@ -171,7 +167,14 @@ AC_DEFUN([AC_LIB_LINKFLAGS_BODY],
additional_libdir="$withval/$acl_libdirstem"
fi
fi
-])
+])])
+
+dnl AC_LIB_LINKFLAGS_SEARCH(name [, dependencies]) searches for libname and
+dnl the libraries corresponding to explicit and implicit dependencies.
+dnl Sets the LIB${NAME}, LTLIB${NAME} and INC${NAME} variables.
+dnl Also, sets the LIB${NAME}_PREFIX variable to nonempty if libname was found
+dnl in ${LIB${NAME}_PREFIX}/$acl_libdirstem.
+AC_DEFUN([AC_LIB_LINKFLAGS_SEARCH],[dnl
dnl Search the library and its dependencies in $additional_libdir and
dnl $LDFLAGS. Using breadth-first-seach.
LIB[]NAME=
@@ -611,6 +614,16 @@ AC_DEFUN([AC_LIB_LINKFLAGS_BODY],
fi
])
+dnl AC_LIB_LINKFLAGS_BODY(name [, dependencies]) searches for libname and
+dnl the libraries corresponding to explicit and implicit dependencies.
+dnl Sets the LIB${NAME}, LTLIB${NAME} and INC${NAME} variables.
+dnl Also, sets the LIB${NAME}_PREFIX variable to nonempty if libname was found
+dnl in ${LIB${NAME}_PREFIX}/$acl_libdirstem.
+AC_DEFUN([AC_LIB_LINKFLAGS_BODY],[
+AC_LIB_LINKFLAGS_ADD($1)
+AC_LIB_LINKFLAGS_SEARCH($1,$2)
+])
+
dnl AC_LIB_APPENDTOVAR(VAR, CONTENTS) appends the elements of CONTENTS to VAR,
dnl unless already present in VAR.
dnl Works only for CPPFLAGS, not for LIB* variables because that sometimes
Re: how to use AC_LIB_LINKFLAGS with a multi-library package?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Bruno, Bruno Haible wrote: > >> How do I check for a package (ffcall) which consists of several >> libraries (avcall and callback)? >> I do not want to force the user to do pass the prefix twice: >> "--with-avcall-prefix=/usr/local --with-callback-prefix=/usr/local" >> I want "--with-ffcall-prefix=/usr/local" instead. > > I agree, what you need is a 'configure --help' that proposes > > --with-ffcall-prefix[=DIR] search for ffcall in DIR/include and DIR/lib > --without-ffcall-prefix don't search for ffcall in includedir and libdir > > I would use an AC_ARG_WITH that produces this help output and then assigns > the value of the with_ffcall_prefix variable to with_avcall_prefix and > with_callback_prefix. the problem is that AC_LIB_LINKFLAGS_BODY does all the checking work AND also calls AC_LIB_ARG_WITH. I suggest that AC_LIB_LINKFLAGS_BODY is split into the checking part and the arg-with part - then the checking part could be used with ffcall.m4 I also suggest that ffcall.m4 is added to gnulib (together with sigsegv.m4 from clisp), just like iconv.m4 is in gnulib. Sam. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHTYQxPp1Qsf2qnMcRAk3qAJ9y1NaL4GTwtp4+L7UJa1mcB5oVBgCfbYDF /qIRbkeotLNUwYAyIkgc7nw= =QQW7 -END PGP SIGNATURE-
how to use AC_LIB_LINKFLAGS with a multi-library package?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 How do I check for a package (ffcall) which consists of several libraries (avcall and callback)? I do not want to force the user to do pass the prefix twice: "--with-avcall-prefix=/usr/local --with-callback-prefix=/usr/local" I want "--with-ffcall-prefix=/usr/local" instead. my first attempt: AC_DEFUN([CL_FFCALL],[dnl AC_ARG_WITH([ffcall], AC_HELP_STRING([--with-ffcall],[use (default is YES, if present)]), [cl_cv_use_ffcall=$withval], [cl_cv_use_ffcall=no]) AC_CACHE_CHECK([whether to use ffcall],[cl_cv_use_ffcall],[cl_cv_use_ffcall=yes]) AC_REQUIRE([AC_LIB_PREPARE_PREFIX])dnl prerequisite of AC_LIB_LINKFLAGS_BODY AC_REQUIRE([AC_LIB_RPATH])dnl prerequisite of AC_LIB_LINKFLAGS_BODY - --->>>>>>>AC_LIB_LINKFLAGS_BODY([ffcall])dnl set LIBFFCALL et al if test $cl_cv_use_ffcall = yes; then AC_CACHE_CHECK([whether ffcall is present],[cl_cv_have_ffcall],[dnl cl_cv_have_ffcall=no AC_CHECK_HEADERS(avcall.h callback.h) AC_SEARCH_LIBS(__builtin_avcall,avcall) AC_SEARCH_LIBS(is_callback,callback) if test $ac_cv_header_avcall_h = yes -a $ac_cv_header_callback_h = yes \ -o $ac_cv_search___builtin_avcall = yes -o $ac_cv_search_is_callback = yes then cl_cv_have_ffcall=yes fi fi])]) is clearly wrong because there is no libffcall.so, one should be checking for libavcall.so and libcallback.so instead, so - --->>>>>>>AC_LIB_LINKFLAGS_BODY([ffcall]) should be replaced with - --->>>>>>>AC_LIB_LINKFLAGS_BODY([avcall]) - --->>>>>>>AC_LIB_LINKFLAGS_BODY([callback]) which will add options --with-avcall-prefix and --with-callback-prefix instead of --with-ffcall-prefix. For a moment I thought AC_LIB_LINKFLAGS_BODY([ffcall],[avcall callback]) would do the trick, but now I doubt that: there is really no libffcall library, so AC_LIB_LINKFLAGS_BODY will fail... Any suggestions? thanks. Sam. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHTJ6nPp1Qsf2qnMcRAuA8AKCDgcH9qj6Tdrt61Pf8CBhFoc22eQCeKLcC pk7k2T5dMeIqH/xuBtaRtWQ= =RX0E -END PGP SIGNATURE-
malloc.m4 should treat mingw like posix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 malloc.m4 says: dnl It is too dangerous to try to allocate a large amount of memory: dnl some systems go to their knees when you do that. So assume that dnl all Unix implementations of the function are POSIX compliant. mingw should be treated just like cygwin. 2007-11-15 Sam Steingold <[EMAIL PROTECTED]> * m4/malloc.m4: mingw malloc is known to be posix-compliant patch is attached. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHPMfMPp1Qsf2qnMcRAi4cAKCSp8vi4p6b1XrTfO25nkxQotDC9QCgsMn4 ytetlofvaqx8irTvM4Xyy80= =xzsK -END PGP SIGNATURE- Index: m4/malloc.m4 === RCS file: /srv/git/gnulib.git/HEAD/m4/malloc.m4,v retrieving revision 1.16 diff -w -p -u m4/malloc.m4 --- m4/malloc.m4 revision 1.16 +++ m4/malloc.m4 working copy @@ -33,7 +33,7 @@ dnl some systems go to their knees when you do that. So assume that dnl all Unix implementations of the function are POSIX compliant. AC_TRY_COMPILE([], -[#if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__ +[#if (defined _WIN32 || defined __WIN32__) && ! (defined __CYGWIN__ || defined __MINGW32__) choke me #endif ], [gl_cv_func_malloc_posix=yes], [gl_cv_func_malloc_posix=no])
Re: regex.m4 test too strict?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Eggert wrote: > Sam Steingold <[EMAIL PROTECTED]> writes: > >> # ac_use_included_regex is NOT cached, so we have to duplicate the >> # logic of src/glm4/regex.m4! >> case $with_included_regex in >> yes|no) ac_use_included_regex=$with_included_regex ;; >> '') case $gl_cv_func_re_compile_pattern_working in >> yes) ac_use_included_regex=no;; >> no) ac_use_included_regex=yes;; >> esac ;; >> esac >> >> is this cheap? > > Yes. this may be cheap from the execution POV, but certainly not from the maintenance POV. >> and, more importantly, is this correct?! > > Yes, for now. But why not just use gl_REGEX? It will be cheap too, > and then you don't have to worry about its internal details changing. I already call gl_REGEX (via gl_INIT) from the top-level configure. if I call gl_REGEX again in subordinate configures, I will have the concomitant #define's in both top-level config.h and subordinate config.h, which causes problems reported in <http://permalink.gmane.org/gmane.lisp.clisp.devel/16815> and <http://permalink.gmane.org/gmane.lisp.clisp.devel/16824>. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHKjwNPp1Qsf2qnMcRAi4OAJ4oi3Rl57YzPpTxMMyW0W9S2T/pOQCfZHji F8Q5sNImh08GE+khUL3pDks= =nXFF -END PGP SIGNATURE-
Re: regex.m4 test too strict?
> * Paul Eggert <[EMAIL PROTECTED]> [2007-10-31 16:47:06 -0700]: > > Sam Steingold <[EMAIL PROTECTED]> writes: > >> incidentally, why isn't ac_use_included_regex cached? > > Typically we don't cache things that can be computed cheaply. Can't > it be computed cheaply, assuming gl_cv_func_re_compile_pattern_working > is cached? here is what I have in the subordinate configure.in # ac_use_included_regex is NOT cached, so we have to duplicate the # logic of src/glm4/regex.m4! case $with_included_regex in yes|no) ac_use_included_regex=$with_included_regex ;; '') case $gl_cv_func_re_compile_pattern_working in yes) ac_use_included_regex=no;; no) ac_use_included_regex=yes;; esac ;; esac is this cheap? and, more importantly, is this correct?! note also that gl_cv_func_re_compile_pattern_working is not found by "grep -i regex" ;-( -- Sam Steingold (http://sds.podval.org/) on Fedora release 7 (Moonshine) http://dhimmi.com http://camera.org http://israelunderattack.slide.com http://ffii.org http://honestreporting.com http://jihadwatch.org Trespassers will be shot. Survivors will be prosecuted.
Re: regex.m4 test too strict?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sam Steingold wrote:
> it appears that gnulib regex.m4 declares my regex broken:
>
> config.cache:818:gl_cv_func_re_compile_pattern_working=${gl_cv_func_re_compile_pattern_working=no}
>
> this is weird given that the system is an fc5 (glibc 2.4).
> are your sure glibc 2.4 has a broken regex implementation?
apparently this is because the system is 64-bit, which still seems wrong
because this is a glibc system and should be using the exact same code.
incidentally, why isn't ac_use_included_regex cached?
this is not a vain question because I want to use it to pass the results
of the check from the top-level configure to the module subconfigure.
I cannot use gl_cv_func_re_compile_pattern_working instead because it
can be overriden by with_included_regex.
Thus, unless ac_use_included_regex is cached, I will have to duplicate
the gl_cv_func_re_compile_pattern_working/with_included_regex logic.
Is there any chance that ac_use_included_regex will be renamed to
ac_cv_use_included_regex and cached?
Thanks.
Sam.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHKL1gPp1Qsf2qnMcRAn7HAKCwhpE4ljsrVyUOwkJYciURYYsNVACdFr6Y
gsBpNfOZokOryyIoDAQ5JVQ=
=F98S
-END PGP SIGNATURE-
regex.m4 test too strict?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
it appears that gnulib regex.m4 declares my regex broken:
config.cache:818:gl_cv_func_re_compile_pattern_working=${gl_cv_func_re_compile_pattern_working=no}
this is weird given that the system is an fc5 (glibc 2.4).
are your sure glibc 2.4 has a broken regex implementation?
thanks
Sam.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHKJ2nPp1Qsf2qnMcRArkIAJ0Tf9MXQyDf6Oh+iFwhM36UM/kMqQCgo3ps
UEBnxHH4J9XaCnLdxV6/FoI=
=lqUo
-END PGP SIGNATURE-
Re: module suggestion: realpath
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruno Haible wrote: > Sam Steingold wrote: >> CLISP comes with a replacement realpath implementation for platforms >> which lacks it (are there still such platforms?). > > If someone provides a correct implementation of realpath for gnulib, we will > accept it. But it's better to use canonicalize_file_name(), because > > - realpath does not have size limitation and associated troubles. Citing the > Linux manpage: > > BUGS >Avoid using this function. It is broken by design since it >is impossible to determine a suitable size for the output >buffer, resolved_path. According to POSIX a buffer of >size PATH_MAX suffices, but PATH_MAX need not be a defined >constant, and may have to be obtained using pathconf(). >And asking pathconf() does not really help, since on the >one hand POSIX warns that the result of pathconf() may be >huge and unsuitable for mallocing memory. And on the other >hand pathconf() may return -1 to signify that PATH_MAX is >not bounded. this is equally applicable to any function what relies on PATH_MAX,e.g., getcwd. pretty soon every user of gnulib will be distributing a full glibc with his package. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHJj/RPp1Qsf2qnMcRAoY7AJ9w7Pmm3HTaBH4HFa/JnIL7QAoWZwCfUO/8 OsMyyBVridwtU9xML1lDDIc= =bvWT -END PGP SIGNATURE-
Re: module suggestion: realpath
> * Bruno Haible <[EMAIL PROTECTED]> [2007-10-28 05:43:54 +0200]: > > Sam Steingold wrote: >> > But it's better to use canonicalize_file_name() >> >> it comes with a huge dependecy set... > > There is an alternative modules 'canonicalize-lgpl'; it has fewer > dependencies. how is it functionally different? if it is not, why two versions? -- Sam Steingold (http://sds.podval.org/) on Fedora release 7 (Moonshine) http://ffii.org http://truepeace.org http://palestinefacts.org http://dhimmi.com http://israelunderattack.slide.com http://jihadwatch.org If abortion is murder, then oral sex is cannibalism.
Re: module suggestion: realpath
> * Bruno Haible <[EMAIL PROTECTED]> [2007-10-27 00:25:01 +0200]: > > Sam Steingold wrote: >> CLISP comes with a replacement realpath implementation for platforms >> which lacks it (are there still such platforms?). > > If someone provides a correct implementation of realpath for gnulib, > we will accept it. you wrote it, it's in pathname.d > But it's better to use canonicalize_file_name() it comes with a huge dependecy set... -- Sam Steingold (http://sds.podval.org/) on Fedora release 7 (Moonshine) http://truepeace.org http://iris.org.il http://israelunderattack.slide.com http://honestreporting.com http://ffii.org http://thereligionofpeace.com If you have no enemies, you are probably dead.
module suggestion: realpath
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CLISP comes with a replacement realpath implementation for platforms which lacks it (are there still such platforms?). I think gnulib is a good home for the code (or, rather, CLISP is not). Sam. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHIfulPp1Qsf2qnMcRAqZPAJ0YRGw0vpgTltDtQofWOYshgbQnzgCfbZAy G1SUcVAY5VseThY8AGfBOig= =m7cV -END PGP SIGNATURE-
Re: required file `build-aux/compile' not found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ralf, Ralf Wildenhues wrote: > > * Sam Steingold wrote on Wed, Oct 24, 2007 at 06:08:49PM CEST: >> I just did >> >> gnulib-tool --import --source-base=src/gllib \ >> --m4-base=src/glm4 --aux-dir=src/build-aux --no-changelog \ >> stdint stdbool regex fnmatch-gnu havelib gettext localcharset \ >> uniwidth/width streq uniname/uniname unitypes >> cd src; automake gllib/Makefile >> gllib/Makefile.am: required file `build-aux/compile' not found >> >> where does this `build-aux/compile' come from? > > Automake. Just do > automake --add-missing gllib/Makefile > > once, and it should get installed. thanks. this created a symlink in src/build-aux. I will replace the symlink with the file and commit it into my cvs, but this episode made me wonder 1. should I always invoke automake with --add-missing? 2. will automake notice that it has a newer version of something for build-aux and tell me or do I need to check that myself every once in a while? is there something like gnulib-update for build-aux? thanks. Sam. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHH3RIPp1Qsf2qnMcRAp1hAJ9dfnMtRZ/dkgLVz5IfdLFrHvoW3gCgk6Ta 6GuXbCcPmv2byZ0U4ch+0B0= =qFo4 -END PGP SIGNATURE-
clisp/utils/unicode & gnulib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruno, diff -u gnulib/tests/uniname/UnicodeDataNames.txt clisp/current/utils/unicode/UnicodeDataFull.txt | wc 5887 24682 319494 which file is correct? are you going to move clisp/current/utils/unicode/ to gnulib completely? Thanks Sam. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHH3FQPp1Qsf2qnMcRAg3MAJ98OrhecvBvWEh0sbpGKWRPG+V/VgCdGmu3 msneUg6ytPhlYcYRPj5fzgU= =MExo -END PGP SIGNATURE-
required file `build-aux/compile' not found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just did gnulib-tool --import --source-base=src/gllib \ --m4-base=src/glm4 --aux-dir=src/build-aux --no-changelog \ stdint stdbool regex fnmatch-gnu havelib gettext localcharset \ uniwidth/width streq uniname/uniname unitypes cd src; automake gllib/Makefile gllib/Makefile.am: required file `build-aux/compile' not found where does this `build-aux/compile' come from? Sam. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHH24RPp1Qsf2qnMcRAhMEAKCyF3gK0CAzosEldlzJvrsKXLZjLACdFK9K 0x+JQBHu+RFC6jm8mcbjDKQ= =vBaa -END PGP SIGNATURE-
Re: users.txt patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruno Haible wrote: > Sam Steingold wrote: >> --- users.txt22 Aug 2007 22:24:56 - 1.19 >> +++ users.txt23 Oct 2007 19:49:52 - >> @@ -4,6 +4,7 @@ >>OPeNDAP http://scm.opendap.org:8090/svn/trunk/ >>autobuild http://josefsson.org/autobuild/ >>bison http://cvs.sv.gnu.org/viewcvs/bison/bison/ >> + clisp http://clisp.cons.org >>coreutils http://cvs.sv.gnu.org/viewcvs/coreutils/coreutils/ >>cvs http://cvs.sv.gnu.org/viewcvs/cvs/ccvs/ >>diffutils http://cvs.sv.gnu.org/viewcvs/diffutils/diffutils/ > > Thank you. clisp was already added to users.txt two days ago, as you can > see from http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=shortlog > (search for "clisp"). this is not in the CVS. why? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHHmp0Pp1Qsf2qnMcRAoo6AJ9xdi1XRzXoC8pSF0i/CQwLk/OoywCeKtgF WzpyzKlrySjZm1lazac/E1w= =oK/U -END PGP SIGNATURE-
users.txt patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Index: users.txt === RCS file: /sources/gnulib/gnulib/users.txt,v retrieving revision 1.19 diff -u -w -u -b -w -i -B -r1.19 users.txt - --- users.txt 22 Aug 2007 22:24:56 - 1.19 +++ users.txt 23 Oct 2007 19:49:52 - @@ -4,6 +4,7 @@ OPeNDAP http://scm.opendap.org:8090/svn/trunk/ autobuild http://josefsson.org/autobuild/ bison http://cvs.sv.gnu.org/viewcvs/bison/bison/ + clisp http://clisp.cons.org coreutils http://cvs.sv.gnu.org/viewcvs/coreutils/coreutils/ cvs http://cvs.sv.gnu.org/viewcvs/cvs/ccvs/ diffutils http://cvs.sv.gnu.org/viewcvs/diffutils/diffutils/ Diffs between working revision and workfile end here. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHHlCqPp1Qsf2qnMcRApgVAKCJIiJ7iTfSA3DVRVzzVZ0u8x444QCfWcSC Ofql2VovtOWWRQkSeHWuEWs= =1TWo -END PGP SIGNATURE-
Re: how to avoid automake dependency?
Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Sam Steingold on 10/22/2007 8:29 AM: I put some gnulib code into my project (in directory gllib) and now I _sometimes_ (usually it works) get this error: /space/sbcl-arch/autobench/+clisp/src/build-aux/missing --run automake-1.9 --gnits gllib/Makefile /space/sbcl-arch/autobench/+clisp/src/build-aux/missing: line 54: automake-1.9: command not found automake likes recording which release generated a Makefile.in. Perhaps all you need is to run 'autoreconf', which will then regenerate all your Makefile.in from your latest automake version (I'm assuming you have 1.10, but not 1.9, installed on your PATH). Once that is done, future gnulib updates will remember that you used automake 1.10, and no longer insist on trying automake-1.9. thanks for your kind reply. alas, I am using 1.9 (and that's all I have). my question is rather this: how do I avoid this target being invoked? even when automake is available, I still get this error: cd src; automake gllib/Makefile configure.in: no proper invocation of AM_INIT_AUTOMAKE was found. configure.in: You should verify that configure.in invokes AM_INIT_AUTOMAKE, configure.in: that aclocal.m4 is present in the top-level directory, configure.in: and that aclocal.m4 was recently regenerated (using aclocal). gllib/Makefile.am:18: Libtool library used but `LIBTOOL' is undefined gllib/Makefile.am:18: gllib/Makefile.am:18: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' gllib/Makefile.am:18: to `configure.in' and run `aclocal' and `autoconf' again. gllib/Makefile.am:33: @LTALLOCA@ used but `LTALLOCA' is undefined /usr/share/automake-1.9/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL /usr/share/automake-1.9/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL $ grep -nH AM_INIT_AUTOMAKE src/configure.in src/configure.in:22:AM_INIT_AUTOMAKE $ ls src/autoconf/aclocal.m4 584 src/autoconf/aclocal.m4 $ grep -nH LIBTOOL src/configure.in src/configure.in:55:AC_LIBTOOL_WIN32_DLL src/configure.in:56:AC_PROG_LIBTOOL I am confused. Sam.
how to avoid automake dependency?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I put some gnulib code into my project (in directory gllib) and now I _sometimes_ (usually it works) get this error: make -C gllib make[1]: Entering directory `/space/sbcl-arch/autobench/+clisp/src/gllib' cd .. && gmake am--refresh gmake[2]: Entering directory `/space/sbcl-arch/autobench/+clisp/src' gmake[2]: Nothing to be done for `am--refresh'. gmake[2]: Leaving directory `/space/sbcl-arch/autobench/+clisp/src' cd .. && /bin/sh /space/sbcl-arch/autobench/+clisp/src/build-aux/missing --run automake-1.9 --gnits gllib/Makefile /space/sbcl-arch/autobench/+clisp/src/build-aux/missing: line 54: automake-1.9: command not found WARNING: `automake-1.9' 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. so, is there a way to avoid this am--refresh target without resorting to "touch src/gllib/Makefile.in"? (which, btw, does not always help). thanks. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHHLPIPp1Qsf2qnMcRAmAjAJ4+ExkpWy3AeVgksgl7W6vBr4H1uwCghf0T 5utMzOpJZmy8Y67x2ji7YSs= =tdu5 -END PGP SIGNATURE-
Re: regex cannot be compiled with g++
Paul Eggert wrote: This casting business is a relatively minor point; I'm more worried about the old-style function definitions. I wish I knew why glibc does it that way. http://sources.redhat.com/bugzilla/show_bug.cgi?id=5200 just ask.
Re: regex cannot be compiled with g++
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Blake wrote: > > You do realize that your patch is a fork from glibc. I do now. > Why not push upstream on the glibc people, then? http://sources.redhat.com/bugzilla/show_bug.cgi?id=5200 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHGMu6Pp1Qsf2qnMcRArnFAJ9Y4ZseOLAbAqKei5q/g0B7EtJLAgCgiAI4 n0IsL6Dov2QDLRrhD1CLbe4= =no7f -END PGP SIGNATURE-
Re: regex cannot be compiled with g++
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruno Haible wrote: > Sam Steingold wrote: >> why not just apply the patch? > > You can also have your patch automatically applied by gnulib-tool. > To achieve this: > - create a directory, say, gnulib-local, > - store your regcomp.diff in gnulib-local/lib/regcomp.c.diff > andregexec.diff in gnulib-local/lib/regexec.c.diff, > - pass the option --local-dir=gnulib-local to gnulib-tool. > > The diffs may require updates every few months, when the copy in gnulib > changes. (gnulib-tool gives an error when a .diff is stored in gnulib-local > but it does not apply cleanly any more.) cool! you want me to fork gnulib! how delightful! > But it's an alternative to weird Makefile hacks that would use gcc when the > user specified g++. both alternatives suck big time. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHGLbIPp1Qsf2qnMcRAjzBAKCrkNPYJCa2PAlyrODf7LDxRQM0YACfc4RH RBMV4sKFk6EERF03klzeoEI= =0B8w -END PGP SIGNATURE-
