On Friday, 24 April 2015 at 18:10:47 UTC, Ali Çehreli wrote:
> On 04/24/2015 10:26 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
>
>> You need to link against libcurl explicitly, it doesn't happen
>> automatically:
>>
>>     dmd -L-lcurl test.d
>
> Another option is to add it to the source:
>
> pragma(lib, "curl");
>
> Then it finds the library on the system and links with it.
>
> Ali

This works, and is actually done in phobos but for windows only.
I opened a PR: https://github.com/D-Programming-Language/phobos/pull/3223

Maybe there is a good reason for this system check, but I couldn't find one.

On 4/24/15 1:44 PM, Steven Schveighoffer wrote:
> On 4/24/15 1:37 PM, Iain Buclaw via Digitalmars-d wrote:
>
>>
>>
>> You need to explicitly link third party libraries.
>>
>
> You shouldn't need to explicitly link anything that comes out of phobos
> IMO.

Did some digging. This issue isn't as simple as I thought.

It's pretty obvious to me std.net.curl should never have been accepted into phobos.

https://issues.dlang.org/show_bug.cgi?id=12572
https://issues.dlang.org/show_bug.cgi?id=13324
https://github.com/D-Programming-Language/phobos/pull/3009
https://issues.dlang.org/show_bug.cgi?id=10710
https://issues.dlang.org/show_bug.cgi?id=7561

-Steve

On Friday, 24 April 2015 at 17:44:32 UTC, Steven Schveighoffer wrote:
> On 4/24/15 1:37 PM, Iain Buclaw via Digitalmars-d wrote:
>
>>
>>
>> You need to explicitly link third party libraries.
>>
>
> You shouldn't need to explicitly link anything that comes out of phobos IMO.
>
> -Steve

It doesn't come with Phobos and DMD can't possibly know how curl is installed on target system.

On 4/24/15 4:06 PM, Dicebot wrote:
> On Friday, 24 April 2015 at 17:44:32 UTC, Steven Schveighoffer wrote:
>> On 4/24/15 1:37 PM, Iain Buclaw via Digitalmars-d wrote:
>>
>>>
>>>
>>> You need to explicitly link third party libraries.
>>>
>>
>> You shouldn't need to explicitly link anything that comes out of
>> phobos IMO.
>>
> It doesn't come with Phobos and DMD can't possibly know how curl is
> installed on target system.

Then it shouldn't be in phobos.

If pragma(lib, "libcurl"); doesn't work normally, then we should remove std.net.curl, and put it in dub.

-Steve

On Friday, 24 April 2015 at 20:27:28 UTC, Steven Schveighoffer wrote:
> If pragma(lib, "libcurl"); doesn't work normally, then we should remove std.net.curl, and put it in dub.

It was a historical mistake, discussed many time over and over. Yes, it shouldn't be in Phobos. No, we can't remove it now that easily.

As for pragma(lib) - it can never work "normally". Linking 3d-party libraries is very platform-specific task that causes great deal of complexity in build systems. It can't be replaced by a single trivial compiler pragma. There is a reason nothing but Windows build of DMD supports it.

On 4/24/15 4:36 PM, Dicebot wrote:
> On Friday, 24 April 2015 at 20:27:28 UTC, Steven Schveighoffer wrote:
>> If pragma(lib, "libcurl"); doesn't work normally, then we should
>> remove std.net.curl, and put it in dub.
>
> It was a historical mistake, discussed many time over and over. Yes, it
> shouldn't be in Phobos. No, we can't remove it now that easily.

deprecated("Please use dub for curl");
module std.net.curl

// this will cause an error until you install the binding, then you can
// go through your imports and update them.
public import some.dub.project;

> As for pragma(lib) - it can never work "normally". Linking 3d-party
> libraries is very platform-specific task that causes great deal of
> complexity in build systems. It can't be replaced by a single trivial
> compiler pragma. There is a reason nothing but Windows build of DMD
> supports it.

