gmane.comp.openoffice.devel.porting

new Apache OpenOffice.org mail list to replace this list

2011-11-02T16:23:59

Invitation to connect on LinkedIn

Hirano Kazunari — 2011-09-28T11:14:41

I'd like to add you to my professional network on LinkedIn.

- Hirano

Hirano Kazunari
I18n/L10n Community Contributor at OpenSolaris
Japan

Confirm that you know Hirano Kazunari:
https://www.linkedin.com/e/ymjwes-gt47x5aa-5d/isd/4381516689/auRUFTH5/?hs=false&tok=3jNnDF8k_2-QU1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/ymjwes-gt47x5aa-5d/7iRvUDqSX83sYrASGtdqLs1bkq0Ej_R17hjJ3nsr/goo/dev%40porting%2Eopenoffice%2Eorg/20061/I1517856740_1/?hs=false&tok=0IzooBUFP2-QU1

(c) 2011 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

Re: [dev] Re: [porting-dev] Re: [dev] EducOOo donated code for ARM Linux port

Rene Engelhard — 2011-02-19T16:30:37

I fixed some more (even syntax errors) in the patch, can't attach it
right now since IZ is down, but here it is.

Will attach a new patch, which
 - defaults to armv4t
 - fixes syntax errors in the patch (test has no < and > but -lt and -gt,
   -a test is broken (either && or -a without test, missing $ before build_cpu)
 - remove the "x$something" nonsense for test which doesn't play well with
   test and -lt/-gt
 - you should not assume the build_cpu is stricly arm. on my debian sid on a
   sheevaplug the triplet is armv5tel-unknown-linux-gnu when not specifying
   arm-* manually on the configure line. There's a reason we have arm* in 
   configure.ins case statements :)

The original "patch" obviously wasn't tested at all...

Grüße/Regards,

René
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe< at >porting.openoffice.org
For additional commands, e-mail: dev-help< at >porting.openoffice.org

Re: [dev] EducOOo donated code for ARM Linux port

Rene Engelhard — 2011-02-19T16:32:12

According to the issue they did do some arm6/armv7 optimizations and "donated"
the change back (Though the patch was buggy and not-working, see my later
comments) but the comment made it look that they "donated (the) code for
ARM Linux port". That was what I objected to.

Grüße/Regards,

René

Re: Re: [dev] EducOOo donated code for ARM Linux port

Rene Engelhard — 2011-02-19T13:37:39

This is broken, too, afaics.
In configure you set ARM_TARGET to e.g. 6 (WITHOUT ARMV)
but there you use it WITH ARMV...

Grüße/Regards,

René

Re: Re: [dev] EducOOo donated code for ARM Linux port

Rene Engelhard — 2011-02-19T12:55:50

Hi,

On Sat, Feb 19, 2011 at 01:51:02PM +0100, Rene Engelhard wrote:

Oh, and this:

+# Default is armv7 mini. If you build
+# for an older version (could be slow),
+# please adapt to your needs
+
+.IF "$(ARM_TARGET)" == "ARMV6"
+ARCH_FLAGS+=-march=armv6 -mfloat-abi=softfp -D__SOFTFP__
+CDEFS+=-DARMV6
+.ENDIF
+
+.IF "$(ARM_TARGET)" == "ARMV7"
+ARCH_FLAGS+=-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -D__SOFTFP__
+CDEFS+=-DARMV7
+.ENDIF
+

is broken, too.
*If* you want to optimize for speed, you want hardfp, and IMHO you don't need to
specify -mfloat-abi=softfp -D__SOFTFP__ manually in either case, that's the job of your toolchain.

Grüße/Regards,

René

Re: [dev] EducOOo donated code for ARM Linux port

Rene Engelhard — 2011-02-19T12:51:02

"EducOOo donated code for ARM Linux port" makes it sound you did the port.
Wrong. Stop your propaganda, please.

Now to the technical points:

ARM_TARGET=7

ehm, no. *If* you want to set a minimal baseline, use armv4t. Assuming anyone
has the latest and greatest ARM is bogus.

And

+    if test "x$with_arm_target" < "x6"
+       then    AC_MSG_RESULT([arm target is armv5 or inferior])
+       ARM_TARGET=5

aha, let's break even more older ARMs...

Intreresting you even dropped the correct list from your CCs (dev< at >porting). What does
marketing to do here instead?
Grüße/Regards,

René

Re: [dev] ARM port

Caolán McNamara — 2011-02-15T09:26:44

OpenOffice.org is already ported to Linux ARM, oabi and eabi, le and
be.

C.

Re: DEV300_m96: rtld difference on FreeBSD

Maho NAKATA — 2011-02-01T00:25:16

From: Stephan Bergmann <stephan.bergmann< at >oracle.com>
Subject: Re: [porting-dev] DEV300_m96: rtld difference on FreeBSD
Date: Mon, 31 Jan 2011 09:23:26 +0100


yes.


Thanks, now I finished DEV300_m96 on FreeBSD...it was long...
thanks

Re: DEV300_m96: rtld difference on FreeBSD

Stephan Bergmann — 2011-01-31T08:23:26

