adding a protocol to (lib)curl?
Hi all I just got a (potentially silly) idea about adding support for the 9P2000 file transfer protocol / file-system [0] along with http, ftp, gopher etc to get curl (the binary) to also act as a 9P client. The strategy would probably involve either linking to libixp[1,2] or to "bake in" libixp into libcurl (similar to the other protocols, the preferred strategy). As "study examples", I have the 9P client in libixp and curl code for the other protocols. Some questions before I even try/start looking: - Would the strategy I thought out even work? Any pro tips? - how "invasive" would adding a protocol be in curl? Since I am a total amateur, a too complex integration process would probably be above my competence level. - In the (unlikely) event that I actually succeeded, would upstream be interested? I am aware that it would most likely be limited to "fringe use cases", but there are uses for the 9P protocol, especially in communications between virtual machines and hosts. [0] http://en.wikipedia.org/wiki/9P [1] http://libs.suckless.org/libixp (old release tarball) [2] http://code.google.com/p/libixp/ (current hg repo) Ps. If anyone else feels the calling to do this instead of me, feel free. It is highly unlikely that I would suceed anyway. Ds. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: latest curl on Plan9
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
latest curl on Plan9
I just wanted to report that the latest curl pretty much built "out of the box" on Plan9/APE (ANSI-POSIX-ENVIRONMENT). Small porting digest: - change configure to not use unsupported stuff like "mv -f", "cp -r" and "ls -di" - change config.sub to include -plan9* - run configure with "kitchen sink approach" - activate every conditional to expose all functionality from the APE libraries - a custom lib/config-plan9.h with a few (re-)definitions - edited lib/select.h to not be inactivated Libcurl + curl binary could be built with zlib support - the compiler used is the posix c compiler (pcc) front end of the native Plan9 compiler (for i386: 8c) - I did this by making mkfiles, but one could probably have used the Makefiles and "cc" under APE as compiler too. Issues: - The existing old openssl port does not seem to contain everything needed for curl - seems to block the use of libssh2 and libmetalink too. - newer openssl has a lot of annoying stuff going for it though: first of all, the source archive contains symlinks (which are not supported on Plan9) and Configure depends on Perl. - will any of the other ssl alternatives work to enable libssh2 and/or libmetalink? Especially axtls looks interesting. - I have libtomcrypt built, but I could not see any reports on this being used as an alternative -lcrypto. - 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. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Static libcurl with static libcurl dependencies
> That's not something the libcurl configure scripts support in the general > case. However, it should work if all the dependent libaries are available > *only* as static libraries, and all their pkg-config files are correctly > configured for those static libraries. And, of course, it should also > work in the case where all the features dependent on external libraries > are turned off with --disable-* and the -static flag is passed to the linker > with LDFLAGS. > Just FYI, the Plan9 port is completely statically linked since there is no such thing as dynamic libraries on that OS. On the other hand, it is a very early port that could not make use of the standard configure scripts with lots of ugly stuff in it still --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: initial attemt at a port of cURL to Plan9
> > Hi, > > This just sounds like fun :-) > > Did you build against an SSL implementation, if yes, which one did you try? > I haven't looked at the package yet. > > > Oscar > :) I use steve's mkmk rc script [1] to generate mkfiles so the standard configure/make stuff is sort of circumvented. I have also attempted to write up a small how-to with handy tips-and-tricks for porting stuff to Plan9/APE [2]. As can be seen in lib/README.Plan9, I have attempted to link against an old ssl port (0.9.8g) that can be found in fgb's contrib http://plan9.bell-labs.com/wiki/plan9/Contrib_index/index.html Also libcrypto.a, libz.a, libbz2.a are attempted to be linked. running curl --version under ape/psh gives the following info: curl 7.23.1 (i386-unknown-plan9) libcurl/7.23.1 zlib/1.2.2 Protocols: dict file ftp gopher http imap pop3 rtsp smtp telnet tftp Features: Largefile libz so in that readout I do not see that ssl would have been sucessfully compiled in... [1] http://man.cat-v.org/plan_9_contrib/1/mkmk [2] http://code.google.com/p/ports2plan9/wiki/PortingStuffToPlan9 --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
