Re: MinGW-Port: Problems with UnoUrlResolver

[Tor Lillqvist]

> I'm using the MinGW-LibreOffice from the daily-build-service (2012-02-20);
> the MinGW itself is the cross tool chain from SuSE 12.1.

I *think* it would be better to just use a normal stable (MSVC-built)
LibreOffice version, not the experimental MinGW build. I hope it
doesn't matter that *your* code is built using MinGW. (But I might be
wrong. In that case, try using MSVC instead.)

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Helmar Spangenberg]

Am Dienstag, 21. Februar 2012, 12:29:58 schrieb Tor Lillqvist:
> > I'm using the MinGW-LibreOffice from the daily-build-service
> > (2012-02-20); the MinGW itself is the cross tool chain from SuSE 12.1.
> 
> I *think* it would be better to just use a normal stable (MSVC-built)
> LibreOffice version, not the experimental MinGW build. I hope it
> doesn't matter that *your* code is built using MinGW. (But I might be
> wrong. In that case, try using MSVC instead.)
> 
> --tml

I would love to use the MSVC version - however my application is based on some 
essential MinGW parts, and until now I have not found a way to link my 
application against the MSVC-DLLs coming with the LibreOffice SDK.

But maybe someone can give me a hint...

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Tor Lillqvist]

> I would love to use the MSVC version - however my application is based on
> some essential MinGW parts, and until now I have not found a way to link my
> application against the MSVC-DLLs coming with the LibreOffice SDK.

Hmm, ah, yes silly me, the joys of mixing compilers when using C++ APIs.

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Michael Meeks]

Hi Helmar,

On Tue, 2012-02-21 at 11:53 +0100, Helmar Spangenberg wrote:
> I would love to use the MSVC version - however my application is based
> on some essential MinGW parts, and until now I have not found a way to
> link my application against the MSVC-DLLs coming with the LibreOffice
> SDK.

Ho hum; so - in -theory- ;-) the SAL APIs are all in-line C++ wrappers
around a native STDCALL C API (for libsal), so assuming you use just the
sal/ code it could ('in theory') with my limited understanding of these
things, etc. etc. work. But I'm clearly an optimist ;-)

What were your linking errors ?

Failing that, I forget if the MINGW cross-compile works well and runs
even without UNO remote-control in the picture :-) did you find the
snapshots worked adequately on Windows ? Then of course, to go deeper
I'd try running the uno bridge tests (which lurk somewhere) on that
version to be reasonably sure that UNO is working well.

Sorry it's a bit of a pain ...

HTH,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Stephan Bergmann]

On 02/21/2012 04:15 PM, Michael Meeks wrote:

On Tue, 2012-02-21 at 11:53 +0100, Helmar Spangenberg wrote:

I would love to use the MSVC version - however my application is based
on some essential MinGW parts, and until now I have not found a way to
link my application against the MSVC-DLLs coming with the LibreOffice
SDK.


Ho hum; so - in -theory- ;-) the SAL APIs are all in-line C++ wrappers
around a native STDCALL C API (for libsal), so assuming you use just the
sal/ code it could ('in theory') with my limited understanding of these
things, etc. etc. work. But I'm clearly an optimist ;-)


The problem here appears not be C-based sal but C++-based cppuhelper 
("using ::cppu::bootstrap()"), which will only work if cppuhelper and 
client code are compiled with the same compiler (either both MSVC or 
both GCC).


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

Re: MinGW-Port: Problems with UnoUrlResolver

[Helmar Spangenberg]

