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
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
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
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.
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
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?
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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo
