www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - libphobos.so libdruntime.so

reply "Marco Leise" <Marco.Leise gmx.de> writes:
As time goes by the D runtime will have it's place on Unix systems next to  
the C runtime. The upcoming support for PIC is the next step. Now I just  
want to quickly raise awareness for "sonames". For any library, there may  
be several incompatible versions installed, since new features are added  
and old features a deprecated. This happens in Phobos as well, no doubt  
:). So the solution is to put the version in the library name as well, so  
they can coexist in the same directory (/usr/lib).

Here is an example for the two versions of libunique I have installed:
	/usr/lib64/libunique-1.0.so         (link to  
/usr/lib64/libunique-1.0.so.0.100.6)
	/usr/lib64/libunique-1.0.so.0       (link to  
/usr/lib64/libunique-1.0.so.0.100.6)
	/usr/lib64/libunique-1.0.so.0.100.6
	/usr/lib64/libunique-3.0.so         (link to  
/usr/lib64/libunique-3.0.so.0.0.2)
	/usr/lib64/libunique-3.0.so.0       (link to  
/usr/lib64/libunique-3.0.so.0.0.2)
	/usr/lib64/libunique-3.0.so.0.0.2
As you can see there is actually the full version down to the tiniest  
minor version appended to the file name and several layers of coarser  
versioning. An application can now link against libunique-1.0.so to get  
the old API and /usr/lib64/libunique-3.0.so to get the new API.

The same has to happen with druntime and Phobos2 or otherwise our programs  
will break with every new release that deprecates or changes non-template  
functions. That would probably be *every* release at the moment, so it  
could look like this:
/usr/lib64/libphobos2.so     (link to /usr/lib64/libphobos2.so.060)
/usr/lib64/libphobos2.so.058
/usr/lib64/libphobos2.so.059
/usr/lib64/libphobos2.so.060
/usr/lib64/libdruntime.so     (link to /usr/lib64/libdruntime.so.060)
/usr/lib64/libdruntime.so.058
/usr/lib64/libdruntime.so.059
/usr/lib64/libdruntime.so.060

