Re: libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf
Hi, On Sat, Feb 25, 2012 at 02:16:09PM +, Luke Kenneth Casson Leighton wrote: # file /usr/share/libreoffice/sdk/classes/win/unowinreg.dll /usr/share/libreoffice/sdk/classes/win/unowinreg.dll: PE32 executable (DLL) (console) Intel 80386 (stripped to external PDB), for MS Windows i686-w64-mingw32-g++ is called. that's different from mingw-w64, then. Wrong. that is mingw-64. peter already said that, though. simply wouldn't even run on an ARM processor anyway seems to have entirely escaped everyone's attention. No. In contast, Stephen said it correctly. actually, he didn't: in the public post he didn't mention that it was purely for shipping with the *windows* version of libreoffice, so that That's wrong anyway. The windows version of libreoffice doesn't even ship it either. It's the *SDK* shipping this. On all archs. For being ale to create cross-platform Java stuff there (which also then runs on windows as intended) people who perform development on gnu/linux of libreoffice applications can ship the libreoffice application with that DLL *such that* the *windows* version of libreoffice will actually work and have access to the windows dll. He said that, sorry. --- snip --- [...] is supposed to be bundled with plugins which need to access the registry, and therefore to be able to correctly build shippable plugins [...] --- snip --- your bullying and lack of forgiveness is duly noted. And you do have one? I didn't see it formulated in your unpolite mail at least. Regards, Rene -- To UNSUBSCRIBE, email to debian-openoffice-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120226202859.gj17...@rene-engelhard.de
Re: libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf
On Fri, Feb 3, 2012 at 5:48 AM, Stephen Kitt st...@sk2.org wrote: Hi Peter, On Fri, Feb 03, 2012 at 02:36:17AM +, peter green wrote: Libreoffice hasn't yet been built on armhf. I consider libreoffice to be a reasonablly important package and one that we need to get in before we can claim we have a reasonablly complete port. [...] This (build-)dependency chain leaves me with a few questions 1: what is the current status of gnat-4.6 on armhf? does an upload look likely any time soon? 2: why does libreoffice need mingw-w64 in the first place? libreoffice uses mingw-w64 to build a DLL, unowinreg.dll, which is provided in the libreoffice-dev package. As I understand it the DLL itself isn't used on Debian, but it is provided by the SDK because it is supposed to be bundled with plugins which need to access the registry, and therefore to be able to correctly build shippable plugins using Debian the SDK packages need to provide the DLL. it's even more hilarious than that: it's actually because java can't access windows registry functions, so someone wrote a c-based DLL which java *can* bind to. the fact that the end-result of the mingw-w64 cross-compiler output would be an x86 64-bit DLL, which simply wouldn't even run on an ARM processor anyway seems to have entirely escaped everyone's attention. i describe the chain here, and have made a request on behalf of the sanity of the debian-arm team that the libreoffice developers consider adding a compile-time switch to remove the complete mental brain-fart retardation from the software for which they are responsible: https://bugs.freedesktop.org/show_bug.cgi?id=46614 let's see if they have a sense of humour, eh? l. -- To UNSUBSCRIBE, email to debian-openoffice-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDyj=rqmiekmqe2z1u03hvr8_27dkdsjzfcyjtma2jl...@mail.gmail.com
Re: libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf
Hi, On Sat, Feb 25, 2012 at 01:49:02PM +, Luke Kenneth Casson Leighton wrote: it's even more hilarious than that: it's actually because java can't access windows registry functions, so someone wrote a c-based DLL which java *can* bind to. the fact that the end-result of the Yes, that is the point. mingw-w64 cross-compiler output would be an x86 64-bit DLL, which No, it's a 32 bit dll. # file /usr/share/libreoffice/sdk/classes/win/unowinreg.dll /usr/share/libreoffice/sdk/classes/win/unowinreg.dll: PE32 executable (DLL) (console) Intel 80386 (stripped to external PDB), for MS Windows i686-w64-mingw32-g++ is called. simply wouldn't even run on an ARM processor anyway seems to have entirely escaped everyone's attention. No. In contast, Stephen said it correctly. [...] isn't used on Debian, but it is provided by the SDK because it is supposed to be bundled with plugins [...] and therefore to be able to correctly build shippable plugins using Debian the SDK packages need to provide the DLL. i describe the chain here, and have made a request on behalf of the sanity of the debian-arm team that the libreoffice developers consider adding a compile-time switch to remove the complete mental brain-fart retardation from the software for which they are responsible: https://bugs.freedesktop.org/show_bug.cgi?id=46614 To be fair, that all is inherited from OOo. And it's a non-issue now that we *do* have mingw-w64 on armhf. let's see if they have a sense of humour, eh? If the bug is formulated like the nonsense in this post I won't believe so. Regards, Rene -- To UNSUBSCRIBE, email to debian-openoffice-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120225140424.gg17...@rene-engelhard.de
Re: libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf
On Sat, Feb 25, 2012 at 2:04 PM, Rene Engelhard r...@debian.org wrote: Hi, On Sat, Feb 25, 2012 at 01:49:02PM +, Luke Kenneth Casson Leighton wrote: it's even more hilarious than that: it's actually because java can't access windows registry functions, so someone wrote a c-based DLL which java *can* bind to. the fact that the end-result of the Yes, that is the point. mingw-w64 cross-compiler output would be an x86 64-bit DLL, which No, it's a 32 bit dll. yes - steven kindly privately outlined a bit more detail about what's involved: he said that it's actually part of the developer kit. # file /usr/share/libreoffice/sdk/classes/win/unowinreg.dll /usr/share/libreoffice/sdk/classes/win/unowinreg.dll: PE32 executable (DLL) (console) Intel 80386 (stripped to external PDB), for MS Windows i686-w64-mingw32-g++ is called. that's different from mingw-w64, then. simply wouldn't even run on an ARM processor anyway seems to have entirely escaped everyone's attention. No. In contast, Stephen said it correctly. actually, he didn't: in the public post he didn't mention that it was purely for shipping with the *windows* version of libreoffice, so that people who perform development on gnu/linux of libreoffice applications can ship the libreoffice application with that DLL *such that* the *windows* version of libreoffice will actually work and have access to the windows dll. [...] isn't used on Debian, but it is provided by the SDK because it is supposed to be bundled with plugins [...] and therefore to be able to correctly build shippable plugins using Debian the SDK packages need to provide the DLL. i describe the chain here, and have made a request on behalf of the sanity of the debian-arm team that the libreoffice developers consider adding a compile-time switch to remove the complete mental brain-fart retardation from the software for which they are responsible: https://bugs.freedesktop.org/show_bug.cgi?id=46614 To be fair, that all is inherited from OOo. And it's a non-issue now that we *do* have mingw-w64 on armhf. hurrah! let's see if they have a sense of humour, eh? If the bug is formulated like the nonsense in this post I won't believe so. your bullying and lack of forgiveness is duly noted. l. -- To UNSUBSCRIBE, email to debian-openoffice-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDyN1EbYuENW8Ph=u5xayzmq8_d2mchwrlpmrp7ezkp...@mail.gmail.com
Re: libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf
Luke Kenneth Casson Leighton wrote: i686-w64-mingw32-g++ is called. that's different from mingw-w64, then. No it's *part of* mingw-w64. Mnigw-w64 is a fork of mingw32 and provides toolchains targetting both 32-bit and 64-bit windows. These toolchains (at least in debian, not sure about upstream) have triplets i686-w64-mingw32 and x86_64-w64-mingw32 . To be fair, that all is inherited from OOo. And it's a non-issue now that we *do* have mingw-w64 on armhf. hurrah! Yeah, I provided the gcc-mingw-w64 maintainers with a patch that disabled gnat support on armhf allowing the rest of the package to be built and the libreoffice build to be tried. Thanks to everyone who helped get libreoffice into armhf unstable. -- To UNSUBSCRIBE, email to debian-openoffice-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f49688e.6040...@p10link.net
Re: libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf
Hi,
Libreoffice hasn't yet been built on armhf. I consider libreoffice to be
a reasonablly important package and one that we need to get in before we
can claim we have a reasonablly complete port.
And the segfault described on
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/900636 and
experienced on harris, too?:
Making: all_bridgetest.dpslo
cd ../../unxlngr.pro/lib :
LD_LIBRARY_PATH=/build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/solver/340/unxlngr.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
/build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/solver/340/unxlngr.pro/bin/uno
\
-ro uno_services.rdb -ro uno_types.rdb \
-s com.sun.star.test.bridge.BridgeTest -- \
com.sun.star.test.bridge.CppTestObject
/bin/bash: line 1: 11210 Segmentation fault
LD_LIBRARY_PATH=/build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/solver/340/unxlngr.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
/build/buildd/libreoffice-3.4.4/libreoffice-build/build/libreoffice-3.4.3.2/solver/340/unxlngr.pro/bin/uno
-ro uno_services.rdb -ro uno_types.rdb -s com.sun.star.test.bridge.BridgeTest
-- com.sun.star.test.bridge.CppTestObject
dmake: Error code 139, while making 'runtest'
I don't see a fast sollution soon. (maybe we can just disable java and python
etc and look whether that one works, but that would be crippling
and I am not sure whether the bridge is also needed for other features. amd64
bugs in the bridges e.g. also affected calc computation back in the
past...)
I've pointed that one out already on #debian-arm...
For the why do you need mingw-w64? part, Stephen already answered it
correctly.
Regards,
Rene
--
To UNSUBSCRIBE, email to debian-openoffice-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120203093726.45...@gmx.net
libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf
Libreoffice hasn't yet been built on armhf. I consider libreoffice to be a reasonablly important package and one that we need to get in before we can claim we have a reasonablly complete port. The reason libreoffice isn't built is because mingw-w64 is not installable. The reason mingw-w64 is not installable is because gcc-mingw-w64 isn't built. The reason gcc-mingw-w64 isn't built is because gnat-4.6 is not built My understanding from a previous reply Konstantinos sent me is that gnat-4.6 is not built on armhf because it needs porting followed by manual boostrapping. This (build-)dependency chain leaves me with a few questions 1: what is the current status of gnat-4.6 on armhf? does an upload look likely any time soon? 2: why does libreoffice need mingw-w64 in the first place? 3: why are we building an ada cross compiler for windows? is it just for completeness or was/is there an identified requirement? 4: if we can't get an ada compiler on armhf in the near future would anyone consider it unreasonable to build gcc-mingw-w64 without ada suport on armhf so that libreoffice can be built? -- To UNSUBSCRIBE, email to debian-openoffice-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f2b4821.8040...@p10link.net
Re: libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf
Hi Peter, On Fri, Feb 03, 2012 at 02:36:17AM +, peter green wrote: Libreoffice hasn't yet been built on armhf. I consider libreoffice to be a reasonablly important package and one that we need to get in before we can claim we have a reasonablly complete port. [...] This (build-)dependency chain leaves me with a few questions 1: what is the current status of gnat-4.6 on armhf? does an upload look likely any time soon? 2: why does libreoffice need mingw-w64 in the first place? libreoffice uses mingw-w64 to build a DLL, unowinreg.dll, which is provided in the libreoffice-dev package. As I understand it the DLL itself isn't used on Debian, but it is provided by the SDK because it is supposed to be bundled with plugins which need to access the registry, and therefore to be able to correctly build shippable plugins using Debian the SDK packages need to provide the DLL. 3: why are we building an ada cross compiler for windows? is it just for completeness or was/is there an identified requirement? It was requested; see #632375. 4: if we can't get an ada compiler on armhf in the near future would anyone consider it unreasonable to build gcc-mingw-w64 without ada suport on armhf so that libreoffice can be built? I wouldn't; I can definitely upload a new version of gcc-mingw-w64 which drops Ada support on armhf. Regards, Stephen -- To UNSUBSCRIBE, email to debian-openoffice-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120203054832.gu5...@sk2.org
