On 11/26/13 6:46 AM, Wyatt wrote:
> On Tuesday, 26 November 2013 at 02:22:50 UTC, Jordi Sayol wrote:
>>
>> On Debian testing (64-bit):
>>
>> $ ldd /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0
>>     linux-vdso.so.1 (0x00007fff36519000)
> /snip
>
> Evidently, Debian builds curl with --enable-everything-under-the-sun.
> Here's mine, with just ssl (via OpenSSL) support:
>
> wyatt@Yue ~ $ ldd /usr/lib/libcurl.so
>          linux-vdso.so.1 (0x00007fff7f7ff000)
>          libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007ff835865000)
>          libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0
> (0x00007ff83547c000)
>          libz.so.1 => /lib64/libz.so.1 (0x00007ff835265000)
>          librt.so.1 => /lib64/librt.so.1 (0x00007ff83505c000)
>          libc.so.6 => /lib64/libc.so.6 (0x00007ff834cb2000)
>          libdl.so.2 => /lib64/libdl.so.2 (0x00007ff834aad000)
>          libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff834890000)
>          /lib64/ld-linux-x86-64.so.2 (0x00007ff835d73000)
>
> I'll be generous and allow that zlib might somehow be a sticking point,
> but there's really nothing unexpected here, IMO.

Great. All this is fine - whatever libcurl is installed will be used. Right?


Andrei

On 11/26/13 7:48 AM, Dejan Lekic wrote:
> On Monday, 25 November 2013 at 07:38:38 UTC, Jordi Sayol wrote:
>> As Jonathan M Davis said:
>> ---
>> Several of the main devs (including Walter) have stated that having
>> std.net.curl on Phobos was a mistake given all of the problems that
>> we've had with it on Windows and Linux as well, and at least some of
>> them have expressed a desire for it to be removed. I expect that
>> there's a good chance that it can and will be removed from Phobos if
>> brought up for discussion.
>>
>> Certainly, I think that it's clear that we will not add any further
>> external dependencies like curl, because curl has proven to be a big
>> problem. It's very desirable to have bindings and wrappers for C
>> libraries - but putting them in the standard library when it's not
>> guaranteed that the appropriate library is on the system by default
>> has proven to be too problematic, so they should be left to external
>> projects.
>> ---
>>
>> "std.net.curl" can also be moved from Phobos to Deimos.
>> Deimos can be rethink, i.e. new build master can add a make building
>> script on Deimos in order to compile all projects included on it,
>> generating "libdeimos.a" and "libdeimos.so", documentation, etc.
>
> +1
> It should have been removed from Phobos long ago.

Why?

Andrei

On 26 November 2013 19:07, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 11/26/13 7:48 AM, Dejan Lekic wrote:
>>
>> On Monday, 25 November 2013 at 07:38:38 UTC, Jordi Sayol wrote:
>>>
>>> As Jonathan M Davis said:
>>> ---
>>> Several of the main devs (including Walter) have stated that having std.net.curl on Phobos was a mistake given all of the problems that we've had with it on Windows and Linux as well, and at least some of them have expressed a desire for it to be removed. I expect that there's a good chance that it can and will be removed from Phobos if brought up for discussion.
>>>
>>> Certainly, I think that it's clear that we will not add any further external dependencies like curl, because curl has proven to be a big problem. It's very desirable to have bindings and wrappers for C libraries - but putting them in the standard library when it's not guaranteed that the appropriate library is on the system by default has proven to be too problematic, so they should be left to external projects.
>>> ---
>>>
>>> "std.net.curl" can also be moved from Phobos to Deimos.
>>> Deimos can be rethink, i.e. new build master can add a make building
>>> script on Deimos in order to compile all projects included on it,
>>> generating "libdeimos.a" and "libdeimos.so", documentation, etc.
>>
>>
>> +1
>> It should have been removed from Phobos long ago.
>
>
> Why?
>
> Andrei

The problem I think is a distribution one.  Not a compiler/library problem.

Remembering to include '-lcurl' when importing std.net.curl is perhaps one urk.  But this will be a no longer a problem if libphobos is built shared.

On Tuesday, 26 November 2013 at 19:00:35 UTC, Andrei Alexandrescu wrote:
> On 11/25/13 4:36 PM, Jonathan M Davis wrote:
>> The number one problem on Windows is the fact that libcurl does not come with
>> Windows and that you have to get a version of it build which is compatible
>> with dmd has proven to be a huge hurdle for Windows developers.
>
> Why is "compatible with dmd" an issue? Do we make it any harder for libcurl than other clients? Could you please explain?
>

To use 32-bit curl you need to generate an OMF import library from the libcurl DLL. It's not terribly hard. I did it originally for when I added downloading of libcurl to the Windows installer. It's not at all obvious to users that they need to distribute libcurl.dll et al when they distribute their application but that's a documentation issue.

If I remember correctly Walter didn't want to distribute in the dmd zip anything that wasn't boost licensed which is why curl on Windows comes as a separate download. zlib is a notable exception but I seem to recall Walter regretted including zlib.

I can't remember off the top of my head if libcurl's license allows it to be statically linked with a boost licensed library but that would certainly simplify things for end users (but complicate the building of phobos a bit).

On Tuesday, 26 November 2013 at 19:06:26 UTC, Andrei Alexandrescu wrote:
> But my understanding is that the dependency is conditional, i.e. you have no dependency on libcurl unless you attempt to use std.net.curl. Which strikes me as entirely reasonable. No?

There is no such thing as _The_ curl library. Different distros may have versions with incompatible symbol versioning installed - this is the very issue with Fedora which was actively discussed in bugzilla.

So yes, dependency is conditional but on some distros it doesn't work _at all_, even if libcurl is installed.

There are only 2 possible ways out of it - distributing only source tarballs or creating distro-specific distribution archives / packages. Nothing else is guaranteed to work. And latter is rarely a good idea.

On 11/26/13 11:13 AM, Iain Buclaw wrote:
> Remembering to include '-lcurl' when importing std.net.curl is perhaps
> one urk.  But this will be a no longer a problem if libphobos is built
> shared.

Interesting. Can we supply a pragma that automates the flag thingie?

Andrei

26-Nov-2013 23:00, Andrei Alexandrescu пишет:
>> There may be other problems, but I think that those are the two bigs
>> ones, and
>> they've come up several times (particularly the issues with libcurl and
>> Windows).
>
> I've asked the question "what exactly is the problem" several times and
> you came closest to answering it, but a bunch of stuff is still unclear
> to me.

I thought I'd chime in on this.

I find that if we actually worked on getting curl integrated better it may just as well be an all right network client lib.

For the moment it looks as if half people are pissed off because of the work they would need to do on it (workaround, shipping, maintenance, etc.), and the other half (using it) are having usability problems on all fronts.

Now to my limited experience with it.
When I work with it on Linux I have to always jump through hoops because of:
https://d.puremagic.com/issues/show_bug.cgi?id=7044

Because of that in the end I tend to dodge it completely and roll some shell script scaffolding that calls `curl`, as in the cmd-line client.

See some hilarious things I had to do to link it properly:
https://github.com/blackwhale/tools/blob/master/posix.mak#L35

Now if that doesn't set off the alarms. Win32/64 curl libraries are NOT shipped with dmd zip or whatever. The better thing is that last time I checked there is no proper which means that for Win32 one had to get the rare OMF object file format (a custom compilation no less).

You may or may not find them at the VARY BOTTOM of downloads page, and figure it out how to fit them, what flags to use etc. Last but not least it's Win32 only. No links for Win64.

All in all, it feels as if somebody actually wanted to sabotage the thing, he could score an A+ job as it stands already.

P.S. And before I forgot - there are specifics problems with curl Linux distros that are not Debian derived and with shared phobos in particular, but there are fokls that must known this side of coin better then I.
-- 
Dmitry Olshansky

On 26 November 2013 19:21, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 11/26/13 11:13 AM, Iain Buclaw wrote:
>>
>> Remembering to include '-lcurl' when importing std.net.curl is perhaps one urk.  But this will be a no longer a problem if libphobos is built shared.
>
>
> Interesting. Can we supply a pragma that automates the flag thingie?
>


If pragma(lib) worked for me. (not talking dmd here :-)

On 11/26/13 11:13 AM, Brad Anderson wrote:
> To use 32-bit curl you need to generate an OMF import library from the
> libcurl DLL. It's not terribly hard. I did it originally for when I
> added downloading of libcurl to the Windows installer.

When is the OMF library needed?

1. While building dmd

2. While building druntime

3. While building phobos

4. While building client code that does NOT use std.net.curl

5. While building client code that DOES use std.net curl

> It's not at all
> obvious to users that they need to distribute libcurl.dll et al when
> they distribute their application but that's a documentation issue.

Or they could kick the can down the road by requiring their customers to have it.

> If I remember correctly Walter didn't want to distribute in the dmd zip
> anything that wasn't boost licensed which is why curl on Windows comes
> as a separate download. zlib is a notable exception but I seem to recall
> Walter regretted including zlib.

On the other hand we've hardly heard one peep from anyone in literally years that their zip code has trouble building.

We can ask the libcurl author if it comes down to redistributing a libcurl binary. But we want to make sure this is the solution of choice.

> I can't remember off the top of my head if libcurl's license allows it
> to be statically linked with a boost licensed library but that would
> certainly simplify things for end users (but complicate the building of
> phobos a bit).

My reading of http://curl.haxx.se/docs/copyright.html is that the author does his best to open up his library.


Andrei

On 11/26/13 11:14 AM, Dicebot wrote:
> On Tuesday, 26 November 2013 at 19:06:26 UTC, Andrei Alexandrescu wrote:
>> But my understanding is that the dependency is conditional, i.e. you
>> have no dependency on libcurl unless you attempt to use std.net.curl.
>> Which strikes me as entirely reasonable. No?
>
> There is no such thing as _The_ curl library. Different distros may have
> versions with incompatible symbol versioning installed - this is the
> very issue with Fedora which was actively discussed in bugzilla.

But can't we say "to use std.net.curl with dmd 2.xxx you must have libcurl 7.10 or higher"?

Andrei