From: Carl Daniel (cpdaniel_at_[hidden])
Date: 2001-10-22 12:04:49
----- Original Message -----
From: "David Abrahams" <david.abrahams_at_[hidden]>
Sent: Monday, October 22, 2001 9:43 AM
Subject: Re: [boost] DLL names under windows
> So, does this get the build system off the hook, or is there still an issue
> to address?
> If there is, somebody PLEASE post a proposal for how things should work,
> with some reasonable amount of detail. I can make the build system do almost
> anything, but I need to understand the requirements first. I am not an
> expert in the domain of DLL conflicts and naming.
It's easy to be an expert in DLL conflicts: if two DLLs weren't built by identical build environments, it's safe to
assume that they're incompatible. If the DLLs expose C++ classes, that'll be nearly 100% accurate. For DLLs with 'C'
APIs, it is possible for them to be compatible across several implementations (it's almost guaranteed - every
implementation needs to be able to use Kernel32.dll, which uses MSFT Naming/calling convention for C).
As Ed Brey responded, dumping DLLs in the Windows System directory has been taboo for many years, although it's still a
common enough practice.
Given the number of binary incompatible implementations of C++ under Windows (MSVC, Borland, MWCW, GCC/Cygwin, ...), it
probably makes sense to encode the development platform into the names of any DLLs which are produced.
Here's an example from the past: Rogue Wave Tools.h++ used the following naming convention:
where - lower case letters are as-is
C code the compiler
b3 - Borland C++ 3.x
h - Metaware High-C
M - Memory model
... fortunately, this is relevant anymore
W - Windows/DOS format. Really, they used this to encode whether a lib was a static lib or a DLL import lib.
(absent) - DOS static import library. This isn't relevant, but the other two could be.
d - dll import library
w - windows static library
G - Codes whether library is a debug build
(absent) - not a debug build
g - debug build
T - codes whether library is a thread-safe build
(absent) - single threaded
mt - multi-threaded
Within MSFTs DLL's, it's customary for debug builds to have names ending in D.
IMO, information like that which Rogue Wave encoded in their C, W, G and T fields is still useful and could avoid
unpleasant incompatibilities when (not if) people dump Boost DLLs into Windows/System32.
I will confess to have not attempted a Boost build with any system, but I was a bit surprised from the original post
that started this thread: I wouldn't expect (or want) Boost::Regexp to produce ANY DLLs at all. I hope that the build
process can produce static libs in addition/instead of DLLs for all of Boost.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk