www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A valid code that won't run?

reply "cym13" <cpicard openmailbox.org> writes:
I have here a little snippet that just won't run (many issues in 
here):

void main(string[] args) {
     import std.stdio, std.net.curl, std.algorithm;

     "http://rosettacode.org/wiki/Web_scraping"
          .byLine
          .filter!(q{ a.canFind("D") })
          .each!writeln;
}

Let's start with ldc:

$ ldc --version
LDC - the LLVM D compiler (0.15.1):
       based on DMD v2.066.1 and LLVM 3.5.1
         Default target: x86_64-unknown-linux-gnu
         Host CPU: corei7
       ...

$ ldc test.d
test.d(11): Error: no property 'each' for type 
'FilterResult!(unaryFun, SyncLineInputRange)'

Same with gdc:

$ gdc --version
gdc (GCC) 4.9.2
...

$ gdc test.d
test.d:11: error: no property 'each' for type 
'FilterResult!(unaryFun, SyncLineInputRange)'

I don't remember if std.algorithm.each existed in v2.066 but I 
find it hard to believe that it is that recent an addition to 
phobos.

Well, let's try DMD:

$ dmd --version
DMD64 D Compiler v2.067
...

$ dmd test.d
/usr/lib/libphobos2.a(curl.o): In function 
`_D3std3net4curl4HTTP21_sharedStaticCtor1500FZv':
(.text._D3std3net4curl4HTTP21_sharedStaticCtor1500FZv+0xf): 
undefined reference to `curl_version_info'
/usr/lib/libphobos2.a(curl.o): In function 
`_D3std3net4curl4Curl21_sharedStaticCtor1502FZv':
(.text._D3std3net4curl4Curl21_sharedStaticCtor1502FZv+0xf): 
undefined reference to `curl_global_init'
/usr/lib/libphobos2.a(curl.o): In function 
`_D3std3net4curl4Curl21_sharedStaticDtor1503FZv':
(.text._D3std3net4curl4Curl21_sharedStaticDtor1503FZv+0x5): 
undefined reference to `curl_global_cleanup'
/usr/lib/libphobos2.a(curl_c4c_192.o): In function 
`_D3std3net4curl4HTTP4Impl6__dtorMFZv':
(.text._D3std3net4curl4HTTP4Impl6__dtorMFZv+0x19): undefined 
reference to `curl_slist_free_all'
/usr/lib/libphobos2.a(curl_c6e_ea.o): In function 
`_D3std3net4curl3FTP4Impl6__dtorMFZv':
(.text._D3std3net4curl3FTP4Impl6__dtorMFZv+0x18): undefined 
reference to `curl_slist_free_all'
/usr/lib/libphobos2.a(curl_c6e_ea.o): In function 
`_D3std3net4curl3FTP3dupMFZS3std3net4curl3FTP':
(.text._D3std3net4curl3FTP3dupMFZS3std3net4curl3FTP+0xab): 
undefined reference to `curl_slist_append'
/usr/lib/libphobos2.a(curl_c6e_ea.o): In function 
`_D3std3net4curl3FTP13clearCommandsMFZv':
(.text._D3std3net4curl3FTP13clearCommandsMFZv+0x20): undefined 
reference to `curl_slist_free_all'
/usr/lib/libphobos2.a(curl_c6e_ea.o): In function 
`_D3std3net4curl3FTP10addCommandMFAxaZv':
(.text._D3std3net4curl3FTP10addCommandMFAxaZv+0x67): undefined 
reference to `curl_slist_append'
/usr/lib/libphobos2.a(curl_c73_432.o): In function 
`_D3std3net4curl4Curl10initializeMFZv':
(.text._D3std3net4curl4Curl10initializeMFZv+0x47): undefined 
reference to `curl_easy_init'
/usr/lib/libphobos2.a(curl_c74_149.o): In function 
`_D3std3net4curl4Curl3dupMFZS3std3net4curl4Curl':
(.text._D3std3net4curl4Curl3dupMFZS3std3net4curl4Curl+0x2b): 
undefined reference to `curl_easy_duphandle'
/usr/lib/libphobos2.a(curl_c78_37c.o): In function 
`_D3std3net4curl4Curl8shutdownMFZv':
(.text._D3std3net4curl4Curl8shutdownMFZv+0x1a): undefined 
reference to `curl_easy_cleanup'
/usr/lib/libphobos2.a(curl_c7a_14c.o): In function 
`_D3std3net4curl4Curl3setMFE3etc1c4curl10CurlOptionAxaZv':
(.text._D3std3net4curl4Curl3setMFE3etc1c4curl10CurlOptionAxaZv+0x5d): 
undefined reference to `curl_easy_setopt'
/usr/lib/libphobos2.a(curl_c7b_14c.o): In function 
`_D3std3net4curl4Curl3setMFE3etc1c4curl10CurlOptionlZv':
(.text._D3std3net4curl4Curl3setMFE3etc1c4curl10CurlOptionlZv+0x2e): 
undefined reference to `curl_easy_setopt'
/usr/lib/libphobos2.a(curl_c7c_14c.o): In function 
`_D3std3net4curl4Curl3setMFE3etc1c4curl10CurlOptionPvZv':
(.text._D3std3net4curl4Curl3setMFE3etc1c4curl10CurlOptionPvZv+0x2e): 
undefined reference to `curl_easy_setopt'
/usr/lib/libphobos2.a(curl_c7d_207.o): In function 
`_D3std3net4curl4Curl5clearMFE3etc1c4curl10CurlOptionZv':
(.text._D3std3net4curl4Curl5clearMFE3etc1c4curl10CurlOptionZv+0x29): 
undefined reference to `curl_easy_setopt'
/usr/lib/libphobos2.a(curl_c7e_67c.o): In function 
`_D3std3net4curl4Curl16clearIfSupportedMFE3etc1c4curl10CurlOptionZv':
(.text._D3std3net4curl4Curl16clearIfSupportedMFE3etc1c4curl1
CurlOptionZv+0x29): 
undefined reference to `curl_easy_setopt'
/usr/lib/libphobos2.a(curl_c7f_2fb.o): In function 
`_D3std3net4curl4Curl7performMFE3std8typecons41__T4FlagVAyaa12_7468726f774f6e4572726f72Z4FlagZi':
(.text._D3std3net4curl4Curl7performMFE3std8typecons41__T4FlagVAyaa12_7468726f774f6e45727
6f72Z4FlagZi+0x22): 
undefined reference to `curl_easy_perform'
/usr/lib/libphobos2.a(curl_c55_65b.o): In function 
`_D3std3net4curl4HTTP16addRequestHeaderMFAxaAxaZv':
(.text._D3std3net4curl4HTTP16addRequestHeaderMFAxaAxaZv+0x11b): 
undefined reference to `curl_slist_append'
/usr/lib/libphobos2.a(curl_c76_4a1.o): In function 
`_D3std3net4curl4Curl11errorStringMFiZAya':
(.text._D3std3net4curl4Curl11errorStringMFiZAya+0x11): undefined 
reference to `curl_easy_strerror'
clang: error: linker command failed with exit code 1 (use -v to 
see invocation)
--- errorlevel 1

