The end of curl (in phobos)

Johannes Pfau via Digitalmars-d digitalmars-d at puremagic.com
Fri May 13 00:05:02 PDT 2016


Am Sun, 8 May 2016 11:33:07 +0300
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> On 5/8/16 11:05 AM, Jonathan M Davis via Digitalmars-d wrote:
> > On Sunday, May 08, 2016 02:44:48 Adam D. Ruppe via Digitalmars-d
> > wrote:  
> >> On Saturday, 7 May 2016 at 20:50:53 UTC, Jonas Drewsen wrote:  
> >>> But std.net.curl supports not just HTTP but also FTP etc. so i
> >>> guess that won't suffice.  
> >>
> >> We can always implement ftp too, it isn't that complicated of a
> >> protocol.
> >>
> >> Though, I suspect its users are a tiny minority and they might
> >> not mind depending on a separate curl package.  
> >
> > An alternative would be to move std.net.curl into a dub package.  
> 
> That would still be a breaking change, is that correct?
> 
> I'm unclear on what the reasons are for removing libcurl so I'd love
> to see them stated clearly. Walter's argumentation was vague - code
> that we don't control etc. There have been past reports of issues
> with libcurl on windows, have those not been permanently solved?
> 
> I even see a plus: dealing with libcurl is a good exercise in eating
> our dogfood regarding "interfacing with C libraries is trivial"
> stance. Having to deal with it is a reflection of what other projects
> have to do on an ongoing basis.
> 
> 
> Andrei
> 

The curl problems are more or less solved now, but it has caused
quite some trouble:

As long as we were statically linking curl:
 * We can't use curl when producing cross compilers for GDC as the
   minimal builds used by crosstool do not include curl. They do not
   even include zlib, we're just lucky that zlib is in GCC and we
   compile it statically into druntime. OTOH I'm not sure if we can get
   conflicts between our statically compiled zlib and libraries which
   link against zlib.
 * For static libraries, we don't need curl at link time, but for
   dynamic libraries we do need it.
 * There was the library versioning issue which made DMD builds
   unusable on some distributions.
 * http://bugzilla.gdcproject.org/show_bug.cgi?id=202 Even programs not
   using libcurl will sometimes require linking curl (This is because
   common templates such as std.conv.to might be instatiated in curl,
   so curl.o is pulled in, which depends on libcurl)
 * Library order when linking is important nowadays, so you need a way
   to specify -lcurl in the correct location relative to -lphobos

Still open issues:
 * Even when dynamically loading curl, it introduces a new dependency:
   libdl for dynamic loading. This is not an issue for shared
   libraries, but the list of libraries which need to be hard coded when
   linking a static libphobos is already quite long:
   -lc -lrt -lm -ldl -lz -lstdc++ -luuid -lws2_32
   In fact GDC doesn't link some of these yet and Iain doesn't want to
   add more special cases to our linking code
(https://github.com/D-Programming-GDC/GDC/pull/182
https://github.com/D-Programming-GDC/GDC/pull/181).


Additionally the complete API, integration with D features and
performance is not really up to phobos standards. This is because of
libcurl API limitations though, so there's nothing we can do about it.
As long as we don't have a D replacement though, it's still the best
HTTP client available...


More information about the Digitalmars-d mailing list