www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Blog post: using dynamic libraries in dub

reply Neia Neutuladh <neia ikeran.org> writes:
 From the "it's a hacky workaround but it's what we've got" 
department: how to use dynamic libraries in dub, with GtkD as the 
example.

GtkD takes about 45MB on its own, and that means it can take a 
fair bit of time to build anything that depends on it -- even if 
it only uses a handful of symbols. Building it as a dynamic 
library can shrink compile times significantly.

https://blog.ikeran.org/?p=323

An example of this strategy in use: 
https://git.ikeran.org/dhasenan/resin-browser/src/master/dub.json
Dec 19 2017
next sibling parent reply Mike Wey <mike-wey example.com> writes:
On 19-12-17 18:58, Neia Neutuladh wrote:

  From the "it's a hacky workaround but it's what we've got" department: 
 how to use dynamic libraries in dub, with GtkD as the example.
 
 GtkD takes about 45MB on its own, and that means it can take a fair bit 
 of time to build anything that depends on it -- even if it only uses a 
 handful of symbols. Building it as a dynamic library can shrink compile 
 times significantly.
 
 https://blog.ikeran.org/?p=323
 
 An example of this strategy in use: 
 https://git.ikeran.org/dhasenan/resin-browser/src/master/dub.json


And for GtkD, that is why it would make sense to relay on the packages 
supplied by your distribution. And just list "gtkd-3" in the "libs" 
section. Avoiding the need for the workaround to build a shared version.

-- 
Mike Wey
Dec 19 2017
parent Neia Neutuladh <neia ikeran.org> writes:
On Tuesday, 19 December 2017 at 21:38:40 UTC, Mike Wey wrote:

 And for GtkD, that is why it would make sense to relay on the 
 packages supplied by your distribution. And just list "gtkd-3" 
 in the "libs" section. Avoiding the need for the workaround to 
 build a shared version.


That would be awesome. I'm not able to access the d-apt 
repository at the moment and Ubuntu 16.04 doesn't seem to have 
gtkd in the repositories. So for the near future, at least, I'll 
continue using this cruddy workaround.
Dec 21 2017
prev sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 12/19/2017 06:58 PM, Neia Neutuladh wrote:

 From the "it's a hacky workaround but it's what we've got" department:
 how to use dynamic libraries in dub, with GtkD as the example.


At some point `dub build` should get a `--shared` option to change the
meaning of `library` target types from `staticLibrary` to
`dynamicLibrary`. The shared libs could be linked with absolute paths.

http://code.dlang.org/package-format?lang=sdl#target-types
https://github.com/dlang/dub/issues/571
Dec 20 2017
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
On Wednesday, 20 December 2017 at 08:09:53 UTC, Martin Nowak 
wrote:

 At some point `dub build` should get a `--shared` option to 
 change the meaning of `library` target types from 
 `staticLibrary` to `dynamicLibrary`. The shared libs could be 
 linked with absolute paths.


Would this work in all cases? Do tls variables work across Linux 
shared libraries? Do we expect all dub libraries to have correct 
export annotations once export goes live?
Dec 20 2017
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-12-20 11:31, Benjamin Thaut wrote:


 Would this work in all cases? Do tls variables work across Linux shared 
 libraries? 


As far as I know it works on Linux and FreeBSD, but it doesn't work on 
macOS. I don't know about windows.


 Do we expect all dub libraries to have correct export 
 annotations once export goes live?


No.

-- 
/Jacob Carlborg
Dec 21 2017
parent reply David Nadlinger <code klickverbot.at> writes:
On Thursday, 21 December 2017 at 12:43:51 UTC, Jacob Carlborg 
wrote:

 On 2017-12-20 11:31, Benjamin Thaut wrote:

 Would this work in all cases? Do tls variables work across 
 Linux shared libraries?


 As far as I know it works on Linux and FreeBSD, but it doesn't 
 work on macOS. I don't know about windows.


Just to clarify, that's true for for DMD only – TLS should work 
just fine on macOS with LDC.


 Do we expect all dub libraries to have correct export 
 annotations once export goes live?


 No.


There would probably have to be some sort of compatibility flag 
to avoid breaking all libraries on systems where symbols are 
visible externally by default (Linux, ...).

  — David