Linking error.... It may be interesting there to notice that [1] 
the foreach version works compiles very well with ldc and gdc 
(ie: it doesn't seem to be related to a library location problem 
on my side) and [2] even if no network function is used in the 
code, simply importing std.net.curl makes it impossible to link 
when using dmd.

Those may be silly little things, but even if I like D a lot I 
find these little things tiring (booo, go contribute to fix bug 
etc....).
Apr 24 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/24/15 1:05 PM, cym13 wrote:


 I don't remember if std.algorithm.each existed in v2.066 but I find it
 hard to believe that it is that recent an addition to phobos.


It is: https://issues.dlang.org/show_bug.cgi?id=12409


 Well, let's try DMD:

 $ dmd --version
 DMD64 D Compiler v2.067
 ....

 $ dmd test.d
 /usr/lib/libphobos2.a(curl.o): In function
 `_D3std3net4curl4HTTP21_sharedStaticCtor1500FZv':
 (.text._D3std3net4curl4HTTP21_sharedStaticCtor1500FZv+0xf): undefined
 reference to `curl_version_info'
 /usr/lib/libphobos2.a(curl.o): In function
 `_D3std3net4curl4Curl21_sharedStaticCtor1502FZv':
 (.text._D3std3net4curl4Curl21_sharedStaticCtor1502FZv+0xf): undefined
 reference to `curl_global_init'


[snip]

This is a sign you don't have libcurl available.


 clang: error: linker command failed with exit code 1 (use -v to see
 invocation)


Why not try this switch? use dmd -v and see why curl is not being 
included in link.


 Those may be silly little things, but even if I like D a lot I find
 these little things tiring (booo, go contribute to fix bug etc....).


These are easily fixed issues. Most people don't run into them. D is 
usually pretty good when it comes to being able to run out of the box.

