torsdagen den 3 januari 2013 11.50.02 skrev Daniel Stenberg:
> On Thu, 3 Jan 2013, Jens Staal wrote:
> > I just wanted to report that the latest curl pretty much built "out of the
> > box" on Plan9/APE (ANSI-POSIX-ENVIRONMENT).
>
> Ah, lovely. Thanks for keeping up your tests and reporting back. I truly
> want curl and libcurl to work on current platforms, including Plan 9.
>
> > - change configure to not use unsupported stuff like "mv -f", "cp -r" and
> > "ls -di"
>
> All of these are entered by the autotools themselves. I'm afraid that
> pushing for such a drastic change upstream there will face quite a
> resistance. What's the motivation behind _not_ supporting them?
>
> They are mention in standards documents at least:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html
> http://pubs.opengroup.org/onlinepubs/009696799/utilities/cp.html
> http://pubs.opengroup.org/onlinepubs/009695399/utilities/ls.html
>
> Of course, I'm not using the latest and the greatest autotools versions when
> I build the release tarballs so there might be improvements made later.
> Although I get the sense these are not details changed recently!

This is rather APE not keeping up with POSIX. The utilities in APE can not do
those things, and follow a much older standard. What I did here was basically
just give a short overview of what I had to do to make the build - not a
proposal for changes upstream.

fixing the configure is pretty easy with sed after all :)
(and could probably be delegated to a "build instructions" file, or possibly a
script that first trims configure and then runs it)

>
> > - change config.sub to include -plan9*
>
> The latest official config.sub seems to live here:
>
> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;h
> b=HEAD
>
> ... and it has no plan9 mentions in it. If you have such improvements, have
> you tried to get them included into that file

no I have not tried that. I probably should..

>
> > - run configure with "kitchen sink approach" - activate every conditional
> > to expose all functionality from the APE libraries
>
> Sorry, I don't understand this sentence. What are you suggesting we should
> do? What is this "kitchen sink approach" you speak of?

Basically what I meant is that I run configure with the CFLAGS environment
variable full of stuff like -D_POSIX_SOURCE -D_SUSV2_SOURCE -D_BSD_EXTENSION -
D_REENTRANT_SOURCE etc... If I don't do that the configure script does not
pick up the availability of some features hidden behind those conditionals.

not really anything to be considered upstream, rather probably something that
need to be put into some sort of "how to build on Plan9" instructions.

>
> > - a custom lib/config-plan9.h with a few (re-)definitions
>
> Hm, we don't do config-[OS].h files for systems that can run the configure
> file as we use those files as the outputs from a would-have-run configure.
> If you need plan9-stuff in a header file we should check for it in the
> configure file and then use #ifdef HAVE_BLABBLA etc in the regular header
> files like setup.h or setup_once.h.

OK good to know. Currently I put a few things in a config-plan9.h that
includes curl_config.h

http://code.google.com/p/ports2plan9/source/browse/KTH/curl/lib/config-plan9.h

>
> > - edited lib/select.h to not be inactivated
>
> Please clarify.
>

I needed the stuff available in lib/select.h but the
#ifndef __SELECT_H hid the information in this header (possibly because of the
system header).
I basically just renamed that #ifndef

...probably also not something desirable for upstream.

> > - The existing old openssl port does not seem to contain everything needed
> > for curl - seems to block the use of libssh2 and libmetalink too.
>
> How old is that? libcurl should be possible to build and use with OpenSSL
> 0.9.6 unless we broke something recently. People probably don't use such old
> OpenSSL versions with new libcurl versions very often...

it should be 0.9.8 so newer than that, but I do not know exactly how it was
built. I need to look into this probably.

>
> > - will any of the other ssl alternatives work to enable libssh2 and/or
> > libmetalink? Especially axtls looks interesting.
>
> libssh2 requires OpenSSL or gcrypt. I don't know what libmetalink can be
> told to use.

ok thanks. Does cyassl with openssl emulation work?

>
> > - A weird thing when compiling with c-ares support: curl binary consumes
> > all CPU power in my VM and hangs like that (even when doing something
> > simple like "curl -V"). This could be an error in the c-ares port but it
> > seems to be curl- specific since the binaries built against c-ares in the
> > c-ares package (acountry, ahost, adig) seem to work as they should.
>
> Sounds weird and would need some deeper digging I guess!

Indeed

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-01-03