On Tue, 11 Mar 2003, Rick Jones wrote:

> here then is the typescript of a configure;make with the hacked configure
> script to get past the select et al problems

Many thanks for your efforts. I'll do my very best to receive them and make
good use of them. I'll bounce back a bunch of questions, and I hope to
produce another pre-release soonish for further testing.

Regarding the hacks needed for configure to do good, did you add those to the
raw configure shell script or have you done any nice configure.in changes?

And what exactly (again) did you need to do to get the select() and
gettimeofday() recognized?

> I'm not sure yet what is up with the sendfile/sendpath warnings, but since
> libcurl does not seem to try to use sendfile/sendpath (an enhancement
> opportunity - feel free to leverage the code from netperf :) I suspect it
> isn't a problem.

That's left for the future, unless someone feels like jumping in here and
help out.

> There are a bunch of warnings in ftp.c like this:
>
> cc: "ftp.c", line 148: warning 604: Pointers are not
> assignment-compatible.^M
> cc: "ftp.c", line 148: warning 563: Argument #3 is not the correct
> type.^M
> cc: "ftp.c", line 149: warning 604: Pointers are not
> assignment-compatible.^M
>
> That appear to stem from arbitrary use of stuff like socklen_t. On HP-UX,
> the socket calls take socklen_t only if _XOPEN_SOURCE_EXTENDED is defined.

What kind of pointers do these functions want when that define isn't set
(which I guess it isn't when we build "normally")? The configure script tries
to detect if there is a socklen_t typedef, and if not it defines one, but I
figure this isn't enough for you here.

> There are some others in url.c with parm5 of calls to Curl_write and
> Curl_read that are not (?) XOPEN things:
>
> cc: "url.c", line 1441: warning 604: Pointers are not
> assignment-compatible.^M
> cc: "url.c", line 1441: warning 563: Argument #5 is not the correct
> type.^M

Not the correct type? Curl_write() has a prototype saying it wants a ssize_t
pointer in parameter 5. The function too. And, in url.c line 1441 the
'&written' argument very much looks like a ssize_t pointer to me.

Do you understand what it wants?

> there is a macro redclaration issue in arpa_telnet.h
>
> cc -DHAVE_CONFIG_H -I../include -I../lib -I../lib -g -c telnet.c
> -Wp,-M.deps/tel
> net.TPlo +Z -DPIC -o .libs/telnet.lo^M
> cpp: "arpa_telnet.h", line 67: warning 2001: Redefinition of macro SE.^M

I went over the telnet code and prefixed all those defines we use there, to
prevent warnings like this.

> cc: "telnet.c", line 451: warning 562: Redeclaration of
> "set_local_option" with a different storage class specifier:
> "set_local_option" will have internal linkage.^M

Nice catch. Fixed now.

> Some additional _XOPEN_SOURCE_EXTENDED warnings from connect.c:
>
> cc: "connect.c", line 265: warning 604: Pointers are not
> assignment-compatible.^
> cc: "connect.c", line 351: warning 604: Pointers are not
> assignment-compatible.^

Yes, these are more of those socklen_t pointer things.

> some warnings in lib503.c:

[snip]

> the file includes test.h, but I'm not sure if it ends-up inlucding
> <sys/time.h> to get the select protos.
>
> the same thing for lib504

Correct. The lib*.c files are build for the test suite, and they did not
include the proper header files. I've made some fixes for this now.

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en