digitalmars.D.announce - Blog post: using dynamic libraries in dub
- Neia Neutuladh (10/10) Dec 19 2017 From the "it's a hacky workaround but it's what we've got"
- Mike Wey (6/18) Dec 19 2017 And for GtkD, that is why it would make sense to relay on the packages
- Neia Neutuladh (5/9) Dec 21 2017 That would be awesome. I'm not able to access the d-apt
- Martin Nowak (6/8) Dec 20 2017 At some point `dub build` should get a `--shared` option to change the
- Benjamin Thaut (5/9) Dec 20 2017 Would this work in all cases? Do tls variables work across Linux
- Jacob Carlborg (6/10) Dec 21 2017 As far as I know it works on Linux and FreeBSD, but it doesn't work on
- David Nadlinger (8/16) Dec 21 2017 Just to clarify, that's true for for DMD only – TLS should work
- Benjamin Thaut (10/14) Dec 21 2017 Agree, although this currently really is a bad default. Having
- Guillaume Piolat (3/6) Dec 21 2017 If this is an option, that would be really great.
- Martin Nowak (3/6) Dec 23 2017 Yes, that's the long-term goal.
- Jacob Carlborg (4/6) Dec 22 2017 Right.
- Walter Bright (3/5) Dec 22 2017 Is there a bugzilla issue with just what is wrong with the TLS code gene...
- Jacob Carlborg (6/8) Dec 23 2017 There's nothing wrong with TLS on macOS. It's just that there are
- Walter Bright (4/12) Dec 23 2017 It'd be nice to collect information on what needs to be done and file a ...
- Jacob Carlborg (7/10) Dec 25 2017 If I knew exactly what would need to be done I would most likely have
- Neia Neutuladh (12/16) Dec 27 2017 If you know that it doesn't work, please file an issue; a bug
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
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.jsonAnd 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
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
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
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
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
On Thursday, 21 December 2017 at 12:43:51 UTC, Jacob Carlborg wrote:On 2017-12-20 11:31, Benjamin Thaut wrote:Just to clarify, that's true for for DMD only – TLS should work just fine on macOS with LDC.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.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, ...). — DavidDo we expect all dub libraries to have correct export annotations once export goes live?No.
Dec 21 2017
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, ...). — DavidAgree, 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
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
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
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
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
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
On 12/23/2017 6:26 AM, Jacob Carlborg wrote:On 2017-12-23 00:18, 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.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.
Dec 23 2017
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
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