Am Dienstag, 21. Februar 2012, 15:15:56 schrieb Michael Meeks:
> Hi Helmar,
> 
> On Tue, 2012-02-21 at 11:53 +0100, Helmar Spangenberg wrote:
> > I would love to use the MSVC version - however my application is based
> > on some essential MinGW parts, and until now I have not found a way to
> > link my application against the MSVC-DLLs coming with the LibreOffice
> > SDK.
> 
>   Ho hum; so - in -theory- ;-) the SAL APIs are all in-line C++ wrappers
> around a native STDCALL C API (for libsal), so assuming you use just the
> sal/ code it could ('in theory') with my limited understanding of these
> things, etc. etc. work. But I'm clearly an optimist ;-)
> 
>   What were your linking errors ?
> 
>   Failing that, I forget if the MINGW cross-compile works well and runs
> even without UNO remote-control in the picture :-) did you find the
> snapshots worked adequately on Windows ? Then of course, to go deeper
> I'd try running the uno bridge tests (which lurk somewhere) on that
> version to be reasonably sure that UNO is working well.
> 
>   Sorry it's a bit of a pain ...
> 
>   HTH,
> 
>   Michael.

Hi Michael,
 
actually the SAL C API seems to work nicely - after Tor's remarks I re-
installed the MSVC-SDK and tried to link my MinGW-code against ist. However, 
the CPPU interface denies the linking - I observe undefined references to 
cppu::bootstrap(), cppu::BootstrapException::getMessage(), and 
cppu::defaultBootstrap_InitialComponentContext() :-( - probably a tribute to 
the decorations of the c++-function names
 
I tested the 3.5 MinGW snapshots quite a lot on Windows - the only problem I 
found so far was a "General error" message during reading or writing odt-
documents (to my naive opinion, this message seems to be a lie, since I could 
work as usual with the documents ignoring that "error"). On the other hand, 
when using doc-Files the error message does not show up. Thus, the 
functionality of the MinGW port seems to be sufficient for my needs.
 
Unfortunately I am not able to crosscompile the code - I always get stuck in 
the modules sal and libexttextcat, both with the message
i686-w64-mingw32-windres: unexpected version string length 68 != 32 + 8
 
I have no idea what this will tell me...
 
BTW - in case you need some (limited) help in doing the tests, let me know 
what I could do ;-)
 
Thanks,
Helmar___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: MinGW-Port: Problems with UnoUrlResolver

[Stephan Bergmann]

On 02/21/2012 06:31 PM, Helmar Spangenberg wrote:

actually the SAL C API seems to work nicely - after Tor's remarks I
re-installed the MSVC-SDK and tried to link my MinGW-code against ist.
However, the CPPU interface denies the linking - I observe undefined
references to cppu::bootstrap(), cppu::BootstrapException::getMessage(),
and cppu::defaultBootstrap_InitialComponentContext() :-( - probably a
tribute to the decorations of the c++-function names


Sounds like you link together C++ code compiled with MSVC with C++ code 
compiled with GCC?  That cannot work.


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

Re: MinGW-Port: Problems with UnoUrlResolver

[Helmar Spangenberg]

Am Dienstag, 21. Februar 2012, 19:37:14 schrieb Stephan Bergmann:
> On 02/21/2012 06:31 PM, Helmar Spangenberg wrote:
> > actually the SAL C API seems to work nicely - after Tor's remarks I
> > re-installed the MSVC-SDK and tried to link my MinGW-code against ist.
> > However, the CPPU interface denies the linking - I observe undefined
> > references to cppu::bootstrap(), cppu::BootstrapException::getMessage(),
> > and cppu::defaultBootstrap_InitialComponentContext() :-( - probably a
> > tribute to the decorations of the c++-function names
> 
> Sounds like you link together C++ code compiled with MSVC with C++ code
> compiled with GCC?  That cannot work.
> 
> Stephan

Yes exactly, that is my problem. That's why I am bound to the MinGW port of 
LibreOffice, but somehow the URE part has some problems.

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Stephan Bergmann]

On 02/21/2012 09:05 PM, Helmar Spangenberg wrote:

Yes exactly, that is my problem. That's why I am bound to the MinGW port
of LibreOffice, but somehow the URE part has some problems.


Yeah, sorry, but I fear I have no idea for you there.  UnoUrlResolver is 
probably the first service that shall be instantiated locally, so it 
looks like something very fundamental is broken.


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

Re: MinGW-Port: Problems with UnoUrlResolver

[Michael Meeks]

On Tue, 2012-02-21 at 17:51 +0100, Stephan Bergmann wrote:
> The problem here appears not be C-based sal but C++-based cppuhelper 
> ("using ::cppu::bootstrap()"), which will only work if cppuhelper and 
> client code are compiled with the same compiler (either both MSVC or 
> both GCC).

I wonder - is it possible to expose a C / salcall set of methods for
the basic bootstrapping, as is done in sal ?

Helmar - I guess, if you're ambitious ;-) you could create such a
wrapper API that does the basic UNO setup / bootstrapping you want,
provide a C API for it, compile that with MSVC++ and then use it. If
that worked well, perhaps we could include it into LibreOffice.

How does that sound ? How much API do you really need before we get to
raw sal / UNO-ness ?

All the best,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Stephan Bergmann]

On 02/22/2012 11:30 AM, Michael Meeks wrote:

On Tue, 2012-02-21 at 17:51 +0100, Stephan Bergmann wrote:

The problem here appears not be C-based sal but C++-based cppuhelper
("using ::cppu::bootstrap()"), which will only work if cppuhelper and
client code are compiled with the same compiler (either both MSVC or
both GCC).


I wonder - is it possible to expose a C / salcall set of methods for
the basic bootstrapping, as is done in sal ?

Helmar - I guess, if you're ambitious ;-) you could create such a
wrapper API that does the basic UNO setup / bootstrapping you want,
provide a C API for it, compile that with MSVC++ and then use it. If
that worked well, perhaps we could include it into LibreOffice.

How does that sound ? How much API do you really need before we get to
raw sal / UNO-ness ?


I doubt that Helmar's application only uses C-based sal API after 
initial setup (how would it communicate with LO then? hand-crafted 
binary UNO calls? and in case it does not communicate with LO via UNO at 
all after setup, why set up the UNO connection in the first place)?  In 
which case that wrapper would buy you nothing.


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

Re: MinGW-Port: Problems with UnoUrlResolver

[Helmar Spangenberg]

Am Mittwoch, 22. Februar 2012, 10:30:26 schrieb Michael Meeks:
> On Tue, 2012-02-21 at 17:51 +0100, Stephan Bergmann wrote:
> > The problem here appears not be C-based sal but C++-based cppuhelper
> > ("using ::cppu::bootstrap()"), which will only work if cppuhelper and
> > client code are compiled with the same compiler (either both MSVC or
> > both GCC).
> 
>   I wonder - is it possible to expose a C / salcall set of methods for
> the basic bootstrapping, as is done in sal ?
> 
>   Helmar - I guess, if you're ambitious ;-) you could create such a
> wrapper API that does the basic UNO setup / bootstrapping you want,
> provide a C API for it, compile that with MSVC++ and then use it. If
> that worked well, perhaps we could include it into LibreOffice.
> 
>   How does that sound ? How much API do you really need before we get to
> raw sal / UNO-ness ?
> 
>   All the best,
> 
>   Michael.

Yes, Michael, that's what I am thinking of, too. Actually - as far as I am 
informed by my linker - only the entry points cppu::bootstrap(), 
cppu::BootstrapException::getMessage() and probably 
cppu::defaultBootstrap_InitialComponentContext() are missing - not too much to 
create a small compatibility library.

I think I will have to learn a little bit of how to create decent dll's ;-) , 
and - of course - once the code should work, you may include it to the normal 
distribution.

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Helmar Spangenberg]

