Re: stage rule on windows problem

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-11-23 07:07:07

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. And now we have a
lot of problems because on windows there's no declspec. Possible
enhancement for one platform becomes portability problem.

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.

Right at the moment, the KDE project is adding relevant declaration to all
the libraries, and judging from email list traffic, this turns out to be
fun ;-)

- Volodya