Re: stage rule on windows problem

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-24 10:30:12

Vladimir Prus <ghost_at_[hidden]> writes:

> Toon Knapen wrote:
>
>>>>...found 16 targets...
>>>>...updating 2 targets...
>>>>msvc.link.dll bin\msvc\debug\libbar.dll bin\msvc\debug\libbar.lib
>>>>bin\msvc\debug\libbar.rsp
>>>>common.copy C:\bjam_test\dynamic\libbar.lib
>>>>The system cannot find the file specified.
>>>>
>>>> copy "bin\msvc\debug\libbar.lib" "C:\bjam_test\dynamic\libbar.lib"
>>> 
>>> 
>>> Sure, your bar.cpp is empty, so DLL exports no symbols, so msvc linker
>>> helpfully produced no .lib file at all.
>>> 
>>> Is this "no exports" situation true for your real project?
>> 
>> currently yes but this is because I only recently started porting this
>> piece of code and there are no dllexport directives yet. Thanks for the
>> help (again!!!).
>
> Slightly offtopic, but this is a general issue with different versions of
> software. MS decided that explicit export of symbols from DLL is a good
> idea. Supposedly, they though it would be good for users. 

It is very good, in fact. If anyone got it "more right," I'd say it
was MS in this case.

> And now we have a lot of problems because on windows there's no
> declspec. Possible enhancement for one platform becomes portability
> problem.

Well, if only they hadn't made it so that no empty DLL can be built by
their tools, it would be fine. I'm sure we could work around that in
BBv2 by auto-generating an empty DLL when linking succeeds but
produces no result.

> And the funny thing about this specific change is that gcc is adopting the
> same model. Some development version have -fvisibility option which can be
> used to change default symbols visibility to "hidden". An explicit
> attribute on a class/function can be used to export a symbols. I'm not sure
> how it happened, but probably this is somewhat affected by this paper:
> http://www.ukuug.org/events/linux2002/papers/pdf/dsohowto.pdf, a pretty
> complete overview of shared libs on Linux/ELF.

It happened because of Niall Douglas, who got tired of waiting for
long link times for Boost.Python extensions (and their large size).

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com