Proposal for a standard for D library naming

Gregor Richards Richards at codu.org
Sun Sep 24 02:31:05 PDT 2006


Gregor Richards wrote:
> Derek Parnell wrote:
> 
>> On Mon, 18 Sep 2006 21:10:46 -0700, Gregor Richards wrote:
>>
>>
>>> Since there aren't many libraries for D (that is, builds that produce 
>>> .so files or the ilk)
>>
>>
>>
>> In fact, are there any? I vaguely remember reading that D does not yet
>> support the creation of .so files. Is that still the case?
>>
>> Anyhow, let's break Gregor's proposal into two parts:
>> (a) creating shared libraries (DLL in Windows, .so in Linux, ? in other
>> *nix)
>> (b) using shared libraries in the build process
>>
>> I will defer (a) until I know how to do it :-)
>>
>> With (b) I'm willing to add this feature to Build but with idea that
>> failure to locate a library from a package name is not a failure to 
>> build.
>> I'm not convinced that Gregor's idea that every (top-level) package must
>> also be a library is a valid idea. I can imagine people still wanting 
>> to do
>> static linking of object files.
>>
> 
> This last paragraph makes me think that I've miscommunicated my concept 
> *urk*
> 
> 1) Failure to locate an appropriately-named library is /not/ a failure, 
> just a failure in that subsystem (if indeed the symbol can't be found 
> anywhere, that'd be a failure).  This would probably be a 
> report-but-continue type warning.
> 2) My creation of libraries is slightly more flexible than what you're 
> suggesting, but less flexible than what you'd like I think.  Any 
> /package/ can be a library (whether top-level or not), only making 
> libraries of top-level packages is just a /default/.  The only reason 
> for making this restriction is, to not place a reasonable restriction on 
> what modules are contained in a library makes the naming exponentially 
> complex or impossible.  Urk.
> 
> As per making .so files, DMD can't do it but GDC can.  For DMD to do it, 
> it would need the equivalent of an -fPIC option, to produce 
> position-independent code - the linking part is easy.  Of course, since 
> either can create .a files, its implementable so long as DMD users are 
> willing to surrender the ability to make .so files until it's capable. 
> If build did this all in its automatic processing, the source maintainer 
> wouldn't need to care whether the compiler being used is capable of 
> producing libraries of any sort.
> 
> (Actually, DMD may be producing position independent code already for 
> all I know, in which case it's perfectly capable, just need -L-shared - 
> unfortunately, this is hard to test, since much software will "just 
> work" even if it's not made position independent)
> 
> Furthermore, this proposal is not shared-library specific, it just shows 
> its greatest benefit there (since the reliability in naming is carried 
> through every conceivable stage of making/running a program).
> 
>  - Gregor Richards

According to DMD's docs, it has an -fPIC flag.  I see no compelling 
reason why it shouldn't be able to create .so files, given that.

To make a .so file (just a guess):

dmd <source files> -fPIC -L-shared -L-Wl-soname=libfoo.so.0 
-oflibfoo.so.0.0.0

(In case you don't get the discrepency in naming, it's all about how ELF 
.so files are versioned: the first number after .so is essentially the 
ABI version, so it should only change when non-backwards-compatible 
changes are made.  The name that programs keep in them has one number. 
The next is generally used for backwards-compatible ABI changes, the 
next for other changes)

If you are willing to implement this in build, I'd be glad to extend my 
help, especially on getting all the UNIX stuff named/installed as would 
be traditional for a UNIX system.  (And of course I've also offered to 
make the changes myself, but I'm under the distinctive impression that 
you'd prefer to make big changes like that yourself - perfectly 
understandable)

  - Gregor Richards



More information about the Digitalmars-d mailing list