cURL / Mailing Lists / curl-library / Single Mail


Re: curl 7.37 build failures on HP-UX 11.23 ia64

From: Dan Fandrich <>
Date: Wed, 9 Jul 2014 23:54:05 +0200

On Wed, Jul 09, 2014 at 03:34:28PM -0400, Richard Gray wrote:
> Taking the hint from above, I re-ran using:
> CFLAGS="-D_XOPEN_SOURCE_EXTENDED" ./configure and I seem to have
> gotten a working curl build. I wonder if configure should always
> set this flag for HP-UX systems? It (or something better) would aim
> for maximum portability on this platform. Is there a place where all
> these
> This warning seems strange. Why set CPPFLAGS for a c program?:

CPPFLAGS stands for C Pre-Processor Flags, not C++ flags.

> configure:3645: using CFLAGS: -D_XOPEN_SOURCE_EXTENDED
> configure:3651: CFLAGS note: CFLAGS should only be used to specify C
> compiler flags, not macro definitions. Use CPPFLAGS for:
> make test was even happy, although the output was littered with stty
> and kill messages, plus this burp in test 1528:
> test 1526...OK (896 out of 936, remaining: 00:24)
> test 1527...OK (897 out of 936, remaining: 00:24)
> test 1528...OK (898 out of 936, remaining: 00:23)
> File "./", line 398
> except RequestTooLargeError as e:
> ^
> SyntaxError: invalid syntax

It looks like your Python version is older than required by this test

> RUN: failed to start the HTTP3 server
> == Contents of files in the log/ dir after test 1900
> test 2000...stty: : Not a typewriter

Curious; can you figure out where this message is coming from? The
-v and -d flags might help.

> Ultimately, I probably want to use the native compiler.
> HP aC++/ANSI C B3910B A.06.10 [Mar 22 2006]
> CC=cc ./configure
> Dies on:
> checking if compiler halts on compilation errors... yes
> checking if compiler halts on negative sized arrays... yes
> checking if compiler halts on function prototype mismatch... no
> configure: error: compiler does not halt on function prototype mismatch.
> just like:
> from that thread says:
> "You can easily just comment out
> autoconf and then run configure again and that failure shouldn't
> bother you."

This feature is used to figure out the right function signature for some
functions. Commenting it out will let the configure proceed, but could
result in a binary that builds but crashes or otherwise doesn't work properly
when run.

> I found and commented out the prototype check in, but
> could not get autoconf to run right:
> >autoconf
> interpreter "/usr/local/bin/perl" not found
> /usr/local/bin/autoconf[271]: /usr/local/bin/autom4te: not found.
> On this system, perl is in /usr/bin. (I don't know if that's normal,
> I did not set the system up.)

Use the buildconf to rebuild the auto* files. It does some sanity checks first
and reconfigures things in the correct order.

>>> Dan
List admin:
Received on 2014-07-09