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.
/usr/sfw/bin/gtar: Archive value 4294967295 is out of gid_t range
-2147483648..2147483647
/usr/sfw/bin/gtar: Archive value 4294967295 is out of gid_t range
-2147483648..2147483647
/usr/sfw/bin/gtar: Archive value 4294967295 is out of gid_t range
-2147483648..2147483647
/usr/sfw/bin/gtar: Archive value 4294967295 is out of gid_t range
-2147483648..2147483647
/usr/sfw/bin/gtar: Archive value 4294967295 is out of gid_t range
-2147483648..2147483647
etc...
I am not sure why. Looking into it now.
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/stdcxx4
-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
#1 "/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/climits.SUNWCCh"
#1 "/usr/include/limits.h"
#pragma ident "@(#)limits.h 1.60 11/04/12 SMI"
#1 "/usr/include/iso/limits_iso.h"
#pragma ident "@(#)limits_iso.h 1.2 03/12/04 SMI"
#1 "/usr/include/sys/int_limits.h"
#pragma ident "@(#)int_limits.h 1.9 04/09/28 SMI"
#35 "/usr/include/limits.h"
unsigned long operator ( ) ( unsigned long __limit ) {
return _M_table [ _M_index1 ] % __limit ;
#1 "/usr/local/include/boost/limits.hpp"
#1 "/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/limits.SUNWCCh"
#1 "/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_limits.h"
class _Numeric_limits_base {
class _Integer_limits : public _Numeric_limits_base < _Int >
class _Floating_limits : public _Numeric_limits_base < __number >
class numeric_limits : public _Numeric_limits_base < _Tp > { } ;
class numeric_limits < bool >
: public _Integer_limits < bool , false , true , 0 , false >
class numeric_limits < char >
: public _Integer_limits < char , ( - 128 ) , 127 , - 1 , true >
class numeric_limits < signed char >
: public _Integer_limits < signed char , ( - 128 ) , 127 , - 1 , true >
class numeric_limits < unsigned char >
: public _Integer_limits < unsigned char , 0 , 255 , - 1 , true >
class numeric_limits < wchar_t >
: public _Integer_limits < wchar_t , ( - 2147483647 - 1 ) , 2147483647 , - 1 ,
true >
class numeric_limits < short >
: public _Integer_limits < short , ( - 32768 ) , 32767 , - 1 , true >
class numeric_limits < unsigned short >
: public _Integer_limits < unsigned short , 0 , 65535 , - 1 , true >
class numeric_limits < int >
: public _Integer_limits < int , ( - 2147483647 - 1 ) , 2147483647 , - 1 , true
>
class numeric_limits < unsigned int >
: public _Integer_limits < unsigned int , 0 , 4294967295U , - 1 , true >
class numeric_limits < long >
: public _Integer_limits < long , ( - 2147483647L - 1L ) , 2147483647L , - 1 ,
true >
class numeric_limits < unsigned long >
: public _Integer_limits < unsigned long , 0 , 4294967295UL , - 1 , true >
class numeric_limits < long long >
: public _Integer_limits < long long , ( - 0x7fffffffffffffffLL - 1LL ) ,
0x7fffffffffffffffLL , - 1 , true >
class numeric_limits < unsigned long long >
: public _Integer_limits < unsigned long long , 0 , 0xffffffffffffffffULL , - 1
, true >
template < > class numeric_limits < float >
: public _Floating_limits < float ,
template < > class numeric_limits < double >
: public _Floating_limits < double ,
class numeric_limits < long double >
: public _Floating_limits < long double ,
return ( _STL :: numeric_limits < SizeType > :: max ) ( ) ;
#1 "/usr/local/include/boost/mpl/limits/arity.hpp"
_Size __depth_limit ) ;
_Size __depth_limit , _Compare __comp ) ;
( _STL :: numeric_limits < _STL :: size_t > :: max ) ( ) ) ?
( _STL :: numeric_limits < _STL :: size_t > :: max ) ( ) :
#1 "/usr/local/include/boost/functional/hash/detail/limits.hpp"
struct limits : _STL :: numeric_limits < T > { } ;
#1 "/usr/local/include/boost/functional/hash/detail/limits.hpp"
exp += limits < T > :: max_exponent -
limits < T > :: min_exponent ;
v = ldexp ( v , limits < _STL :: size_t > :: digits ) ;
= ( limits < T > :: digits *
boost :: static_log2 < limits < T > :: radix > :: value
+ limits < _STL :: size_t > :: digits - 1 )
/ limits < _STL :: size_t > :: digits ;
v = ldexp ( v , limits < _STL :: size_t > :: digits ) ;
const int size_t_bits = _STL :: numeric_limits < _STL :: size_t > :: digits ;
const int length = ( _STL :: numeric_limits < T > :: digits - 1 )
const int size_t_bits = _STL :: numeric_limits < _STL :: size_t > :: digits ;
const int length = ( _STL :: numeric_limits < T > :: digits - 1 )
________________________________________
From: Herbert Duerr [[email protected]]
Sent: Wednesday, September 11, 2013 7:02 AM
To: [email protected]
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
On 10.09.2013 19:29, Steele, Raymond wrote:
> I cannot seem to figure out which <limits> integer_fw.hpp is using on my
> system. I put the following in scopeguard.cxx and received a
>
> void ScopeGuard::dismiss()
> {
> struct Dummy{} dummy = ::std::numeric_limits<unsigned char>::digits;
> m_func.clear();
> }
>
>
> Here is the output.
> [...]
> "/usr/local/include/boost/integer_fwd.hpp", line 138: Error: Illegal value
> for template parameter.
> "/usr/local/include/boost/integer_fwd.hpp", line 138: Error: Cannot use class
> specialization with non-classes.
> "/opt/aoo-4.0.0/main/comphelper/source/misc/scopeguard.cxx", line 63: Error:
> Cannot use const int to initialize Dummy.
Ah, so this shows that the digits member is a const int as it should be.
Why low_bit_mask_t<> doesn't like the specialization with int is
strange, because in my boost/integer/integer_mask.hpp only allows
integer specializations (for std::size_t)!
What is also interesting is the location of the integer_fwd.hpp header
file: /usr/local/include/boost/
Are you using "--with-system-boost" or "--with-system-headers"? What
version of boost is installed on your system? AOO's current reference
implementation of boost is 1.48.
> I did a search for all the limits files on my system. Here are the results.:
>
> bash-3.2# find / -name limits
> /usr/sfw/include/c++/3.4.3/limits
> /usr/include/stdcxx4/limits
> /usr/local/include/boost/mpl/limits
> /usr/local/include/boost/tr1/tr1/limits
> /usr/local/include/boost_52/mpl/limits
> /usr/local/include/boost_52/tr1/tr1/limits
> /usr/local/gcc-4.8.1/include/c++/4.8.1/limits
> /opt/aoo-4.0.0/main/stlport/unxsoli4.pro/inc/stlport/limits
> /opt/aoo-4.0.0/main/stlport/unxsoli4.pro/inc/stlport/SC5/limits
> /opt/aoo-4.0.0/main/stlport/unxsoli4.pro/misc/build/STLport-4.0/stlport/limits
> /opt/aoo-4.0.0/main/stlport/unxsoli4.pro/misc/build/STLport-4.0/stlport/SC5/limits
> /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/limits
> /opt/aoodeps/perl-5.18.1/cpan/Devel-PPPort/parts/inc/limits
> /opt/aoodeps/STLport-5.2.1/stlport/limits
> /opt/aoodeps/boost_1_48_0/boost/mpl/limits
> /opt/aoodeps/boost_1_48_0/boost/tr1/tr1/limits
> /opt/aoodeps/gcc-4.8.1/libstdc++-v3/testsuite/18_support/headers/limits
> /opt/aoodeps/gcc-4.8.1/libstdc++-v3/include/std/limits
> /opt/solarisstudio12.3/prod/include/CC/Cstd/limits
> /opt/solarisstudio12.3/prod/include/CC/stlport4/limits
> /boost_1_54_0/boost/mpl/limits
> /boost_1_54_0/boost/tr1/tr1/limits
> /gcc-4.8.1.OLD/include/c++/4.8.1/limits
Darn, these are a lot of <limits> file. If the compiler picks one that
is not consistent with the related include files then all kinds of
troubles are not surprising.
To find out which <limits> file is included you could use the gcc option
"-E", that tells the compiler to just preprocess a source file and
output the preprocessed result to the output file specified by "-o".
As an example change into the configmgr directory and
build verbose=true
there. You'll see the exact command line for the compiler building e.g.
partial.cxx. Change the "-c" option ("compile") to "-E" ("preprocess
only") and run this one command line. The resulting partial.o is the
preprocessed source that will show you which <limits> was included.
> Lastly,
> The following patch seems to address the erf() issue. I edited
> /opt/aoo-4.0./main/solver/400/unxsoli4.pro/inc/vigra/config.hxx with the
> following and it seems to compile without error. However, isn't
> /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/config.hxx generated by
> the build. Should this be modified somewhere else?
When external libraries are built the process is as follows:
1. the tarball of the library is unpacked
2. some patches are applied (for vigra its the file "vigra-1.6.0.patch")
3. the library is built
4. the library is delivered to "solver"
Though modifying the header in solver can temporarily solve a compile
problem in a dependent module (e.g. basebmp) it is better to do the
needed modification before the library is built to get a consistent
state. To get the patch in as early as possible the patch file has to be
modified. As mentioned yesterday I already attached a patch against
"vigra-1.6.0.patch" to issue 123228.
By the way, did the modified vigra config.hxx allow basebmp to be built?
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
