curl / Mailing Lists / curl-library / Single Mail

curl-library

Re: Build issues for curl/libcurl > 7.53.1 on OpenServer 5.0.7

From: Kevin R. Bulgrien <kevinb_at_systemsdesignusa.com>
Date: Tue, 19 Jun 2018 17:13:25 -0500 (CDT)

----- Original Message -----
> From: "Daniel Stenberg" <daniel_at_haxx.se>
> To: "libcurl development" <curl-library_at_cool.haxx.se>
> Sent: Tuesday, June 19, 2018 4:27:56 PM
> Subject: Re: Build issues for curl/libcurl > 7.53.1 on OpenServer 5.0.7
>
> On Tue, 19 Jun 2018, Kevin R. Bulgrien wrote:
>
> > The patch, autoreconf, and ./configure, results in a successful build:
>
> Cool. But it makes me really curious:
>
> Your patch adds a block of defines that is identical to the "safe
> guess" block that is the default already if no other #if check
> matches. So why is the patch necessary?

Without the patch, after autoreconf and ./configure:

[kevinb_at_sddemokb:~/src/curl/curl-7.60.0]$ make
Making all in lib
make[1]: Entering directory `/csdi/admin/kevinb/src/curl/curl-7.60.0/lib'
make all-am
make[2]: Entering directory `/csdi/admin/kevinb/src/curl/curl-7.60.0/lib'
  CC libcurl_la-file.lo
In file included from ../include/curl/curl.h:38,
                 from curl_setup.h:142,
                 from file.c:23:
../include/curl/system.h:426: parse error before `curl_socklen_t'
../include/curl/system.h:426: warning: data definition has no type or storage class
In file included from hostip.h:27,
                 from urldata.h:97,
                 from file.c:52:
curl_addrinfo.h:56: parse error before `curl_socklen_t'
curl_addrinfo.h:56: warning: no semicolon at end of struct or union
curl_addrinfo.h:60: parse error before `}'
In file included from file.c:55:
sendf.h:55: warning: `warn_unused_result' attribute directive ignored
make[2]: *** [libcurl_la-file.lo] Error 1
make[2]: Leaving directory `/csdi/admin/kevinb/src/curl/curl-7.60.0/lib'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/csdi/admin/kevinb/src/curl/curl-7.60.0/lib'
make: *** [all-recursive] Error 1

In case it's relevant, my full build environment is more like:

ACCEPT_INFERIOR_RM_PROGRAM=yes
CPATH=/csdi/admin/kevinb/include
CFLAGS=-static
PKG_CONFIG_PATH=/csdi/admin/kevinb/lib/pkgconfig
CC=/csdi/admin/kevinb/bin/gcc-3.4.6

$ CC= CFLAGS= ./configure --without-zlib --disable-threaded-resolver -C --prefix="${HOME}" --enable-shared --enable-static

I haven't built zlib for this platform as of yet, and I have not filled the
threaded resolver dependencies either. )

I suppose the need for "a patch" as opposed to "the patch" is because the
__GNUC__ is defined and the existing code is not adequate for this system:

#elif defined(__GNUC__)
# if !defined(__LP64__) && \
  (defined(__ILP32__) || defined(__i386__) || defined(__hppa__) || \
   defined(__ppc__) || defined(__powerpc__) || defined(__arm__) || \
   defined(__sparc__) || defined(__mips__) || defined(__sh__) || \
   defined(__XTENSA__) || \
   (defined(__SIZEOF_LONG__) && __SIZEOF_LONG__ == 4) || \
   (defined(__LONG_MAX__) && __LONG_MAX__ == 2147483647L))
# define CURL_TYPEOF_CURL_OFF_T long long
# define CURL_FORMAT_CURL_OFF_T "lld"
# define CURL_FORMAT_CURL_OFF_TU "llu"
# define CURL_SUFFIX_CURL_OFF_T LL
# define CURL_SUFFIX_CURL_OFF_TU ULL
# elif defined(__LP64__) || \
        defined(__x86_64__) || defined(__ppc64__) || defined(__sparc64__) || \
        (defined(__SIZEOF_LONG__) && __SIZEOF_LONG__ == 8) || \
        (defined(__LONG_MAX__) && __LONG_MAX__ == 9223372036854775807L)
# define CURL_TYPEOF_CURL_OFF_T long
# define CURL_FORMAT_CURL_OFF_T "ld"
# define CURL_FORMAT_CURL_OFF_TU "lu"
# define CURL_SUFFIX_CURL_OFF_T L
# define CURL_SUFFIX_CURL_OFF_TU UL
# endif
# define CURL_TYPEOF_CURL_SOCKLEN_T socklen_t
# define CURL_PULL_SYS_TYPES_H 1
# define CURL_PULL_SYS_SOCKET_H 1

#else

Frankly, until I got things working, it took a lot less thinking to make a
"quick fix" than modify the the __GNUC__ bit.

Now that the build works, it may be best to alter the __GNUC__ logic to
either fall through in the case that _SCO_DS is defined, or, perhaps,
to modify the __GNUC__ bit to address the underlying weakness.

-- 
Kevin R. Bulgrien, Network/Software Engineer
http://www.systemsdesignusa.com
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html
Received on 2018-06-20