Am Mittwoch, 22. Februar 2012, 11:39:14 schrieb Stephan Bergmann:
> On 02/22/2012 11:30 AM, Michael Meeks wrote:
> > On Tue, 2012-02-21 at 17:51 +0100, Stephan Bergmann wrote:
> >> The problem here appears not be C-based sal but C++-based cppuhelper
> >> ("using ::cppu::bootstrap()"), which will only work if cppuhelper and
> >> client code are compiled with the same compiler (either both MSVC or
> >> both GCC).
> >> 
> > I wonder - is it possible to expose a C / salcall set of methods for
> > 
> > the basic bootstrapping, as is done in sal ?
> > 
> > Helmar - I guess, if you're ambitious ;-) you could create such a
> > 
> > wrapper API that does the basic UNO setup / bootstrapping you want,
> > provide a C API for it, compile that with MSVC++ and then use it. If
> > that worked well, perhaps we could include it into LibreOffice.
> > 
> > How does that sound ? How much API do you really need before we get to
> > 
> > raw sal / UNO-ness ?
> 
> I doubt that Helmar's application only uses C-based sal API after
> initial setup (how would it communicate with LO then? hand-crafted
> binary UNO calls? and in case it does not communicate with LO via UNO at
> all after setup, why set up the UNO connection in the first place)?  In
> which case that wrapper would buy you nothing.
> 
> Stephan

My understanding of the whole subject still is too small - I thought, once I 
got the context bootstrapped, the whole communication to the office is done by 
a socket or a pipe. Is it too naive to think that when the context is 
available all the rest of the communication should work?

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Michael Meeks]

On Wed, 2012-02-22 at 11:39 +0100, Stephan Bergmann wrote:
> I doubt that Helmar's application only uses C-based sal API after 
> initial setup. In which case that wrapper would buy you nothing.

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 ;-)

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 :-)

Anyhow - Helmar - I guess the best suggestion then is to try to debug
your problems remote controlling a remote MSVC++ compiled libreoffice
using the mingw compiled URE / SDK :-) but - of course the  bug you
found there is a bit of a pain.

HTH,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Stephan Bergmann]

On 02/22/2012 11:53 AM, Helmar Spangenberg wrote:

My understanding of the whole subject still is too small - I thought,
once I got the context bootstrapped, the whole communication to the
office is done by a socket or a pipe.


Yes, but what gets communicated over that pipe is remote procedure 
calls, so on the client side you need some code to engage in that remote 
procedure calling.  And the code that is available for that is either 
C++ or Java.



Is it too naive to think that when the context is available all the
rest of the communication should work?


Yes, I fear so.  Again, the inability to obtain local UnoUrlResolver 
service probably indicates a fundamental problem somewhere in the MinGW 
UNO stack.  (Note that it is not necessarily a big problem, maybe even 
only a triviality.  But hard to tell w/o an environment to try it out.)


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

Re: 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
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: MinGW-Port: Problems with UnoUrlResolver

[Helmar Spangenberg]

Am Mittwoch, 22. Februar 2012, 11:56:13 schrieb Michael Meeks:
> On Wed, 2012-02-22 at 11:39 +0100, Stephan Bergmann wrote:
> > I doubt that Helmar's application only uses C-based sal API after
> > initial setup. In which case that wrapper would buy you nothing.
> 
>   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 ;-)
> 
>   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 :-)
> 
>   Anyhow - Helmar - I guess the best suggestion then is to try to debug
> your problems remote controlling a remote MSVC++ compiled libreoffice
> using the mingw compiled URE / SDK :-) but - of course the  bug you
> found there is a bit of a pain.
> 
>   HTH,
> 
>   Michael.

In the meantime I am a step further - having found some very annoying things:
The recent MinGW cross tool chain supplied for SuSE 12.1 (64bit) seems to be 
broken - at least with regards to the LibreOffice code. Actually, I found 2 
"bugs":
a) windres does not work correctly
b) IFileDilogCustomize somwhere around "Vista"-files remains undefined

Fortunately I still have an installation of SuSE 11.4 (status December) as a 
fallback on my system, so I changed back and at least could again compile 
everything. The office itself (of December) now shows up again, the problem 
with the UnoUrlResolver comes up here, too. But at least, I now have a way to 
debug the beast...

Since the MinGW office seems to work rather nicely, I will in the first step 
remain on that one - I guess, remote controlling probably will introduce 
further difficulties ;-) - especially since I have the feeling that my 
problems are locally..

What came to my mind: Since I moved the LibreOffice directories, could it be 
possible that I have to adjust one or more ini-files? Furthermore, which 
environment variables are used setting up the local context? Until now I did 
some experiments with URE_MORE_TYPES, UNO_PATH, OFFICE_PROGRAM_PATH, and 
URE_INTERNAL_LIB_DIR (I used the notation "file:///L:/blabla/blublu/..." to 
name a path). 

Helmar

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Michael Meeks]

On Thu, 2012-02-23 at 11:07 +0100, Helmar Spangenberg wrote:
> In the meantime I am a step further - having found some very annoying things:
> The recent MinGW cross tool chain supplied for SuSE 12.1 (64bit) seems to be 
> broken - at least with regards to the LibreOffice code.

Are you not using Fridrich's toolchain / bits from here:

https://build.opensuse.org/project/show?project=windows%3Amingw%3Awin32

All the best,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Michael Stahl]

On 23/02/12 11:07, Helmar Spangenberg wrote:

> What came to my mind: Since I moved the LibreOffice directories, could it be 
> possible that I have to adjust one or more ini-files? Furthermore, which 
> environment variables are used setting up the local context? Until now I did 
> some experiments with URE_MORE_TYPES, UNO_PATH, OFFICE_PROGRAM_PATH, and 
> URE_INTERNAL_LIB_DIR (I used the notation "file:///L:/blabla/blublu/..." to 
> name a path). 

earlier this week i bootstrapped a little python thingy on Linux with
these variables (found by trial and error, not by actual understanding),
perhaps URE_BOOTSTRAP could be of interest to you:

URE_BOOTSTRAP=file:///data/lo/core_3_5/solver/unxlngx6/installation/opt/program/fundamentalrc
LD_LIBRARY_PATH=/data/lo/core_3_5/solver/unxlngx6/installation/opt/program
PYTHONPATH=/data/lo/core_3_5/solver/unxlngx6/installation/opt/program

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Helmar Spangenberg]

Am Donnerstag, 23. Februar 2012, 11:24:00 schrieb Michael Meeks:
> On Thu, 2012-02-23 at 11:07 +0100, Helmar Spangenberg wrote:
> > In the meantime I am a step further - having found some very annoying
> > things: The recent MinGW cross tool chain supplied for SuSE 12.1
> > (64bit) seems to be broken - at least with regards to the LibreOffice
> > code.
> 
>   Are you not using Fridrich's toolchain / bits from here:
> 
> https://build.opensuse.org/project/show?project=windows%3Amingw%3Awin32
> 
>   All the best,
> 
>   Michael.

Ah - I did not know about that URL - I used the packages from the archive 
being named in the README.cross.

But I will have a try onFridrich's toolchain :-)

Helmar

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Helmar Spangenberg]

Am Donnerstag, 23. Februar 2012, 14:48:14 schrieb Helmar Spangenberg:
> > Are you not using Fridrich's toolchain / bits from here:
> > https://build.opensuse.org/project/show?project=windows%3Amingw%3Awin32
> > 
> > All the best,
> > 
> > Michael.
> 
> Ah - I did not know about that URL - I used the packages from the archive
> being named in the README.cross.
> 
> But I will have a try onFridrich's toolchain :-)
> 
> Helmar
Forget my foolish remark - I use the same SuSE repository as Fridrich...

Maybe I should reinstall the whole toolchain to get rid of possible artefacts 
;-)

Helmar

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Helmar Spangenberg]

Am Donnerstag, 23. Februar 2012, 12:49:13 schrieb Michael Stahl:
(...)
> 
> earlier this week i bootstrapped a little python thingy on Linux with
> these variables (found by trial and error, not by actual understanding),
> perhaps URE_BOOTSTRAP could be of interest to you:

