Re: A valid code that won't run?
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
Re: A valid code that won't run?
On 4/24/15 1:26 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " 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
Re: A valid code that won't run?
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
Re: A valid code that won't run?
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).
Re: A valid code that won't run?
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...
Re: A valid code that won't run?
On 24 April 2015 at 19:34, cym13 via Digitalmars-d 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.
Re: A valid code that won't run?
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
Re: A valid code that won't run?
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.
Re: A valid code that won't run?
On 04/24/2015 10:26 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " 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
Re: A valid code that won't run?
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=?= " 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.
Re: A valid code that won't run?
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
Re: A valid code that won't run?
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.
Re: A valid code that won't run?
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
Re: A valid code that won't run?
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.
Re: A valid code that won't run?
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
Re: A valid code that won't run?
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.
Re: A valid code that won't run?
On Fri, 24 Apr 2015 16:52:16 -0400
Steven Schveighoffer via Digitalmars-d 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?
Re: A valid code that won't run?
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.
Re: A valid code that won't run?
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
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.
Re: A valid code that won't run?
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
Re: A valid code that won't run?
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.
Re: A valid code that won't run?
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
Re: A valid code that won't run?
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
Re: A valid code that won't run?
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
Re: A valid code that won't run?
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.
Re: A valid code that won't run?
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.
Re: A valid code that won't run?
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
Re: A valid code that won't run?
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