You mean, building tools (migrated to gbuild) recorded a wrong RPATH in 
the tl library?  Yes, that would explain why unopkg failed to load the 
libraries on which tl depends.

-Stephan

Re: DEV300_m96: rtld difference on FreeBSD

Stephan Bergmann — 2011-01-31T08:21:26

(FreeBSD uses ELF, including features like RPATH, right?)


But in both cases there is an error (basegfx/$INPATH/lib/libbasegfx*.so 
does not find the libraries it depends on; which is OK as the basegfx 
library's location does not match its RPATH settings).  It is just 
reported slightly differently.


What would be interesting is the output of ldd 
/work/OOO/debussy8i386/DEV300_m96/ports/editors/openoffice.org-3-devel/work/DEV300_m96/instsetoo_native/unxfbsdi.pro/OpenOffice/archive/install/en-US_inprogress/OOo_3.4.0_FreeBSD_install-arc_en-US/openoffice.org/basis3.4/program/libtlfi.so

-Stephan

Re: DEV300_m96: rtld difference on FreeBSD

Maho NAKATA — 2011-01-31T00:13:32

Forward to dev< at >porting list

From: Konstantin Belousov <kostikbel< at >gmail.com>
Subject: Re: [porting-dev] DEV300_m96: rtld difference on FreeBSD
Date: Sun, 30 Jan 2011 12:16:54 +0200

Re: DEV300_m96: rtld difference on FreeBSD

Maho NAKATA — 2011-01-30T09:36:32

Hi Kostik Belousov, Stephan, Björn,

Now I find an answer.

I forgot that, to pass $ORIGIN for FreeBSD,
we also need "-Wl,-z,origin" as well. Still some parts use
older "DEV300_m96/solenv/inc/unxfbsd.mk", which have correct
$ORIGIN line and not "gmake" migrated modules. For such parts
$ORIGIN worked fine. For other parts, which are migrated modules,  
I just copy and pasted from Linux, then for that part, build was
broken.

Thanks
 Nakata Maho


From: Maho NAKATA <maho< at >openoffice.org>
Subject: Re: [porting-dev] DEV300_m96: rtld difference on FreeBSD
Date: Sun, 30 Jan 2011 16:09:53 +0900 (JST)

>

Re: DEV300_m96: rtld difference on FreeBSD

Maho NAKATA — 2011-01-30T07:09:53

Hi Kostik Belousov,
I found a small difference of rtld behavior between Linux and FreeBSD.


ldd fails like that on FreeBSD,

but on Linux

.

Is it a correct behavior? Just i'm not sure ...

Thanks
 Nakata Maho

From: Maho NAKATA <maho< at >openoffice.org>
Subject: [porting-dev] DEV300_m96: rtld difference on FreeBSD
Date: Sun, 30 Jan 2011 15:16:28 +0900 (JST)

>

DEV300_m96: rtld difference on FreeBSD

Maho NAKATA — 2011-01-30T06:16:28

Hi Stephan, Björn,

I encountered another build brekage of DEV300_m96 on FreeBSD.
it seems small difference rtld between Linux and FreeBSD.

On FreeBSD 8,

# cd basegfx/unxfbsdi.pro/lib ; ldd ./libbasegfxfi.so 
./libbasegfxfi.so:
/libexec/ld-elf.so.1: ./libbasegfxfi.so: Unexpected inconsistency: dependency libuno_sal.so.3 not found
./libbasegfxfi.so: exit status 1

On FreeBSD ldd erroneously exit on libbasegfxfi.so when it 
didn't find some libraries.  

On Linux
maho< at >:~/DEV300_m96/basegfx/unxlngi6.pro/lib$ ldd ./libbasegfxli.so 
  linux-gate.so.1 =>  (0x0040d000)
  libuno_sal.so.3 => not found
  libuno_cppuhelpergcc3.so.3 => not found
  libuno_cppu.so.3 => not found
  libstlport_gcc.so => not found
  libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00542000)
  libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x00b77000)
  libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00d8b000)
  libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x008d5000)
  /lib/ld-linux.so.2 (0x00e4b000)

problem here on FreeBSD is that ldd fails after it didn't find some libraries,
whereas on Linux, it just says it doesn't found.

It prevents packaging process, so FreeBSD build is broken at instsetoo_native
like following:
**************************************************
ERROR: ERROR: unopkg sync --verbose -env:BUNDLED_EXTENSIONS_USER="file:///work/OOO/debussy8i386/DEV300_m96/ports/editors/openoffice.org-3-devel/work/DEV300_m96/instsetoo_native/unxfbsdi.pro/OpenOffice/archive/install/en-US_inprogress/OOo_3.4.0_FreeBSD_install-arc_en-US/openoffice.org3/share/prereg/bundled" -env:UserInstallation=file:///work/tmp/ooopackaging/i_485471296326978/unxfbsdi.pro/OpenOffice/archive/uno/en-US -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
in function: register_extensions
**************************************************

