[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf



Hi,

On Sat, Feb 25, 2012 at 01:49:02PM +0000, 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


Reply to: