Help --- OOO300_m9 --- openoffice cross compile

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Help --- OOO300_m9 --- openoffice cross compile

Caesar-3
Hi all,

All those days, I was trying to cross compile openoffice OOO300_m9, and the
entire procedure functioned pretty well on both x86 and ARM(simulated)
native environments.
However, when I tried to have it compiled on the environment provided by
scratchbox, it failed.
First, it fails because of a glibc bug which relates to the flag
"-rpath,'$ORIGIN'", then I solved it by remove 4 of these flags from the
unxlngr.mk file and 3 other *.mk files under subdirectories of the redland
directory. But my qestion is does this would cause any side effect?
And the next time it fails when it's compiling the udkapi or offapi modules
with the following info.
------------------------------
------------------------------

idlc: could not create registry file
'file:///local/ooo-build/ooo-build/build/src680-m175/udkapi/
unxlngx6.pro/ucrdoc/com/sun/star/bridge/BridgeExistsException._idlc_'
......dmake: Error: -- `../unxlngr.pro/ucr/cssawt.db' not found, and can't
be madeERROR: Error 65280 occurred while making
/home/caesar/OOo/OOO300_m9/offapi/util
......dmake: Error: -- `../unxlngr.pro/ucr/cssbridge.db' not found, and
can't be madeERROR: Error 65280 occurred while making
/home/caesar/OOo/OOO300_m9/udkapi/util
-------------------------------------------------------------
And the last two messages corresponding to modules offapi and udkapi,
respectively, when it failed, one of this two will pop up.
Sometimes, no error pops up when it's compiling module udkapi and offapi,
but several minutes later, errors pop up and message tells me this:
--------------------------------------------------------------
cc1plus: warning: include location "/usr/include" is unsafe for
cross-compilation
In file included from ../../inc/com/sun/star/uno/Any.h:35,
                 from ../../inc/cppu/helper/purpenv/Mapping.hxx:34,
                 from
/home/caesar/OOo/OOO300_m9/cppu/source/AffineBridge/AffineBridge.cxx:39:
../../inc/com/sun/star/uno/Type.h:35:42: error:
com/sun/star/uno/TypeClass.hdl:No such file or directory
In file included from ../../inc/com/sun/star/uno/Any.h:35,
                 from ../../inc/cppu/helper/purpenv/Mapping.hxx:34,
                 from
/home/caesar/OOo/OOO300_m9/cppu/source/AffineBridge/AffineBridge.cxx:39:
../../inc/com/sun/star/uno/Type.h:99: error: expected `)' before
'eTypeClass'
../../inc/com/sun/star/uno/Type.h:106: error: expected `)' before
'eTypeClass'
../../inc/com/sun/star/uno/Type.h:151: error: 'TypeClass' does not name a
type
In file included from ../../inc/cppu/helper/purpenv/Mapping.hxx:34,
                 from
/home/caesar/OOo/OOO300_m9/cppu/source/AffineBridge/AffineBridge.cxx:39:
../../inc/com/sun/star/uno/Any.h:150: error: 'TypeClass' does not name a
type
dmake:  Error code 1, while making '../../unxlngr.pro/slo/AffineBridge.obj'

ERROR: Error 65280 occurred while making
/home/caesar/OOo/OOO300_m9/cppu/source/AffineBridge
rmdir /tmp/22127
dmake:  Error code 1, while making 'build_instsetoo_native'
--------------------------------------------------------------
Furthermore, I notised that the typesconfig crashed during the compilation
of the module sal because of the qemu fails to support something
---------------------------------------------------------------
char            = unsigned
char
short           = signed
short
int             = signed
int
long            = signed
long
long long               = signed long
long
sizeof(short)           =
2
sizeof(int)             =
4
sizeof(long)            =
4
sizeof(long long)               =
8
sizeof(float)           = 4
sizeof(double)          = 8
sizeof(void *)          = 4
LITTLEENDIAN (Intel, x86-64, PowerPC(LE))
qemu: uncaught target signal 11 (Segmentation fault) - exiting
cannot read address (nil)
qemu: uncaught target signal 11 (Segmentation fault) - exiting
cannot write address (nil)
can read address 0x4007dca4
can write address 0x4007dca4
Access short on 8-Aligned Address : OK
Access short on 4-Aligned Address : OK
Access short on 2-Aligned Address : OK
qemu: uncaught target signal 6 (Aborted) - exiting
Access short on 1-Aligned Address : ERROR
Access int on 8-Aligned Address : OK
Access int on 4-Aligned Address : OK
qemu: uncaught target signal 6 (Aborted) - exiting
Access int on 2-Aligned Address : ERROR
qemu: uncaught target signal 6 (Aborted) - exiting
Access int on 1-Aligned Address : ERROR
Access long on 8-Aligned Address : OK
Access long on 4-Aligned Address : OK
qemu: uncaught target signal 6 (Aborted) - exiting
Access long on 2-Aligned Address : ERROR
qemu: uncaught target signal 6 (Aborted) - exiting
Access long on 1-Aligned Address : ERROR
Access double on 8-Aligned Address : OK
qemu: uncaught target signal 6 (Aborted) - exiting
Access double on 4-Aligned Address : ERROR
qemu: uncaught target signal 6 (Aborted) - exiting
Access double on 2-Aligned Address : ERROR
qemu: uncaught target signal 6 (Aborted) - exiting
Access double on 1-Aligned Address : ERROR
---------------------------------------------------------------

So, can anyone tells me what is going on, and what I need to do to handle
those errors.
Thanks in advance!

Best,

S. Caesar Huang

P.S.:
Info. of my environment:
HOST: x86 Ubuntu 8.10 system
TARGET: ARMv5tel
Reply | Threaded
Open this post in threaded view
|

Re: Help --- OOO300_m9 --- openoffice cross compile

Rene Engelhard-7
Hi,

Caesar wrote:
> First, it fails because of a glibc bug which relates to the flag
> "-rpath,'$ORIGIN'", then I solved it by remove 4 of these flags from the
> unxlngr.mk file and 3 other *.mk files under subdirectories of the redland

That will make your office not usable.

> directory. But my qestion is does this would cause any side effect?

Yes. (See above)

> And the next time it fails when it's compiling the udkapi or offapi modules
> with the following info.
[...]
> And the last two messages corresponding to modules offapi and udkapi,
> respectively, when it failed, one of this two will pop up.
> Sometimes, no error pops up when it's compiling module udkapi and offapi,
> but several minutes later, errors pop up and message tells me this:
[...]
> --------------------------------------------------------------
> cc1plus: warning: include location "/usr/include" is unsafe for
> cross-compilation

yes, it is.

> Furthermore, I notised that the typesconfig crashed during the compilation
> of the module sal because of the qemu fails to support something
[...]
> So, can anyone tells me what is going on, and what I need to do to handle
> those errors.

Build natively.

Regards,

Rene

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Help --- OOO300_m9 --- openoffice cross compile

Caesar-3
Hi Rene,

Thanks!
Indeed, I have finished native compilation.
But my mission is to perform cross compilaion.

Whatever, could you please tell me what is the side effect related to the
remove of the flag "-rpath,'$ORIGIN'".

Thank you very much!

Best,

S. Caesar Huang
On Tue, Dec 16, 2008 at 9:48 PM, Rene Engelhard <[hidden email]> wrote:

> Hi,
>
> Caesar wrote:
> > First, it fails because of a glibc bug which relates to the flag
> > "-rpath,'$ORIGIN'", then I solved it by remove 4 of these flags from the
> > unxlngr.mk file and 3 other *.mk files under subdirectories of the
> redland
>
> That will make your office not usable.
>
> > directory. But my qestion is does this would cause any side effect?
>
> Yes. (See above)
>
> > And the next time it fails when it's compiling the udkapi or offapi
> modules
> > with the following info.
> [...]
> > And the last two messages corresponding to modules offapi and udkapi,
> > respectively, when it failed, one of this two will pop up.
> > Sometimes, no error pops up when it's compiling module udkapi and offapi,
> > but several minutes later, errors pop up and message tells me this:
> [...]
> > --------------------------------------------------------------
> > cc1plus: warning: include location "/usr/include" is unsafe for
> > cross-compilation
>
> yes, it is.
>
> > Furthermore, I notised that the typesconfig crashed during the
> compilation
> > of the module sal because of the qemu fails to support something
> [...]
> > So, can anyone tells me what is going on, and what I need to do to handle
> > those errors.
>
> Build natively.
>
> Regards,
>
> Rene
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Help --- OOO300_m9 --- openoffice cross compile

Caolán McNamara
In reply to this post by Rene Engelhard-7
On Tue, 2008-12-16 at 14:48 +0100, Rene Engelhard wrote:
> Caesar wrote:
> > Furthermore, I notised that the typesconfig crashed during the
> > compilation of the module sal because of the qemu fails to support
> > something

That's not inherently a problem. typesconfig deliberately finds out what
it is allowed or disallowed to do on a given system. As long as it truly
is the case that e.g. it is disallowed to access a short on 1-aligned
address on your emulated system, then the "crash" is ok.

> Build natively.

Building natively doesn't have to be a totally horrible experience.
e.g. configure and build under qemu-arm, put a distcc client on the
qemu-arm, point it as a distcc server on the x86_64 and point the
distcc server at the cross compiler. That'll knock a week off the build
:-)

My understanding is that scratchbox should semi-magically fake an arm
environment, set the compiler to be the cross-compiler and use qemu to
run any output arm binaries which are executed, so I guess it should
work in theory. But I wasn't even able to get scratchbox2 to build
hello world when I give it a quick attempt some time ago so I don't
think there's anyone with much experience around in building OOo with
it.

Removing the $ORIGIN lines isn't a great idea. All *might*
work ok during the build itself as there's a LD_LIBRARY_PATH in
operation then, but after the output has been deployed then ld.so won't
be able find the libraries that bits of OOo are linked against, e.g.

readelf -d /usr/lib/openoffice.org3/program/soffice.bin |grep ORIGIN
 Library rpath:
[$ORIGIN:$ORIGIN/../basis-link/program:$ORIGIN/../basis-link/ure-link/lib]
so for e.g. soffice.bin ldd
/path/to/openoffice.org3/program/soffice.bin | grep uno_sal
 libuno_sal.so.3 =>
/path/to/openoffice.org3/program/../basis-link/ure-link/lib/libuno_sal.so.3

So libuno_sal.so.3 is found by traversing ../basic-link/ure-link/lib
relative to soffice.bin's location. If you cut that out then it won't be able
to do that without hacking around with at least a LD_LIBRARY_PATH.

C.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Help --- OOO300_m9 --- openoffice cross compile

Caesar-3
Thanks Caolan,

Thanks for your email!

I think the distcc approach is the greatest method one can figure out and I
am going to do this with the help of the remote shell.
As to the flag issue, I have a final solution already; I will recompile my
toolchain with a new version glibc.
BUT, if it's not a problem caused by the remove of that flag and the crash
of the typesconfig, why I got the following info:
------------------------------

......dmake: Error: -- `../unxlngr.pro/ucr/cssawt.db' not found, and can't
be madeERROR: Error 65280 occurred while making
/home/caesar/OOo/OOO300_m9/offapi/util

OR
......dmake: Error: -- `../unxlngr.pro/ucr/cssbridge.db' not found, and
can't be madeERROR: Error 65280 occurred while making
/home/caesar/OOo/OOO300_m9/udkapi/util
------------------------------

WHAT IS MORE WEIRD, SOMETIMES, no error pops up when it's compiling module
udkapi and offapi, but several minutes later, errors pop up and message
tells me this:
--------------------------------------------------------------
cc1plus: warning: include location "/usr/include" is unsafe for
cross-compilation
In file included from ../../inc/com/sun/star/uno/Any.h:35,
                 from ../../inc/cppu/helper/purpenv/Mapping.hxx:34,
                 from
/home/caesar/OOo/OOO300_m9/cppu/source/AffineBridge/AffineBridge.cxx:39:
../../inc/com/sun/star/uno/Type.h:35:42: error:
com/sun/star/uno/TypeClass.hdl:No such file or directory
In file included from ../../inc/com/sun/star/uno/Any.h:35,
                 from ../../inc/cppu/helper/purpenv/Mapping.hxx:34,
                 from
/home/caesar/OOo/OOO300_m9/cppu/source/AffineBridge/AffineBridge.cxx:39:
../../inc/com/sun/star/uno/Type.h:99: error: expected `)' before
'eTypeClass'
../../inc/com/sun/star/uno/Type.h:106: error: expected `)' before
'eTypeClass'
../../inc/com/sun/star/uno/Type.h:151: error: 'TypeClass' does not name a
type
In file included from ../../inc/cppu/helper/purpenv/Mapping.hxx:34,
                 from
/home/caesar/OOo/OOO300_m9/cppu/source/AffineBridge/AffineBridge.cxx:39:
../../inc/com/sun/star/uno/Any.h:150: error: 'TypeClass' does not name a
type
dmake:  Error code 1, while making '../../unxlngr.pro/slo/AffineBridge.obj'
ERROR: Error 65280 occurred while making /home/caesar/OOo/OOO300_m9/

cppu/source/AffineBridge
rmdir /tmp/22127
dmake:  Error code 1, while making 'build_instsetoo_native'
--------------------------------------------------------------
Do you have any idea or, what do you think about this?

Thanks for your help!

Best,

S. Caesar Huang

On Tue, Dec 16, 2008 at 10:18 PM, Caolán McNamara <[hidden email]>wrote:

> On Tue, 2008-12-16 at 14:48 +0100, Rene Engelhard wrote:
> > Caesar wrote:
> > > Furthermore, I notised that the typesconfig crashed during the
> > > compilation of the module sal because of the qemu fails to support
> > > something
>
> That's not inherently a problem. typesconfig deliberately finds out what
> it is allowed or disallowed to do on a given system. As long as it truly
> is the case that e.g. it is disallowed to access a short on 1-aligned
> address on your emulated system, then the "crash" is ok.
>
> > Build natively.
>
> Building natively doesn't have to be a totally horrible experience.
> e.g. configure and build under qemu-arm, put a distcc client on the
> qemu-arm, point it as a distcc server on the x86_64 and point the
> distcc server at the cross compiler. That'll knock a week off the build
> :-)
>
> My understanding is that scratchbox should semi-magically fake an arm
> environment, set the compiler to be the cross-compiler and use qemu to
> run any output arm binaries which are executed, so I guess it should
> work in theory. But I wasn't even able to get scratchbox2 to build
> hello world when I give it a quick attempt some time ago so I don't
> think there's anyone with much experience around in building OOo with
> it.
>
> Removing the $ORIGIN lines isn't a great idea. All *might*
> work ok during the build itself as there's a LD_LIBRARY_PATH in
> operation then, but after the output has been deployed then ld.so won't
> be able find the libraries that bits of OOo are linked against, e.g.
>
> readelf -d /usr/lib/openoffice.org3/program/soffice.bin |grep ORIGIN
>  Library rpath:
> [$ORIGIN:$ORIGIN/../basis-link/program:$ORIGIN/../basis-link/ure-link/lib]
> so for e.g. soffice.bin ldd
> /path/to/openoffice.org3/program/soffice.bin | grep uno_sal
>  libuno_sal.so.3 =>
> /path/to/openoffice.org3/program/../basis-link/ure-link/lib/libuno_sal.so.3
>
> So libuno_sal.so.3 is found by traversing ../basic-link/ure-link/lib
> relative to soffice.bin's location. If you cut that out then it won't be
> able
> to do that without hacking around with at least a LD_LIBRARY_PATH.
>
> C.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Help --- OOO300_m9 --- openoffice cross compile

Caolán McNamara
On Wed, 2008-12-17 at 09:39 +0800, Caesar wrote:

> Thanks Caolan,
>
> Thanks for your email!
>
> I think the distcc approach is the greatest method one can figure out and I
> am going to do this with the help of the remote shell.
> As to the flag issue, I have a final solution already; I will recompile my
> toolchain with a new version glibc.
> BUT, if it's not a problem caused by the remove of that flag and the crash
> of the typesconfig, why I got the following info:
> ------------------------------
>
> ......dmake: Error: -- `../unxlngr.pro/ucr/cssawt.db' not found, and can't
> be madeERROR: Error 65280 occurred while making
> /home/caesar/OOo/OOO300_m9/offapi/util

I have no idea, but I have a *vague* memory of some terrible random
problems building under qemu or maybe some other emulator which turned
out to be clock-scew between the emulator and the nfs mounted build dir.

C.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Help --- OOO300_m9 --- openoffice cross compile

Caesar-3
I did encounter to much problems building in a qemu box, but it's a
time-consuming job; I took me five days to finished the whole procedure.

If there was no problem with the simulator, I thought we can finish it in 6
to 7 hours in scratchbox. Unfortunately, I think qemu cannot fully support
arm eabi version 4 and above.

So, I have tried the romote shell approach today. If everything goes well,
the whole procedure will take proximately 2 days. Still low performance!
Reply | Threaded
Open this post in threaded view
|

Re: Help --- OOO300_m9 --- openoffice cross compile

Caesar-3
Sorry! I did not encourter to much problems building in a qemu box!
:-)

On Wed, Dec 17, 2008 at 10:27 PM, Caesar <[hidden email]> wrote:

> I did encounter to much problems building in a qemu box, but it's a
> time-consuming job; I took me five days to finished the whole procedure.
>
> If there was no problem with the simulator, I thought we can finish it in 6
> to 7 hours in scratchbox. Unfortunately, I think qemu cannot fully support
> arm eabi version 4 and above.
>
> So, I have tried the romote shell approach today. If everything goes well,
> the whole procedure will take proximately 2 days. Still low performance!
>