-Steve
Apr 24 2015
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 24 April 2015 at 17:14:53 UTC, Steven Schveighoffer 
wrote:

 On 4/24/15 1:05 PM, cym13 wrote:

 $ dmd test.d
 /usr/lib/libphobos2.a(curl.o): In function
 `_D3std3net4curl4HTTP21_sharedStaticCtor1500FZv':
 (.text._D3std3net4curl4HTTP21_sharedStaticCtor1500FZv+0xf): 
 undefined
 reference to `curl_version_info'
 /usr/lib/libphobos2.a(curl.o): In function
 `_D3std3net4curl4Curl21_sharedStaticCtor1502FZv':
 (.text._D3std3net4curl4Curl21_sharedStaticCtor1502FZv+0xf): 
 undefined
 reference to `curl_global_init'


 [snip]

 This is a sign you don't have libcurl available.


You need to link against libcurl explicitly, it doesn't happen 
automatically:

     dmd -L-lcurl test.d
Apr 24 2015
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/24/15 1:26 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:

 On Friday, 24 April 2015 at 17:14:53 UTC, Steven Schveighoffer wrote:

 On 4/24/15 1:05 PM, cym13 wrote:

 $ dmd test.d
 /usr/lib/libphobos2.a(curl.o): In function
 `_D3std3net4curl4HTTP21_sharedStaticCtor1500FZv':
 (.text._D3std3net4curl4HTTP21_sharedStaticCtor1500FZv+0xf): undefined
 reference to `curl_version_info'
 /usr/lib/libphobos2.a(curl.o): In function
 `_D3std3net4curl4Curl21_sharedStaticCtor1502FZv':
 (.text._D3std3net4curl4Curl21_sharedStaticCtor1502FZv+0xf): undefined
 reference to `curl_global_init'


 [snip]

 This is a sign you don't have libcurl available.


 You need to link against libcurl explicitly, it doesn't happen
 automatically:

      dmd -L-lcurl test.d


Really? I thought it did it automatically if you import std.curl?

That is something that needs fixing...

-Steve
Apr 24 2015
prev sibling next sibling parent reply "cym13" <cpicard openmailbox.org> writes:
On Friday, 24 April 2015 at 17:26:03 UTC, Marc Schütz wrote:

 On Friday, 24 April 2015 at 17:14:53 UTC, Steven Schveighoffer 
 wrote:

 On 4/24/15 1:05 PM, cym13 wrote:

 $ dmd test.d
 /usr/lib/libphobos2.a(curl.o): In function
 `_D3std3net4curl4HTTP21_sharedStaticCtor1500FZv':
 (.text._D3std3net4curl4HTTP21_sharedStaticCtor1500FZv+0xf): 
 undefined
 reference to `curl_version_info'
 /usr/lib/libphobos2.a(curl.o): In function
 `_D3std3net4curl4Curl21_sharedStaticCtor1502FZv':
 (.text._D3std3net4curl4Curl21_sharedStaticCtor1502FZv+0xf): 
 undefined
 reference to `curl_global_init'


 [snip]

 This is a sign you don't have libcurl available.


 You need to link against libcurl explicitly, it doesn't happen 
 automatically:

     dmd -L-lcurl test.d


Nice to have a workarround but it would be much nicer if it did 
like ldc and gdc that linked didn't need explicit linking...
Apr 24 2015
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 24 April 2015 at 19:34, cym13 via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Friday, 24 April 2015 at 17:26:03 UTC, Marc Schütz wrote:

 On Friday, 24 April 2015 at 17:14:53 UTC, Steven Schveighoffer wrote:

 On 4/24/15 1:05 PM, cym13 wrote:

 $ dmd test.d
 /usr/lib/libphobos2.a(curl.o): In function
 `_D3std3net4curl4HTTP21_sharedStaticCtor1500FZv':
 (.text._D3std3net4curl4HTTP21_sharedStaticCtor1500FZv+0xf): undefined
 reference to `curl_version_info'
 /usr/lib/libphobos2.a(curl.o): In function
 `_D3std3net4curl4Curl21_sharedStaticCtor1502FZv':
 (.text._D3std3net4curl4Curl21_sharedStaticCtor1502FZv+0xf): undefined
 reference to `curl_global_init'



 [snip]

 This is a sign you don't have libcurl available.



 You need to link against libcurl explicitly, it doesn't happen
 automatically:

     dmd -L-lcurl test.d



 Nice to have a workarround but it would be much nicer if it did like ldc and
 gdc that linked didn't need explicit linking...



You need to explicitly link third party libraries.
Apr 24 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Apr 24 2015
next sibling parent "Meta" <jared771 gmail.com> writes:
On Friday, 24 April 2015 at 17:44:32 UTC, Steven Schveighoffer 
wrote:

 You shouldn't need to explicitly link anything that comes out 
 of phobos IMO.

 -Steve


+1, getting pages of linker errors is extremely confusing and 
intimidating for newcomers to D.
Apr 24 2015
prev sibling next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Apr 24 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Apr 24 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Apr 24 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Apr 24 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Apr 24 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Apr 24 2015
next sibling parent "cym13" <cpicard openmailbox.org> writes:
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.
Apr 24 2015
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 24 April 2015 at 21:06:59 UTC, Dicebot wrote:

 Typical example is when in specific distro library name 
 includes major version number in the static library name, i.e. 
 libcurl4.a


Isn't this very problem why pkg-config exists?


 Another case is multilib paths, those are not uniform either (I 
 add -L-L/usr/lib32 to default dmd.conf for it to work)


Yeah, I don't think they ever made it better at dealing with 
that; have to set PKG_CONFIG_PATH.  (But that's multilib for you.)

-Wyatt
Apr 24 2015
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/24/15 5:06 PM, 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.


Anyone using std.net.curl already is doing non-standard build on Linux. 
And anyone using libcurl on Windows is using whatever DMD provides (do 
we update that to keep up with patches?).

dub is on code.dlang.org, it's not an obscure tool. It takes minutes to 
install dub.

But really, I meant use code.dlang.org, dub shouldn't be a requirement.

libcurl is fine to have as a library with D bindings. But it's not an 
"out of the box" experience. It shouldn't be part of the standard library.


 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.


Good point.


 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.


Probably true. It would be nice to be able to configure pragma(lib) 
somehow so it had some input from the environment.

-Steve
Apr 24 2015
prev sibling next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
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?
Apr 24 2015
parent reply "cym13" <cpicard openmailbox.org> writes:
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.
Apr 24 2015
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 24 April 2015 at 21:47:50 UTC, cym13 wrote:

 Reimplementing sure sounds like the best long-term way to go...
 Maybe we don't need all libcurl features


Actually, I find curl doesn't provide much of what I actually 
need and I have to build stuff on top of it!

But the hard part to reimplment isn't basic get stuff... the hard 
part is the encrypted sockets, and you're still likely going to 
depend on a third party library for them....
Apr 24 2015
prev sibling parent "David Eagen" <davideagen mailinator.com> writes:
On Friday, 24 April 2015 at 21:47:50 UTC, cym13 wrote:

 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.


Vibed already provides a good HTTP library. There is also an 
HTTP/2 library on dub that is being incorporated into Vibed. I 
would suggesting using these if you are doing anything new rather 
than using std.net.curl.
Apr 25 2015
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 24 April 2015 at 20:52:16 UTC, Steven Schveighoffer 
wrote:

 There is a reason nothing but Windows build of DMD supports it.


 You are right about not having pragma(lib anywhere but windows,



pragma(lib) works on all versions of dmd, including on Linux.
Apr 24 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/24/15 6:03 PM, Adam D. Ruppe wrote:

 On Friday, 24 April 2015 at 20:52:16 UTC, Steven Schveighoffer wrote:

 There is a reason nothing but Windows build of DMD supports it.


 You are right about not having pragma(lib anywhere but windows,



 pragma(lib) works on all versions of dmd, including on Linux.


No, I meant that phobos only uses pragma(lib) on Windows.

-Steve
Apr 24 2015
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 24 Apr 2015 22:55, "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.


Doesn't DMD use dmd.conf for these?  Libc may be called something else,
libm may or may not be part of libc, and librt may not exist at all.

For the first two, the system C compiler will know this information and
implicitly link when you run 'cc mydprog.o -lphobos2'.  For librt, it's
less likely so you'll need '-L-lrt' in your D environment vars.



 Apr 24 2015



  parent  Jacob Carlborg <doob me.com>  writes:


On 2015-04-25 08:42, Iain Buclaw via Digitalmars-d wrote:


 Doesn't DMD use dmd.conf for these?


No, on OS X DMD adds the following when calling GCC:

-lphobos2 -lpthread -lm

-- 
/Jacob Carlborg



 Apr 27 2015



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2015-04-24 22:27, Steven Schveighoffer wrote:


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


It doesn't work with GDC.

-- 
/Jacob Carlborg



 Apr 27 2015



prev sibling  parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com>  writes:


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



 Apr 24 2015



  parent  "cym13" <cpicard openmailbox.org>  writes:


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.



 Apr 24 2015



prev sibling  parent  "cym13" <cpicard openmailbox.org>  writes:


On Friday, 24 April 2015 at 17:14:53 UTC, Steven Schveighoffer 
wrote:

 On 4/24/15 1:05 PM, cym13 wrote:


 I don't remember if std.algorithm.each existed in v2.066 but I 
 find it
 hard to believe that it is that recent an addition to phobos.


 It is: https://issues.dlang.org/show_bug.cgi?id=12409


OK. It's always nice to learn something, I didn't see it in the 
changelog the
first time I checked (on double-check, it is there).



 Apr 24 2015