Thread overview | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
December 19, 2017 Blog post: using dynamic libraries in dub | ||||
---|---|---|---|---|
| ||||
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 |
December 19, 2017 Re: Blog post: using dynamic libraries in dub | ||||
---|---|---|---|---|
| ||||
Posted in reply to Neia Neutuladh | 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 |
December 20, 2017 Re: Blog post: using dynamic libraries in dub | ||||
---|---|---|---|---|
| ||||
Posted in reply to Neia Neutuladh | 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 |
December 20, 2017 Re: Blog post: using dynamic libraries in dub | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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?
|
December 21, 2017 Re: Blog post: using dynamic libraries in dub | ||||
---|---|---|---|---|
| ||||
Posted in reply to Benjamin Thaut | 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 |
December 21, 2017 Re: Blog post: using dynamic libraries in dub | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 |
December 21, 2017 Re: Blog post: using dynamic libraries in dub | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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.
|
December 21, 2017 Re: Blog post: using dynamic libraries in dub | ||||
---|---|---|---|---|
| ||||
Posted in reply to Benjamin Thaut | 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.
|
December 21, 2017 Re: Blog post: using dynamic libraries in dub | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Wey | 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.
|
December 22, 2017 Re: Blog post: using dynamic libraries in dub | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 |
Copyright © 1999-2021 by the D Language Foundation