-
-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[dub-guide/plugins_dlls] Basic content #62
Comments
The bit about mangling isn't accurate I've managed to find out.
I believe it's an encoding issue on our end some place.
Everything else is still good.
…On Sun, Sep 17, 2023, 07:38 Jan Jurzitza ***@***.***> wrote:
- Tell about how dub packages can be made as DLLs / plugins for
applications
- ask @rikkimax <https://github.com/rikkimax> for what goes on here
- notes about platform limitations / shared runtime
- Short descriptions of other IPC tools:
- Win32 COM interface
- DBus on Linux
- Named pipes
- Unix domain sockets
- Mention scripting capabilities using script language packages
------------------------------
@rikkimax <https://github.com/rikkimax>
D shared library being used from a D executable/shared library:
- Windows dmd dll support is pretty much a write off, LDC and GDC may
work for a given usecase.
- Always have a configuration option available to switch between
shared library and static library builds.
- The current ~master and above should support shared library building
for LDC regardless of platform without any extra dflags.
- No *nix support has been implemented to cover RPATH, this will need
custom lflags depending on the distribution.
D shared library being used from non-D executable/shared library:
- No *nix support has been implemented to cover RPATH, this will need
custom lflags depending on the distribution.
Runtimes are more of a @kinke <https://github.com/kinke> thing. Although
we've seen that LDC --static build did resolve some problems in a shared
library build even though it may not be the best.
------------------------------
wrt. injectSourceFiles:
- Is an advanced feature that should not be used except in very
specific cases
- Should be used automatically when registering symbols/types with
your dependency
- Currently, no way to access what modules are in a build/being built
although this needs to be done
- If you have any files injected they MUST be liberally licensed such
as Boost otherwise you can give some lawyers are very horrible day (and
hence you too!)
- Is shared library and executable build aware, should not inject for
a static or source library
- Injects upwards in the dependency tree, rather than downwards like
flags do
------------------------------
Don't use Unicode in exported symbols on Windows. Microsoft doesn't intend
for that to work. We haven't implemented a mangling workaround for it.
—
Reply to this email directly, view it on GitHub
<#62>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHSL476E5IL2CL53PWCL43X2X5ZPANCNFSM6AAAAAA43CVO2Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@rikkimax
D shared library being used from a D executable/shared library:
D shared library being used from non-D executable/shared library:
Runtimes are more of a @kinke thing. Although we've seen that LDC
--static
build did resolve some problems in a shared library build even though it may not be the best.wrt. injectSourceFiles:
Don't use Unicode in exported symbols on Windows. Microsoft doesn't intend for that to work. We haven't implemented a mangling workaround for it.
The text was updated successfully, but these errors were encountered: