Skip to content
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

Build instructions #51

Open
yochananmarqos opened this issue Jul 4, 2022 · 1 comment
Open

Build instructions #51

yochananmarqos opened this issue Jul 4, 2022 · 1 comment

Comments

@yochananmarqos
Copy link

I tried dub build, but it did not create libundead.so, only libundead.a and undead-test-library,

@PetarKirov
Copy link
Member

TL;DR If you really really need a shared library, change line 6 in dub.sdl to: targetType "dynamicLibrary".

General note about the use of shared libraries in D

In general, source-only or source + static library are the most common ways to consume D libraries. Dynamic libraries (shared objects) + header files are rare occurrence in D, because most libraries only promise source compatibility and not ABI compatibility. Most notably, D's runtime and standard libraries don't have a stable ABI neither across compiler releases (even patch versions - e.g. 2.100.0 vs 2.100.1), nor across the same frontend version, but different compiler vendors (e.g. LDC 1.29.0 is based on DMD 2.099.1). That means, that unless the author(s) of a D library have specifically promised to maintain a stable ABI surface, simply compiling it and installing it in /usr/lib is not going to work out, unless you include both the full library version in the name, as well as the compiler's name and version (that was used to compile the library.) That is not to say that having a stable ABI is impossible in D - quite the opposite, especially if one sticks to the BettterC susbset, it's just that in practice it is a rather rare occurrence, especially because many users are used to Dub's model, where Dub manages both the fetching and the building of dependencies and very few if any D developers expect to find their library or the D-based dependencies installed globally for the current user, much less for all users on a system (e.g. in /usr/lib/)

Background info regarding Dub

Dub has the concept of target types which allow the package author to specify the whether the package is a program that should be compiled to an executable, or whether it is a library in which case it could be a source library, static library or dynamic library. (There is also the the option to specify the target type as simply library which in theory could allow downstream users of the package to decide whether they prefer the library do be compiled as a static or dynamic, but I don't know if anyone is working on implementing this.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants