On Tuesday, 26 November 2013 at 20:02:29 UTC, Andrei Alexandrescu wrote:
> On 11/26/13 11:56 AM, Brad Anderson wrote:
>> On Tuesday, 26 November 2013 at 19:27:07 UTC, Andrei Alexandrescu wrote:
>>> 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
>>>
>>
>> 5. std.net.curl actually existed for several releases of dmd before I
>> went to use it one day and got linker errors and decided to fix it with
>> the installer change.
>
> Awesome. So can we assume https://github.com/D-Programming-Language/installer/pull/27 takes care of Windows for good?

It still needs one of the guys that can upload to the downloads page to upload the new binary but yeah, it's more or less ready for all scenarios now.

>
> Thanks for your work!!! I'll make sure I'll get a word of thanks to @broccolis as well.
>

Will do.

>>> 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.
>>
>> Walter actually already did that and the author of libcurl said
>> redistributing it was fine.
>>
>> Here's an old thread discussing the licensing:
>> http://forum.dlang.org/post/wgnsetqkzbzgulccphvu@forum.dlang.org
>
> Terrific, thanks.
>
>
> Andrei

On 11/26/13 11:57 AM, Dicebot wrote:
> On Tuesday, 26 November 2013 at 19:29:02 UTC, Andrei Alexandrescu wrote:
>>> 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
>
> It is not that simple. Well, I remember you taking part in
> https://d.puremagic.com/issues/show_bug.cgi?id=10710 so you should be
> aware of it. It is not about version number of curl but about transitive
> dependency - openssl vs gnutls.
>
> We can say "you must have this version of libcurl built with this flags"
> but it is not much different from saying "use Debian-likes or get out".

What flags are we requiring for use with std.net.curl? Are those depending on what specific calls are being used (e.g. using https etc)? We could document that stuff. All in all it doesn't seem unreasonable to me to require certain specifics for using std.net.curl.

Andrei

On 2013-11-26 20:00, Andrei Alexandrescu wrote:

> So what is the classic recommended solution for such cases? We can't be
> the first people who are having this issue on Unix.

As many have mentioned before. Everything (in this case Phobos) should be built on the same platform as it is shipping. So we needed specific releases for each Linux distribution we want to support.

> 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.

On Linux the problem is that Phobos is built on a Debian based system where libcurl has symbol names not present in any other libcurl built for other distributions.

-- 
/Jacob Carlborg

On 11/26/13 12:06 PM, Jacob Carlborg wrote:
> On 2013-11-26 20:00, Andrei Alexandrescu wrote:
>
>> So what is the classic recommended solution for such cases? We can't be
>> the first people who are having this issue on Unix.
>
> As many have mentioned before. Everything (in this case Phobos) should
> be built on the same platform as it is shipping. So we needed specific
> releases for each Linux distribution we want to support.

OK, thanks. That seems like something approachable from our end. Is this a common approach among other language distributions, e.g. python, ruby, go, rust etc. etc? What is a list of platforms we need to support?

>> 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.
>
> On Linux the problem is that Phobos is built on a Debian based system
> where libcurl has symbol names not present in any other libcurl built
> for other distributions.

I see. So we need more OSs in as many virtual machines. We need to start with a list. Looks like something we could dump on the build czar. Andrew, are you there? :o)


Andrei

On 2013-11-26 21:10, Andrei Alexandrescu wrote:

> OK, thanks. That seems like something approachable from our end. Is this
> a common approach among other language distributions, e.g. python, ruby,
> go, rust etc. etc? What is a list of platforms we need to support?

Yes, that's always the preferred choice to use dist specific packages if available. Python and Ruby are available the system package manager in all distributions, don't know about Go an Rust.

> I see. So we need more OSs in as many virtual machines. We need to start
> with a list. Looks like something we could dump on the build czar.
> Andrew, are you there? :o)

Yes, that's what we need. I think we can cover most of the distributions with a Fedora based and a Debian based system.

-- 
/Jacob Carlborg

On 2013-11-26 21:04, Andrei Alexandrescu wrote:

> What flags are we requiring for use with std.net.curl? Are those
> depending on what specific calls are being used (e.g. using https etc)?
> We could document that stuff. All in all it doesn't seem unreasonable to
> me to require certain specifics for using std.net.curl.

Preferably std.net.curl should work with any variant of libcurl. Regardless if it's using OpenSSL or GNU TLS.

-- 
/Jacob Carlborg

On 2013-11-26 18:58, Iain Buclaw wrote:

> Especially when you look at the "competitors"
>
> http://curl.haxx.se/libcurl/competitors.html
>
>
> The checkboxes that would need to be ticked for me:
>
> 1. Does it have any third party dependencies?  Preferably no.
> 2. Can it be built into libphobos easily - see: zlib in phobos, or
> sqllite3.amalgamation.c which I thought *was* in phobos at some
> point... maybe not?

What's nice about libcurl, if we're not building or own solution, is that is available on basically all platforms and comes pre-installed on many.

-- 
/Jacob Carlborg

On Tuesday, 26 November 2013 at 20:10:19 UTC, Andrei Alexandrescu wrote:
>> As many have mentioned before. Everything (in this case Phobos) should
>> be built on the same platform as it is shipping. So we needed specific
>> releases for each Linux distribution we want to support.
>
> OK, thanks. That seems like something approachable from our end. Is this a common approach among other language distributions, e.g. python, ruby, go, rust etc. etc? What is a list of platforms we need to support?

I have already linked Python example - they provide only source tarballs for Linux, no binary distribution. It is assumed that Linux way of getting stuff is either using native package manager or compiling manually.

One can try to prepare archives for every distro separately but it hardly scales. First, you need to decide how many you would like to support (few? dozens? hundreds?) Second, those will always be inferior to packages supplied from native repository (assuming active maintainer) - it is a pretty time-consuming job to do this right and no build czar can do it for dozens of platforms at once.

I really think providing just source + single additional .deb package as an example is the best way to go.

26-Nov-2013 23:40, Andrei Alexandrescu пишет:
> On 11/26/13 11:23 AM, Dmitry Olshansky wrote:
>> 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.
>
> I don't think that's the whole set. Don't forget the forum participation
> is a very small fraction of people who actually use D out there. So
> there are a bunch of people who don't use curl and aren't hurt, and
> presumably quite a few people who do use std.net.curl without troubles
> and don't know we plan to pull the plug on it.

Yeah, there is a big part of people how don't use it and are just fine. And some folks that may as well use it (with a custom link step on Linux) and be OK. I don't think we should deprecate or remove std.net.curl unless a strong alternative comes along.

It seems that radically inclined folks want to get rid of it now, presumably for immediate maintenance benefits. The thing is, the best we can pull off with deprecation is no less then a year. Then there is basically no point in it, we just as well bite the bullet and fix what there is to fix in the said 1 year time frame.

>> 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
>
> Interesting. Never knew of the pattern syntax in there.

Me neither, must be some google-foo of mine.

>> 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).
>
> Is that file needed if one does NOT use std.net.curl? Would it be a bear
> for us to distributed that particular file?

To build phobos - most likely yes. I think we must distribute it, no matter how much of LICENSE notices it takes.

>> 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.
>
> Which downloads page? Ours or others'?

http://dlang.org/download.html


>> All in all, it feels as if somebody actually wanted to sabotage the
>> thing, he could score an A+ job as it stands already.
>
> What I see above is it's in our power to fix
> https://d.puremagic.com/issues/show_bug.cgi?id=7044 and that would
> benefit not only curl but other libs as well.

Would be freaking amazing. Walter seemed surprisingly adamant on not fixing this (there was a pull I believe), I really have no idea what his the reservations are.



-- 
Dmitry Olshansky

On Tuesday, 26 November 2013 at 19:13:40 UTC, 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.

Isn't that like -lm for C programs? Doesn't seem big to me.