Re: curl 7.37 build failures on HP-UX 11.23 ia64
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
> 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 "./http_pipe.py", 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 runtests.pl
-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:
> http://curl.haxx.se/mail/lib-2013-09/0081.html from that thread says:
> "You can easily just comment out
> CURL_CHECK_COMPILER_PROTOTYPE_MISMATCH from configure.ac, re-run
> 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
> I found and commented out the prototype check in configure.ac, but
> could not get autoconf to run right:
> >autoconf configure.ac
> interpreter "/usr/local/bin/perl" not found
> /usr/local/bin/autoconf: /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.
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2014-07-09