Re: [Libreoffice] SW_DLLPUBLIC limitations ...

2010-11-01 Thread Thorsten Behrens 
Cedric Bosdonnat wrote:
 I finally got it working with SAL_DLLPUBLIC_EXPORT as michael suggested.
 If there is any possible trouble, let me know ;)
 
Hi - oh wow, dynamic_casting on interfaces is really nasty - we
should truly put up a bunch of big red warning signs around that.
FWIW, if you try that with UNO interfaces, that'll fail even more
spectacularly - they're defined with SAL_NO_VTABLE. ;)

Cheers,

-- Thorsten


pgppe28eWdhyS.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] SW_DLLPUBLIC limitations ...

2010-10-27 Thread Cedric Bosdonnat 
Hi Tor, Michael,

I finally got it working with SAL_DLLPUBLIC_EXPORT as michael suggested.
If there is any possible trouble, let me know ;)

--
Cedric

On Wed, 2010-10-27 at 07:21 -0600, Tor Lillqvist wrote:
  The question (for
  Tor) is - if we have a __declspec(dllexport) on two identical symbols in
  two shared libraries that link to each other: will we get some vile
  linking conflict ? [ or not ] ;-)
 
 As far as I could see by experimenting, yes, as long as you from a DLL don't 
 both import and export a symbol with the same name, it should work.
 
 Possibly using some clever tricks or useful options to the linker it might be 
 possible to make the linker create a DLL that both imports a certain symbol 
 from another DLL, and also exports the same symbol.
 
 (If just you manage to create such a DLL, using it should not be 
 problematic... After all, to the run-time linker, there should be nothing 
 confusing going on.)
 
 But of course, without actually trying, and considering C++ is involved, take 
 all the above with a large grain of salt.
 
 --tml
 
 


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice