I removed the -library=no%Cstd from the two files and performed a clean build,
but still have the same issues. Also, I am untarring the BOOST package version
1.48 so I downloaded the zipped version and unzipped it, placed the resulting
boost directory in /usr/local/include after using --with-system-boost
configuration. Still no luck. I also reconfigured with --without-stlport. It
still appears that I it is using
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/climits.SUNWCCh.
________________________________________
From: Herbert Duerr [h...@apache.org]
Sent: Friday, September 13, 2013 3:40 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
On 12.09.2013 20:15, Steele, Raymond wrote:
> Yes, the modified vigra config.hxx allowed basebmp to be built. I am using
> --with-system-boost, however, I just did a reconfigure after removing it and
> ran into issues during the boost build. I receive the following hundreds of
> times until it fails.
Good, so the vigra erf() problem can be considered as solved.
> /usr/sfw/bin/gtar: Archive value 4294967295 is out of gid_t range
> -2147483648..2147483647
> [...]
>
> I am not sure why. Looking into it now.
I found [1] ("Whoever created that tar file did so on a platform that
allows gid_t values of 32bits."), and this probably means the boost
tarball was packed on a too new system. Or that gtar on your system
needs to be updated.
[1] http://comments.gmane.org/gmane.comp.gnu.mingw.msys/4816
> Also, here is filtered output from the CC -E of partial.cxx. I grep'd for
> limits, as you can see in the command I issued.
>
> bash-3.2# /opt/solarisstudio12.3/bin/CC -E -temp=/tmp -xarch=generic -xO3
> -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -xldscope=hidden -I.
> -I../unxsoli4.pro/inc/configmgr -I../inc -I../inc/pch -I../inc -I../unx/inc
> -I../unxsoli4.pro/inc -I.
> -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl
> -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/external
> -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc
> -I/opt/aoo-4.0.0/main/solenv/unxsoli4/inc -I/opt/aoo-4.0.0/main/solenv/inc
> -I/opt/aoo-4.0.0/main/res
> -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl
> -I/opt/solarisstudio12.3/include -I/opt/aoo-4.0.0/main/solenv/inc/Xp31
> -I/usr/jdk/latest/include -I/usr/jdk/latest/include/solaris
> -I/usr/jdk/latest/include/native_threads/include: -I/usr/local/include
> -I/usr/include -I/usr/local/include/boost
> -I/opt/solarisstudio12.3/prod/include/CC/Cstd/ -I/usr/local/include/rasqal:
> -I/usr/local/include -I/usr/include -I/usr/local/include/boost
> -I/usr/local/include/rasqal -I/usr/include/std
cxx4 -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/offuh -I. -I../res -I.
-features=no%altspell -library=no%Cstd "-features=rvalueref" +w2
-erroff=doubunder,identexpected,inllargeuse,inllargeint,notemsource,reftotemp,truncwarn,wnoretvalue,anonnotype
-KPIC -mt -DSOLARIS -DUNX -DVCL -DC52 -DC52 -DINTEL -D_PTHREADS -DSYSV -DSUN
-DSUN4 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DSTLPORT_VERSION=400 -D__DMAKE
-DUNIX -DCPPU_ENV=sunpro5 -DSUPD=400 -DPRODUCT -DNDEBUG -DOSL_DEBUG_LEVEL=0
-DOPTIMIZE -DCUI -DSOLAR_JAVA -DSHAREDLIB -D_DLL_ -DEXCEPTIONS_ON -o
/tmp/file /opt/aoo-4.0.0/main/configmgr/source/partial.cxx|grep -i limit
The compiler option "-library=no%Cstd" could have introduced some
trouble. In AOO 4.0 we want to use this compiler STL (wrapped with
boost's TR1 library to fill the missing TR1 pieces and for easier porting).
I see this flag is set in
main/solenv/inc/unxsol*.mk
and in
main/solenv/gbuild/platform/solaris.mk
and suggest to remove it in all places.
> #1 "/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/climits.SUNWCCh"
This header shouldn't be there if your configure step used the
"--without-stlport" option. If you didn't use the option then please
reconfigure the AOO build using it.
Please see e.g. the Linux configure options in [2] as a reference.
[2]
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds
> [other lines matching a grep for "limit"]
These other grepped lines are interesting too, but with the two
suggestions I made things could change considerably here.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
