Re: LibreOffice-SDK for MinGW
Hi Joachim! Am Montag, 6. Mai 2013, 14:50:45 schrieb Joachim Langenbach: > Dear Helmar and Kendy, > > I'm also trying to build the LibreOffice SDK with MinGW. Goal is to connect > an > application compiled with MinGW to LibreOffice on Windows, Linux and may be > other platforms. Since my attampts to cross compile LibreOffice are not very > successfully, I have two questions, before investing more time in that. In case youare interested I can submit my MinGW development environment for LO --- the office as stand-alone "beast" seems to work pretty well with some adjustments in the code (at least as far I was able to test it...). Please contact me directly on my e-mail account, I think there is too much code to be transferred via the list... Difficulties arise as soon as the UNO-environment contacts the office and tries to get information with regards to services and interfaces. To be very cautious: I have the feeling that the information submitted by the office is correct, but somehow allocated memory in the UNO bridge seems to get corrupted (under very special circumstances I was able to remote control the office to create a new document...). Since the UNO-bridge is based on several threads my guess is that there is a problem with thread-safe use of shared memory. Unfortunately, at the moment I am bound with a money earning project, so my time for this issue is rather limited. However, I definitely will help in any possible way to solve this problem. > > > So far the MinGW build is still a very experimental thing; I mostly use > > that when I develop something Windows-only because I can still keep my > > workflow, but as the binaries built with the MinGW SDK will be > > incompatible with the LibreOffice release builds, I am not sure it makes > > much sense to invest effort in that at this stage. > > Does it mean, that an application linked against the MinGW SDK, could not > connect to a MSVC standard libreoffice installation? Well, I use a 2 years old SDK (MinGW) which is able to connect to an off-the-shelf MS-LibreOffice. Sure, there are some shortcomings (not all event listeners work properly), but for my application it is sufficient. > > And second, what are the alternatives of using the SDK to connect to > LibreOffce > (if an compiler switch to MSVC is not wanted)? Ole connection may be used, > but > ole is not platform independent (or is it available under linux or MacOS?). SDK and Linux is a dream - it simply works. SDK and Windows is not so easy (I have problems to compile the SDK stuff under MSVC - however my MSVC knowledge is rather small; I definitely would prefer MinGW). A (Mac-addicted) colleague told me that the SDK for MacOS available half a year ago only contained code for 32-Bit Macs, which does not work with recent 64-Bit machines/os'es. I don't know the actual situation with regards to that issue, but I would expect that using the correct wordlength the MacOS-SDK should be comparable to the Linux version. Best wishes, Helmar > > Are there any other possiblities or have the SDK or OLE connection some other > advantages and disadvantages? > > Kind regards, > > Joachim Langenbach > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > > signature.asc Description: This is a digitally signed message part. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
LibreOffice-SDK for MinGW
Hi, is it possible to create the sdk package on the nightly builds for MinGW? On my system (SuSE 12.3 / x86-64) with the actual mingw packages I run into big problems. To get LO compiled I had to do some code adjustments (in case you are interested, I will send them later); I managed to get the compiled LO run under wine and windows. However, the sdk worked only as long as I did not contact LO, it seems that there are some problems transfering the control structures to the environment. I suspect, the MinGW threads in my environment do something horrible to the data;in a debug session I can see, something probably reasonable is transferred, but later, trying to use the data, ends aup with a crash. I mean "reasonable" since it was once possible to control LO remotely - I must have had a constellation of the memory which kept the structures untouched. But as soon I changed the code adding functions or other stuff, everything crashed. Thanks in advance, Helmar Spangenberg ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: MinGW-Port: Problems with UnoUrlResolver
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
Re: Problems to access table columns via UNO interface
Hi Michael, Am Freitag, 9. März 2012, 09:51:06 schrieb Michael Meeks: > > for example. In this case you're going to need to read the code I think > to work out what's up. Personally, I loathe the (IMHO brain-damaged) > design choice of using (y, x) instead of (x, y) as all right thinking > people do ;-) but at least you seem to get that right - there are 5 > columns. > > > tabelle->initialize(2, 5); > > Reference tcols (tabelle->getColumns(), UNO_SET_THROW); > > pval <<= tcols->getByIndex(2); > > So I'd read around sw/source/core/unocore/unotbl.cxx in particular: > > uno::Any SwXTableColumns::getByIndex(sal_Int32 nIndex) > > And see what is going on there :-) Last night, after several hours reading the big manual called source code and reading several comments in the lists reaching back to 2003 I actually found in sw/source/core/unocore/unotbl.cxx within the function getByIndex() the coment "!! writer tables do not have columns!!". A little bit mean is, this function seems to do something maybe useful, but at the end unconditionally returns an empty XInterface :-( Thus, my nice idea of creating extending tables in a text probably never will work... As a workaround I am now experimenting with text frames to set up a table-like structure. Seems to work rather nice (although a little bit slow); the only issue is to force the frames to have an equal height (depending on that frame containing the highest amount of text). Is there a possibility to obtain the physical position of a text or whatever cursor on the page? Thanks, Helmar___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: MinGW-Port: Problems with UnoUrlResolver
> > 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
Problems to access table columns via UNO interface
Hello list,
I have difficulties to access table columns (and rows) via the UNO interface.
I have no problems to create a table, but I am not able to manipulate the
properties of the columns.
Basically my code can be nailed down to
Reference docServices (rDocument, UNO_QUERY_THROW);
Reference tabelle(docServices->
createInstance(OUString::createFromAscii("com.sun.star.text.TextTable")),
UNO_QUERY_THROW);
tabelle->initialize(2, 5);
Reference tcols (tabelle->getColumns(), UNO_SET_THROW);
Any pval;
pval <<= tcols->getByIndex(2);
Reference s_properties(pval, UNO_QUERY_THROW);
Some debugging showed that the method getByIndex returns an Any with a pointer
to 0. Since in my case "tcols" seems to be initiated correctly
(tcols->getCount() returns 5 as expected, and tcols->hasElements() returns
true),
can someone please tell me what is wrong in my code!
I am using LO-3.5 as distributed from www.libreoffice.org; I observe this
behavior under SuSE Linux 12.1 (64bit).
Thanks in advance,
Helmar
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: MinGW-Port: Problems with UnoUrlResolver
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
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
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
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
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
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
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
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
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
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
MinGW-Port: Problems with UnoUrlResolver
Hello List, I have a working Qt/C++ application connecting to the office using ::cppu::bootstrap(). After porting this application to MinGW, I got a BootstrapException saying "unexpected UNO exception caught: component context fails to supply service com.sun.star.bridge.UnoUrlResolver of type com.sun.star.bridge.XUnoUrlResolver". Going down to the basics I compiled the example office_connect.cxx under MinGW and got the error message "Couldn't instantiate com.sun.star.bridge.UnoUrlResolver service". I have the feeling that some information is missing, but I don't know how to submit it. All environmental variables known to me don't help. Is there anybody who can give me a hint what I should do? 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. Thanks, Helmar___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