I tried it - unfortunately there was no change in th behavior.

However, those variables seem to be very sensitive; after several test I got 
LibreOffice being started by the UNO bootstrap procedure - after setting 
UNO_PATH to L:\myPathToTheInstallation\program (a little bit weird, since the 
notation "FILE:///L:/myPathToTheInstallation/program" which should be used for 
other variables definitely does NOT work in this place).

Helmar
> 
> URE_BOOTSTRAP=file:///data/lo/core_3_5/solver/unxlngx6/installation/opt/prog
> ram/fundamentalrc
> LD_LIBRARY_PATH=/data/lo/core_3_5/solver/unxlngx6/installation/opt/program
> PYTHONPATH=/data/lo/core_3_5/solver/unxlngx6/installation/opt/program
> 
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Helmar Spangenberg]

Am Donnerstag, 23. Februar 2012, 11:24:00 schrieb Michael Meeks:
> On Thu, 2012-02-23 at 11:07 +0100, Helmar Spangenberg wrote:
> > In the meantime I am a step further - having found some very annoying
> > things: The recent MinGW cross tool chain supplied for SuSE 12.1
> > (64bit) seems to be broken - at least with regards to the LibreOffice
> > code.
> 
>   Are you not using Fridrich's toolchain / bits from here:
> 
> https://build.opensuse.org/project/show?project=windows%3Amingw%3Awin32
> 
>   All the best,
> 
>   Michael.

Ok, it really seems that the SuSE 12.1 (64 bit) toolchain is broken - on 
another computer I had the same problems.

Anyway - using the older toolchain I got a working testing environment and 
proceded a little bit. I have the impression that the difficulties rise 
building the local context. As far as I could debug it, everything looks fine 
until a UnoUrlResolver instance shall be created using the local context. That 
fails - obviously when checking "the_instance.is()".

So my guess is, the created local context is incomplete.

Checking a little further, it seems that the file "uno.ini" in my actual 
working directory is analyzed to set up te local context (unfortunately I do 
not understand the entries in that file - any hint?); but a little bit further 
down in the code my debugs signal a NULL context, so that something else is 
created as local context.

I tried to find out where the ini-file is analyzed and/or the local context is 
created, but I got stuck  - the code as a whole is somewhat confusing...
Is there anybody who can tell where I should seek to find the context creation 
functions?

Helmar

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Michael Meeks]

On Mon, 2012-02-27 at 13:07 +0100, Helmar Spangenberg wrote:
> Checking a little further, it seems that the file "uno.ini" in my actual 
> working directory is analyzed to set up te local context (unfortunately I do 
> not understand the entries in that file - any hint?)

:-) So there are two unorc files (or uno.inis on windows) one next to
the URE libraries, and one inside the libreoffice install itself. The
ini file syntax itself is parsed / dealt with by
sal/rtl/source/bootstrap.cxx IIRC, and we like to load a good handful of
these files at startup (I'm afraid).

> I tried to find out where the ini-file is analyzed and/or the local context 
> is 
> created, but I got stuck  - the code as a whole is somewhat confusing...
> Is there anybody who can tell where I should seek to find the context 
> creation 
> functions?

:-) Stephan is really the expert here, but there are several entry
points into those ini files; a:

git grep -5 SAL_CONFIGFILE

would prolly find a scad of this sort of thing, not all of them for
that unorc ...

HTH,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Stephan Bergmann]

On 02/27/2012 01:07 PM, Helmar Spangenberg wrote:

Anyway - using the older toolchain I got a working testing environment and
proceded a little bit. I have the impression that the difficulties rise
building the local context. As far as I could debug it, everything looks fine
until a UnoUrlResolver instance shall be created using the local context. That
fails - obviously when checking "the_instance.is()".

So my guess is, the created local context is incomplete.

Checking a little further, it seems that the file "uno.ini" in my actual
working directory is analyzed to set up te local context (unfortunately I do
not understand the entries in that file - any hint?); but a little bit further
down in the code my debugs signal a NULL context, so that something else is
created as local context.

