MinGW-Port: Problems with UnoUrlResolver

[Stephan Bergmann]

On 02/22/2012 12:56 PM, Michael Meeks wrote:
> 	So - the question would be then, how much of UNO is usable via the
> in-line C wrappers ? I was under the impression that lots of it should
> be - but perhaps I'm in cloud cuckoo land ;-)

With "in-line C wrappers" you mean the inline C++ code in exported 
headers of sal etc., right?  That's enough to re-use the fundamental 
helper functionality for C/C++ UNO, so to speak, but it does not allow 
you at all to interact with UNO entities at the "UNO level," so to speak 
(i.e., call methods of UNO objects etc.).

> 	I suppose, the vtable mismatch would need bridging between mingw and
> msvc - which would be quite fun I suppose. Ho hum, as you say it's not a
> wonderful idea - though having that bridging in place might be nice for
> flexibility in future wrt. mingw cross-compile vs. MSVC building :-)

In principle, it should work to combine in a single process the UNO 
bridges for MSVC-ABI C++ UNO and GCC-ABI C++ UNO, and entities from the 
two worlds could then communicate transparently via UNO (going via the 
binary UNO hub, which is the common endpoint of the two different C++ 
bridges).  All the URE libraries that are specific to a given C++ ABI 
would be loaded into the process in two versions (note that all those 
libraries contain the identifier for the C++ ABI in their names).

In practice, the (slightly?) tricky parts would be (a) to see that it 
really works to combine two C++ UNO bridges in one process---nobody has 
ever tried that AFAIK, and (b) to provide a LO installation set that 
contains the C++ ABI specific URE parts in both versions.

Stephan