Apache OpenOffice (AOO) Bugzilla – Issue 98048
harmonize --with{out}-stlport default
Last modified: 2009-09-15 15:21:45 UTC
Hi, [ imho this is P2 because currently plain ./configure builds differ in the ABI from vanilla on some archs ] seeing that the x86_64 version of OOo is (by Sun) also built with USE_SYSTEM_STL YES, we probably should harmonize the ./configure defaults with reality. - Linux/i386, Windows, Solaris 32 bit: stay with STLport - all other Linux builds than i386 should be changed - Mac Intel: built by Sun defauls according to Sun to system-stl, too. - Solaris 64bit uses system-stl -> default should be changed If no one objects I'd strt with this: --- configure.in (Revision 266120) +++ configure.in (Arbeitskopie) @@ -2306,7 +2306,7 @@ DEFAULT_TO_STLPORT="yes" if test "$_os" = "Linux"; then case "$build_cpu" in - i?86|powerpc|sparc) + i?86) DEFAULT_TO_STLPORT="yes" ;; *) @@ -2315,11 +2315,19 @@ esac elif test "$_os" = "Darwin"; then DEFAULT_TO_STLPORT="no" + elif test "$_os" = "SunOS"; then + if test $SIZEOF_LONG = 8; then + DEFAULT_TO_STLPORT="no" + else + DEFAULT_TO_STLPORT="yes" + fi + elif test "$_os" = "WINNT"; then + DEFAULT_TO_STLPORT="yes" fi if test "$DEFAULT_TO_STLPORT" = "yes"; then AC_MSG_RESULT([stlport]) else - AC_MSG_RESULT([gcc]) + AC_MSG_RESULT([system]) fi if test "$WITH_STLPORT" = "auto"; then WITH_STLPORT=$DEFAULT_TO_STLPORT port people, do you have a comment? Especially for the OSes/archs not covered here? What about *BSD? What about OS/2? What about possible future Windows 64bit? What about someting else? :)
oops, forgot ydario
I'll do it
.
@rene: 1 There are no working Solaris 64bit ports currently (there was an experimental one for Solaris SPARC 64bit, but it is stalled), so I would suggest generally using DEFAULT_TO_STLPORT="yes" for SunOS, without further differentiation. (Where did you get the information that "Solaris 64bit uses system-stl"?) 2 As a matter of style, I think it is not good to set DEFAULT_TO_STLPORT="yes" at the outset and then re-confirm this default for various platforms again by again setting DEFAULT_TO_STLPORT="yes". I would suggest to either remove all the branches that explicitly set "yes" again, or remove the default "yes" before the branches and instead make it a final else branch.
1. Hmm, well, I just noticed cwses for it. (And who told me that it uses system-stl: Heiner). It uses ccs stl (which is a optimized STLport, but that still makes it the compilers stl) 2. good point
Re 1: FYI, citing from a (unfortunately Sun-Hamburg internal) wiki page about unxsolu (i.e., Solaris SPARC 64bit): "Support for unxsolu4 is lacking in the configure-based environment (CVS module config_office); unxsolu4 for now is only available in the (Sun-Hamburg) setsolar-based environment[.]" and "In general, using -library=stlport4 is problematic, as the C++ Compiler group gives no stability guarantees, but we do." In short, use of compiler STLport for that port was controversial and unsettled, there was no configure support for that port, and the port is dead, anyway. So, to simplify things, I would just ignore the existence of that port in configure.
sb: ok, if that port really is dead... will remove that if
@sb, @rene: Solaris Sparc 64 bit is not AFAIK not dead. At least I have the task to make it do something useful ASAP. Really. Regarding the compiler STLPort of SunStudio. As long as there is not an official stable replace for classic RW and STLport in the compiler I consider the compiler STLPort good enough for a 64 bit version which won't be released for a while. It's not set in stone for all times as long as we don't make it official. Maybe someone comes along and want to play a bit with it so I don't see why we should support it in configure. @rene: Stefan is right in that you probably shouldn't worry to much about Solaris 64 bit in configure, it will be experimental for a while.
OH oh, no caffeine yet so I got a lot of those pesky double negations wrong ... I mean we should support 64 bit Solaris in configure if it's easily done, but it's not worth to poor a lot of effort in it.
ok, so so I changed it to --- configure.in (Revision 266120) +++ configure.in (Arbeitskopie) @@ -2303,23 +2303,25 @@ dnl Checks for what the default STL should be dnl =================================================================== AC_MSG_CHECKING([what the default STL should be]) - DEFAULT_TO_STLPORT="yes" + DEFAULT_TO_STLPORT="no" if test "$_os" = "Linux"; then case "$build_cpu" in - i?86|powerpc|sparc) + i?86) DEFAULT_TO_STLPORT="yes" ;; *) DEFAULT_TO_STLPORT="no" ;; esac - elif test "$_os" = "Darwin"; then - DEFAULT_TO_STLPORT="no" + elif test "$_os" = "SunOS"; then + DEFAULT_TO_STLPORT="yes" + elif test "$_os" = "WINNT"; then + DEFAULT_TO_STLPORT="yes" fi if test "$DEFAULT_TO_STLPORT" = "yes"; then AC_MSG_RESULT([stlport]) else - AC_MSG_RESULT([gcc]) + AC_MSG_RESULT([system]) fi if test "$WITH_STLPORT" = "auto"; then WITH_STLPORT=$DEFAULT_TO_STLPORT which means that the default is now to NOT use STLport EXCEPT on the archs which need it. committed this to cws configuretoplevel, will keep this issue open, though for feedback for other archs Especially *BSD... maho?
Hi rene thanks for your good work and asking me about it. For FreeBSD, currently > checking what the default STL should be... stlport > checking for STL providing headers... using internal stlport. and > The variable STLPORT4 is set to: NO_STLPORT4 ... > The variable STLPORT_VER is set to: 400 I assume setting DEFAULT_TO_STLPORT="yes" preserves above. Right? then, adding + elif test "$_os" = "FreeBSD"; then + DEFAULT_TO_STLPORT="yes" is okay. Thanks!
maho: done, thanks
12:52 * _rene_ wonders whether he should wait for OS/2, change Os2 to use STlport, or something else :-) 12:52 < _rene_> that's the last issue in this cws open right now :) [...] 13:21 < _rene_> ah, well, I'll just make it use STLport (include it in the WINNT clause) -> FIXED
looks good
Close issue.