I tried to find out where the ini-file is analyzed and/or the local context is
created, but I got stuck  - the code as a whole is somewhat confusing...
Is there anybody who can tell where I should seek to find the context creation
functions?


Calling defaultBootstrap_InitialComponentContext() (i.e., the variant 
without arguments) causes the code to pick up a "uno" ini file next to 
the cppuhelper dynamic library (see get_unorc in 
cppuhelper/source/bootstrap.cxx).


For the relevant entries in that ini file see "UNO Deployment Variables" 
in ure/source/README.


Setting up a UNO environment manually for an application is difficult 
and error prone.  The easiest approach is to use the wrapper provided by 
the SDK, see 
.


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

Re: MinGW-Port: Problems with UnoUrlResolver

[Michael Meeks]

Hi Helmar,

On Thu, 2012-03-08 at 17:25 +0100, Helmar Spangenberg wrote:
> finally I could solve the problem.

Great news ! :-)

> UNO_PATH=L:\blabla\libreoffice3.5\program
> URE_MORE_TYPES=file:///L:/blabla/libreoffice3.5/program/types/offapi.rdb
> 
> Now I even can use the MinGW-UNO with an off-the-shell (MSVC) installation of 
> LO :-)

Wonderful.

> In case someone is interested I will supply a short example (Qt/MinGW based) 
> how to start an LO with an empty "sheet of paper" out of a small program. I 
> don't want to pollute the list, therefore tell me a (central) address where 
> to 
> send the files to.

Sounds really useful - we should license it with some hyper-liberal
license too so people are happy to cut/paste it. BSD or somesuch.

How large is that ? It sounds like a good thing to have in
odk/examples/cpp - perhaps 'qt-mingw-demo' or something ? hopefully the
source is not too big ? the other samples are ~20k or so.

Really glad you got things working :-)

All the best,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Helmar Spangenberg]

> > In case someone is interested I will supply a short example (Qt/MinGW
> > based) how to start an LO with an empty "sheet of paper" out of a small
> > program. I don't want to pollute the list, therefore tell me a
> > (central) address where to send the files to.
> 
>   Sounds really useful - we should license it with some hyper-liberal
> license too so people are happy to cut/paste it. BSD or somesuch.
I agree - since I learned my part of LO programming that way, too, I feel I 
should return something useful to the community ;-)
> 
>   How large is that ? It sounds like a good thing to have in
> odk/examples/cpp - perhaps 'qt-mingw-demo' or something ? hopefully the
> source is not too big ? the other samples are ~20k or so.
Unpacked something like 15k - but I still want to write a little README since 
someone really has to be very careful with regards to the whole environment. 
But once the environment is set up, the whole thing seems to work rather 
stable.
So probably tomorrow I will have written the missing "manual"; should I send 
the tarball to you?
> 
>   Really glad you got things working :-)
So am I - but (maybe you already have realized it) I ran into the next problem 
working with TextTables ;-)

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

Re: MinGW-Port: Problems with UnoUrlResolver

[Helmar Spangenberg]

Hello all,

finally I could solve the problem. Basically, for the Windows installation, I 
had to adjust uno.ini in the working directory of my "remote control" 
according to my installation of LO. Furthermore, there are some weird 
inconsistencies concerning URLs. Under Windows I had to set 2 environment 
variables:
UNO_PATH=L:\blabla\libreoffice3.5\program
URE_MORE_TYPES=file:///L:/blabla/libreoffice3.5/program/types/offapi.rdb

Now I even can use the MinGW-UNO with an off-the-shell (MSVC) installation of 
LO :-)

In case someone is interested I will supply a short example (Qt/MinGW based) 
how to start an LO with an empty "sheet of paper" out of a small program. I 
don't want to pollute the list, therefore tell me a (central) address where to 
send the files to.

Thanks,
Helmar

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