sys/mount.h not C++ clean on kfreebsd
Libreoffice failed to build on kfreebsd-i386 and kfreebsd-amd64 with the following error. Compiling: sal/osl/unx/file_volume.cxx In file included from /build/buildd-libreoffice_3.4.5-3-kfreebsd-amd64-ukEv52/libreoffice-3.4.5/libreoffice-build/build/libreoffice-3.4.5.2/sal/osl/unx/file_volume.cxx:77:0: /usr/include/x86_64-kfreebsd-gnu/sys/mount.h: In function 'int getvfsbyname(const char*, xvfsconf*)': /usr/include/x86_64-kfreebsd-gnu/sys/mount.h:398:23: error: invalid conversion from 'void*' to 'xvfsconf*' [-fpermissive] /build/buildd-libreoffice_3.4.5-3-kfreebsd-amd64-ukEv52/libreoffice-3.4.5/libreoffice-build/build/libreoffice-3.4.5.2/sal/osl/unx/file_volume.cxx: At global scope: /build/buildd-libreoffice_3.4.5-3-kfreebsd-amd64-ukEv52/libreoffice-3.4.5/libreoffice-build/build/libreoffice-3.4.5.2/sal/osl/unx/file_volume.cxx:1153:17: warning: unused parameter 'pszPath' [-Wunused-parameter] /build/buildd-libreoffice_3.4.5-3-kfreebsd-amd64-ukEv52/libreoffice-3.4.5/libreoffice-build/build/libreoffice-3.4.5.2/sal/osl/unx/file_volume.cxx:1153:17: warning: unused parameter 'pItem' [-Wunused-parameter] /build/buildd-libreoffice_3.4.5-3-kfreebsd-amd64-ukEv52/libreoffice-3.4.5/libreoffice-build/build/libreoffice-3.4.5.2/sal/osl/unx/file_volume.cxx:1160:17: warning: unused parameter 'pDevice' [-Wunused-parameter] /build/buildd-libreoffice_3.4.5-3-kfreebsd-amd64-ukEv52/libreoffice-3.4.5/libreoffice-build/build/libreoffice-3.4.5.2/sal/osl/unx/file_volume.cxx:555:35: warning: 'oslVolumeDeviceHandleImpl* osl_newVolumeDeviceHandleImpl()' defined but not used [-Wunused-function] /build/buildd-libreoffice_3.4.5-3-kfreebsd-amd64-ukEv52/libreoffice-3.4.5/libreoffice-build/build/libreoffice-3.4.5.2/sal/osl/unx/file_volume.cxx:579:13: warning: 'void osl_freeVolumeDeviceHandleImpl(oslVolumeDeviceHandleImpl*)' defined but not used [-Wunused-function] /build/buildd-libreoffice_3.4.5-3-kfreebsd-amd64-ukEv52/libreoffice-3.4.5/libreoffice-build/build/libreoffice-3.4.5.2/sal/osl/unx/file_volume.cxx:1153:17: warning: 'sal_Bool osl_getFloppyMountEntry(const sal_Char*, oslVolumeDeviceHandleImpl*)' defined but not used [-Wunused-function] /build/buildd-libreoffice_3.4.5-3-kfreebsd-amd64-ukEv52/libreoffice-3.4.5/libreoffice-build/build/libreoffice-3.4.5.2/sal/osl/unx/file_volume.cxx:1160:17: warning: 'sal_Bool osl_isFloppyMounted(oslVolumeDeviceHandleImpl*)' defined but not used [-Wunused-function] dmake: Error code 1, while making '../../unxkfgx6.pro/obj/file_volume.obj' Retrying /build/buildd-libreoffice_3.4.5-3-kfreebsd-amd64-ukEv52/libreoffice-3.4.5/libreoffice-build/build/libreoffice-3.4.5.2/sal/osl/unx A simple test program including the header (and with an empty main function) compiles fine when built as C but fails when built as C++. So it looks like this is a case of the header not being C++ clean (implicit conversion from void* to other pointer types is allowed in C but not in C++). Presumablly the fix is to add an explicit typecast. I would file a bug report but packages.debian.org doesn't seem to want to tell me what package sys/mount.h is in. -- 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/4f48d24d.60...@p10link.net
Re: sys/mount.h not C++ clean on kfreebsd
Hi, On Sat, Feb 25, 2012 at 12:21:33PM +, peter green wrote: Compiling: sal/osl/unx/file_volume.cxx In file included from /build/buildd-libreoffice_3.4.5-3-kfreebsd-amd64-ukEv52/libreoffice-3.4.5/libreoffice-build/build/libreoffice-3.4.5.2/sal/osl/unx/file_volume.cxx:77:0: /usr/include/x86_64-kfreebsd-gnu/sys/mount.h: In function 'int getvfsbyname(const char*, xvfsconf*)': /usr/include/x86_64-kfreebsd-gnu/sys/mount.h:398:23: error: invalid conversion from 'void*' to 'xvfsconf*' [-fpermissive] Already pointed out on http://lists.debian.org/debian-bsd/2012/02/msg00061.html see also http://lists.debian.org/debian-bsd/2012/02/msg00080.html And aurel32 promised that upload for this weekend :) I would file a bug report but packages.debian.org doesn't seem to want to tell me what package sys/mount.h is in. libc0.1-dev 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/20120225125603.gf17...@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: sys/mount.h not C++ clean on kfreebsd
El 25 de febrer de 2012 12:56, Rene Engelhard r...@debian.org ha escrit: I would file a bug report but packages.debian.org doesn't seem to want to tell me what package sys/mount.h is in. libc0.1-dev There's already #660397 and #660401. -- Robert Millan -- 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/caofdtxoawacsese6fkeec87kk-jelepq2sow11ayzl_--xd...@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
Bug#661294: libreoffice FTBFS on alpha because of unsatisfiable build-depends on libgraphite2-dev
Source: libreoffice Version: 1:3.4.5-3 Severity: normal User: debian-al...@lists.debian.org Usertags: alpha X-Debbugs-CC: debian-al...@lists.debian.org libreoffice can't be built on the Alpha architecture because graphite2 FTBFS, thus the build-dependency on libgraphite2-dev cannot be satisfied. I see that armel and sparc have the same problem and that it has been resolved by removing the build-dependency on libgraphite2-dev for those architectures. I am asking that the same be done for Alpha. Please note that openoffice has built in the past on Alpha---about nine months ago we had an installable and also working version of openoffice. Thanks Michael -- 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/4f4983ab.10...@orcon.net.nz