**************************************************
ERROR: Saved logfile: /work/OOO/debussy8i386/DEV300_m96/ports/editors/openoffice.org-3-devel/work/DEV300_m96/instsetoo_native/unxfbsdi.pro/OpenOffice/archive/logging/en-US/log_DEV300_en-US.log
**************************************************
... cleaning the output tree ...
... removing directory /work/tmp/ooopackaging/i_485471296326978 ...
Sun Jan 30 03:54:19 2011 (04:41 min.)
dmake:  Error code 255, while making 'openoffice_en-US.archive'

.

The relevant part of output of "DEV300_m96/instsetoo_native/unxfbsdi.pro/OpenOffice/archive/logging/en-US/log_DEV300_en-US.log" is 


Systemcall: unopkg sync --verbose -env:BUNDLED_EXTENSIONS_USER="file:///work/OOO/debussy8i386/DEV300_m96/ports/editors/openoffice.org-3-devel/work/DEV300_m96/instsetoo_native/unxfbsdi.pro/OpenOffice/archive/install/en-US_inprogress/OOo_3.4.0_FreeBSD_install-arc_en-US/openoffice.org3/share/prereg/bundled" -env:UserInstallation=file:///work/tmp/ooopackaging/i_671801296343016/unxfbsdi.pro/OpenOffice/archive/uno/en-US -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 |
/libexec/ld-elf.so.1: Shared object "libbasegfxfi.so" not found, required by "libtlfi.so"
ERROR: Could not execute "unopkg sync --verbose -env:BUNDLED_EXTENSIONS_USER="file:///work/OOO/debussy8i386/DEV300_m96/ports/editors/openoffice.org-3-devel/work/DEV300_m96/instsetoo_native/unxfbsdi.pro/OpenOffice/archive/install/en-US_inprogress/OOo_3.4.0_FreeBSD_install-arc_en-US/openoffice.org3/share/prereg/bundled" -env:UserInstallation=file:///work/tmp/ooopackaging/i_671801296343016/unxfbsdi.pro/OpenOffice/archive/uno/en-US -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 |"!Exitcode: '256'

It seems we need LD_LIBRARY_PATH at packaging process(?)

Thanks,

Re: Re: More on "tools" module; on FreeBSD

Maho NAKATA — 2011-01-23T01:00:51

From: Michael Stahl <Michael.X.Stahl< at >Oracle.COM>
Subject: [porting-dev] Re: More on "tools" module; on FreeBSD
Date: Mon, 17 Jan 2011 11:15:44 +0100


yes, that's actually what I have been doing :-)
and in FreeBSD's case, just copy and paste from Linux is usually enough.

Thanks,
 Nakata Maho

Re: More on "tools" module; on FreeBSD

Maho NAKATA — 2011-01-23T00:59:37

From: Björn Michaelsen <bjoern.michaelsen< at >oracle.com>
Subject: Re: [porting-dev] More on "tools" module; on FreeBSD
Date: Mon, 17 Jan 2011 12:27:04 +0100


yes.

thanks for your comment.

Re: More on "tools" module; on FreeBSD

Maho NAKATA — 2011-01-23T00:59:16

Ohayogozaimasu (Hello) Ono-san,
many thanks for your comment, and build is progressing!
still broken in different place, though.

thanks
 Nakata Maho

From: Takashi Ono <t_ono< at >hkfreak.net>
Subject: Re: [porting-dev] More on "tools" module; on FreeBSD
Date: Sun, 16 Jan 2011 14:29:04 +0900

Re: More on "tools" module; on FreeBSD

Michael Stahl — 2011-01-17T10:15:44

yes, exactly.

the problem is that unfortunately there is significant creativity when it
comes to library names in OOo.

gbuild needs to construct the file names of the library somehow.
this is done by generic rules that e.g. append the 2/3-letter platform
suffix and such.

in many cases this is sufficient, but there are quite a few exceptions.
like comphelper, which is called libcomphelp4gcc3.so or something like
that on linux, and something else on windows, for reasons nobody knows.

these exceptions are handled on a per-platform basis in RepositoryFixes.mk.
if your platform is "just like linux", then you may be able to just re-use
the linux stuff in that file.

the goal is of course that once all modules are migrated to gbuild we can
rename the exceptions so they follow the rules instead, and get rid of the
RepositoryFixes.mk.

Re: More on "tools" module; on FreeBSD

Björn Michaelsen — 2011-01-17T11:27:04

Hi Maho,

Am Sun, 16 Jan 2011 12:17:46 +0900 (JST)
schrieb Maho NAKATA <maho< at >openoffice.org>:


did Takashis answer help you?

BR,

Bjoern

Re: More on "tools" module; on FreeBSD

Takashi Ono — 2011-01-16T05:29:04

Hi Maho,

In message "Re: [porting-dev] More on "tools" module; on FreeBSD",
Maho NAKATA wrote...

 >where ../../solver/300/unxfbsdi.pro/workdir/Headers/Library/libcomphelpergcc3.so comes 
from?

The names of the libraries are defined in Reopsitory.mk and RepositoryFixes.mk in source 
root. I think you need some fix entries for FreeBSD in RepositoryFixes.mk.

Regards,

Takashi Ono (tono< at >openoffice.org)