You are right about not having pragma(lib anywhere but windows, but we do depend on 3rd party libs -- libc, libm, librt, etc. They are just always in the right places.

I'm not quite sure where libcurl would be except /usr/lib, and why -L-lcurl wouldn't work (and therefore pragma(lib ). Seems like all the issues are for people who custom-build or custom-install libcurl.

But I'm not really concerned about that. AFAIK, we have no other 3rd party dependencies like this, std.net.curl sticks out blatantly as something that was done in error, and we should correct it.

-Steve

On Friday, 24 April 2015 at 20:52:16 UTC, Steven Schveighoffer wrote:
> On 4/24/15 4:36 PM, Dicebot wrote:
>> On Friday, 24 April 2015 at 20:27:28 UTC, Steven Schveighoffer wrote:
>>> If pragma(lib, "libcurl"); doesn't work normally, then we should
>>> remove std.net.curl, and put it in dub.
>>
>> It was a historical mistake, discussed many time over and over. Yes, it
>> shouldn't be in Phobos. No, we can't remove it now that easily.
>
> deprecated("Please use dub for curl");
> module std.net.curl

Not really feasible until dub is part of standard distribution.

> // this will cause an error until you install the binding, then you can
> // go through your imports and update them.
> public import some.dub.project;
>
>> As for pragma(lib) - it can never work "normally". Linking 3d-party
>> libraries is very platform-specific task that causes great deal of
>> complexity in build systems. It can't be replaced by a single trivial
>> compiler pragma. There is a reason nothing but Windows build of DMD
>> supports it.
>
> You are right about not having pragma(lib anywhere but windows, but we do depend on 3rd party libs -- libc, libm, librt, etc. They are just always in the right places.

It isn't that simple. On Linux it uses gcc for linking making use of the fact those libraries are also needed for C applications and system-wide installation of GCC already knows it.

> I'm not quite sure where libcurl would be except /usr/lib, and why -L-lcurl wouldn't work (and therefore pragma(lib ). Seems like all the issues are for people who custom-build or custom-install libcurl.

Typical example is when in specific distro library name includes major version number in the static library name, i.e. libcurl4.a
Another case is multilib paths, those are not uniform either (I add -L-L/usr/lib32 to default dmd.conf for it to work)

In general the more obscure and less "established" library you want to link, the more complicated it is to do in cross-platform way. This is why `pragma(lib)` is design failure.

On Fri, 24 Apr 2015 16:52:16 -0400
Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 4/24/15 4:36 PM, Dicebot wrote:
> > On Friday, 24 April 2015 at 20:27:28 UTC, Steven Schveighoffer wrote:
> >> If pragma(lib, "libcurl"); doesn't work normally, then we should remove std.net.curl, and put it in dub.
> >
> > It was a historical mistake, discussed many time over and over. Yes, it shouldn't be in Phobos. No, we can't remove it now that easily.
> 
> deprecated("Please use dub for curl");
> module std.net.curl
> 
> // this will cause an error until you install the binding, then you can
> // go through your imports and update them.
> public import some.dub.project;
> 
> > As for pragma(lib) - it can never work "normally". Linking 3d-party libraries is very platform-specific task that causes great deal of complexity in build systems. It can't be replaced by a single trivial compiler pragma. There is a reason nothing but Windows build of DMD supports it.
> 
> You are right about not having pragma(lib anywhere but windows, but we do depend on 3rd party libs -- libc, libm, librt, etc. They are just always in the right places.
> 
> I'm not quite sure where libcurl would be except /usr/lib, and why -L-lcurl wouldn't work (and therefore pragma(lib ). Seems like all the issues are for people who custom-build or custom-install libcurl.

everywher with even diferent name

> 
> But I'm not really concerned about that. AFAIK, we have no other 3rd party dependencies like this, std.net.curl sticks out blatantly as something that was done in error, and we should correct it.

> -Steve

Yes, but how? We maybe can reimplement all funcionality :D, any takers?

On Friday, 24 April 2015 at 21:06:59 UTC, Dicebot wrote:
> On Friday, 24 April 2015 at 20:52:16 UTC, Steven Schveighoffer wrote:
>> On 4/24/15 4:36 PM, Dicebot wrote:
>>> On Friday, 24 April 2015 at 20:27:28 UTC, Steven Schveighoffer wrote:
>>>> If pragma(lib, "libcurl"); doesn't work normally, then we should
>>>> remove std.net.curl, and put it in dub.
>>>
>>> It was a historical mistake, discussed many time over and over. Yes, it
>>> shouldn't be in Phobos. No, we can't remove it now that easily.
>>
>> deprecated("Please use dub for curl");
>> module std.net.curl
>
> Not really feasible until dub is part of standard distribution.
>
>> // this will cause an error until you install the binding, then you can
>> // go through your imports and update them.
>> public import some.dub.project;
>>
>>> As for pragma(lib) - it can never work "normally". Linking 3d-party
>>> libraries is very platform-specific task that causes great deal of
>>> complexity in build systems. It can't be replaced by a single trivial
>>> compiler pragma. There is a reason nothing but Windows build of DMD
>>> supports it.
>>
>> You are right about not having pragma(lib anywhere but windows, but we do depend on 3rd party libs -- libc, libm, librt, etc. They are just always in the right places.
>
> It isn't that simple. On Linux it uses gcc for linking making use of the fact those libraries are also needed for C applications and system-wide installation of GCC already knows it.
>
>> I'm not quite sure where libcurl would be except /usr/lib, and why -L-lcurl wouldn't work (and therefore pragma(lib ). Seems like all the issues are for people who custom-build or custom-install libcurl.
>
> Typical example is when in specific distro library name includes major version number in the static library name, i.e. libcurl4.a
> Another case is multilib paths, those are not uniform either (I add -L-L/usr/lib32 to default dmd.conf for it to work)
>
> In general the more obscure and less "established" library you want to link, the more complicated it is to do in cross-platform way. This is why `pragma(lib)` is design failure.


Maybe D should ship its own version of libcurl. I mean, I can't
see a successful standard library without basic networking
features, and it seems that the only way to know where it is is to
ship it. Using the default C compiler to build it at install
wouldn't be worse than the gcc/pragma trick.

On Friday, 24 April 2015 at 21:42:43 UTC, Daniel Kozak wrote:
>
> On Fri, 24 Apr 2015 16:52:16 -0400
> Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> On 4/24/15 4:36 PM, Dicebot wrote:
>> > On Friday, 24 April 2015 at 20:27:28 UTC, Steven Schveighoffer wrote:
>> >> If pragma(lib, "libcurl"); doesn't work normally, then we should
>> >> remove std.net.curl, and put it in dub.
>> >
>> > It was a historical mistake, discussed many time over and over. Yes, it
>> > shouldn't be in Phobos. No, we can't remove it now that easily.
>> 
>> deprecated("Please use dub for curl");
>> module std.net.curl
>> 
>> // this will cause an error until you install the binding, then you can
>> // go through your imports and update them.
>> public import some.dub.project;
>> 
>> > As for pragma(lib) - it can never work "normally". Linking 3d-party
>> > libraries is very platform-specific task that causes great deal of
>> > complexity in build systems. It can't be replaced by a single trivial
>> > compiler pragma. There is a reason nothing but Windows build of DMD
>> > supports it.
>> 
>> You are right about not having pragma(lib anywhere but windows, but we do depend on 3rd party libs -- libc, libm, librt, etc. They are just always in the right places.
>> 
>> I'm not quite sure where libcurl would be except /usr/lib, and why -L-lcurl wouldn't work (and therefore pragma(lib ). Seems like all the issues are for people who custom-build or custom-install libcurl.
>
> everywher with even diferent name
>
>> 
>> But I'm not really concerned about that. AFAIK, we have no other 3rd party dependencies like this, std.net.curl sticks out blatantly as something that was done in error, and we should correct it.
>
>> -Steve
>
> Yes, but how? We maybe can reimplement all funcionality :D, any takers?

Reimplementing sure sounds like the best long-term way to go...
Maybe we don't need all libcurl features, we could provide a basic
set for 80% of use-cases and advanced users would use the
newly-non-standard libcurl binding.