Re: [boost] DLL names under windows

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-22 12:19:14

Carl,

Your proposal is a start, but doesn't go far enough. There are MANY more
features which can affect link-compatibility of DLLs (and static libs for
that matter), which is part of the reason that Boost.Build puts all
link-incompatible targets into separate directories. Further, the same
problems exist for other platforms. I am not willing to hardcode such a name
mangling scheme into Boost.Build, because I don't think that people will be
able to agree on the mangling. It would be easy to arrange a
user-configurable scheme, though. To get a sense of what needs to happen,
please take a look at the build system documentation at
www.boost.org/tools/build/build_system.htm, in particular the section on
feature declarations. Any target name mangling schema ought to be integrated
with feature declaration and selection. I'd like to hear some suggestions on
how to modify the build system interface to account for it.

Regards,
Dave

----- Original Message -----
From: "Carl Daniel" <cpdaniel_at_[hidden]>

> > 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:
>
> CtlMWGT.lib  (.dll)
>
> 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.
>
> -cd
>
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>