There are two steps involved in getting this out of the door now:
1) I'm not an expert with these things, but from the looks of it, I think  
the Makefile should handle appending the version string
2) The runtime should be downloadable as a separate package (like the  
famous MSVC Runtime Redistributables)
Developers have three choices then:
- static linking
- packaging the so/dll with their application (always using the  
tested-works version)
- use the system installation of druntime/Phobos2 (benefit from patches  
(as far as WinSxS doesn't intervene))

-- Marco
Feb 02 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 03, 2012 02:29:20 Marco Leise wrote:

 As time goes by the D runtime will have it's place on Unix systems next to
 the C runtime. The upcoming support for PIC is the next step. Now I just
 want to quickly raise awareness for "sonames". For any library, there may
 be several incompatible versions installed, since new features are added
 and old features a deprecated. This happens in Phobos as well, no doubt
 
 :). So the solution is to put the version in the library name as well, so
 
 they can coexist in the same directory (/usr/lib).
 
 Here is an example for the two versions of libunique I have installed:
 	/usr/lib64/libunique-1.0.so         (link to
 /usr/lib64/libunique-1.0.so.0.100.6)
 	/usr/lib64/libunique-1.0.so.0       (link to
 /usr/lib64/libunique-1.0.so.0.100.6)
 	/usr/lib64/libunique-1.0.so.0.100.6
 	/usr/lib64/libunique-3.0.so         (link to
 /usr/lib64/libunique-3.0.so.0.0.2)
 	/usr/lib64/libunique-3.0.so.0       (link to
 /usr/lib64/libunique-3.0.so.0.0.2)
 	/usr/lib64/libunique-3.0.so.0.0.2
 As you can see there is actually the full version down to the tiniest
 minor version appended to the file name and several layers of coarser
 versioning. An application can now link against libunique-1.0.so to get
 the old API and /usr/lib64/libunique-3.0.so to get the new API.
 
 The same has to happen with druntime and Phobos2 or otherwise our programs
 will break with every new release that deprecates or changes non-template
 functions. That would probably be *every* release at the moment, so it
 could look like this:
 /usr/lib64/libphobos2.so     (link to /usr/lib64/libphobos2.so.060)
 /usr/lib64/libphobos2.so.058
 /usr/lib64/libphobos2.so.059
 /usr/lib64/libphobos2.so.060
 /usr/lib64/libdruntime.so     (link to /usr/lib64/libdruntime.so.060)
 /usr/lib64/libdruntime.so.058
 /usr/lib64/libdruntime.so.059
 /usr/lib64/libdruntime.so.060
 
 There are two steps involved in getting this out of the door now:
 1) I'm not an expert with these things, but from the looks of it, I think
 the Makefile should handle appending the version string
 2) The runtime should be downloadable as a separate package (like the
 famous MSVC Runtime Redistributables)
 Developers have three choices then:
 - static linking
 - packaging the so/dll with their application (always using the
 tested-works version)
 - use the system installation of druntime/Phobos2 (benefit from patches
 (as far as WinSxS doesn't intervene))


I would point out that druntime is bundled with libphobos.a. I wouldn't expect 
libdruntime to be on the system.

- Jonathan M Davis
Feb 02 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-02-03 02:33, Jonathan M Davis wrote:

 On Friday, February 03, 2012 02:29:20 Marco Leise wrote:

 As time goes by the D runtime will have it's place on Unix systems next to
 the C runtime. The upcoming support for PIC is the next step. Now I just
 want to quickly raise awareness for "sonames". For any library, there may
 be several incompatible versions installed, since new features are added
 and old features a deprecated. This happens in Phobos as well, no doubt

 :). So the solution is to put the version in the library name as well, so

 they can coexist in the same directory (/usr/lib).

 Here is an example for the two versions of libunique I have installed:
 	/usr/lib64/libunique-1.0.so         (link to
 /usr/lib64/libunique-1.0.so.0.100.6)
 	/usr/lib64/libunique-1.0.so.0       (link to
 /usr/lib64/libunique-1.0.so.0.100.6)
 	/usr/lib64/libunique-1.0.so.0.100.6
 	/usr/lib64/libunique-3.0.so         (link to
 /usr/lib64/libunique-3.0.so.0.0.2)
 	/usr/lib64/libunique-3.0.so.0       (link to
 /usr/lib64/libunique-3.0.so.0.0.2)
 	/usr/lib64/libunique-3.0.so.0.0.2
 As you can see there is actually the full version down to the tiniest
 minor version appended to the file name and several layers of coarser
 versioning. An application can now link against libunique-1.0.so to get
 the old API and /usr/lib64/libunique-3.0.so to get the new API.

 The same has to happen with druntime and Phobos2 or otherwise our programs
 will break with every new release that deprecates or changes non-template
 functions. That would probably be *every* release at the moment, so it
 could look like this:
 /usr/lib64/libphobos2.so     (link to /usr/lib64/libphobos2.so.060)
 /usr/lib64/libphobos2.so.058
 /usr/lib64/libphobos2.so.059
 /usr/lib64/libphobos2.so.060
 /usr/lib64/libdruntime.so     (link to /usr/lib64/libdruntime.so.060)
 /usr/lib64/libdruntime.so.058
 /usr/lib64/libdruntime.so.059
 /usr/lib64/libdruntime.so.060

 There are two steps involved in getting this out of the door now:
 1) I'm not an expert with these things, but from the looks of it, I think
 the Makefile should handle appending the version string
 2) The runtime should be downloadable as a separate package (like the
 famous MSVC Runtime Redistributables)
 Developers have three choices then:
 - static linking
 - packaging the so/dll with their application (always using the
 tested-works version)
 - use the system installation of druntime/Phobos2 (benefit from patches
 (as far as WinSxS doesn't intervene))


 I would point out that druntime is bundled with libphobos.a. I wouldn't expect
 libdruntime to be on the system.

 - Jonathan M Davis


If Phobos and druntime would be compiled as dynamic libraries both 
libphobos and libdruntime would be needed to be shipped.

-- 
/Jacob Carlborg
Feb 03 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 02, 2012 at 05:33:49PM -0800, Jonathan M Davis wrote:
[...]

 I would point out that druntime is bundled with libphobos.a. I
 wouldn't expect libdruntime to be on the system.


[...]

Are there any *good* reasons why druntime and libphobos are not
dynamically linked? In the long run, we need to support that, since
otherwise D binaries will be unnecessarily large and the OS won't be
able to optimize memory usage by sharing library images with multiple
processes.


T

-- 
BREAKFAST.COM halted...Cereal Port Not Responding. -- YHL
Feb 02 2012
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 03.02.2012, 03:34 Uhr, schrieb H. S. Teoh <hsteoh quickfur.ath.cx>:


 Are there any *good* reasons why druntime and libphobos are not
 dynamically linked? In the long run, we need to support that, since
 otherwise D binaries will be unnecessarily large and the OS won't be
 able to optimize memory usage by sharing library images with multiple
 processes.


 T


No fear, the people in charge know about all that, it was technical  
reasons that held back the support. That said, there are people who prefer  
static linking. May they speak for themselves...
Feb 02 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 03, 2012 04:27:37 Marco Leise wrote:

 Am 03.02.2012, 03:34 Uhr, schrieb H. S. Teoh <hsteoh quickfur.ath.cx>:

 Are there any *good* reasons why druntime and libphobos are not
 dynamically linked? In the long run, we need to support that, since
 otherwise D binaries will be unnecessarily large and the OS won't be
 able to optimize memory usage by sharing library images with multiple
 processes.
 
 
 T


 
 No fear, the people in charge know about all that, it was technical
 reasons that held back the support. That said, there are people who prefer
 static linking. May they speak for themselves...


Dynamic linking is evil. Static linking is _way_ better when you can do it. 
The problem is, of course, that you often need dynamic linking for a variety 
of reasons (saving memory being one of them).

- Jonathan M Davis
Feb 02 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 3 February 2012 at 03:40:07 UTC, Jonathan M Davis 
wrote:

 Dynamic linking is evil.


Amen!


 dynamic linking for a variety of reasons (saving memory being 
 one of them).


Smart operating systems don't even need it for this;
they can do de-duplication of identical pages in both
memory and on the drive.
Feb 02 2012
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 03.02.2012, 04:42 Uhr, schrieb Adam D. Ruppe  
<destructionator gmail.com>:


 On Friday, 3 February 2012 at 03:40:07 UTC, Jonathan M Davis wrote:

 Dynamic linking is evil.


 Amen!


 dynamic linking for a variety of reasons (saving memory being one of  
 them).


 Smart operating systems don't even need it for this;
 they can do de-duplication of identical pages in both
 memory and on the drive.


Are you serious? I have seen a flag in Linux for hosting virtual machines,  
but it must be an enormous overhead to check every executable page or  
every executable file on the file system for duplicates. If this were for  
free, it would be great, but the most spread OSes today and in the  
foreseeable future wont have filesystems that do something like automatic  
hardlinks of duplicate pages in executables. Both the file system and more  
importantly executable formats aren't ready for this. Let's imagine the  
library to link against against was Gtk. Would you want every binary  
download on the internet to include libraries of that size?
The best we have for the job is dynamic linking. Personally I think it is  
quite good, but you have to be careful as a library author to properly  
version API differences.
Feb 02 2012
next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
P.S.: Another good example for the benefit of size reduction are filter  
plugins for multimedia application. Those are usually a dozen small  
libraries with a few lines of code, where the ratio of own code vs runtime  
can quickly run out of proportion. I think someone here mentioned writing  
plugins for some VST program.
Feb 02 2012
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 3 February 2012 at 04:23:34 UTC, Marco Leise wrote:

 I have seen a flag in Linux for hosting virtual machines, but 
 it must be an enormous overhead to check every executable page 
 or every executable file on the file system for duplicates.


tbh I haven't benchmarked it, but one of the cloud
providers I worked on used it on Solaris, and we had
a good experience.


 great, but the most spread OSes today and in the foreseeable 
 future wont have filesystems that do something like automatic 
 hardlinks of duplicate pages in executables.


Regardless, most computers today aren't exactly
counting their kilobytes either. (And those that are
don't multitask much anyway.)

Phobos, in a typical D program, consumes a few hundred
kb. Maybe if you're running 1,000 D processes at once will
it become a problem... but that's not a realistic scenario.

Distributing standalone D programs, or having D programs that
use different versions of Phobos *is* something we face. With
static linking, this isn't a problem. It's mindlessly easy.


 Let's imagine the library to link against against was Gtk. 
 Would you want every binary download on the internet to include 
 libraries of that size?


Yes, actually. I'd rather download a 10 MB executable that
*actually works* than have to download a separate library,
and hope I get the right version.

(And 10 MB is probably an overestimate! I've used statically
linked Qt apps that come in at only about 6 MB.)


There's times when dynamic linking is a good call. Core
operating system libraries, plugins, stuff like that.

But, Phobos isn't one of them, and I doubt it ever will be.
Feb 02 2012
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 02 Feb 2012 22:38:58 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 On Friday, February 03, 2012 04:27:37 Marco Leise wrote:

 Am 03.02.2012, 03:34 Uhr, schrieb H. S. Teoh <hsteoh quickfur.ath.cx>:

 Are there any *good* reasons why druntime and libphobos are not
 dynamically linked? In the long run, we need to support that, since
 otherwise D binaries will be unnecessarily large and the OS won't be
 able to optimize memory usage by sharing library images with multiple
 processes.


 T


 No fear, the people in charge know about all that, it was technical
 reasons that held back the support. That said, there are people who  
 prefer
 static linking. May they speak for themselves...


 Dynamic linking is evil. Static linking is _way_ better when you can do  
 it.
 The problem is, of course, that you often need dynamic linking for a  
 variety
 of reasons (saving memory being one of them).


Dynamic linking is not evil, poorly managed packaging of dynamic libs is  
evil.

Static linking has its advantages too, but as far as phobos and druntime  
are concerned, dynamic linking would be way way better.

-Steve
Feb 04 2012
parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Sunday, 5 February 2012 at 03:58:03 UTC, Steven Schveighoffer 
wrote:

Static linking has its advantages too, but as far as phobos and 
druntime  are concerned, dynamic linking would be way way better.


Bollocks. In the general case (which is silly to talk about, I'll 
admit) I'd take static linking every time. Sure, it increases the 
size of the executable, but if I'm distributing my app, I'm 
almost certainly distributing libphobos.so with it, so that's 
moot.

As has been said, Phobos/druntime changes often enough that 
relying on it being present on the users system is ridiculous.

This isn't to say being able to dynamically link Phobos and 
druntime is undesirable, it isn't. But even if it were an option, 
I would still statically link them to my apps.
Feb 05 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, February 02, 2012 18:34:34 H. S. Teoh wrote:

 On Thu, Feb 02, 2012 at 05:33:49PM -0800, Jonathan M Davis wrote:
 [...]
 

 I would point out that druntime is bundled with libphobos.a. I
 wouldn't expect libdruntime to be on the system.


 
 [...]
 
 Are there any *good* reasons why druntime and libphobos are not
 dynamically linked? In the long run, we need to support that, since
 otherwise D binaries will be unnecessarily large and the OS won't be
 able to optimize memory usage by sharing library images with multiple
 processes.


Because dmd does not yet support shared libraries on Linux.

- Jonathan M Davis
Feb 02 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 02, 2012 at 07:19:37PM -0800, Jonathan M Davis wrote:

 On Thursday, February 02, 2012 18:34:34 H. S. Teoh wrote:


[...]

 Are there any *good* reasons why druntime and libphobos are not
 dynamically linked? In the long run, we need to support that, since
 otherwise D binaries will be unnecessarily large and the OS won't be
 able to optimize memory usage by sharing library images with
 multiple processes.


 
 Because dmd does not yet support shared libraries on Linux.


[...]

Hmph. Since gdc *does* support shared libraries (I think?), it should be
possible, at least in principle, no?


T

-- 
I think Debian's doing something wrong, `apt-get install pesticide',
doesn't seem to remove the bugs on my system! -- Mike Dresser
Feb 02 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Fri, 03 Feb 2012 05:47:28 +0100, H. S. Teoh <hsteoh quickfur.ath.cx>  
wrote:


 On Thu, Feb 02, 2012 at 07:19:37PM -0800, Jonathan M Davis wrote:

 On Thursday, February 02, 2012 18:34:34 H. S. Teoh wrote:


 [...]

 Are there any *good* reasons why druntime and libphobos are not
 dynamically linked? In the long run, we need to support that, since
 otherwise D binaries will be unnecessarily large and the OS won't be
 able to optimize memory usage by sharing library images with
 multiple processes.


 Because dmd does not yet support shared libraries on Linux.


 [...]

 Hmph. Since gdc *does* support shared libraries (I think?), it should be
 possible, at least in principle, no?


It does as much as dmd. The issues are with missing druntime support.
I have implemented that but we are still merging.
Feb 02 2012
prev sibling next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Marco Leise wrote:

 As time goes by the D runtime will have it's place on Unix systems next=



 to the C runtime. The upcoming support for PIC is the next step. Now I
 just want to quickly raise awareness for "sonames". For any library,
 there may be several incompatible versions installed, since new feature=


s

 are added and old features a deprecated. This happens in Phobos as well=


,

 no doubt :). So the solution is to put the version in the library name
 as well, so they can coexist in the same directory (/usr/lib).
=20
 Here is an example for the two versions of libunique I have installed:
     /usr/lib64/libunique-1.0.so         (link to
 /usr/lib64/libunique-1.0.so.0.100.6)
     /usr/lib64/libunique-1.0.so.0       (link to
 /usr/lib64/libunique-1.0.so.0.100.6)
     /usr/lib64/libunique-1.0.so.0.100.6
     /usr/lib64/libunique-3.0.so         (link to
 /usr/lib64/libunique-3.0.so.0.0.2)
     /usr/lib64/libunique-3.0.so.0       (link to
 /usr/lib64/libunique-3.0.so.0.0.2)
     /usr/lib64/libunique-3.0.so.0.0.2
 As you can see there is actually the full version down to the tiniest
 minor version appended to the file name and several layers of coarser
 versioning. An application can now link against libunique-1.0.so to get=



 the old API and /usr/lib64/libunique-3.0.so to get the new API.
=20
 The same has to happen with druntime and Phobos2 or otherwise our
 programs will break with every new release that deprecates or changes
 non-template functions. That would probably be *every* release at the
 moment, so it could look like this:
 /usr/lib64/libphobos2.so     (link to /usr/lib64/libphobos2.so.060)
 /usr/lib64/libphobos2.so.058
 /usr/lib64/libphobos2.so.059
 /usr/lib64/libphobos2.so.060
 /usr/lib64/libdruntime.so     (link to /usr/lib64/libdruntime.so.060)
 /usr/lib64/libdruntime.so.058
 /usr/lib64/libdruntime.so.059
 /usr/lib64/libdruntime.so.060
=20
 There are two steps involved in getting this out of the door now:
 1) I'm not an expert with these things, but from the looks of it, I
 think the Makefile should handle appending the version string
 2) The runtime should be downloadable as a separate package (like the
 famous MSVC Runtime Redistributables)
 Developers have three choices then:
 - static linking
 - packaging the so/dll with their application (always using the
 tested-works version)
 - use the system installation of druntime/Phobos2 (benefit from patches=



 (as far as WinSxS doesn't intervene))
=20


	Do not forget to add the proper soname information *inside* the
files. With GNU ld you need these options: "-soname
libphobos2.so.060"...

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Feb 03 2012
prev sibling parent reply Trass3r <un known.com> writes:
 The same has to happen with druntime and Phobos2 or otherwise our  
 programs will break with every new release that deprecates or changes  
 non-template functions. That would probably be *every* release at the  
 moment, so it could look like this:
 /usr/lib64/libphobos2.so     (link to /usr/lib64/libphobos2.so.060)
 /usr/lib64/libphobos2.so.058
 /usr/lib64/libphobos2.so.059
 /usr/lib64/libphobos2.so.060
 /usr/lib64/libdruntime.so     (link to /usr/lib64/libdruntime.so.060)
 /usr/lib64/libdruntime.so.058
 /usr/lib64/libdruntime.so.059
 /usr/lib64/libdruntime.so.060


And you don't consider this insane?
The 'shared' approach is fine if a library has settled and is used  
pervasively like C runtime.
Also the library needs to have an appropriate development approach with  
major (feature) revisions and smaller non-breaking versions.
Phobos is a fast-moving target and doesn't fit in this model neither will  
it in the foreseeable future.

Why do people always treat D like a mainstream language? It isn't.
The chance that one has more than a few real D apps on one's machine is  
quite low. The chance that they use the very same version of  
phobos/druntime is even lower.
And usually the only ones you actually use are developed by yourself  
anyway.

I rather have a slightly bigger executable than having my system cluttered  
with hundreds of phobos versions I don't need.
And you should keep in mind that dmd's phobos is currently 17MB, gdc's is  
25+5.5. Plus most apps only use a small share of that.


Making druntime shared sometime is ok I think, but it's just not ready  
yet. See the recent associative arrays dilemma. And the crappy GC.
Feb 03 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 03, 2012 at 08:28:04PM +0100, Trass3r wrote:
[...]

 Why do people always treat D like a mainstream language? It isn't.


But things like shared libraries that will become necessary once it
becomes mainstream. Lack of shared library support is one of the
barriers to it becoming mainstream (among many other things).



 The chance that one has more than a few real D apps on one's machine
 is quite low. The chance that they use the very same version of
 phobos/druntime is even lower.
 And usually the only ones you actually use are developed by yourself
 anyway.
 
 I rather have a slightly bigger executable than having my system
 cluttered with hundreds of phobos versions I don't need.


Um, that's what you use a package manager for...



 And you should keep in mind that dmd's phobos is currently 17MB,
 gdc's is 25+5.5. Plus most apps only use a small share of that.
 
 Making druntime shared sometime is ok I think, but it's just not
 ready yet. See the recent associative arrays dilemma. And the crappy
 GC.


It's strange, I noticed one thing about the D forums, and that is people
keep complaining about this problem and that problem, this lack and that
lack, and it seems very few are willing to actually do something about
it. Like write some code and submit patches. I mean, this isn't some
closed, proprietary system where you pretty much have to hope that the
developers will implement what you want; the phobos/druntime source code
and dmd frontend are open-source for a reason. And hopefully that reason
isn't just so you feel all nice and warm inside. The source code is
there so that people can look at it and more importantly improve it.

Same goes for lack of support for certain features that some regard as
mainstream or critical. If library X doesn't exist yet, nothing stops
anyone from writing it and submitting it for review. And even if it's
not approved, nobody stops you from posting your code online somewhere
and make it available as a 3rd party library. I find it utterly strange
that people would just keep complaining about the lack of feature X yet
it seems they don't want to write it either. If that's the case, then
we're going nowhere. Nobody wants to implement feature X yet people are
clamoring for feature X. Strange.


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze
Feb 03 2012
next sibling parent reply Trass3r <un known.com> writes:
 But things like shared libraries that will become necessary once it
 becomes mainstream. Lack of shared library support is one of the
 barriers to it becoming mainstream (among many other things).


Support for that is almost ready even in dmd.
You were talking about making phobos shared and that's a different thing.



 I rather have a slightly bigger executable than having my system
 cluttered with hundreds of phobos versions I don't need.


 Um, that's what you use a package manager for...


I didn't say anything about management.



 And you should keep in mind that dmd's phobos is currently 17MB,
 gdc's is 25+5.5. Plus most apps only use a small share of that.

 Making druntime shared sometime is ok I think, but it's just not
 ready yet. See the recent associative arrays dilemma. And the crappy
 GC.


 It's strange, I noticed one thing about the D forums, and that is people
 keep complaining about this problem and that problem, this lack and that
 lack, and it seems very few are willing to actually do something about
 it.


I wasn't complaining, I was stating that even druntime is far from being  
stable.
Feb 03 2012
parent Johannes Pfau <nospam example.com> writes:
Am Fri, 03 Feb 2012 21:46:49 +0100
schrieb Trass3r <un known.com>:


 But things like shared libraries that will become necessary once it
 becomes mainstream. Lack of shared library support is one of the
 barriers to it becoming mainstream (among many other things).


 
 Support for that is almost ready even in dmd.
 You were talking about making phobos shared and that's a different
 thing.
 


There's probably no need to make phobos shared by default, but it
should be supported. IIRC a shared runtime is necessary for dynamically
loaded D plugins, plugins written in D to be used in C apps and similar
stuff.


 I rather have a slightly bigger executable than having my system
 cluttered with hundreds of phobos versions I don't need.


 Um, that's what you use a package manager for...


 
 I didn't say anything about management.
 
 

 And you should keep in mind that dmd's phobos is currently 17MB,
 gdc's is 25+5.5. Plus most apps only use a small share of that.

 Making druntime shared sometime is ok I think, but it's just not
 ready yet. See the recent associative arrays dilemma. And the
 crappy GC.


 It's strange, I noticed one thing about the D forums, and that is
 people keep complaining about this problem and that problem, this
 lack and that lack, and it seems very few are willing to actually
 do something about it.


 
 I wasn't complaining, I was stating that even druntime is far from
 being stable.
Feb 03 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-02-03 20:55, H. S. Teoh wrote:

 On Fri, Feb 03, 2012 at 08:28:04PM +0100, Trass3r wrote:
 [...]

 Why do people always treat D like a mainstream language? It isn't.


 But things like shared libraries that will become necessary once it
 becomes mainstream. Lack of shared library support is one of the
 barriers to it becoming mainstream (among many other things).



 The chance that one has more than a few real D apps on one's machine
 is quite low. The chance that they use the very same version of
 phobos/druntime is even lower.
 And usually the only ones you actually use are developed by yourself
 anyway.

 I rather have a slightly bigger executable than having my system
 cluttered with hundreds of phobos versions I don't need.


 Um, that's what you use a package manager for...


Even if you would use a package manager to install the 
applications/libraries it would still be cluttered with different 
versions of Phobos.

-- 
/Jacob Carlborg
Feb 04 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Feb 04, 2012 at 07:11:25PM +0100, Jacob Carlborg wrote:

 On 2012-02-03 20:55, H. S. Teoh wrote:

On Fri, Feb 03, 2012 at 08:28:04PM +0100, Trass3r wrote:




[...]

I rather have a slightly bigger executable than having my system
cluttered with hundreds of phobos versions I don't need.


Um, that's what you use a package manager for...


 
 Even if you would use a package manager to install the
 applications/libraries it would still be cluttered with different
 versions of Phobos.


[...]

Not if your package manager is clueful enough to be able to detect (and
optionally remove) libraries that nothing depends on, automatically.


T

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!
Feb 04 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-02-05 00:42, H. S. Teoh wrote:

 On Sat, Feb 04, 2012 at 07:11:25PM +0100, Jacob Carlborg wrote:

 On 2012-02-03 20:55, H. S. Teoh wrote:

 On Fri, Feb 03, 2012 at 08:28:04PM +0100, Trass3r wrote:




 [...]

 I rather have a slightly bigger executable than having my system
 cluttered with hundreds of phobos versions I don't need.


 Um, that's what you use a package manager for...


 Even if you would use a package manager to install the
 applications/libraries it would still be cluttered with different
 versions of Phobos.


 [...]

 Not if your package manager is clueful enough to be able to detect (and
 optionally remove) libraries that nothing depends on, automatically.


Yeah, but as long as something depends on the libraries you cannot 
remove them.

-- 
/Jacob Carlborg
Feb 05 2012
prev sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 03.02.2012, 20:28 Uhr, schrieb Trass3r <un known.com>:


 The same has to happen with druntime and Phobos2 or otherwise our  
 programs will break with every new release that deprecates or changes  
 non-template functions. That would probably be *every* release at the  
 moment, so it could look like this:
 /usr/lib64/libphobos2.so     (link to /usr/lib64/libphobos2.so.060)
 /usr/lib64/libphobos2.so.058
 /usr/lib64/libphobos2.so.059
 /usr/lib64/libphobos2.so.060
 /usr/lib64/libdruntime.so     (link to /usr/lib64/libdruntime.so.060)
 /usr/lib64/libdruntime.so.058
 /usr/lib64/libdruntime.so.059
 /usr/lib64/libdruntime.so.060


 And you don't consider this insane?


More with the wink of an eye, that in the event of shared libraries,  
deprecations of functions in every release will have this effect. :)


 The 'shared' approach is fine if a library has settled and is used  
 pervasively like C runtime.
 Also the library needs to have an appropriate development approach with  
 major (feature) revisions and smaller non-breaking versions.
 Phobos is a fast-moving target and doesn't fit in this model neither  
 will it in the foreseeable future.

 Why do people always treat D like a mainstream language? It isn't.


How about having the option? Handling this correctly from the start on  
will reduce the likelyhood that someone considers D a toy language.


 The chance that one has more than a few real D apps on one's machine is  
 quite low. The chance that they use the very same version of  
 phobos/druntime is even lower.
 And usually the only ones you actually use are developed by yourself  
 anyway.


I'm using software written in OCaml, Python, Java, C++ and Delphi and it  
is possible that there will be D apps I install through the package  
manager, once there are standard packages in Linux distributions. And I  
think that is more likely if D can come with the runtime as a shared  
library. And like Johannes said earlier, there may be situations where you  
depend on the availability of shared libraries.


 Making druntime shared sometime is ok I think, but it's just not ready  
 yet. See the recent associative arrays dilemma. And the crappy GC.


Fair enough. I guess, I just don't want to say "I knew this would happen"  
later. :)
Feb 03 2012