Re: AC_C_CONST fails with -Werror
On 09/01/2011 07:49 AM, Ralf Wildenhues wrote: Hello Dan, * Dan Kegel wrote on Thu, Sep 01, 2011 at 02:06:39AM CEST: Reviving https://lists.gnu.org/archive/html/bug-autoconf/2008-11/msg7.html https://lists.gnu.org/archive/html/bug-autoconf/2008-11/msg8.html There is an argument for fixing AC_C_CONST: the way it breaks caused strange errors building one package because its config.h defined const to /**/. Users shouldn't have to go digging around to figure stuff like that out. (Well, ok, any user who does ./configure CFLAGS=-Werror -Wall is asking for it, and shouldn't mind digging around, but still.) We are not sure whether these code changes will still cause the original tests to be effective in uncovering the same compiler issues, should someone really need to work with those compilers. I'll leave it to Eric to decide whether or not to just ditch this reason. I don't think trying to cope with -Werror makes sense, because -Werror contradicts the working principles autoconf is based on. Ralf
Re: [GNU autoconf 2.68] testsuite 12 22 35 37 69 74 140 181 192 244 252 263 269 289 325 334 348 375 376 377 391 427 447 448 474 failed
On 10/01/2010 02:53 PM, Paolo Bonzini wrote: On 09/28/2010 05:28 PM, Ralf Corsepius wrote: However, when using autoconf to build real code, I am occasionally observing sh (== bash) breaksdowns (in unix terms: segfaults) Are you by chance on a 64-bit Windows VM, running inside CentOS 5/RHEL 5 Xen? No, it's an Atom N270, running 32bit WinXP Home: cygcheck report it to be: Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 3 There's a known bug breaking cygwin in that case; however, I'd be surprised that _anything_ worked in that case... Ralf
Re: [GNU autoconf 2.68] testsuite 12 22 35 37 69 74 140 181 192 244 252 263 269 289 325 334 348 375 376 377 391 427 447 448 474 failed
On 09/28/2010 05:09 PM, Eric Blake wrote: On 09/27/2010 09:43 AM, Ralf Corsepius wrote: Excluding tests 199 and 205, I finally managed to get a testsuite.log. Something is wrong with your cygwin environment. Simple shell commands should not be aborting like that. I'm suspecting that you are running into a case where cygwin's fork() is failing to remap dependent .dlls to the same address in the child as they were in the parent. Do you need to rebase your cygwin .dlls, using the 'rebaseall' program? rebaseall worked wonders. Apart of 199 and 205, I am now only observing one failure: 183 Ralf
Re: [GNU autoconf 2.68] testsuite 12 22 35 37 69 74 140 181 192 244 252 263 269 289 325 334 348 375 376 377 391 427 447 448 474 failed
On 09/28/2010 05:09 PM, Eric Blake wrote: On 09/27/2010 09:43 AM, Ralf Corsepius wrote: Excluding tests 199 and 205, I finally managed to get a testsuite.log. [From what I experience, 199 hangs ca. 3 out of 4 times, 205 always hangs] Ralf # -*- compilation -*- 15. tools.at:504: testing autoconf: input from stdin ... ./tools.at:510: echo 'AC_INIT(X, 1.0, bug-autoconf@gnu.org)' | autoconf -t AC_INIT - --- /dev/null2010-09-27 12:19:01.0 +0200 +++ /home/admin/tmp/autoconf-2.68/tests/testsuite.dir/at-groups/15/stderr 2010-09-27 12:18:59.419875000 +0200 @@ -0,0 +1,5 @@ +/home/admin/tmp/autoconf-2.68/bin/autoconf: line 82: 2744 Aborted ( test X`printf %s $as_echo` = X$as_echo ) 2 /dev/null Something is wrong with your cygwin environment. Simple shell commands should not be aborting like that. I'm suspecting that you are running into a case where cygwin's fork() is failing to remap dependent .dlls to the same address in the child as they were in the parent. Do you need to rebase your cygwin .dlls, using the 'rebaseall' program? As I told you before, I am more or less a newbie to cygwin and don't even understand this remark of yours. Are you running with an interfering virus checker or other ill-behaved system-level code-injection application that interferes with cygwin operation? You may be better off asking on the cygwin list for ideas how to diagnose and repair your installation. http://cygwin.com/faq/faq.using.html#faq.using.bloda This system doesn't have any of the programs listed on this page installed. Other than the known failures of 199 and 205 (because of the known cygwin bugs in named fifo handling), the remaining tests all pass for me under cygwin 1.7.7. As I also told you before, all of these errors (except of 199 and 205) appear at random, sometimes they appear, sometimes they don't. However, when using autoconf to build real code, I am occasionally observing sh (== bash) breaksdowns (in unix terms: segfaults) Ralf
Re: autoconf-2.68: test 199 hangs under Cygwin
On 09/26/2010 09:38 AM, Ralf Wildenhues wrote:
Hello Ralf,
* Ralf Corsepius wrote on Thu, Sep 23, 2010 at 02:30:54PM CEST:
Several, but I don't have any real testsuites results, yet, because
the testsuite still hasn't completed, yet.
Typing the failed ons off from the terminal:
38
40
81
101
147
166
183
195
202
No further results, because the testsuite now hangs in test 203.
You could send
tests/testsuite.dir/{038,040,081,101,147,166,183,195,202}/testsuite.log
OK, will do so next time.
FWIW:
1. These breakdowns seem to be non-deterministic. Each time I rerun
make check different testsuite errors occur.
2.
199 seems to hang non-deterministically (ca. 3 out of 4 times)
205 seems to hang deterministically (has never completed for me).
3. make check is dog-slow on my Cygwin/WinXP system (Each iteration
takes many hours). Part of this slowness certainly originates from the
HW (An N270 Atom netbook), but certainly not all of it (Linux is
reasonably fast on the same machine).
Ralf
Re: autoconf-2.68: no AC_LANG_SOURCE call detected in body
On 09/23/2010 02:56 PM, Ralf Corsepius wrote: Hi, I am facing a new issue/regression with autoconf-2.68: When running autoreconf on the follow configure.ac[1]: Another case, but this time triggered by libtool: -- snip -- AC_INIT([foo],[0.1]) AC_CONFIG_SRCDIR([configure.ac]) AC_CONFIG_MACRO_DIR([m4]) AM_INIT_AUTOMAKE([foreign]) LT_INIT AC_CONFIG_FILES([Makefile]) AC_OUTPUT -- snip -- # autoreconf -fi configure.ac:7: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... /usr/share/aclocal/libtool.m4:1022: _LT_SYS_MODULE_PATH_AIX is expanded from... /usr/share/aclocal/libtool.m4:4161: _LT_LINKER_SHLIBS is expanded from... /usr/share/aclocal/libtool.m4:5236: _LT_LANG_C_CONFIG is expanded from... /usr/share/aclocal/libtool.m4:138: _LT_SETUP is expanded from... /usr/share/aclocal/libtool.m4:67: LT_INIT is expanded from... configure.ac:7: the top level configure.ac:7: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... /usr/share/aclocal/libtool.m4:4161: _LT_LINKER_SHLIBS is expanded from... /usr/share/aclocal/libtool.m4:5236: _LT_LANG_C_CONFIG is expanded from... /usr/share/aclocal/libtool.m4:138: _LT_SETUP is expanded from... /usr/share/aclocal/libtool.m4:67: LT_INIT is expanded from... configure.ac:7: the top level configure.ac:7: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... aclocal.m4:1037: _LT_SYS_MODULE_PATH_AIX is expanded from... aclocal.m4:4176: _LT_LINKER_SHLIBS is expanded from... aclocal.m4:5251: _LT_LANG_C_CONFIG is expanded from... aclocal.m4:159: _LT_SETUP is expanded from... aclocal.m4:88: LT_INIT is expanded from... configure.ac:7: the top level configure.ac:7: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... aclocal.m4:4176: _LT_LINKER_SHLIBS is expanded from... aclocal.m4:5251: _LT_LANG_C_CONFIG is expanded from... aclocal.m4:159: _LT_SETUP is expanded from... aclocal.m4:88: LT_INIT is expanded from... configure.ac:7: the top level libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac:7: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... /usr/share/aclocal/libtool.m4:1022: _LT_SYS_MODULE_PATH_AIX is expanded from... /usr/share/aclocal/libtool.m4:4161: _LT_LINKER_SHLIBS is expanded from... /usr/share/aclocal/libtool.m4:5236: _LT_LANG_C_CONFIG is expanded from... /usr/share/aclocal/libtool.m4:138: _LT_SETUP is expanded from... /usr/share/aclocal/libtool.m4:67: LT_INIT is expanded from... configure.ac:7: the top level configure.ac:7: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... /usr/share/aclocal/libtool.m4:4161: _LT_LINKER_SHLIBS is expanded from... /usr/share/aclocal/libtool.m4:5236: _LT_LANG_C_CONFIG is expanded from... /usr/share/aclocal/libtool.m4:138: _LT_SETUP is expanded from... /usr/share/aclocal/libtool.m4:67: LT_INIT is expanded from... configure.ac:7: the top level configure.ac:7: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... aclocal.m4:1037: _LT_SYS_MODULE_PATH_AIX is expanded from... aclocal.m4:4176: _LT_LINKER_SHLIBS is expanded from... aclocal.m4:5251: _LT_LANG_C_CONFIG is expanded from
Re: [GNU Autoconf 2.68] testsuite: 205 failed
On 09/23/2010 07:03 AM, Ralf Wildenhues wrote: Hello Ralf, thanks for the bug report. * Ralf Corsepius wrote on Thu, Sep 23, 2010 at 06:31:47AM CEST: autoconf-2.68's testsuite deterministically fails for me in test 205 for a variety of OSes: ... 205: parallel autotest and signal handling FAILED (autotest.at:1617) Yeah, it's the test that is broken, not Autotest. The bug is known. Sorry, I didn't manage to get it fixed in time for 2.68. Thanks. This is what I had assume and wanted to hear ;) I am going to temporarily disable this check. FWIW, the test wrongly assumes that the output crosses a pipe buffer boundary and thus elicits a SIGPIPE, which is simply not true on some systems. Some? It fails on all Linux distros, I've tried ;) Ralf
Re: autoconf-2.68: test 199 hangs under Cygwin
On 09/23/2010 02:07 PM, Eric Blake wrote: On 09/23/2010 01:03 AM, Ralf Corsepius wrote: Hi, I just gave autoconf-2.68 a try under Cygwin. Is this supposed to work rsp. does this work for anybody? Cygwin has known bugs with named pipes, and they are so severe that autotest parallel tests are known to fail on that platform. There's nothing autoconf can do about it until cygwin's pipe implementation is fixed. For me, autoconf-2.68's testsuite seems to hang in test 199, When rerunning the testsuite, ... test 199 has completed. Checking tests/testsuite.log tells: 199. parallel test execution (autotest.at:1371): ok (0m57.333s 1m3.784s) after having emitting several FAILEDs on preceeding tests. Which tests? Several, but I don't have any real testsuites results, yet, because the testsuite still hasn't completed, yet. Typing the failed ons off from the terminal: 38 40 81 101 147 166 183 195 202 No further results, because the testsuite now hangs in test 203. Ralf
Re: [GNU Autoconf 2.68] testsuite: 205 failed
On 09/23/2010 02:11 PM, Eric Blake wrote: On 09/22/2010 10:31 PM, Ralf Corsepius wrote: ... 205: parallel autotest and signal handling FAILED (autotest.at:1617) ... * Fedora 12/13/14 i386/x86_64 * RHEL6 beta2 i386/x86_64 Odd, because I specifically tested under these two, and it passed for me. Is there an environmental difference between our two setups, Likely - As with previous reports I sent on 2.67, I am actually building autoconf rpms in mock chroots on Fedora 13/x86_64. such as an inherited ignored SIGPIPE setup in the test environment? Remember, POSIX states that a shell that inherits ignored SIGPIPE at startup cannot undo that effect (which is rather annoying). From what I can gather, it's the killer test which fails: Not quite, it's the point at which the testsuite.log shows a diff in expected vs. actual output. The killer test is supposed to fail, and the real failure is occurring later in the log. But Ralf Wildenhues' analysis is correct - the test is making a bad assumption about what scenarios will cause a SIGPIPE, and if SIGPIPE doesn't actually happen, then the test gets confused and fails. OK. Ralf
Re: autoconf-2.68: test 199 hangs under Cygwin
On 09/23/2010 02:14 PM, Eric Blake wrote: On 09/23/2010 06:07 AM, Eric Blake wrote: On 09/23/2010 01:03 AM, Ralf Corsepius wrote: Hi, I just gave autoconf-2.68 a try under Cygwin. Is this supposed to work rsp. does this work for anybody? Cygwin has known bugs with named pipes, and they are so severe that autotest parallel tests are known to fail on that platform. There's nothing autoconf can do about it until cygwin's pipe implementation is fixed. Unless you can find a quickie shell test that validates whether the named pipe implementation is buggy and can thus skip parallel testing on cygwin in the first place (I haven't yet found such a test that rules out cygwin but without hanging). We already have other quickie tests, like whether set -m works, whether mkfifo works and whether trap ... STOP works; but the problem is all three of those work on cygwin. I recall older versions of autoconf under older Cygwins having had problems with some process related resources and people being recommended to increase some of them. If so, which and how? I am only very infrequently using Cygwin and Windows in general, so I don't recall the details and am more or less a completely illiterate about Cygwin. Ralf
autoconf-2.68: no AC_LANG_SOURCE call detected in body
Hi, I am facing a new issue/regression with autoconf-2.68: When running autoreconf on the follow configure.ac[1] -- snip -- AC_INIT([foo],[0.1]) AC_CONFIG_SRCDIR([configure.ac]) AM_INIT_AUTOMAKE([foreign]) AC_COMPILE_IFELSE([ #ifndef FOO choke me #endif ]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT -- snip -- autoconf-2.68 complains: # autoreconf -fi autoreconf -fi configure.ac:6: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from... configure.ac:6: the top level configure.ac:6: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from... configure.ac:6: the top level configure.ac:6: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from... configure.ac:6: the top level configure.ac:6: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from... configure.ac:6: the top level With older autoconfs, autoreconf remains entirely silent. What is wrong with this configure.ac rsp. how to overcome these warnings? Ralf [1] I actually tripped this issue with a real world package. The configure.ac above is a stripped version of a much more complex real world configure script.
Re: autoconf-2.68: no AC_LANG_SOURCE call detected in body
On 09/23/2010 03:52 PM, Eric Blake wrote: On 09/23/2010 06:56 AM, Ralf Corsepius wrote: Hi, I am facing a new issue/regression with autoconf-2.68: That is not a regression, but a feature. Your feature is my regression - It broke what appeared to have worked for ages ;) Reread NEWS: AC_COMPILE_IFELSE([ #ifndef FOO choke me #endif ]) You should have used: AC_COMPILE_IFELSE([AC_LANG_SOURCE([ #ifndef FOO choke me #endif ]) OK, thanks. With older autoconfs, autoreconf remains entirely silent. Not only were they entirely silent, but most likely generated a broken configure. If you don't use AC_LANG_SOURCE, then you don't get the benefit of all the prior AC_DEFINEs being implicitly included before the body of your test, which leads to documented cases of mis-diagnosing whether a feature is present for a given build. Actually, I don't need the AC_DEFINES in this particular case - Adding them however, should not do much harm, either. What is wrong with this configure.ac rsp. how to overcome these warnings? Use AC_LANG_SOURCE, like the warning told you to do in the first place. Well, really usable warnings look a bit different than this warning. They might be self-explanatory to you, but to me this warning was Greek. Ralf
[GNU Autoconf 2.68] testsuite: 205 failed
Hi, autoconf-2.68's testsuite deterministically fails for me in test 205 for a variety of OSes: ... 205: parallel autotest and signal handling FAILED (autotest.at:1617) ... OSes affected: * CentOS 5 i386/x86_64 * Fedora 12/13/14 i386/x86_64 * RHEL6 beta2 i386/x86_64 * openSUSE 11.2/11.3 i386/x86_64 From what I can gather, it's the killer test which fails: ... # make -C tests/testsuite.dir/205 check ... 1: test number 1 ok 2: test number 2 ok 3: test number 3 ok 4: killer test FAILED (micro-suite.at:12) 5: test number 5 ok 6: test number 6 ok 7: test number 7 ok ## - ## ## Test results. ## ## - ## ERROR: All 7 tests were run, 1 failed unexpectedly. ... Ralf
Re: AC_PROG_CC fails when target C library is missing fopen
On 08/12/2009 06:51 PM, Ralf Corsepius wrote: On 08/12/2009 02:09 PM, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paolo Bonzini on 8/10/2009 4:27 PM: On 08/11/2009 12:11 AM, Ralf Wildenhues wrote: I don't see in this discussion where the main argument to switch to using fopen is addressed: http://thread.gmane.org/gmane.comp.sysutils.autoconf.patches/6656 IOW, how do you prevent AC_COMPUTE_INT and friends from getting you wrong answers on your system (if you happen to have a simulator around)? In my patch I use an empty source code file to determine the default file name. Then I use one with fopen to determine if the user is cross-compiling; this would fail for RTEMS so that the preprocessor-only AC_COMPUTE_INT is used. If we get feedback from both RTEMS I am observing what I would call partial success. Using atoi definitely is much better than fopen for RTEMS (Thanks Paolo!). However, with this check applied, I am now observing a similar problem with autoconf's check for cross-compilation, when using a toolchain with RTEMS function stubs removed (The official rtems toolchains have these stubs) Example: # cat configure.ac AC_PREQ([2.64]) AC_INIT([cccheck],[0.2]) AM_INIT_AUTOMAKE([foreign 1.11 dist-bzip2]) AC_PROG_CC AC_CONFIG_FILES(Makefile) AC_OUTPUT # ./configure --host=i386-rtems4.10 The resulting config.log shows this: ... configure:2729: checking whether we are cross compiling configure:2737: i386-rtems4.10-gcc -o conftestconftest.c 5 /opt/rtems-4.10/lib64/gcc/i386-rtems4.10/4.4.1/../../../../i386-rtems4.10/lib/libc.a(lib_a-findfp.o): In function `__sfmoreglue': /users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/findfp.c:88: undefined reference to `_malloc_r' /opt/rtems-4.10/lib64/gcc/i386-rtems4.10/4.4.1/../../../../i386-rtems4.10/lib/libc.a(lib_a-fopen.o): In function `_fopen_r': /users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/fopen.c:141: undefined reference to `_open_r' /opt/rtems-4.10/lib64/gcc/i386-rtems4.10/4.4.1/../../../../i386-rtems4.10/lib/libc.a(lib_a-fseek.o): In function `_fseek_r': /users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/fseek.c:233: undefined reference to `_fstat_r' /users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/fseek.c:258: undefined reference to `_fstat_r' /opt/rtems-4.10/lib64/gcc/i386-rtems4.10/4.4.1/../../../../i386-rtems4.10/lib/libc.a(lib_a-makebuf.o): In function `__smakebuf_r': /users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/makebuf.c:59: undefined reference to `_fstat_r' /users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/makebuf.c:95: undefined reference to `_malloc_r' /users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/makebuf.c:110: undefined reference to `_isatty_r' /opt/rtems-4.10/lib64/gcc/i386-rtems4.10/4.4.1/../../../../i386-rtems4.10/lib/libc.a(lib_a-stdio.o): In function `__sclose': /users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/stdio.c:124: undefined reference to `_close_r' /opt/rtems-4.10/lib64/gcc/i386-rtems4.10/4.4.1/../../../../i386-rtems4.10/lib/libc.a(lib_a-stdio.o): In function `__swrite': /users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/stdio.c:86: undefined reference to `_write_r' collect2: ld returned 1 exit status I.e. something still pulls in symbols, RTEMS libc (newlib) doesn't contain. We still needs stub functions in libc/newlib to let AC_PROG_CC work out correctly. Ralf
Re: AC_PROG_CC fails when target C library is missing fopen
On 08/12/2009 02:09 PM, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paolo Bonzini on 8/10/2009 4:27 PM: On 08/11/2009 12:11 AM, Ralf Wildenhues wrote: I don't see in this discussion where the main argument to switch to using fopen is addressed: http://thread.gmane.org/gmane.comp.sysutils.autoconf.patches/6656 IOW, how do you prevent AC_COMPUTE_INT and friends from getting you wrong answers on your system (if you happen to have a simulator around)? In my patch I use an empty source code file to determine the default file name. Then I use one with fopen to determine if the user is cross-compiling; this would fail for RTEMS so that the preprocessor-only AC_COMPUTE_INT is used. If we get feedback from both RTEMS FYI: I haven't forgotten about your patch, but haven't been able to look into this at depth yet, but hope to be able to look into this sometime next week. Sorry for the inconvenience. Ralf
Re: AC_PROG_CC fails when target C library is missing fopen
On 08/05/2009 07:56 PM, Adam Sampson wrote: Hi, I've upgraded to autoconf 2.64 recently, and it works nicely -- except in one slightly odd configuration. One of the projects I work on (KRoC, an occam compiler and runtime) can be cross-compiled for the AVR series of microcontrollers. This used to work, but now this happens: checking for avr-gcc... avr-gcc checking for C compiler default output file name... configure: error: in `/home/ats/src/kroc-svn/obj-avr/modules/inmoslibs/libsrc': configure: error: C compiler cannot create executables See `config.log' for more details. What's going on? Well, the AC_PROG_CC test now tries to compile a little program that uses fopen -- but the AVR-GCC toolchain uses avr-libc, which doesn't provide fopen. (Which might seem silly -- and is certainly non-standards-compliant -- but kind of makes sense when your typical target device is a microcontroller with 8K of flash, and nothing even vaguely resembling a filesystem.) In 2.63 and earlier, the program it compiled just did return 0;, so it was quite happy with avr-libc. We are facing a similar regression with autoconf-2.64 and rtems. The fopen check pulls in a chain of file-io related symbols, causing all AC_PROG_CC to fail, because rtems has them outside of libc. Any suggestions? I suppose one option would be to try to persuade the avr-libc maintainers to add a dummy fopen() implementation that always returns NULL... That's what we (rtems) currently are doing. Unfortunately, this approach opens a can of worms, because when doing so, AC_CHECK_FUNC etc. will return bogus results (false positives) when checking for presence of fopen and other file-io related functions (e.g. while using autoconf to build the library providing fopen etc). IMO, it would be best to revert the change in autoconf. Ralf
Re: autoconf 2.63 and newlib
First of all, your posting is off topic on this list. This list is about bugs in autoconf and autoconf-development, not about autoconf use-cases (here: newlib) uglyoldbob wrote: I have been unable to compile newlib 1.16 with autoconf 2.63. You can't and should not. Compiling with binutils 2.19.1, gcc-4.3.2 modified source to work for my kernel. binutils and GCC also require specific versions of the autotools. They are a bit more tolerant, but they have not been tested with the versions you are trying to use. I have tracked the issue to differences to the version of autoconf. It works with autoconf 2.59 but fails with 2.63. Correct. newlib needs autoconf-2.59. Ralf
Re: CFLAGS is for the user in GNU
Karl Berry wrote:
The description of CFLAGS in the Autoconf manual omits the most
important point about it. To quote the coding standards
(make-stds.texi):
If there are C compiler options that @emph{must} be used for proper
compilation of certain files, do not include them in @code{CFLAGS}.
Users expect to be able to specify @code{CFLAGS} freely themselves.
I would write a patch for it, but I'm not sure if there is a variable to
suggest for such required options for the C compiler proper these days.
Maybe it never comes up in practice?
Ohh, the problem does come up in practice.
However, I think you trying to solve a non-issue, because such
hard-coded flags are package-specific internal configuration details,
a package's configuration implementor will treat just like any other
package-specific configuration detail.
I.e., he will typically add some *_*FLAGS macros/AS_SUBST's and use them
inside of his hand-crafted Makefile.in's.
Ralf
Re: autoconf-2.62 doesn't build on RHEL4
On Wed, 2008-04-23 at 06:11 -0600, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Corsepius on 4/23/2008 2:44 AM: | Really, we require newer m4 because older versions caused autoconf to | create erroneous configure scripts, and those errors were very difficult | to diagnose. Not to make life harder for you. | It might be inconvenient to you but reality simply is as simple as: | Autoconf-2.62 has proven to miss its objective: portability. Wait a minute. You are still mixing apples and oranges. I don't think I am. It's as simple as this: You broke autoconf's portability and usability. Autoconf has regressed from once having been a portable tool into one of amoungst many GNU-centric proprietary tools - It's the defect many people have accused the autotools for for many years - You proved them to be right. Autoconf's objective is to output portable configure scripts, and this triumphs over any concerns about being portable itself. The reason that Autoconf itself uses non-portable tools such as new enough GNU m4 and perl, in spite of the GNU Coding Standards stating that these tools are not to be used in building portable programs, is that it was decided long ago that developers are smart enough to install proper prerequisites if they want to then generate something that DOES comply with GCS for their end users. I am well aware about this statement: Ask yourself why the perl in (esp. automake) is frozen to an ancient perl-standard and did not adopt modern perl dialects. Adopting modern perl would have essentially the same impact as autoconf-2.62+gm4 has, except that upgrading perl is not as trivial as it is to upgrade gm4. Let's stop this thread here. I don't think, it will anywhere. Ralf
Re: autoconf-2.62 doesn't build on RHEL4
On Tue, 2008-04-22 at 19:18 +0200, Ralf Wildenhues wrote: Hello Ralf, * Ralf Corsepius wrote on Tue, Apr 22, 2008 at 03:41:36PM CEST: On Tue, 2008-04-22 at 07:19 -0600, Eric Blake wrote: You're comparing apples and oranges. I don't see this ... You require a particular version of gm4 instead of searching for a feasible, sufficient m4 (note: m4 vs. gm4). Autoconf has required GNU m4 for a looong time. Well, when this had been decided, GNU m4 had been assumed to be a viable and stable basis. autoconf-2.62 has proven this assumption to be wrong. Really, we require newer m4 because older versions caused autoconf to create erroneous configure scripts, and those errors were very difficult to diagnose. Not to make life harder for you. It might be inconvenient to you but reality simply is as simple as: Autoconf-2.62 has proven to miss its objective: portability. May-be RH realizes that RHEL4 doesn't meet autoconf's requirements and therefore doesn't qualify as suitable platform for ongoing development :/ Them upgrading their toolchains, would help us, but of cause doesn't help autoconf in general. Anyway, we just decided to drop supporting RHEL 4 from our supported platforms portfolio and decided to stay with autoconf-2.61 for the current branch of our development - It's a pity, but all this is a direct consequence of autoconf-2.62. Ralf
Re: autoconf-2.62 doesn't build on RHEL4
On Tue, 2008-04-22 at 06:18 -0600, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Corsepius on 4/21/2008 11:49 PM: | I am not upgrading the distro. I want to enable to developers to work on | my sources. Therefore, I am shipping autoconf+automake add-on packages | (Installed to /opt/...). | | ... now, autoconf is forcing me to also ship gm4. | | To me, this is a massive regression on autoconf's part. I'm sorry you feel this is a regression, but autoconf has required gm4 for ages, and only now are we enforcing that gm4 is new enough to not silently generate broken configure files. I know - But I feel you have shot autoconf into its foot by doing. | | What will be next - bash-X, gawk-Y? No. The resulting configure scripts do not depend on a particular bash Well, they spend a significant amount of effort in working around shell portability issues and shell bugs. Requiring (or even bundling) one particular flavor of a shell would likely significantly simply configure scripts :() | These distros are ultra-conservative, ... security fixes only, and | hardly any upgrades ever. And m4 1.4.4 and earlier have KNOWN security bugs. Your distro is doing you a disservice by not upgrading it. I am not working for RedHat, I am not even using RHEL. Even m4 1.4.10 has a known stack overrun/arbitrary code execution bug when abusing the -F option that was only fixed in 1.4.11. OK, so running autoconf is a SECURITY risk on almost all existing Linux distributions? It's time autoconf dumps using m4 in favor something more stable! And guess what - autoconf uses the -F option (at least autoconf doesn't tickle the m4 bug in the normal use case of portable file names). - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) I guess you know how old and broken Cygwin's GCC is? I guess, I'll start to require gcc-4.3.x for my sources, such that Cygwin users will have to upgrade their GCC. Ralf
Re: autoconf-2.62 doesn't build on RHEL4
On Mon, 2008-04-21 at 10:59 +0200, Ralf Corsepius wrote: Hi, Building autoconf-2.62 fails on RHEL4 ... checking for expr... /usr/bin/expr checking for GNU M4 that supports accurate traces... configure: error: no acceptable m4 could be found in $PATH. GNU M4 1.4.5 or later is required; 1.4.11 is recommended The error message is wrong and misleading: # gawk --version GNU Awk 3.1.3 nor does config.log contain any further hints on why configuring autoconf fails. Urgh, my bad, I should have looked closer :( RHEL 4 still ships an antiquated m4-1.4.1 (Time for me to abandon supporting RHEL-4, I suppose ;) Ralf
Re: meaning of CFLAGS
On Thu, 2006-07-20 at 16:08 +0200, Bruno Haible wrote: Hi, The autoconf manual describes CFLAGS like this: Variable: CFLAGS Debugging and optimization options for the C compiler. If it is not set in the environment when `configure' runs, the default value is set when you call `AC_PROG_CC' (or empty if you don't). `configure' uses this variable when compiling programs to test for C features. Based on this text, in a Makefile.in of mine, I use CFLAGS for .c to .o compilation, but not for linking. Because debugging and optimization flags are useless for linking. This assumption is wrong. Such flags can affect linking, e.g. pull different startup files, different run time libraries and imply different linker flags (consider profiling). But the GNU standards say: `CFLAGS' should be used in every invocation of the C compiler, both those which do compilation and those which do linking. Now it makes a difference. A user on Solaris/x86_64 tried to use CC=cc CFLAGS=-xarch=amd64 and it didn't work with my Makefile.in. Is the user supposed to use such setting? Or does he need to use CC=cc -xarch=amd64 It depends on what -xarch=... does. The fundamental question would be: Which component of a toolchain does a flag affect/is a flag processed by? There exist cases where first form is needed and there exist cases where the latter form is needed and there exists a fairly large grey zone inbetween. Ralf
Re: AC_EGREP_CPP double quotes the PATTERN parameter
On Wed, 2005-08-31 at 17:35 +0200, Stepan Kasal wrote: Hello, I noticed the above. If we are to fix it, we probably have to invent new name for AC_EGREP_CPP and AC_EGREP_HEADER? What about AC_GREP_E_CPP and AC_GREP_E_HEADER? The old ones would become obsolete... Wdyt? Unless there is an inevitable technical need to do so, don't change the API. Ralf
