Re: config.status and /bin/sh on Solaris

2017-01-28 Thread Dimitrios Apostolou
On Sat, 28 Jan 2017, Dimitrios Apostolou wrote: So the configure script goes like this: if test x$as_have_required = xyes && (eval "$as_suggested") 2>/dev/null; then : else [ ... Almost 100 lines never executed ... ] fi fi SHELL=${CONFIG_SHELL-/bin/sh} export S

configure fails when PATH=/usr/xpg4/bin:/usr/bin on Solaris 11

2017-01-28 Thread Dimitrios Apostolou
Hello again, here is the failing log of "configure" (as generated by GNU Autoconf 2.69) when executed with altered path on Solaris 11: $ PATH=/usr/xpg4/bin:/usr/bin /bin/sh ./configure checking for a BSD-compatible install... config/install-sh -c checking whether build environment is

Re: config.status and /bin/sh on Solaris

2017-01-28 Thread Dimitrios Apostolou
On Sat, 28 Jan 2017, Bob Friesenhahn wrote: What does 'echo $SHELL' show for your login session? It's /usr/bin/bash for this system (but I'm having /similar/, maybe related issues on a Solaris 11 with /bin/sh as login shell). I don't think the login shell is relevant, but the PATH tweak is

Re: config.status and /bin/sh on Solaris

2017-01-28 Thread Dimitrios Apostolou
On Sat, 28 Jan 2017, Bob Friesenhahn wrote: On Sat, 28 Jan 2017, Dimitrios Apostolou wrote: On Fri, 27 Jan 2017, Bob Friesenhahn wrote: I have been using Solaris 10 daily for Autoconf related development since 2005 and have never seen configure select /bin/sh. One reason

Re: config.status and /bin/sh on Solaris

2017-01-27 Thread Dimitrios Apostolou
On Fri, 27 Jan 2017, Bob Friesenhahn wrote: I have been using Solaris 10 daily for Autoconf related development since 2005 and have never seen configure select /bin/sh. One reason is that the system normally has /usr/bin/bash installed. Are you missing /usr/bin/bash on your system? Hi, I

Re: config.status and /bin/sh on Solaris

2017-01-27 Thread Dimitrios Apostolou
On Sat, 28 Jan 2017, Dimitrios Apostolou wrote: + as_required=as_fn_return () { (exit $1); } as_fn_success () { as_fn_return 0; } as_fn_failure () { as_fn_return 1; } as_fn_ret_success () { return 0; } as_fn_ret_failure () { return 1; } exitcode=0 as_fn_success || { exitcode=1; echo

Re: config.status and /bin/sh on Solaris

2017-01-27 Thread Dimitrios Apostolou
On Fri, 27 Jan 2017, Zack Weinberg wrote: On Fri, Jan 27, 2017 at 7:29 PM, Dimitrios Apostolou <ji...@gmx.net> wrote: So I've been tracing the execution of "configure", but I don't CONFIG_SHELL to be set, and the script reaches a point that the following happens: SHELL=${CONF

Re: config.status and /bin/sh on Solaris

2017-01-27 Thread Dimitrios Apostolou
On Fri, 27 Jan 2017, Eric Blake wrote: On 01/27/2017 01:11 PM, Dimitrios Apostolou wrote: Where is the source for this shebang generation? Maybe I can make some sense out of it. The #! line in config.status is _supposed_ to be the value of CONFIG_SHELL (whether inherited from

Re: config.status and /bin/sh on Solaris

2017-01-27 Thread Dimitrios Apostolou
On Fri, 27 Jan 2017, Zack Weinberg wrote: On Fri, Jan 27, 2017 at 1:36 PM, Dimitrios Apostolou <ji...@gmx.net> wrote: on my Solaris 10, for some unknown reason, /sometimes/ config.status is generated with "#! /bin/sh" shebang, instead of bash. You should figure out why *th

config.status and /bin/sh on Solaris

2017-01-27 Thread Dimitrios Apostolou
Hello list, on my Solaris 10, for some unknown reason, /sometimes/ config.status is generated with "#! /bin/sh" shebang, instead of bash. When this happens, the configure script prints ugly messages but *succeeds*, but then gmake fails miserably because of malformed Makefile. Here are the

Re: AC_PROG_CC_C89 is not adding -std=c89 to CFLAGS

2017-01-16 Thread Dimitrios Apostolou
On Fri, 13 Jan 2017, Paul Eggert wrote: Dimitrios Apostolou wrote: I was expecting that adding AC_PROG_CC_C89 to configure.ac, would force C89 Eeeuuw. Who would want to do that? See the context in my first email, apparently some defines were not very well thought. Passing -std=gnu89

AC_PROG_CC_C89 is not adding -std=c89 to CFLAGS

2017-01-13 Thread Dimitrios Apostolou
Hello list, recent GCC versions default to C99 or even C11. I was expecting that adding AC_PROG_CC_C89 to configure.ac, would force C89, probably by using -std=gnu89. But this was not the case. Any ideas why? Context is compiling a C program using a recent gcc on Solaris 10, resulted to

AM_CONDITIONAL fails with line break at the end of $2

2014-07-17 Thread Dimitrios Apostolou
Hello list, the following snippet generates invalid shell code (and a cryptic error message) because of the line break right before the closing parenthesis. AM_CONDITIONAL([HAVE_LIBXML2], [test x$with_libxml2 != xno test x$ac_cv_lib_xml2_xmlFirstElementChild = xyes] ) Generated

Re: AM_CONDITIONAL fails with line break at the end of $2

2014-07-17 Thread Dimitrios Apostolou
Hi Erik, thank you for forwarding to the appropriate list! On Thu, 17 Jul 2014, Eric Blake wrote: I don't know if automake should work around your bad syntax, or if you should just fix your configure.ac to use correct syntax to begin with. I Is my syntax illegal? Can't I put line-breaks

Re: autoconf tests and stdcall name mangling

2013-05-23 Thread Dimitrios Apostolou
On Wed, 22 May 2013, Eric Blake wrote: On 05/22/2013 02:12 PM, Zack Weinberg wrote: On Wed, May 22, 2013 at 1:06 PM, Nick Bowler nbow...@elliptictech.com wrote: The fundamental problem, I think, is that you really need the proper headers included and AC_REPLACE_FUNCS does not seem to allow

Re: autoconf tests and stdcall name mangling

2013-05-23 Thread Dimitrios Apostolou
On Wed, 22 May 2013, Zack Weinberg wrote: On Wed, May 22, 2013 at 1:06 PM, Nick Bowler nbow...@elliptictech.com wrote: The fundamental problem, I think, is that you really need the proper headers included and AC_REPLACE_FUNCS does not seem to allow you to specify the includes. So you probably

autoconf tests and stdcall name mangling

2013-05-22 Thread Dimitrios Apostolou
(Not sure which list is relevant, so I'm cross-posting to both mingw-users and autoconf lists) Hello lists, when I'm cross compiling from linux x86_64 to 32-bit MinGW autoconf refuses to detect getaddrinfo and define HAVE_GETADDRINFO. I've limited the case to the following behaviour: The

Re: autoconf tests and stdcall name mangling

2013-05-22 Thread Dimitrios Apostolou
On Wed, 22 May 2013, Dimitrios Apostolou wrote: (Not sure which list is relevant, so I'm cross-posting to both mingw-users and autoconf lists) Not a cross-post after all since mingw-users requires registration. I'd appreciate any help from autoconf people, just make sure you don't CC mingw