On Mon, 4 Dec 2000, Rich Gray wrote:

First, thanks for doing this. It is a great piece of feedback!

> Unfortunately, I don't have time to persue these issues and will continue
> to use 6.5.2 for an FTP application.

It feels as if we haven't done much progress when the 6.5.2 is still the most
portable version of curl.

I have been planning, and this surely makes the neeed obvious, to start
working with people to do automatic builds and tests on regular intervals. If
we would get enough people to suck out the CVS contents, build curl and run
the test suite we would much faster realize when we (I) break something. We
would of course need to do this on a series of platforms, including a few
exotic ones. I figure we could write a script (system) that could be easily
run by anyone that would do the whole operation and generate a summary
output.

Volounteers in this area are welcome!

> **** NCR MP-RAS i486-ncr-sysv4.3.03
>
> Seems to compile, but:
>
> UX:ld: WARNING: /usr/lib/libnsl.so: warning: attempted multiple inclusion of
> file
> UX:ld: WARNING: /usr/lib/libsocket.so: warning: attempted multiple inclusion
> of file
> dynamic linker : lt-curl : error opening libcurl.so.1^M
> Killed
>
> Perhaps this yet another variation of troubles due to needing both libnsl
> & libsocket.

Yes, it seems as if it could be something like that. It would be interesting
to see the whole ld command line used there.

> If so, SCO 5 should have failed too, but it did not get to link phase.
> I'm wondering where the ^M came from...

I'm curious as well.

> Do I need to force curl to static link??

You shouldn't need to. libtool figures out those things itself.

> ***** SCO 5 i686-pc-sco3.2v5.0.5
>
> cc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -I../include -g -belf -c url.c
> -Kpic -
> DPIC -o .libs/url.lo
> UX:acomp: ERROR: "./getpass.h", line 6: identifier redeclared: getpass_r

I noticed the problem was the third argument in getpass.h that the mismatch
with the SCO's internal getpass_r() function. SCO is the only system I'm
aware of that has a getpass_r(). I corrected this.

> UX:acomp: WARNING: "url.c", line 1351: argument is incompatible with
> prototype: arg #3

That's getsockname() which has a problematic third argument as different
systems have different types. size_t * and socklen_t * are common, but curl
typecasts this to int *. Although the warning is harmless.

> ***** Data General m88k-dg-dgux5.4R3.00
> checking if gcc supports -c -o file.o... yes
> ./ltconfig[851]: ..: not found

That's really weird. The line 851 only does a "cd ..".

> UX:rmdir: ERROR: conftest: Directory does not exist

Yes, since it couldn't "cd .." it can't find any 'conftest' directory. I
suspect that everything beyond that point may be because of the cd .. that
doesn't work.

> ***** HP-UX hppa1.1-hp-hpux9.05
>
> rc -I../include -Aa -DA1.0 -D _HPUX_SOURCE -c url.c
> cc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -I../include -Aa -DA1.0 -D
> _HPUX_SOURCE
> -c url.c
> cpp: "", line 0: warning 2003: Illegal argument to '-D' option.
> cc: "url.c", line 726: error 1588: "SA_RESTART" undefined.
> cc: "url.c", line 726: error 1559: Complement operator takes integral
> operand.

This is the sigaction stuff. It appars it has sigaction, although not the
SA_RESTART define.

I found an interesting article about Sun => HPUX porting at
ftp://ftp.interworks.org/pub/comp.hp/porting_info/sun_hpux_port_ascii_0295
and it mentions:

 "SunOS's sigaction() automatically restarts system calls. The default
 behavior on HP-UX is to not restart."

So, we shouldn't need to unmask the SA_RESTART bit when using HPUX. The
problem would possibly be to properly detect HPUX...

> (It complains about the -D on all compiles, 6.5.2 did too...)

How did that -D get there? It is obviously a space too much...

> ***** IBM AIX 4.3 powerpc-ibm-aix4.3.2.0
>
> compiled and executed, but:
>
> ld: 0711-224 WARNING: Duplicate symbol: p_xargc
> ld: 0711-224 WARNING: Duplicate symbol: p_xargv
> ld: 0711-224 WARNING: Duplicate symbol: p_xrcfg
> ld: 0711-224 WARNING: Duplicate symbol: p_xrc
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
> information.

Yes, this has been with us all the time. So far nobody has been able to get
it fixed.

-- 
  Daniel Stenberg -- curl project maintainer -- http://curl.haxx.se/