Should --without-stlport4 be used for the Mac port? (If yes, it would
of course have to be done in a way that a simple configure without
arguments correctly uses --without-stlport4 on Mac; otherwise, the build
mechansims would be too fragile.)
Getting rid of unnecessary dependencies and extra code (the STLport
stuff included in the OOo sources, in this case) is a good thing, IMO,
so that would be the pro for doing this.
The cons might be:
- On platforms where people already created C++ UNO software (e.g., OOo
extensions written in C++), we cannot switch to --without-stlport4
without breaking compatibility (and thus having such software no longer
work). Is there any such software (that should continue to work)
already written for Mac?
- Similarly, the used STL bits need to stay ABI compatible. This is
true for --with-stlport4 (as we control the sources used in that case),
but its unclear whether it is true for e.g. Gnu's libstdc++ (ABI
compatibility has dramatically matured for gcc over the past few years,
I am not sure how much this is still an issue).
-Stephan
-------- Original Message --------
Subject: Re: [porting-dev] OpenOffice.org Linux/MIPS (EL)
Date: 25 Jul 2007 12:35:21 +0200
From: Caolan McNamara <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: StarOffice / Sun Microsystems, Inc.
To: [EMAIL PROTECTED]
Newsgroups: openoffice.porting.dev
References: <[EMAIL PROTECTED]>
On Wed, 2007-07-25 at 12:23 +0200, Sunil Amitkumar Janki wrote:
I have ported Slackware 12.0 to little-endian MIPS on the Loongson
processor and have tried many times to build OpenOffice.org but
haven't succeeded yet.
The error I get even after rebuilding binutils, glibc and gcc
multiple times is the following:
> touch ./unxlngmips.pro/misc/build/so_patched_so_stlport
> touch ./unxlngmips.pro/misc/build/so_configured_so_stlport
> mkdir ./unxlngmips.pro/misc/build/STLport-4.5/src
> mkdir: cannot create directory
I suggest for new ports that use gcc to give configure-ing with
--without-stlport4
a go. That way you avoid the need to build stlport and use the system
gcc stl instead. That may get you further into the build, though of
course a per-arch uno bridge will be required in bridges/source/cpp_uno
that'll be the real hard bit.
C.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