Dec 21 2017
next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
On Thursday, 21 December 2017 at 13:30:32 UTC, David Nadlinger 
wrote:

 There would probably have to be some sort of compatibility flag 
 to avoid breaking all libraries on systems where symbols are 
 visible externally by default (Linux, ...).

  — David


Agree, although this currently really is a bad default. Having 
all symbols visible by default can lead to really long shared 
library load times especially with template heavy code. I've seen 
reports of shared libaries using boost in c++ having load times 
of 60 seconds and above due to the number of visible symbols.

Ideally we should end up with visibility hidden being the default 
and only making symbols visible which use "export", because that 
is what it was designed for in the first place.
Dec 21 2017
next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 21 December 2017 at 13:44:18 UTC, Benjamin Thaut 
wrote:

 Ideally we should end up with visibility hidden being the 
 default and only making symbols visible which use "export", 
 because that is what it was designed for in the first place.


If this is an option, that would be really great.
Dec 21 2017
prev sibling parent Martin Nowak <code dawg.eu> writes:
On Thursday, 21 December 2017 at 13:44:18 UTC, Benjamin Thaut 
wrote:

 Ideally we should end up with visibility hidden being the 
 default and only making symbols visible which use "export", 
 because that is what it was designed for in the first place.


Yes, that's the long-term goal.
Dec 23 2017
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-12-21 14:30, David Nadlinger wrote:


 Just to clarify, that's true for for DMD only – TLS should work just 
 fine on macOS with LDC.


Right.

-- 
/Jacob Carlborg
Dec 22 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/21/2017 5:30 AM, David Nadlinger wrote:

 Just to clarify, that's true for for DMD only – TLS should work just fine on 
 macOS with LDC.


Is there a bugzilla issue with just what is wrong with the TLS code generation 
on macOS?
Dec 22 2017
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-12-23 00:18, Walter Bright wrote:


 Is there a bugzilla issue with just what is wrong with the TLS code 
 generation on macOS?


There's nothing wrong with TLS on macOS. It's just that there are 
additional work that needs to be done. Just the same as TLS worked 
before dynamic libraries worked on Linux.

-- 
/Jacob Carlborg
Dec 23 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/23/2017 6:26 AM, Jacob Carlborg wrote:

 On 2017-12-23 00:18, Walter Bright wrote:
 

 Is there a bugzilla issue with just what is wrong with the TLS code generation 
 on macOS?


 
 There's nothing wrong with TLS on macOS. It's just that there are additional 
 work that needs to be done. Just the same as TLS worked before dynamic
libraries 
 worked on Linux.


It'd be nice to collect information on what needs to be done and file a
bugzilla 
issue on it. Otherwise it's just generic "doesn't work on macOS" which contains 
no useful information.
Dec 23 2017
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-12-23 21:59, Walter Bright wrote:


 It'd be nice to collect information on what needs to be done and file a
 bugzilla issue on it. Otherwise it's just generic "doesn't work on
 macOS" which contains no useful information.


If I knew exactly what would need to be done I would most likely have 
done it already :). Perhaps Martin that implemented the support on Linux 
or David that, I think, implemented it for LDC on macOS would be better 
suited for such a bugzilla issue.

-- 
/Jacob Carlborg
Dec 25 2017
parent Neia Neutuladh <neia ikeran.org> writes:
On Monday, 25 December 2017 at 08:57:09 UTC, Jacob Carlborg wrote:

 If I knew exactly what would need to be done I would most 
 likely have done it already :). Perhaps Martin that implemented 
 the support on Linux or David that, I think, implemented it for 
 LDC on macOS would be better suited for such a bugzilla issue.


If you know that it doesn't work, please file an issue; a bug 
that just says "this doesn't work" is more valuable than its 
absence.

If you have a test case, that is valuable; "what would need to be 
done" is to make the test case work.

If you know that it works with LDC, that is also valuable; "what 
would need to be done" is to port over LDC's fixes.

I haven't used a Mac since 2012 (an experience that I am anxious 
to avoid repeating), so I don't even know whether TLS works with 
dynamic libraries on OSX. I can't test fixes. All I could do is 
report that there's a rumor.
Dec 27 2017