FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian GCC

 
 
LinkBack Thread Tools
 
Old 02-03-2012, 04:48 AM
Stephen Kitt
 
Default libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf

Hi Peter,

On Fri, Feb 03, 2012 at 02:36:17AM +0000, 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-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120203054832.GU5919@sk2.org">http://lists.debian.org/20120203054832.GU5919@sk2.org
 
Old 02-03-2012, 08:37 AM
"Rene Engelhard"
 
Default 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-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120203093726.45690@gmx.net">http://lists.debian.org/20120203093726.45690@gmx.net
 
Old 02-03-2012, 10:46 AM
peter green
 
Default libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf

Rene Engelhard wrote:

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?:


I wasn't aware of that

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...)


looks way out of my league.

I've pointed that one out already on #debian-arm...

Not all of us live on irc, if you want to get something through to
everyone working on the port the mailing list is probablly a better bet.

For the "why do you need mingw-w64?" part, Stephen already answered it correctly.


Thanks for explaining.


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F2BC912.6060505@p10link.net">http://lists.debian.org/4F2BC912.6060505@p10link.net
 
Old 02-25-2012, 12:49 PM
Luke Kenneth Casson Leighton
 
Default libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf

On Fri, Feb 3, 2012 at 5:48 AM, Stephen Kitt <steve@sk2.org> wrote:
> Hi Peter,
>
> On Fri, Feb 03, 2012 at 02:36:17AM +0000, 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-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAPweEDyj=RQMiEKMQE2Z1u03hvR8_27DkdsjzFcyjtMA2JLw9 A@mail.gmail.com">http://lists.debian.org/CAPweEDyj=RQMiEKMQE2Z1u03hvR8_27DkdsjzFcyjtMA2JLw9 A@mail.gmail.com
 
Old 02-25-2012, 01:04 PM
Rene Engelhard
 
Default 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


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120225140424.GG17772@rene-engelhard.de">http://lists.debian.org/20120225140424.GG17772@rene-engelhard.de
 
Old 02-25-2012, 01:16 PM
Luke Kenneth Casson Leighton
 
Default libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf

On Sat, Feb 25, 2012 at 2:04 PM, Rene Engelhard <rene@debian.org> wrote:
> 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.

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-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAPweEDyN1EbYuENW8Ph=u5Xayzmq8_d2mChwRLPMRP7EzkpNC Q@mail.gmail.com">http://lists.debian.org/CAPweEDyN1EbYuENW8Ph=u5Xayzmq8_d2mChwRLPMRP7EzkpNC Q@mail.gmail.com
 
Old 02-25-2012, 10:02 PM
peter green
 
Default 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-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F49688E.6040401@p10link.net">http://lists.debian.org/4F49688E.6040401@p10link.net
 
Old 02-26-2012, 07:28 PM
Rene Engelhard
 
Default libreoffice, mingw-w64, gcc-mingw-w64 and gnat-4.6 on armhf

Hi,

On Sat, Feb 25, 2012 at 02:16:09PM +0000, 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-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120226202859.GJ17772@rene-engelhard.de">http://lists.debian.org/20120226202859.GJ17772@rene-engelhard.de
 

Thread Tools




All times are GMT. The time now is 10:05 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org