LibreOffice-SDK for MinGW
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. 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? 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?). 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
Re: LibreOffice-SDK for MinGW
Dear Jan and Stephan, Joachim Langenbach píše v Po 06. 05. 2013 v 14:50 +0200: 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. What exact failures did you have, please? I've tried building 3.6.6.2 and 4.0.3.3. Both versions are configured with the attached autogen.lastrun on an OpenSUSE system with installed mingw32 packages from OpenSUSE build service. Within the 4.0.3.3 version I have fixed already some errors (e. g. lcms.h). The 3.6.6.2 are in original state. The errors I have currently are listed in the attached log files. 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? I am afraid this is the case so far :-( Thanks for this clarification! And second, what are the alternatives of using the SDK to connect to LibreOffce (if an compiler switch to MSVC is not wanted)? Basically the advice would be to use Java or Python I'm afraid. But I suppose you want to connect a C or C++ application to LibreOffice, is that correct? In that case getting the MinGW SDK working would be best. But if your MinGW approach fails, you might experiment with actually using the Python bridge from your C++ code using Boost.Python - that will perform worse than direct C++, but will be able to connect even to the LibreOffice built using MSVC. Or (and that might be easier) create a small Python wrapper that calls the functions / services you need from SDK, and provides your application with a simple API, and you'd call functions of this wrapper from your C++ code using Boost.Python. Ok, thanks for your hints. Since I'm developing with Qt, an python extension of the Qt-c++ application seems to be also a good option for me than. This should be platform independent also. Ole connection may be used, but ole is not platform independent (or is it available under linux or MacOS?). Are there any other possiblities or have the SDK or OLE connection some other advantages and disadvantages? I'd say here it depends on what exactly do you need to achieve... From Stephan: Depends on what you mean with connect. Two independent processes communicating via the URP protocol should be fine. Trying to load any libraries from the MSVC-based LO installation into your MinGW-based process would obviously fail. You are right, the term connect is not really clear here. My goal is to read and write office files from my application. Therefore I designed an interface. Than I can implement the interface within plugins, which utilize different tools to read and write the files. For example one plugin handles CSV files, another uses MS Office per OLE and another should use LibreOffice. So connect is meant as any possible interaction between libreoffice and my plugin to read and write office files (precisly spreadsheets). Kind regards, Joachim Langenbach/usr/local/src/libreoffice/libreoffice-4.0.3.3/solenv/gbuild/Package.mk:44: *** gb_Deliver_deliver: file does not exist in solver, and cannot be delivered: /usr/local/src/libreoffice/libreoffice-4.0.3.3/solver/unxlngi6.pro/lib/libvcllo.so. Schluss. log for /usr/local/src/libreoffice/libreoffice-core-3.6.6.2/glib patching file glib-2.28.1/build/win32/dirent/makefile.msc Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 2 out of 2 hunks ignored -- saving rejects to file glib-2.28.1/build/win32/dirent/makefile.msc.rej patching file glib-2.28.1/build/win32/make.msc Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 5 out of 5 hunks ignored -- saving rejects to file glib-2.28.1/build/win32/make.msc.rej patching file glib-2.28.1/gio/gzlibcompressor.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 3 out of 3 hunks ignored -- saving rejects to file glib-2.28.1/gio/gzlibcompressor.c.rej patching file glib-2.28.1/gio/gzlibdecompressor.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 3 out of 3 hunks ignored -- saving rejects to file glib-2.28.1/gio/gzlibdecompressor.c.rej patching file glib-2.28.1/gio/makefile.msc Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 9 out of 9 hunks ignored -- saving rejects
Re: LibreOffice-SDK for MinGW
Hi Helmar, 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... May be also others (including the libreoffice team, e. g. dtardon) are interested in those files. Is there another (public) way to share those files easily? (May be github or something like that) 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. Ok, so it seems to be at least an alternative. 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. Over all, the SDK seems to be not as platfrom independent as the LibreOffice project itself. Regards, Joachim ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
