You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openoffice.apache.org by "Steele, Raymond" <ra...@lmco.com> on 2013/09/03 18:10:10 UTC
RE: Building comphelper
Anyone? This seems to pertain to the GNU bug described here since mathconf.h included in the AOO source has a comment about it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608
From: Steele, Raymond
Sent: Wednesday, August 28, 2013 2:54 PM
To: dev@openoffice.apache.org; users@openoffice.apache.org
Subject: RE: Building comphelper
I'm not sure why I am having so many issues with comphelper, but I am also getting the following:
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/rtl/math.hxx, line 315: Error: The function "isfinite" must have a prototype
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/rtl/math.hxx, line 328: Error: The function "isfinite" must have a prototype
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/rtl/math.hxx, line 339: Error: The function "isfinite" must have a prototype
Each instance of the above is complaining about the use of SAL_MATH_FINITE. which I think is defined in mathconf.h
Any help would be greatly appreciated.
From: Steele, Raymond
Sent: Wednesday, August 28, 2013 2:38 PM
To: dev@openoffice.apache.org<ma...@openoffice.apache.org>; users@openoffice.apache.org<ma...@openoffice.apache.org>
Subject: Building comphelper
While build AOO 4.0, the build fails in module comphelper. It seems to be complaining about the boost/integer_fwd file.
/usr/local/include/boost/integer_fwd.hpp line 137, Error: Illegal value for template parameter.
/usr/local/include/boost/integer_fwd.hpp line 137, Error: Cannot use class specialization with non-classes.
integer_fwd.cpp contains the following on line 136 and 137:
136: template < >
137: struct low_bits_mask_t< ::std::numeric_limits<unsigned char>::digits>;
Any ideas? Has anyone run into this before.
Raymond
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
It does not look like my partial.hxx and medication.hxx file were attached, so they are pasted below.
#ifndef INCLUDED_CONFIGMGR_SOURCE_PARTIAL_HXX
#define INCLUDED_CONFIGMGR_SOURCE_PARTIAL_HXX
#include "sal/config.h"
#include <boost/unordered_map.hpp> // using the boost container because it explicitly allows recursive types
#include <set>
#include "boost/noncopyable.hpp"
#include "path.hxx"
#include "rtl/ustring.hxx"
namespace configmgr {
class Partial: private boost::noncopyable {
public:
enum Containment { CONTAINS_NOT, CONTAINS_SUBNODES, CONTAINS_NODE };
Partial(
std::set< rtl::OUString > const & includedPaths,
std::set< rtl::OUString > const & excludedPaths);
~Partial();
Containment contains(Path const & path) const;
private:
struct Node {
typedef boost::unordered_map< rtl::OUString, Node, rtl::OUStringHash > Children;
Node(): startInclude(false) {}
void clear() { startInclude=false; children.clear(); }
Children children;
bool startInclude;
};
Node root_;
};
}
#endif
/**************************************************************
*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*
*************************************************************/
#ifndef INCLUDED_CONFIGMGR_SOURCE_MODIFICATIONS_HXX
#define INCLUDED_CONFIGMGR_SOURCE_MODIFICATIONS_HXX
#include "sal/config.h"
#include <map>
#include "boost/noncopyable.hpp"
#include "path.hxx"
namespace rtl { class OUString; }
namespace configmgr {
class Modifications: private boost::noncopyable {
public:
struct Node {
typedef std::map< rtl::OUString, Node > Children;
Children children;
};
Modifications();
~Modifications();
void add(Path const & path);
void remove(Path const & path);
Node const & getRoot() const;
private:
Node root_;
};
}
#endif
-----Original Message-----
From: Steele, Raymond
Sent: Tuesday, September 10, 2013 9:12 AM
To: Herbert Duerr; dev@openoffice.apache.org
Subject: RE: EXTERNAL: Re: Building comphelper
Attached are my two files in question. I reverted modifications.hxx back to the original and kept partial.hxx as you patched in http://svn.apache.org/viewvc?view=revision&revision=1515285
Here is what I am receiving upon compile of configmgr.
bash-3.2# dmake
Compiling: configmgr/source/access.cxx
Compiling: configmgr/source/broadcaster.cxx
Compiling: configmgr/source/childaccess.cxx
Compiling: configmgr/source/components.cxx
Compiling: configmgr/source/configurationprovider.cxx
Compiling: configmgr/source/configurationregistry.cxx
"/opt/aoo-4.0.0/main/configmgr/source/configurationregistry.cxx", line 800: Warning: "::RegistryKey::createKey(const rtl::OUString&)" is expected to return a value.
"/opt/aoo-4.0.0/main/configmgr/source/configurationregistry.cxx", line 831: Warning: "::RegistryKey::openKeys()" is expected to return a value.
"/opt/aoo-4.0.0/main/configmgr/source/configurationregistry.cxx", line 842: Warning: "::RegistryKey::getKeyNames()" is expected to return a value.
3 Warning(s) detected.
Compiling: configmgr/source/data.cxx
Compiling: configmgr/source/defaultprovider.cxx
Compiling: configmgr/source/groupnode.cxx
Compiling: configmgr/source/localizedpropertynode.cxx
Compiling: configmgr/source/localizedvaluenode.cxx
Compiling: configmgr/source/lock.cxx
Compiling: configmgr/source/modifications.cxx
Compiling: configmgr/source/node.cxx
"/opt/aoo-4.0.0/main/configmgr/source/node.cxx", line 52: Warning: "configmgr::Node::getMembers()" is expected to return a value.
1 Warning(s) detected.
Compiling: configmgr/source/nodemap.cxx
Compiling: configmgr/source/parsemanager.cxx
Compiling: configmgr/source/partial.cxx
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199: Error: Could not find a match for boost::tuples::get<boost::tuples::N, boost::tuples::HT, boost::tuples::TT>(const boost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>) needed in boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node, boost::tuples::null_type>(configmgr::Partial::Node*, const boost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>&).
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350: Where: While instantiating "boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node, boost::tuples::null_type>(configmgr::Partial::Node*, const boost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>&)".
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350: Where: Instantiated from boost::unordered::unordered_map<rtl::OUString, configmgr::Partial::Node, rtl::OUStringHash, _STL::equal_to<rtl::OUString>, _STL::allocator<_STL::pair<const rtl::OUString, configmgr::Partial::Node>>>::operator[](const rtl::OUString&).
"/opt/aoo-4.0.0/main/configmgr/source/partial.cxx", line 82: Where: Instantiated from non-template code.
1 Error(s) detected.
dmake: Error code 2, while making '../unxsoli4.pro/slo/partial.obj'
________________________________________
From: Herbert Duerr [hdu@apache.org]
Sent: Tuesday, September 10, 2013 3:34 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
On 09.09.2013 19:59, Steele, Raymond wrote:
> I am using trying to build the source code that I pulled from here:
>
> http://www.apache.org/dist/openoffice/4.0.0/source/
Thanks for the info. Now I know better what to patch.
> I make the changes to my local copy of the files specified at
> http://svn.apache.org/viewvc?view=revision&revision=1515285
>
> Now, I am receiving the following. Looking into the cause now.
> [...]
> "/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_tree.c", line 590: Error: Too many arguments in call to "rtl::OUStringHash::operator()(const rtl::OUString&) const".
> [...]
The patch in the revision I mentioned was for a newer branch than
AOO400: To adapt it to your tree please keep the patched partial.hxx and revert modifications.hxx to its original.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Attached are my two files in question. I reverted modifications.hxx back to the original and kept partial.hxx as you patched in http://svn.apache.org/viewvc?view=revision&revision=1515285
Here is what I am receiving upon compile of configmgr.
bash-3.2# dmake
Compiling: configmgr/source/access.cxx
Compiling: configmgr/source/broadcaster.cxx
Compiling: configmgr/source/childaccess.cxx
Compiling: configmgr/source/components.cxx
Compiling: configmgr/source/configurationprovider.cxx
Compiling: configmgr/source/configurationregistry.cxx
"/opt/aoo-4.0.0/main/configmgr/source/configurationregistry.cxx", line 800: Warning: "::RegistryKey::createKey(const rtl::OUString&)" is expected to return a value.
"/opt/aoo-4.0.0/main/configmgr/source/configurationregistry.cxx", line 831: Warning: "::RegistryKey::openKeys()" is expected to return a value.
"/opt/aoo-4.0.0/main/configmgr/source/configurationregistry.cxx", line 842: Warning: "::RegistryKey::getKeyNames()" is expected to return a value.
3 Warning(s) detected.
Compiling: configmgr/source/data.cxx
Compiling: configmgr/source/defaultprovider.cxx
Compiling: configmgr/source/groupnode.cxx
Compiling: configmgr/source/localizedpropertynode.cxx
Compiling: configmgr/source/localizedvaluenode.cxx
Compiling: configmgr/source/lock.cxx
Compiling: configmgr/source/modifications.cxx
Compiling: configmgr/source/node.cxx
"/opt/aoo-4.0.0/main/configmgr/source/node.cxx", line 52: Warning: "configmgr::Node::getMembers()" is expected to return a value.
1 Warning(s) detected.
Compiling: configmgr/source/nodemap.cxx
Compiling: configmgr/source/parsemanager.cxx
Compiling: configmgr/source/partial.cxx
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199: Error: Could not find a match for boost::tuples::get<boost::tuples::N, boost::tuples::HT, boost::tuples::TT>(const boost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>) needed in boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node, boost::tuples::null_type>(configmgr::Partial::Node*, const boost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>&).
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350: Where: While instantiating "boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node, boost::tuples::null_type>(configmgr::Partial::Node*, const boost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>&)".
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350: Where: Instantiated from boost::unordered::unordered_map<rtl::OUString, configmgr::Partial::Node, rtl::OUStringHash, _STL::equal_to<rtl::OUString>, _STL::allocator<_STL::pair<const rtl::OUString, configmgr::Partial::Node>>>::operator[](const rtl::OUString&).
"/opt/aoo-4.0.0/main/configmgr/source/partial.cxx", line 82: Where: Instantiated from non-template code.
1 Error(s) detected.
dmake: Error code 2, while making '../unxsoli4.pro/slo/partial.obj'
________________________________________
From: Herbert Duerr [hdu@apache.org]
Sent: Tuesday, September 10, 2013 3:34 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
On 09.09.2013 19:59, Steele, Raymond wrote:
> I am using trying to build the source code that I pulled from here:
>
> http://www.apache.org/dist/openoffice/4.0.0/source/
Thanks for the info. Now I know better what to patch.
> I make the changes to my local copy of the files specified at http://svn.apache.org/viewvc?view=revision&revision=1515285
>
> Now, I am receiving the following. Looking into the cause now.
> [...]
> "/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_tree.c", line 590: Error: Too many arguments in call to "rtl::OUStringHash::operator()(const rtl::OUString&) const".
> [...]
The patch in the revision I mentioned was for a newer branch than
AOO400: To adapt it to your tree please keep the patched partial.hxx and
revert modifications.hxx to its original.
Herbert
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
On 09.09.2013 19:59, Steele, Raymond wrote:
> I am using trying to build the source code that I pulled from here:
>
> http://www.apache.org/dist/openoffice/4.0.0/source/
Thanks for the info. Now I know better what to patch.
> I make the changes to my local copy of the files specified at http://svn.apache.org/viewvc?view=revision&revision=1515285
>
> Now, I am receiving the following. Looking into the cause now.
> [...]
> "/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_tree.c", line 590: Error: Too many arguments in call to "rtl::OUStringHash::operator()(const rtl::OUString&) const".
> [...]
The patch in the revision I mentioned was for a newer branch than
AOO400: To adapt it to your tree please keep the patched partial.hxx and
revert modifications.hxx to its original.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
I am using trying to build the source code that I pulled from here:
http://www.apache.org/dist/openoffice/4.0.0/source/
I make the changes to my local copy of the files specified at http://svn.apache.org/viewvc?view=revision&revision=1515285
Now, I am receiving the following. Looking into the cause now.
=============
Building module configmgr
=============
Entering /opt/aoo-4.0.0/main/configmgr/qa/unoapi
Entering /opt/aoo-4.0.0/main/configmgr/inc
Entering /opt/aoo-4.0.0/main/configmgr/source
Compiling: configmgr/source/components.cxx
"/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_tree.c", line 590: Error: Too many arguments in call to "rtl::OUStringHash::operator()(const rtl::OUString&) const".
"/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_map.h", line 192: Where: While instantiating "_STL::_Rb_tree<rtl::OUString, _STL::pair<const rtl::OUString, configmgr::Modifications::Node>, _STL::_Select1st<_STL::pair<const rtl::OUString, configmgr::Modifications::Node>>, rtl::OUStringHash, _STL::allocator<_STL::pair<const rtl::OUString, configmgr::Modifications::Node>>>::find(const rtl::OUString&) const".
"/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_map.h", line 192: Where: Instantiated from non-template code.
"/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_tree.c", line 596: Error: Too many arguments in call to "rtl::OUStringHash::operator()(const rtl::OUString&) const".
"/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_map.h", line 192: Where: While instantiating "_STL::_Rb_tree<rtl::OUString, _STL::pair<const rtl::OUString, configmgr::Modifications::Node>, _STL::_Select1st<_STL::pair<const rtl::OUString, configmgr::Modifications::Node>>, rtl::OUStringHash, _STL::allocator<_STL::pair<const rtl::OUString, configmgr::Modifications::Node>>>::find(const rtl::OUString&) const".
"/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_map.h", line 192: Where: Instantiated from non-template code.
2 Error(s) detected.
dmake: Error code 2, while making '../unxsoli4.pro/slo/components.obj'
1 module(s):
configmgr
need(s) to be rebuilt
Reason(s):
ERROR: error 65280 occurred while making /opt/aoo-4.0.0/main/configmgr/source
When you have fixed the errors in that module you can resume the build by running:
build --all:configmgr
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Monday, September 09, 2013 2:28 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 07.09.2013 02:17, Steele, Raymond wrote:
> Problem after problem.
So far the problems where quite trivial platform differences. Of course the problems only become simple after their root cause is understood ;-)
> Now I am getting:
>
> Entering /opt/aoo-4.0.0/main/configmgr/source
>
> Compiling: configmgr/source/partial.cxx
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199: Error: Could not find a match for boost::tuples::get<boost::tuples::N, boost::tuples::HT, boost::tuples::TT>(const boost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>) needed in boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node, boost::tuples::null_type>(configmgr::Partial::Node*, const boost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>&).
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350: Where: While instantiating "boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node, boost::tuples::null_type>(configmgr::Partial::Node*, const boost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>&)".
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350: Where: Instantiated from boost::unordered::unordered_map<rtl::OUString, configmgr::Partial::Node, boost::hash<rtl::OUString>, _STL::equal_to<rtl::OUString>, _STL::allocator<_STL::pair<const rtl::OUString, configmgr::Partial::Node>>>::operator[](const rtl::OUString&).
> "/opt/aoo-4.0.0/main/configmgr/source/partial.cxx", line 82: Where: Instantiated from non-template code.
> 1 Error(s) detected.
> dmake: Error code 2, while making '../unxsoli4.pro/slo/partial.obj'
What version of AOO are you building? AOO trunk? AOO400 or AOO401? If you're not building AOO trunk I suggest to apply my change from revision
1515285 to it and recompile configmgr. If it helps then the change is a candidate to be merged into the release branch as well.
[1] http://svn.apache.org/viewvc?view=revision&revision=1515285
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi Raymond,
On 07.09.2013 02:17, Steele, Raymond wrote:
> Problem after problem.
So far the problems where quite trivial platform differences. Of course
the problems only become simple after their root cause is understood ;-)
> Now I am getting:
>
> Entering /opt/aoo-4.0.0/main/configmgr/source
>
> Compiling: configmgr/source/partial.cxx
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199: Error: Could not find a match for boost::tuples::get<boost::tuples::N, boost::tuples::HT, boost::tuples::TT>(const boost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>) needed in boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node, boost::tuples::null_type>(configmgr::Partial::Node*, const boost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>&).
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350: Where: While instantiating "boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node, boost::tuples::null_type>(configmgr::Partial::Node*, const boost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>&)".
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350: Where: Instantiated from boost::unordered::unordered_map<rtl::OUString, configmgr::Partial::Node, boost::hash<rtl::OUString>, _STL::equal_to<rtl::OUString>, _STL::allocator<_STL::pair<const rtl::OUString, configmgr::Partial::Node>>>::operator[](const rtl::OUString&).
> "/opt/aoo-4.0.0/main/configmgr/source/partial.cxx", line 82: Where: Instantiated from non-template code.
> 1 Error(s) detected.
> dmake: Error code 2, while making '../unxsoli4.pro/slo/partial.obj'
What version of AOO are you building? AOO trunk? AOO400 or AOO401? If
you're not building AOO trunk I suggest to apply my change from revision
1515285 to it and recompile configmgr. If it helps then the change is a
candidate to be merged into the release branch as well.
[1] http://svn.apache.org/viewvc?view=revision&revision=1515285
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Problem after problem. Now I am getting:
Entering /opt/aoo-4.0.0/main/configmgr/source
Compiling: configmgr/source/partial.cxx
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199: Error: Could not find a match for boost::tuples::get<boost::tuples::N, boost::tuples::HT, boost::tuples::TT>(const boost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>) needed in boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node, boost::tuples::null_type>(configmgr::Partial::Node*, const boost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>&).
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350: Where: While instantiating "boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node, boost::tuples::null_type>(configmgr::Partial::Node*, const boost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>&)".
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350: Where: Instantiated from boost::unordered::unordered_map<rtl::OUString, configmgr::Partial::Node, boost::hash<rtl::OUString>, _STL::equal_to<rtl::OUString>, _STL::allocator<_STL::pair<const rtl::OUString, configmgr::Partial::Node>>>::operator[](const rtl::OUString&).
"/opt/aoo-4.0.0/main/configmgr/source/partial.cxx", line 82: Where: Instantiated from non-template code.
1 Error(s) detected.
dmake: Error code 2, while making '../unxsoli4.pro/slo/partial.obj'
1 module(s):
configmgr
need(s) to be rebuilt
Reason(s):
ERROR: error 65280 occurred while making /opt/aoo-4.0.0/main/configmgr/source
When you have fixed the errors in that module you can resume the build by running:
build --all:configmgr
I thought I paste it here to see if you could help. Thanks!
-----Original Message-----
From: Steele, Raymond
Sent: Friday, September 06, 2013 3:17 PM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Subject: RE: EXTERNAL: Re: Building comphelper
Herbert,
To address the isfinite() issue I added the following to rtl/math.hxx:
#ifdef SOLARIS
#undef SAL_MATH_FINITE
#define SAL_MATH_FINITE(d) finite(d)
#endf
Your links were very helpful. Thanks so much.
Now onto:
integer_fwd.cpp contains the following on line 136 and 137:
136: template < > 137: struct low_bits_mask_t< ::std::numeric_limits<unsigned
char>::digits>;
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Thursday, September 05, 2013 12:34 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hy Raymond,
On 04.09.2013 18:33, Steele, Raymond wrote:
> You are right, I completely missed your post. I am updating my compiler (SolarisStudio 12.3) now. As far as I can see now, I do not have isfinite is not a member of std on my system. Although, Netbeans allows me to choose C++ Standard C++11. What do you mean by " experiment with the different SAL_MATH_FINITE definitions"?
mathconf.h is a C header file, so we need the C definition of isfinite.
According to [1] the "C" isfinite() should be defined in <math.h>. Maybe on your platform there is a bug similar to [2] that undefines it later.
But we can assume that isfinite() is available in one form or the other on your system. Maybe it is called finite(), _finite(), or __builtin_isfinite()? Assuming [3] applies here then finite() may be the pre-standard equivalent to the isfinite() function that we are looking for.
[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/isfinite.html
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608
[3] https://www.varnish-cache.org/trac/ticket/464
What I meant with "experiment with the different SAL_MATH_FINITE definitions" is to check whether one of the above pre-standard
isfinite() alternatives work. If you found one then add a define for SOLARIS only that doesn't break the other platforms.
By the way std::isfinite() should be provided via <cmath> for C++11. But as the mathconf.h header is a "C" header this C++11 header is not available in this context.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
On 05.09.2013 18:37, Steele, Raymond wrote:
> Thanks for the information. I will give this a try if my current strategy does not work.
> Apparently, SolarisStudios 12.3 compiler is not compatible with c++11.
We don't build in C++11 mode for (most of) our target platforms yet.
> I just finished building GCC 4.8.1 so that I can attempt to build with that.
I'm a bit worried about our UNO bridges when I hear this. This code in
main/bridges/source/cpp_uno is very sensitive to platform/compiler
changes. GCC 4.8 is quite new and I'm also afraid that the gcc-solaris
bridges are not as well exercised as their suncc counterparts.
By the way, are you targeting sparc or x86 CPUs?
> Now, I am having the issue described here: http://wiki.openoffice.org/wiki/OpenSolaris_Build_Instructions/Configure_Errors#Error:_GCC_Linker because I have CC and CXX pointing to my new gcc and g++. How can I point these variables to SolarisStudio compilers for linking, but use gcc for compiling?
If I understand the error message in the referenced Wiki section
correctly you'd want to link with GNU ld on Solaris if you built with
gcc and link with Sun ld if you built with Sun CC, so all should be fine
with CC and CXX being set.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Thanks for the information. I will give this a try if my current strategy does not work. Apparently, SolarisStudios 12.3 compiler is not compatible with c++11. I just finished building GCC 4.8.1 so that I can attempt to build with that. Now, I am having the issue described here: http://wiki.openoffice.org/wiki/OpenSolaris_Build_Instructions/Configure_Errors#Error:_GCC_Linker because I have CC and CXX pointing to my new gcc and g++. How can I point these variables to SolarisStudio compilers for linking, but use gcc for compiling?
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Thursday, September 05, 2013 12:34 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hy Raymond,
On 04.09.2013 18:33, Steele, Raymond wrote:
> You are right, I completely missed your post. I am updating my compiler (SolarisStudio 12.3) now. As far as I can see now, I do not have isfinite is not a member of std on my system. Although, Netbeans allows me to choose C++ Standard C++11. What do you mean by " experiment with the different SAL_MATH_FINITE definitions"?
mathconf.h is a C header file, so we need the C definition of isfinite.
According to [1] the "C" isfinite() should be defined in <math.h>. Maybe on your platform there is a bug similar to [2] that undefines it later.
But we can assume that isfinite() is available in one form or the other on your system. Maybe it is called finite(), _finite(), or __builtin_isfinite()? Assuming [3] applies here then finite() may be the pre-standard equivalent to the isfinite() function that we are looking for.
[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/isfinite.html
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608
[3] https://www.varnish-cache.org/trac/ticket/464
What I meant with "experiment with the different SAL_MATH_FINITE definitions" is to check whether one of the above pre-standard
isfinite() alternatives work. If you found one then add a define for SOLARIS only that doesn't break the other platforms.
By the way std::isfinite() should be provided via <cmath> for C++11. But as the mathconf.h header is a "C" header this C++11 header is not available in this context.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
I was doing a dmake clean in the main directory. Apparently, it was not removing the solver dir.
________________________________________
From: Herbert Duerr [hdu@apache.org]
Sent: Wednesday, September 18, 2013 3:33 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 16.09.2013 19:40, Steele, Raymond wrote:
> 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.
This file should and cannot be there if the --without-stlport build was
clean. For its recipe see main/stlport/makefile.mk. Please retry doing
the --without-stlport clean build, i.e. main/solver and */unxsoli4.pro
output directories removed.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi Raymond,
On 16.09.2013 19:40, Steele, Raymond wrote:
> 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.
This file should and cannot be there if the --without-stlport build was
clean. For its recipe see main/stlport/makefile.mk. Please retry doing
the --without-stlport clean build, i.e. main/solver and */unxsoli4.pro
output directories removed.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
I am not sure why my attachments are not going through, but here is the preprocessor output. I filtered on utility.
/opt/solarisstudio12.3/bin/CC -E -temp=/tmp -xarch=generic -xO3 -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -D_FILE_OFFSET_BITS=64 -I/usr/local/include/boost/ -I. -I../../unxsoli4.pro/inc/oslall -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/rasqal -I/usr/include/stdcxx4 -I/opt/aoo-4.0.0/main/stlport/systemstl/: -I/usr/local/include -I/usr/include -I/usr/local/include/rasqal -I/usr/include/stdcxx4 -I/opt/aoo-4.0.0/main/stlport/systemstl/: -I/usr/local/include -I/usr/include -I/usr/local/inclue/rasqal -I/opt/aoo-4.0.0/main/stlport/systemstl/ -I/opt/solarisstudio12.3/prod/include/CC/Cstd/ -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/offuh -I. -I../../res -I. -features=no%altspell "-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 -DEXCEPTIONS_ON -o /tmp/file /opt/aoo-4.0.0/main/sal/osl/all/debugbase.cxx|grep utility
#1 "/usr/local/include/boost/config/no_tr1/utility.hpp"
#1 "/opt/solarisstudio12.3/prod/include/CC/Cstd/utility"
#52 "/opt/solarisstudio12.3/prod/include/CC/Cstd/utility"
#1 "/usr/local/include/boost/utility/enable_if.hpp"
#1 "/usr/local/include/boost/utility/addressof.hpp"
#1 "/usr/local/include/boost/utility/swap.hpp"
"/usr/local/include/boost/tr1/detail/config_all.hpp", line 161: Error: Could not open include file<../include/utility>.
________________________________________
From: Herbert Duerr [hdu@apache.org]
Sent: Friday, September 20, 2013 8:53 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
> I found hash_set in ../main/stlport/systemstl
>
> Is that where it is supposed to be.
Yes.
> Once, I added this to my SOLARINC and SOLARINV environment variables, everything was okay, but then I received a
>
> "/usr/local/include/boost/tr1/detail/config_all.hpp", line 161: Error: Could not open include file<../include/utility>
The <utility> header should come somewhere from your c++ compiler
includes. According to [1] it should be there somewhere. If it is not
found we need to put its path at the end of the include paths.
[1] http://docs.oracle.com/cd/E19205-01/819-5267/bkajw/index.html
Sorry for the late answer. I was busy with AOO401rc3.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi Raymond,
On 02.10.2013 17:26, Steele, Raymond wrote:
> I have hit a stop work on the Solaris 10 port for now. We are in the process of moving over to Solaris 11. I will probably need to port OpenOffice to Solaris 11 soon.
Thanks for the update! With the newer build environment there things
should be easier... Hope springs eternal ;-)
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
I have hit a stop work on the Solaris 10 port for now. We are in the process of moving over to Solaris 11. I will probably need to port OpenOffice to Solaris 11 soon.
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Friday, September 20, 2013 11:58 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 20.09.2013 19:52, Steele, Raymond wrote:
> No problems on the delay. I am very greatful for your assistance!!
>
> Here is my compiler command and below are locations of my utility file. Hopefully this may help. I added utility to the include path, but still no luck.
>
> bash-3.2# /opt/solarisstudio12.3/bin/CC -c -temp=/tmp -xarch=generic -xO3 -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -D_FILE_OFFSET_BITS=64 -I. -I../../unxsoli4.pro/inc/oslall -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/externa l -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/unx soli4.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/rasqal -I/usr/include/stdcxx4 -I/opt/aoo-4.0.0/main/stlport/systemstl/: -I/usr/local/include -I/usr/include -I/usr/local/i nclude/rasqal -I/usr/include/stdcxx4 -I/opt/a
oo-4.0.0/main/stlport/systemstl/: -I/usr/local/include -I/usr/include -I/usr/local/inclue/rasqal -I/opt/aoo-4.0.0/main/stlport/systemstl/ -I/opt /solarisstudio12.3/prod/include/CC/Cstd/ -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/offuh -I. -I../../res -I. -features=no%altspell "-features=rvalueref" +w2 -erroff=doubunder,ident expected,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 -DEXCEPTIONS_ON -o . ./../unxsoli4.pro/obj/debugbase.o /opt/aoo-4.0.0/main/sal/osl/all/debugbase.cxx
> "/usr/local/include/boost/tr1/detail/config_all.hpp", line 161: Error: Could not open include file<../include/utility>.
>
> [...]
> /usr/include/stdcxx4/utility
> [...]
> /opt/solarisstudio12.3/prod/include/CC/Cstd/utility
I think one of these two header files is the one we are looking for.
Boost is using the "relative include path" trick with its
BOOST_TR1_STD_HEADER() macro because the neat "include_next" extension is not supported in the solaris compiler.
One of the BOOST_TR1_STD_HEADER defines in config_all.hpp is looking for the stdcxx4 path. I wonder why it isn't picked up. Either 1. one of the defines is wrong (__SUNPRO_CC,__STD_RWCOMPILER_H,
___RWSTD_VER) or boost erroneously doesn't pick it up 2. the -I/opt/solarisstudio12.3/prod/include/CC/Cstd/ part of the compile options should be changed to find /usr/include/stdcxx4/ instead 3. the BOOST_TR1_STD_HEADER define should be changed to "../Cstd/"
Which of the alternatives 2. or 3. is better depends on which of both STL header sets better implements C++'s std templates as defined in TR1.
From the name I'd guess the Cstd one is better.
> /opt/solarisstudio12.3/prod/include/CC/stlport4/utility
>
> I found this about Solaris 11, but the fix appears to be included in boost version 1_48 (Mine is attached).
>
> https://svn.boost.org/trac/boost/ticket/5111
Interesting. Maybe the above and this are related.
Hope that helps. Have a nice weekend!
Herbert
(about to upload AOO401rc3 to the snapshot page)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Tyler Kavanaugh <tw...@kc.rr.com>.
On 1/8/2014 4:32 AM, Herbert Duerr wrote:
> On 08.01.2014 01:09, Kay Schenk wrote:
>> [...]
>> Given your recent commits as patches to (now suppiled) boost_1.55, AND
>> some
>> interesting definitions in /main/stlport/systemstl/slist
>>
>> #else // fall back to boost/tr1 (forward_list or plain list)
>> #include <boost/config.hpp>
>>
>> (who knows if the suppiled config.hpp jives with my own)
>
> The config.hpp provided by boost must match with the rest of the
> library. At least that's what this header is intended for.
>
>> I ditched using my local boost_1.54, and things are going much much
>> better.
>> Not quite there yet but close. :}
>
> Yay!
>
>> At this point, given the customized work you've done, we might think of
>> warning folks against using their local boost versions -- at least put
>> some
>> notes in configure.in. Just a thought.
>
> We should add such a warning to about every system library that is not
> regularly enabled for building and testing. The release builds prefer
> the defaults, but for many libraries AOO's configure script allows the
> use of system provided alternatives:
> apache-commons, apr, apr-util, beanshell, boost, cairo, coinmp, cppunit,
> curl, db, dicts, expat, graphite, hsqldb, hunspell, hyphen, icu, jpeg,
> libtextcat, libtextcat-data, libwpd, libxml, libxslt, lucene, mdds,
> mysql, mysql-cppconn, mythes, nss, odbc-headers, openssl, poppler,
> python, redland, sane-header, saxon, serf, vigra, xrender-headers and zlib.
>
> Assuming that each of the above mentioned libraries have 4 to 12
> different versions out in the wild this means that between 4^40 and
> 12^40 different configurations are possible, of which we build and test
> only very few (<=4?) regularly.
>
> The configuration space is increased even more when we consider that
> there are many different kinds of compilers in different versions, also
> linkers etc.
>
> What would be the simplest approach to address this? Just adding a "use
> the --with-system-X options only if you know that this works or if you
> enjoy debugging"? Or should we hide them behind an
> "--enable-expert-options" configure switch which would be similar to the
> broad "--enable-category-b" option?
For my part, I'd suggest we hide them behind a "--enable-expert-options"
switch. Given the massive number of configurations, doing such a thing
could alleviate many headaches, especially given that it could be
extremely difficult for some of us to reproduce and track down problems
related to very specific library, compiler, and linker versions.
>
> Herbert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Jan 8, 2014 at 11:14 PM, Herbert Duerr <hd...@apache.org> wrote:
> On 01/08/2014 07:52 PM, Kay Schenk wrote:
> > On Wed, Jan 8, 2014 at 2:32 AM, Herbert Duerr <hd...@apache.org> wrote:
> >> [...]
> >> The config.hpp provided by boost must match with the rest of the
> library.
> >> At least that's what this header is intended for.
> >
> >
> > yes...but if a developer is using a local boost, might they inadvertently
> > include some config options that might not be compatible with
> OpenOffice's
> > build process? This was my concern when I saw this.
>
> If the system boost version is new enough and its config.hpp matches to
> the rest of its headers then it should be possible to make AOO build
> with it. If there are platforms where the system boost's default
> configuration doesn't work for building AOO then AOO should be adapted
> for it. Patches for that situation should be integrated if they don't
> cause regressions for other platforms / the boost version AOO brings along.
>
> >> I ditched using my local boost_1.54, and things are going much much
> >>> better.
> >>> Not quite there yet but close. :}
> >>>
> >>
> >> Yay!
> >
> >
> > yes, got a good build! YAY! Indeed!
>
> :-)
>
> >
> >
> >>
> >> At this point, given the customized work you've done, we might think of
> >>> warning folks against using their local boost versions -- at least put
> >>> some
> >>> notes in configure.in. Just a thought.
> >>>
> >>
> >> We should add such a warning to about every system library that is not
> >> regularly enabled for building and testing. The release builds prefer
> the
> >> defaults, but for many libraries AOO's configure script allows the use
> of
> >> system provided alternatives:
> >> apache-commons, apr, apr-util, beanshell, boost, cairo, coinmp, cppunit,
> >> curl, db, dicts, expat, graphite, hsqldb, hunspell, hyphen, icu, jpeg,
> >> libtextcat, libtextcat-data, libwpd, libxml, libxslt, lucene, mdds,
> mysql,
> >> mysql-cppconn, mythes, nss, odbc-headers, openssl, poppler, python,
> >> redland, sane-header, saxon, serf, vigra, xrender-headers and zlib.
> >>
> >> Assuming that each of the above mentioned libraries have 4 to 12
> different
> >> versions out in the wild this means that between 4^40 and 12^40
> different
> >> configurations are possible, of which we build and test only very few
> >> (<=4?) regularly.
> >>
> >> The configuration space is increased even more when we consider that
> there
> >> are many different kinds of compilers in different versions, also
> linkers
> >> etc.
> >>
> >> What would be the simplest approach to address this? Just adding a "use
> >> the --with-system-X options only if you know that this works or if you
> >> enjoy debugging"? Or should we hide them behind an
> >> "--enable-expert-options" configure switch which would be similar to the
> >> broad "--enable-category-b" option?
> >
> >
> > Your analysis above is well-taken. And, dealing with configure options,
> > which local configure options might be helpful, and which ones might be
> > more challenging, is an interesting question. These are topics that
> should
> > be discussed in a new thread, I think.
>
> +1
>
coming soon...hopefully with more information pertaining to the your
comments here
>
> I have to admit that I'm not an expert on autoconf, so I don't know
> whether we can make options disappear for e.g. a non-expert mode. But at
> least a better grouping of these options should be possible.
>
> > I know we all want developers to have a "good" experience and providing
> > more clarification on how the configure options effect the outcome will
> > certainly help.
>
> +1 again
>
> Even people who worked for many years with the OpenOffice code often
> don't really know the exact impact of each configure switch. Many use
> their "tried and working" configure scripts and almost never deviate
> from that.
>
> E.g. for each of --with-system-X switches it is very hard to answer how
> enabling it would impact the build and the result, especially when X is
> available in a couple of different versions and configurations.
>
> But this might be an interesting opportunity for volunteers? E.g. when
> trying to figure out the impact of the --with-system-hunspell switch one
> could install one hunspell version after the other on the different
> platforms, do a clean build with each of them and test the install set.
> The experience gained from these iterations could result in a much
> improved description of such a configuration switch, which would be very
> much appreciated by everyone.
>
> > Thanks again for all your help with my build problems...
>
> You're welcome!
>
> Herbert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Herbert Duerr <hd...@apache.org>.
On 01/08/2014 07:52 PM, Kay Schenk wrote:
> On Wed, Jan 8, 2014 at 2:32 AM, Herbert Duerr <hd...@apache.org> wrote:
>> [...]
>> The config.hpp provided by boost must match with the rest of the library.
>> At least that's what this header is intended for.
>
>
> yes...but if a developer is using a local boost, might they inadvertently
> include some config options that might not be compatible with OpenOffice's
> build process? This was my concern when I saw this.
If the system boost version is new enough and its config.hpp matches to
the rest of its headers then it should be possible to make AOO build
with it. If there are platforms where the system boost's default
configuration doesn't work for building AOO then AOO should be adapted
for it. Patches for that situation should be integrated if they don't
cause regressions for other platforms / the boost version AOO brings along.
>> I ditched using my local boost_1.54, and things are going much much
>>> better.
>>> Not quite there yet but close. :}
>>>
>>
>> Yay!
>
>
> yes, got a good build! YAY! Indeed!
:-)
>
>
>>
>> At this point, given the customized work you've done, we might think of
>>> warning folks against using their local boost versions -- at least put
>>> some
>>> notes in configure.in. Just a thought.
>>>
>>
>> We should add such a warning to about every system library that is not
>> regularly enabled for building and testing. The release builds prefer the
>> defaults, but for many libraries AOO's configure script allows the use of
>> system provided alternatives:
>> apache-commons, apr, apr-util, beanshell, boost, cairo, coinmp, cppunit,
>> curl, db, dicts, expat, graphite, hsqldb, hunspell, hyphen, icu, jpeg,
>> libtextcat, libtextcat-data, libwpd, libxml, libxslt, lucene, mdds, mysql,
>> mysql-cppconn, mythes, nss, odbc-headers, openssl, poppler, python,
>> redland, sane-header, saxon, serf, vigra, xrender-headers and zlib.
>>
>> Assuming that each of the above mentioned libraries have 4 to 12 different
>> versions out in the wild this means that between 4^40 and 12^40 different
>> configurations are possible, of which we build and test only very few
>> (<=4?) regularly.
>>
>> The configuration space is increased even more when we consider that there
>> are many different kinds of compilers in different versions, also linkers
>> etc.
>>
>> What would be the simplest approach to address this? Just adding a "use
>> the --with-system-X options only if you know that this works or if you
>> enjoy debugging"? Or should we hide them behind an
>> "--enable-expert-options" configure switch which would be similar to the
>> broad "--enable-category-b" option?
>
>
> Your analysis above is well-taken. And, dealing with configure options,
> which local configure options might be helpful, and which ones might be
> more challenging, is an interesting question. These are topics that should
> be discussed in a new thread, I think.
+1
I have to admit that I'm not an expert on autoconf, so I don't know
whether we can make options disappear for e.g. a non-expert mode. But at
least a better grouping of these options should be possible.
> I know we all want developers to have a "good" experience and providing
> more clarification on how the configure options effect the outcome will
> certainly help.
+1 again
Even people who worked for many years with the OpenOffice code often
don't really know the exact impact of each configure switch. Many use
their "tried and working" configure scripts and almost never deviate
from that.
E.g. for each of --with-system-X switches it is very hard to answer how
enabling it would impact the build and the result, especially when X is
available in a couple of different versions and configurations.
But this might be an interesting opportunity for volunteers? E.g. when
trying to figure out the impact of the --with-system-hunspell switch one
could install one hunspell version after the other on the different
platforms, do a clean build with each of them and test the install set.
The experience gained from these iterations could result in a much
improved description of such a configuration switch, which would be very
much appreciated by everyone.
> Thanks again for all your help with my build problems...
You're welcome!
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Jan 8, 2014 at 2:32 AM, Herbert Duerr <hd...@apache.org> wrote:
> On 08.01.2014 01:09, Kay Schenk wrote:
>
>> [...]
>>
>> Given your recent commits as patches to (now suppiled) boost_1.55, AND
>> some
>> interesting definitions in /main/stlport/systemstl/slist
>>
>> #else // fall back to boost/tr1 (forward_list or plain list)
>> #include <boost/config.hpp>
>>
>> (who knows if the suppiled config.hpp jives with my own)
>>
>
> The config.hpp provided by boost must match with the rest of the library.
> At least that's what this header is intended for.
yes...but if a developer is using a local boost, might they inadvertently
include some config options that might not be compatible with OpenOffice's
build process? This was my concern when I saw this.
>
>
> I ditched using my local boost_1.54, and things are going much much
>> better.
>> Not quite there yet but close. :}
>>
>
> Yay!
yes, got a good build! YAY! Indeed!
>
> At this point, given the customized work you've done, we might think of
>> warning folks against using their local boost versions -- at least put
>> some
>> notes in configure.in. Just a thought.
>>
>
> We should add such a warning to about every system library that is not
> regularly enabled for building and testing. The release builds prefer the
> defaults, but for many libraries AOO's configure script allows the use of
> system provided alternatives:
> apache-commons, apr, apr-util, beanshell, boost, cairo, coinmp, cppunit,
> curl, db, dicts, expat, graphite, hsqldb, hunspell, hyphen, icu, jpeg,
> libtextcat, libtextcat-data, libwpd, libxml, libxslt, lucene, mdds, mysql,
> mysql-cppconn, mythes, nss, odbc-headers, openssl, poppler, python,
> redland, sane-header, saxon, serf, vigra, xrender-headers and zlib.
>
> Assuming that each of the above mentioned libraries have 4 to 12 different
> versions out in the wild this means that between 4^40 and 12^40 different
> configurations are possible, of which we build and test only very few
> (<=4?) regularly.
>
> The configuration space is increased even more when we consider that there
> are many different kinds of compilers in different versions, also linkers
> etc.
>
> What would be the simplest approach to address this? Just adding a "use
> the --with-system-X options only if you know that this works or if you
> enjoy debugging"? Or should we hide them behind an
> "--enable-expert-options" configure switch which would be similar to the
> broad "--enable-category-b" option?
Your analysis above is well-taken. And, dealing with configure options,
which local configure options might be helpful, and which ones might be
more challenging, is an interesting question. These are topics that should
be discussed in a new thread, I think.
I know we all want developers to have a "good" experience and providing
more clarification on how the configure options effect the outcome will
certainly help.
Thanks again for all your help with my build problems...
>
> Herbert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Herbert Duerr <hd...@apache.org>.
On 08.01.2014 01:09, Kay Schenk wrote:
> [...]
> Given your recent commits as patches to (now suppiled) boost_1.55, AND some
> interesting definitions in /main/stlport/systemstl/slist
>
> #else // fall back to boost/tr1 (forward_list or plain list)
> #include <boost/config.hpp>
>
> (who knows if the suppiled config.hpp jives with my own)
The config.hpp provided by boost must match with the rest of the
library. At least that's what this header is intended for.
> I ditched using my local boost_1.54, and things are going much much better.
> Not quite there yet but close. :}
Yay!
> At this point, given the customized work you've done, we might think of
> warning folks against using their local boost versions -- at least put some
> notes in configure.in. Just a thought.
We should add such a warning to about every system library that is not
regularly enabled for building and testing. The release builds prefer
the defaults, but for many libraries AOO's configure script allows the
use of system provided alternatives:
apache-commons, apr, apr-util, beanshell, boost, cairo, coinmp, cppunit,
curl, db, dicts, expat, graphite, hsqldb, hunspell, hyphen, icu, jpeg,
libtextcat, libtextcat-data, libwpd, libxml, libxslt, lucene, mdds,
mysql, mysql-cppconn, mythes, nss, odbc-headers, openssl, poppler,
python, redland, sane-header, saxon, serf, vigra, xrender-headers and zlib.
Assuming that each of the above mentioned libraries have 4 to 12
different versions out in the wild this means that between 4^40 and
12^40 different configurations are possible, of which we build and test
only very few (<=4?) regularly.
The configuration space is increased even more when we consider that
there are many different kinds of compilers in different versions, also
linkers etc.
What would be the simplest approach to address this? Just adding a "use
the --with-system-X options only if you know that this works or if you
enjoy debugging"? Or should we hide them behind an
"--enable-expert-options" configure switch which would be similar to the
broad "--enable-category-b" option?
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Jan 2, 2014 at 2:44 PM, Kay Schenk <ka...@gmail.com> wrote:
>
> On Thu, Jan 2, 2014 at 10:28 AM, Kay Schenk <ka...@gmail.com> wrote:
>
>>
>>
>> On Thu, Jan 2, 2014 at 6:32 AM, Herbert Duerr <hd...@apache.org> wrote:
>>
>>> Happy new year!
>>>
>>> A small update on the problem Kay mentioned:
>>>
>>>
>>> On 23.12.2013 08:51, Herbert Duerr wrote:
>>>
>>>> Kay Schenk wrote:
>>>>
>>>>> On Fri, Dec 13, 2013 at 6:04 AM, Herbert Duerr <hd...@apache.org> wrote:
>>>>>
>>>>>> [...]
>>>>>> In your installation the hash template is apparently already mapped
>>>>>> to the
>>>>>> std namespace, so us trying to map it there again causes trouble. To
>>>>>> verify
>>>>>> this idea you could comment out the
>>>>>> using STLP4_EMUBASE_NS::hash;
>>>>>> lines in booth main/stlport/systemstl/hash_* files.
>>>>>>
>>>>>>
>>>>> a short update on my progress...
>>>>>
>>>>> The suggestion above worked for that problem...
>>>>>
>>>>
>>>> Wonderful! This means some parts (or all?) of boost's tr1 headers are
>>>> already directly into the std namespace. And they are of course also
>>>> available in the std::tr1 namespace where they come from. Please have a
>>>> look at the preprocessor output. To see what the compiler sees to achive
>>>> this.
>>>>
>>>
>>> If you compiled in C++11 mode then the C++11 templates for TR1 libraries
>>> are already required to be in the std namespace. When I tried it out myself
>>> I saw similar problems to the ones you saw. I fixed them in issue 123947 /
>>> revision 1554812 on trunk. You might want to try it out.
>>>
>>
>> OK -- I hadn't gotten back to this yet.
>>
>>
>>>
>>> Kay, did you explicitly enable C++11 mode for your Linux build? AFAIK
>>> C++11 mode is not enabled by default on any Linux distribution, or has a
>>> distro already switched this default? I'm sure this would break a lot of
>>> third-party codes...
>>>
>>
>> yes, since I thought we were working toward this as a standard...
>>
>> I saw your commits and am hopeful this will solve my situation...
>>
>>
>>>
>>>
>>> Herbert
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>>
>>
>> --
>>
>> -------------------------------------------------------------------------------------------------
>> MzK
>>
>> "Cats do not have to be shown how to have a good time,
>> for they are unfailing ingenious in that respect."
>> -- James Mason
>>
>
> Well I got a bit further long with this -- so YAY! for your changes.
>
> But,...I am now having problems compiling regimpl.cxx in module "registry"
> --
>
> Here's the traceback if you're interested but I will investigate as well.
>
>
> In file included from /usr/include/boost/bind/mem_fn.hpp:25:0,
> from /usr/include/boost/mem_fn.hpp:22,
> from /usr/include/boost/tr1/functional.hpp:62,
> from /usr/include/boost/tr1/tr1/functional:27,
> from /home/kschenk/AOO_source/main/solver/410/
> unxlngi6.pro/inc/stl/functional:36,
> from /usr/include/c++/4.7/memory:81,
> from
> /home/kschenk/AOO_source/main/registry/source/regimpl.cxx:29:
> /usr/include/boost/get_pointer.hpp:27:40: error: template declaration of
> 'T* boost::get_pointer'
> /usr/include/boost/get_pointer.hpp:27:35: error: 'auto_ptr' is not a
> member of 'std'
> /usr/include/boost/get_pointer.hpp:27:50: error: expected
> primary-expression before '>' token
> /usr/include/boost/get_pointer.hpp:27:52: error: expected
> primary-expression before 'const'
> /usr/include/boost/get_pointer.hpp:34:41: error: template declaration of
> 'T* boost::get_pointer'
> /usr/include/boost/get_pointer.hpp:34:36: error: 'unique_ptr' is not a
> member of 'std'
> /usr/include/boost/get_pointer.hpp:34:53: error: expected
> primary-expression before '>' token
> /usr/include/boost/get_pointer.hpp:34:55: error: expected
> primary-expression before 'const'
> /usr/include/boost/get_pointer.hpp:39:41: error: template declaration of
> 'T* boost::get_pointer'
> /usr/include/boost/get_pointer.hpp:39:36: error: 'shared_ptr' is not a
> member of 'std'
> /usr/include/boost/get_pointer.hpp:39:53: error: expected
> primary-expression before '>' token
> /usr/include/boost/get_pointer.hpp:39:55: error: expected
> primary-expression before 'const'
> /home/kschenk/AOO_source/main/registry/source/regimpl.cxx: In member
> function 'RegError ORegistry::saveKey(RegKeyHandle, const rtl::OUString&,
> sal_Bool, sal_Bool)':
> /home/kschenk/AOO_source/main/registry/source/regimpl.cxx:963:37: warning:
> 'auto_ptr' is deprecated (declared at
> /usr/include/c++/4.7/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
> dmake: Error code 1, while making '../unxlngi6.pro/slo/regimpl.obj'
>
>
>
>
> --
>
> -------------------------------------------------------------------------------------------------
> MzK
>
> "Cats do not have to be shown how to have a good time,
> for they are unfailing ingenious in that respect."
> -- James Mason
>
Given your recent commits as patches to (now suppiled) boost_1.55, AND some
interesting definitions in /main/stlport/systemstl/slist
#else // fall back to boost/tr1 (forward_list or plain list)
#include <boost/config.hpp>
(who knows if the suppiled config.hpp jives with my own)
I ditched using my local boost_1.54, and things are going much much better.
Not quite there yet but close. :}
At this point, given the customized work you've done, we might think of
warning folks against using their local boost versions -- at least put some
notes in configure.in. Just a thought.
Thanks again for your help.
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Jan 2, 2014 at 10:28 AM, Kay Schenk <ka...@gmail.com> wrote:
>
>
> On Thu, Jan 2, 2014 at 6:32 AM, Herbert Duerr <hd...@apache.org> wrote:
>
>> Happy new year!
>>
>> A small update on the problem Kay mentioned:
>>
>>
>> On 23.12.2013 08:51, Herbert Duerr wrote:
>>
>>> Kay Schenk wrote:
>>>
>>>> On Fri, Dec 13, 2013 at 6:04 AM, Herbert Duerr <hd...@apache.org> wrote:
>>>>
>>>>> [...]
>>>>> In your installation the hash template is apparently already mapped to
>>>>> the
>>>>> std namespace, so us trying to map it there again causes trouble. To
>>>>> verify
>>>>> this idea you could comment out the
>>>>> using STLP4_EMUBASE_NS::hash;
>>>>> lines in booth main/stlport/systemstl/hash_* files.
>>>>>
>>>>>
>>>> a short update on my progress...
>>>>
>>>> The suggestion above worked for that problem...
>>>>
>>>
>>> Wonderful! This means some parts (or all?) of boost's tr1 headers are
>>> already directly into the std namespace. And they are of course also
>>> available in the std::tr1 namespace where they come from. Please have a
>>> look at the preprocessor output. To see what the compiler sees to achive
>>> this.
>>>
>>
>> If you compiled in C++11 mode then the C++11 templates for TR1 libraries
>> are already required to be in the std namespace. When I tried it out myself
>> I saw similar problems to the ones you saw. I fixed them in issue 123947 /
>> revision 1554812 on trunk. You might want to try it out.
>>
>
> OK -- I hadn't gotten back to this yet.
>
>
>>
>> Kay, did you explicitly enable C++11 mode for your Linux build? AFAIK
>> C++11 mode is not enabled by default on any Linux distribution, or has a
>> distro already switched this default? I'm sure this would break a lot of
>> third-party codes...
>>
>
> yes, since I thought we were working toward this as a standard...
>
> I saw your commits and am hopeful this will solve my situation...
>
>
>>
>>
>> Herbert
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
>
> --
>
> -------------------------------------------------------------------------------------------------
> MzK
>
> "Cats do not have to be shown how to have a good time,
> for they are unfailing ingenious in that respect."
> -- James Mason
>
Well I got a bit further long with this -- so YAY! for your changes.
But,...I am now having problems compiling regimpl.cxx in module "registry"
--
Here's the traceback if you're interested but I will investigate as well.
In file included from /usr/include/boost/bind/mem_fn.hpp:25:0,
from /usr/include/boost/mem_fn.hpp:22,
from /usr/include/boost/tr1/functional.hpp:62,
from /usr/include/boost/tr1/tr1/functional:27,
from /home/kschenk/AOO_source/main/solver/410/
unxlngi6.pro/inc/stl/functional:36,
from /usr/include/c++/4.7/memory:81,
from
/home/kschenk/AOO_source/main/registry/source/regimpl.cxx:29:
/usr/include/boost/get_pointer.hpp:27:40: error: template declaration of
'T* boost::get_pointer'
/usr/include/boost/get_pointer.hpp:27:35: error: 'auto_ptr' is not a member
of 'std'
/usr/include/boost/get_pointer.hpp:27:50: error: expected
primary-expression before '>' token
/usr/include/boost/get_pointer.hpp:27:52: error: expected
primary-expression before 'const'
/usr/include/boost/get_pointer.hpp:34:41: error: template declaration of
'T* boost::get_pointer'
/usr/include/boost/get_pointer.hpp:34:36: error: 'unique_ptr' is not a
member of 'std'
/usr/include/boost/get_pointer.hpp:34:53: error: expected
primary-expression before '>' token
/usr/include/boost/get_pointer.hpp:34:55: error: expected
primary-expression before 'const'
/usr/include/boost/get_pointer.hpp:39:41: error: template declaration of
'T* boost::get_pointer'
/usr/include/boost/get_pointer.hpp:39:36: error: 'shared_ptr' is not a
member of 'std'
/usr/include/boost/get_pointer.hpp:39:53: error: expected
primary-expression before '>' token
/usr/include/boost/get_pointer.hpp:39:55: error: expected
primary-expression before 'const'
/home/kschenk/AOO_source/main/registry/source/regimpl.cxx: In member
function 'RegError ORegistry::saveKey(RegKeyHandle, const rtl::OUString&,
sal_Bool, sal_Bool)':
/home/kschenk/AOO_source/main/registry/source/regimpl.cxx:963:37: warning:
'auto_ptr' is deprecated (declared at
/usr/include/c++/4.7/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
dmake: Error code 1, while making '../unxlngi6.pro/slo/regimpl.obj'
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Jan 2, 2014 at 6:32 AM, Herbert Duerr <hd...@apache.org> wrote:
> Happy new year!
>
> A small update on the problem Kay mentioned:
>
>
> On 23.12.2013 08:51, Herbert Duerr wrote:
>
>> Kay Schenk wrote:
>>
>>> On Fri, Dec 13, 2013 at 6:04 AM, Herbert Duerr <hd...@apache.org> wrote:
>>>
>>>> [...]
>>>> In your installation the hash template is apparently already mapped to
>>>> the
>>>> std namespace, so us trying to map it there again causes trouble. To
>>>> verify
>>>> this idea you could comment out the
>>>> using STLP4_EMUBASE_NS::hash;
>>>> lines in booth main/stlport/systemstl/hash_* files.
>>>>
>>>>
>>> a short update on my progress...
>>>
>>> The suggestion above worked for that problem...
>>>
>>
>> Wonderful! This means some parts (or all?) of boost's tr1 headers are
>> already directly into the std namespace. And they are of course also
>> available in the std::tr1 namespace where they come from. Please have a
>> look at the preprocessor output. To see what the compiler sees to achive
>> this.
>>
>
> If you compiled in C++11 mode then the C++11 templates for TR1 libraries
> are already required to be in the std namespace. When I tried it out myself
> I saw similar problems to the ones you saw. I fixed them in issue 123947 /
> revision 1554812 on trunk. You might want to try it out.
>
OK -- I hadn't gotten back to this yet.
>
> Kay, did you explicitly enable C++11 mode for your Linux build? AFAIK
> C++11 mode is not enabled by default on any Linux distribution, or has a
> distro already switched this default? I'm sure this would break a lot of
> third-party codes...
>
yes, since I thought we were working toward this as a standard...
I saw your commits and am hopeful this will solve my situation...
>
>
> Herbert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Herbert Duerr <hd...@apache.org>.
Happy new year!
A small update on the problem Kay mentioned:
On 23.12.2013 08:51, Herbert Duerr wrote:
> Kay Schenk wrote:
>> On Fri, Dec 13, 2013 at 6:04 AM, Herbert Duerr <hd...@apache.org> wrote:
>>> [...]
>>> In your installation the hash template is apparently already mapped to the
>>> std namespace, so us trying to map it there again causes trouble. To verify
>>> this idea you could comment out the
>>> using STLP4_EMUBASE_NS::hash;
>>> lines in booth main/stlport/systemstl/hash_* files.
>>>
>>
>> a short update on my progress...
>>
>> The suggestion above worked for that problem...
>
> Wonderful! This means some parts (or all?) of boost's tr1 headers are
> already directly into the std namespace. And they are of course also
> available in the std::tr1 namespace where they come from. Please have a
> look at the preprocessor output. To see what the compiler sees to achive
> this.
If you compiled in C++11 mode then the C++11 templates for TR1 libraries
are already required to be in the std namespace. When I tried it out
myself I saw similar problems to the ones you saw. I fixed them in issue
123947 / revision 1554812 on trunk. You might want to try it out.
Kay, did you explicitly enable C++11 mode for your Linux build? AFAIK
C++11 mode is not enabled by default on any Linux distribution, or has a
distro already switched this default? I'm sure this would break a lot of
third-party codes...
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Herbert Duerr <hd...@apache.org>.
Kay Schenk wrote:
> On Fri, Dec 13, 2013 at 6:04 AM, Herbert Duerr <hd...@apache.org> wrote:
>> [...]
>> In your installation the hash template is apparently already mapped to the
>> std namespace, so us trying to map it there again causes trouble. To verify
>> this idea you could comment out the
>> using STLP4_EMUBASE_NS::hash;
>> lines in booth main/stlport/systemstl/hash_* files.
>>
>
> a short update on my progress...
>
> The suggestion above worked for that problem...
Wonderful! This means some parts (or all?) of boost's tr1 headers are
already directly into the std namespace. And they are of course also
available in the std::tr1 namespace where they come from. Please have a
look at the preprocessor output. To see what the compiler sees to achive
this.
>> [...]
>>> so I don't know if we need to do something about BOOST_HASH_NO_EXTENSIONS
>>>
>>
>> That's a good idea. If we knew that the hash template was already
>> available in the std namespace then we wouldn't have to map it there
>> ourselves. Maybe one of these two boost configuration defines (or maybe the
>> BOOST_HASH_TR1_HASH define?) allow us to determine what your boost
>> installation needs to get us a nice hash template in the std namespace.
>> [...]
>
> I'm still working on the errors generated from the latter area...
The preprocessor output could help you identify which source file
already mapped the containers directly into the std namespace. If the
responsible lines are known then figuring out which defines where
responsible for it should be easy.
> Thank you for all your help.
You're very welcome!
I'll be (mostly) offline for the rest of the year.
Merry Christmas and a Happy New Year!
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Kay Schenk <ka...@gmail.com>.
On Fri, Dec 13, 2013 at 6:04 AM, Herbert Duerr <hd...@apache.org> wrote:
> Hi Kay,
>
>
> On 13.12.2013 01:20, Kay Schenk wrote:
>
>> On Mon, Dec 9, 2013 at 10:29 AM, Kay Schenk <ka...@gmail.com> wrote:
>>
>>> On Mon, Dec 9, 2013 at 5:29 AM, Herbert Duerr <hd...@apache.org> wrote:
>>>
>>>> By the way I created an enhancement issue [1] for upgrading to the
>>>> latest
>>>> boost version. I also developed a patch that already works with my
>>>> systems
>>>> and attached it to that issue.
>>>>
>>>> [1] https://issues.apache.org/ooo/show_bug.cgi?id=123817
>>>>
>>>> It would be interesting to know if that experimental patch to support
>>>> the
>>>> new boost version works better for e.g. our Solaris ports? Please test.
>>>> Maybe upgrading to boost 1.55 is a good idea for the AOO 4.1 release.
>>>>
>>>> OK, good...I'll have a look soonish.
>>>
>>
>> Well I applied this patch but decided to just continue with 1.54 (my
>> local)
>> instead of downloading 1.55, or using supplied supplied boost with the
>> patch (I may try that next).
>>
>> My traceback...
>> [...]
>>
>> /home/kschenk/AOO_source/main/solver/410/unxlngi6.pro/inc/
>> stl/hash_set:42:26:
>> error: 'hash' is already declared in this scope
>>
>
> AOO's "normal" boost has the hash template in the boost/tr1 namespace. We
> need it in the std namespace though (like TR1's unordered containers), so
> we map them from their original boost/tr1 namespace to the std namespace.
>
> In your installation the hash template is apparently already mapped to the
> std namespace, so us trying to map it there again causes trouble. To verify
> this idea you could comment out the
> using STLP4_EMUBASE_NS::hash;
> lines in booth main/stlport/systemstl/hash_* files.
>
a short update on my progress...
The suggestion above worked for that problem...
>
> [...]
>>
>> The second one seems to center around the following from boost itself in
>> --
>> In file included from /usr/include/boost/functional/hash/hash.hpp
>>
>> #if !defined(BOOST_HASH_NO_EXTENSIONS) \
>> && !defined(BOOST_FUNCTIONAL_HASH_EXTENSIONS_HPP)
>> #include <boost/functional/hash/extensions.hpp>
>> #endif
>>
>> so I don't know if we need to do something about BOOST_HASH_NO_EXTENSIONS
>>
>
> That's a good idea. If we knew that the hash template was already
> available in the std namespace then we wouldn't have to map it there
> ourselves. Maybe one of these two boost configuration defines (or maybe the
> BOOST_HASH_TR1_HASH define?) allow us to determine what your boost
> installation needs to get us a nice hash template in the std namespace.
>
>
> Herbert
>
I'm still working on the errors generated from the latter area...
Thank you for all your help.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Herbert Duerr <hd...@apache.org>.
Hi Kay,
On 13.12.2013 01:20, Kay Schenk wrote:
> On Mon, Dec 9, 2013 at 10:29 AM, Kay Schenk <ka...@gmail.com> wrote:
>> On Mon, Dec 9, 2013 at 5:29 AM, Herbert Duerr <hd...@apache.org> wrote:
>>> By the way I created an enhancement issue [1] for upgrading to the latest
>>> boost version. I also developed a patch that already works with my systems
>>> and attached it to that issue.
>>>
>>> [1] https://issues.apache.org/ooo/show_bug.cgi?id=123817
>>>
>>> It would be interesting to know if that experimental patch to support the
>>> new boost version works better for e.g. our Solaris ports? Please test.
>>> Maybe upgrading to boost 1.55 is a good idea for the AOO 4.1 release.
>>>
>> OK, good...I'll have a look soonish.
>
> Well I applied this patch but decided to just continue with 1.54 (my local)
> instead of downloading 1.55, or using supplied supplied boost with the
> patch (I may try that next).
>
> My traceback...
> [...]
> /home/kschenk/AOO_source/main/solver/410/unxlngi6.pro/inc/stl/hash_set:42:26:
> error: 'hash' is already declared in this scope
AOO's "normal" boost has the hash template in the boost/tr1 namespace.
We need it in the std namespace though (like TR1's unordered
containers), so we map them from their original boost/tr1 namespace to
the std namespace.
In your installation the hash template is apparently already mapped to
the std namespace, so us trying to map it there again causes trouble. To
verify this idea you could comment out the
using STLP4_EMUBASE_NS::hash;
lines in booth main/stlport/systemstl/hash_* files.
> [...]
> The second one seems to center around the following from boost itself in --
> In file included from /usr/include/boost/functional/hash/hash.hpp
>
> #if !defined(BOOST_HASH_NO_EXTENSIONS) \
> && !defined(BOOST_FUNCTIONAL_HASH_EXTENSIONS_HPP)
> #include <boost/functional/hash/extensions.hpp>
> #endif
>
> so I don't know if we need to do something about BOOST_HASH_NO_EXTENSIONS
That's a good idea. If we knew that the hash template was already
available in the std namespace then we wouldn't have to map it there
ourselves. Maybe one of these two boost configuration defines (or maybe
the BOOST_HASH_TR1_HASH define?) allow us to determine what your boost
installation needs to get us a nice hash template in the std namespace.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Dec 5, 2013 at 10:56 PM, Herbert Duerr <hd...@apache.org> wrote:
> Hi Raymond,
>
> Steele, Raymond wrote:
> > Are you recommending that we use boost version 1_49 versus the one
> delivered with OpenOffice?
>
> Please see my other mail ("Using system boost 1.54") from today. It is
> desirable that AOO should build with newer system boost versions too,
> but it requires probably more than just a recompile to make everything
> work. Volunteers are invited to work on this interesting topic.
>
> > If so, then we will reconfigure using the --with-system-boost flag. If
> we use 1_49, does it require any special configure / build steps?
>
> I'm not sure whether anyone actually built AOO with boost 1.49, 1.50,
> 1.51, 1.52, 1.53 or the 1.54 versions, so you're in unexplored territory.
>
> Maybe 1.49 is close enough to 1.48 so using it could work out of the box
> with AOO. But as Kay noticed 1.54 is already so different that more work
> is needed for sure.
>
oh boy and thanks...I guess I missed your earlier post...I will revert to
1.49 with the patch as well. Keeping my fingers crossed.
> > Today, we replaced the 1_48 version of emplace_args.hpp with the 1_49
> version, then implemented the patch [2] and the issues below went away,
>
> Thanks for checking: It proves that we're on the right track!
>
> > but the compile complains about an undefined boost type on line 220 :
> >
> > BOOST_UNORDERED_CONSTRUCT_FROM_TUPLE(10, boost)
> >
> > We are thinking that we need to pull in another file from 1_49, but that
> may snowball into needing more files, but we are not sure.
>
> That snowball/domino effect is a real problem. And we always prefer to
> work with off-the-shelf releases of external libraries if possible.
>
> In your case I'd try to
> - replace the missing boost type, but as [1] shows they are using some
> magic there especially for Solaris compilers
> - rebuild with system-boost 1.49
> - rebuild with system-boost 1.50
>
> [1] http://lists.boost.org/boost-commit/2012/04/40663.php
>
> If these alternatives don't work then we really need a volunteer who
> solves the build problems with the latest 1.55 version so that AOO's
> internal version can be upgraded to that.
>
> Herbert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi Raymond,
Steele, Raymond wrote:
> Are you recommending that we use boost version 1_49 versus the one delivered with OpenOffice?
Please see my other mail ("Using system boost 1.54") from today. It is
desirable that AOO should build with newer system boost versions too,
but it requires probably more than just a recompile to make everything
work. Volunteers are invited to work on this interesting topic.
> If so, then we will reconfigure using the --with-system-boost flag. If we use 1_49, does it require any special configure / build steps?
I'm not sure whether anyone actually built AOO with boost 1.49, 1.50,
1.51, 1.52, 1.53 or the 1.54 versions, so you're in unexplored territory.
Maybe 1.49 is close enough to 1.48 so using it could work out of the box
with AOO. But as Kay noticed 1.54 is already so different that more work
is needed for sure.
> Today, we replaced the 1_48 version of emplace_args.hpp with the 1_49 version, then implemented the patch [2] and the issues below went away,
Thanks for checking: It proves that we're on the right track!
> but the compile complains about an undefined boost type on line 220 :
>
> BOOST_UNORDERED_CONSTRUCT_FROM_TUPLE(10, boost)
>
> We are thinking that we need to pull in another file from 1_49, but that may snowball into needing more files, but we are not sure.
That snowball/domino effect is a real problem. And we always prefer to
work with off-the-shelf releases of external libraries if possible.
In your case I'd try to
- replace the missing boost type, but as [1] shows they are using some
magic there especially for Solaris compilers
- rebuild with system-boost 1.49
- rebuild with system-boost 1.50
[1] http://lists.boost.org/boost-commit/2012/04/40663.php
If these alternatives don't work then we really need a volunteer who
solves the build problems with the latest 1.55 version so that AOO's
internal version can be upgraded to that.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Hey Herbert,
Thanks for the quick response and your fix worked. The svx module built perfectly.
I don't know why we are having these errors appear now that we are recompiling in debug mode. Unfortunately we ran into another problem at the end of the day here (and after nearly a whole day of compiling and everything looking good) and we'd thought we'd send off a quick message to you to see if you might have an answer.
While rebuilding the "sw" module, the build of the "fmtatr2" file failed.
The first error message in the failure references the /usr/include/stdcxx4/rw/_autoptr.h file saying that the file "Could not find a match for std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> >>::auto_ptr_ref<std::auto_ptr_ref<const std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange>::_TypeU>(std::auto_ptr<conststd::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange>, const std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> *) needed in std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> > ::operator std::auto_ptr_ref<const std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange>><const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> >>() "
Raymond and I know that this reference is located in the memory.h file, but it doesn't appear that any of the files in the /main/sw/source/core/txtnode include the memory.h file even though it may be included in one of the other included files. Is it possible that something inside the OpenOffice files might be conflicting with the definition or usage of the auto_ptr_ref defined in the /usr/include/stdcxx4/memory.h? do we need to include memory.h inside any of the files inside /main/sw/source/core/txtnode? Is there a header definition that we need to change similar to the erf problems that we encountered previously?
Thanks,
David Meffe
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Wednesday, January 08, 2014 4:06 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond; Meffe, David K
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
Hi David,
On 07.01.2014 23:11, Steele, Raymond wrote:
> Raymond and I remain stuck on the last issue that we wrote to you about. We would like to better encapsulate our problem and see if you might be able to provide more clarification on what we might be able to try.
>
> 1. We have performed a directory clean and restarted the build --all process from the beginning with the debug flag set. This time we are not using the multi-processing commands.
> 2. The build process proceeds without error, even compiling all the files up to the svx module.
> 3. When the svx module is finished compiling and the LNK of the Library/libsvxcore.so is being performed the process stops with an "Undefined symbol" linking error.
> 4. The symbol is ParagraphData&ParagraphData::operator(const ParagraphData&) and it used to complain about this file in the e3dundo.o.
Wasn't it complaining about a missing ParagraphDataVector symbol originally?
> 5. Since the ParagraphData didn't appear in e3dundo neither did the OutlinerParaObject, I was at a loss for this linking error, but there was an #include <editeng/outlobj.hxx>. Since that is the location of OutlinerParaObject, I have commented out that include to see what would happen. The result is the system still compiled, but the linking failed again, this time in another location.
> 6. The new location that we got the same "Undefined symbol" error link message on was in the file sdrlinefillshadowtextattribute.o located in the attribute directory. This time I was unable to find a #include <editeng/outlobj.hxx> in either the header or source file. However sdrlinefillshadowtextattribute includes sdrlinesshadowtextattribute.hxx which includes sdrtextattribute.
> 7. sdrtextattribute was the first location we have found where the OutlinerParaObject is used and the #include <editeng/outlobj.hxx>. Since we had not found this object before (at least in the path that was failing), this was the first thing that made some sense in this problem.
> 8. We have reviewed your last email, but are having a difficult time understanding what you recommended. It appeared you were recommending we modify the OutlinerParaObject constructor, but how? You wanted us to remove the ParagraphDataVector parameter? Or did you want us to create a different constructor? What would the constructor look like?
I was suggesting to add another constructor that didn't have the problem of needing a ParagraphDataVector symbol. Does this patch work for you? Since this makes svx "binary incompatible" with its original you need to do a "build --prepare --from svx" when you apply it.
--- main/editeng/inc/editeng/outlobj.hxx
+++ main/editeng/inc/editeng/outlobj.hxx
@@ -46,10 +46,8 @@ private:
public:
// constructors/destructor
- OutlinerParaObject(
- const EditTextObject& rEditTextObject,
- const ParagraphDataVector& rParagraphDataVector = ParagraphDataVector(),
- bool bIsEditDoc = true);
+ OutlinerParaObject( const EditTextObject&, const ParagraphDataVector&, bool bIsEditDoc = true);
+ OutlinerParaObject( const EditTextObject&);
OutlinerParaObject(const OutlinerParaObject& rCandidate);
~OutlinerParaObject();
--- main/editeng/source/outliner/outlobj.cxx
+++ main/editeng/source/outliner/outlobj.cxx
@@ -98,6 +98,10 @@ OutlinerParaObject::OutlinerParaObject(const EditTextObject& rEditTextObject, co { }
+OutlinerParaObject::OutlinerParaObject( const EditTextObject&)
+: mpImplOutlinerParaObject( new ImplOutlinerParaObject( rEditTextObject.Clone(), ParagraphDataVector(), true))
+{}
+
OutlinerParaObject::OutlinerParaObject(const OutlinerParaObject& rCandidate)
: mpImplOutlinerParaObject(rCandidate.mpImplOutlinerParaObject)
{
> 9. Also even after all of this, do you think that if we modify the OutlinerParaObject that the rest of the svx will link correctly and that all these errors we have seen from this problem resulted from an error in the OutlinerParaObject and our compiler?
I sure hope so ;-)
> Once again, thanks for all your help in advance.
You're welcome!
> I hope you had a good holiday season. We look forward to hearing back from you.
BTW: I'll also be away next week.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
On 09.01.2014 16:47, Steele, Raymond wrote:
> We found a work around for this problem, but believe it may be implemented incorrectly.
>
> We added the following to the top of fmtatr2.cxx:
>
> #ifndef _RWSTD_NO_MEMBER_TEMPLATES
> #define _RWSTD_NO_MEMBER_TEMPLATES 1
> #endif
A good find! And indeed [1] also ran into such a problem and defining
that to disable templatized version of std::vector<T>::assign() was a
workaround needed by the SunStudio compiler.
http://trac.osgeo.org/geos/ticket/224
> The compile of sw then began compiling correctly. Any thoughts?
I'd say that all such defines that make boost less aggressive in using
advanced template magic are fine, so don't worry about it. But I'd use
such an option consistently then, not only in one file. I suggest to add a
-D_RWSTD_NO_MEMBER_TEMPLATES=1
into the solaris makefiles in solenv.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Thanks for the information Herbert. We continued looking at this today, but we still have not determined the reason it is crashing. The application crashes at SidebarController::notifyContextChangeEvent in SidebarController.cxx at maRequestedContext =Context {...}. Our debugger says that eEvent is of the value <ERROR>.
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Tuesday, January 21, 2014 5:11 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi David,
> I just wanted to share the basics of what I have found so far. I still have no idea on how to solve the issue. Any help would be great!
>
> Observed Behaviour
> 1. OpenOffice starts, the splash screen with logo appears and then closes replaced with the full application window and choices for specific OpenOffice projects.
> 2. Selecting either the Word or Spreadsheet project causes a segmentation fault and closes the application.
> 3. Following the start of the application with the debugger, we can see the SidebarController is created in a first pass without error (known because first time to this stop point does not error).
> 4. As the process continues, the SidebarController constructor is called a second time (unknown why, but could be understood with more familiarity with the system).
> 5. The failure doesn't appear in the constructor, but the trace follows down SidebarController constructor call of "WeakReference<SidebarController> WeakController (this);"
> 6. This template definition for WeakController uses Reference<Template>::Refrence( interface_type *pInterface) as its definition in ::com::sun::star::uno::Reference.hxx.
> 7. The function will try to convert the pInterface parameter to a XInterface type called _pInterface.
> 8. If it succeeds in converting the pInterface to _pInterface then the function will try to acquire a new reference.
> 9. Assumption: Creating this new reference calls SidebarController::notifyContextChangeEvent with a corrupt or bad rEvent. This assumption is based on the stack where the immediate next routine after the Reference function call is the notifyContextChangeEvent, also while following along in the debugger, the rEvent parameter at this point is already corrupted with the value <ERROR> stored in the structure.
> 10. It is later after the notifyContextChangeEvent calls Context and then ustring that the segmentation fault occurs, but I believe the error located in rEvent is what causes this later problem.
I haven't fully caught up with everything, but if I had to debug this I'd watch out for exceptions thrown in step 5 and later. In gdb I'd use the command
catch throw
to find the throwing code. Is there a similar facility in Solaris Studio?
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi David,
> I just wanted to share the basics of what I have found so far. I still have no idea on how to solve the issue. Any help would be great!
>
> Observed Behaviour
> 1. OpenOffice starts, the splash screen with logo appears and then closes replaced with the full application window and choices for specific OpenOffice projects.
> 2. Selecting either the Word or Spreadsheet project causes a segmentation fault and closes the application.
> 3. Following the start of the application with the debugger, we can see the SidebarController is created in a first pass without error (known because first time to this stop point does not error).
> 4. As the process continues, the SidebarController constructor is called a second time (unknown why, but could be understood with more familiarity with the system).
> 5. The failure doesn't appear in the constructor, but the trace follows down SidebarController constructor call of "WeakReference<SidebarController> WeakController (this);"
> 6. This template definition for WeakController uses Reference<Template>::Refrence( interface_type *pInterface) as its definition in ::com::sun::star::uno::Reference.hxx.
> 7. The function will try to convert the pInterface parameter to a XInterface type called _pInterface.
> 8. If it succeeds in converting the pInterface to _pInterface then the function will try to acquire a new reference.
> 9. Assumption: Creating this new reference calls SidebarController::notifyContextChangeEvent with a corrupt or bad rEvent. This assumption is based on the stack where the immediate next routine after the Reference function call is the notifyContextChangeEvent, also while following along in the debugger, the rEvent parameter at this point is already corrupted with the value <ERROR> stored in the structure.
> 10. It is later after the notifyContextChangeEvent calls Context and then ustring that the segmentation fault occurs, but I believe the error located in rEvent is what causes this later problem.
I haven't fully caught up with everything, but if I had to debug this
I'd watch out for exceptions thrown in step 5 and later. In gdb I'd use
the command
catch throw
to find the throwing code. Is there a similar facility in Solaris Studio?
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Hey,
I just wanted to share the basics of what I have found so far. I still have no idea on how to solve the issue. Any help would be great!
Observed Behaviour
1. OpenOffice starts, the splash screen with logo appears and then closes replaced with the full application window and choices for specific OpenOffice projects.
2. Selecting either the Word or Spreadsheet project causes a segmentation fault and closes the application.
3. Following the start of the application with the debugger, we can see the SidebarController is created in a first pass without error (known because first time to this stop point does not error).
4. As the process continues, the SidebarController constructor is called a second time (unknown why, but could be understood with more familiarity with the system).
5. The failure doesn't appear in the constructor, but the trace follows down SidebarController constructor call of "WeakReference<SidebarController> WeakController (this);"
6. This template definition for WeakController uses Reference<Template>::Refrence( interface_type *pInterface) as its definition in ::com::sun::star::uno::Reference.hxx.
7. The function will try to convert the pInterface parameter to a XInterface type called _pInterface.
8. If it succeeds in converting the pInterface to _pInterface then the function will try to acquire a new reference.
9. Assumption: Creating this new reference calls SidebarController::notifyContextChangeEvent with a corrupt or bad rEvent. This assumption is based on the stack where the immediate next routine after the Reference function call is the notifyContextChangeEvent, also while following along in the debugger, the rEvent parameter at this point is already corrupted with the value <ERROR> stored in the structure.
10. It is later after the notifyContextChangeEvent calls Context and then ustring that the segmentation fault occurs, but I believe the error located in rEvent is what causes this later problem.
Thanks,
David Meffe
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Friday, January 10, 2014 3:29 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
On 09.01.2014 22:48, Steele, Raymond wrote:
> Attached is a copy of the stack trace when we tried to launch both the Word Processor and the Spreadsheet application in OpenOffice. We are going to attempt to resolve the crash based on this information, but if anything pops out at you, please let us know.
The crashes in Writer and Calc you are seeing both happen when copy constructing an OUString from one provided by the SidebarController, so the provided string must be bad.
I suggest to set a breakpoint at SidebarController.cxx:257 and examine the rEvent.ApplicationName and rEvent.ContextName whether these are good strings. From the stack I'd say they probably are not. Then go up the stack and check where they come from and why their are bad.
Good luck!
(I'll be away next week, starting this weekend)
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
On 09.01.2014 22:48, Steele, Raymond wrote:
> Attached is a copy of the stack trace when we tried to launch both the Word Processor and the Spreadsheet application in OpenOffice. We are going to attempt to resolve the crash based on this information, but if anything pops out at you, please let us know.
The crashes in Writer and Calc you are seeing both happen when copy
constructing an OUString from one provided by the SidebarController, so
the provided string must be bad.
I suggest to set a breakpoint at SidebarController.cxx:257 and examine
the rEvent.ApplicationName and rEvent.ContextName whether these are good
strings. From the stack I'd say they probably are not. Then go up the
stack and check where they come from and why their are bad.
Good luck!
(I'll be away next week, starting this weekend)
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
Attached is a copy of the stack trace when we tried to launch both the Word Processor and the Spreadsheet application in OpenOffice. We are going to attempt to resolve the crash based on this information, but if anything pops out at you, please let us know.
Thanks,
David Meffe
-----Original Message-----
From: Steele, Raymond
Sent: Thursday, January 09, 2014 8:47 AM
To: 'Herbert Duerr'; 'dev@openoffice.apache.org'
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Herbert,
We found a work around for this problem, but believe it may be implemented incorrectly.
We added the following to the top of fmtatr2.cxx:
#ifndef _RWSTD_NO_MEMBER_TEMPLATES
#define _RWSTD_NO_MEMBER_TEMPLATES 1
#endif
The compile of sw then began compiling correctly. Any thoughts?
Raymond
-----Original Message-----
From: Steele, Raymond
Sent: Wednesday, January 08, 2014 5:03 PM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Hey Herbert,
Thanks for the quick response and your fix worked. The svx module built perfectly.
I don't know why we are having these errors appear now that we are recompiling in debug mode. Unfortunately we ran into another problem at the end of the day here (and after nearly a whole day of compiling and everything looking good) and we'd thought we'd send off a quick message to you to see if you might have an answer.
While rebuilding the "sw" module, the build of the "fmtatr2" file failed.
The first error message in the failure references the /usr/include/stdcxx4/rw/_autoptr.h file saying that the file "Could not find a match for std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> >>::auto_ptr_ref<std::auto_ptr_ref<const std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange>::_TypeU>(std::auto_ptr<conststd::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange>, const std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> *) needed in std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> > ::operator std::auto_ptr_ref<const std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange>><const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> >>() "
Raymond and I know that this reference is located in the memory.h file, but it doesn't appear that any of the files in the /main/sw/source/core/txtnode include the memory.h file even though it may be included in one of the other included files. Is it possible that something inside the OpenOffice files might be conflicting with the definition or usage of the auto_ptr_ref defined in the /usr/include/stdcxx4/memory.h? do we need to include memory.h inside any of the files inside /main/sw/source/core/txtnode? Is there a header definition that we need to change similar to the erf problems that we encountered previously?
Thanks,
David Meffe
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Wednesday, January 08, 2014 4:06 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond; Meffe, David K
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
Hi David,
On 07.01.2014 23:11, Steele, Raymond wrote:
> Raymond and I remain stuck on the last issue that we wrote to you about. We would like to better encapsulate our problem and see if you might be able to provide more clarification on what we might be able to try.
>
> 1. We have performed a directory clean and restarted the build --all process from the beginning with the debug flag set. This time we are not using the multi-processing commands.
> 2. The build process proceeds without error, even compiling all the files up to the svx module.
> 3. When the svx module is finished compiling and the LNK of the Library/libsvxcore.so is being performed the process stops with an "Undefined symbol" linking error.
> 4. The symbol is ParagraphData&ParagraphData::operator(const ParagraphData&) and it used to complain about this file in the e3dundo.o.
Wasn't it complaining about a missing ParagraphDataVector symbol originally?
> 5. Since the ParagraphData didn't appear in e3dundo neither did the OutlinerParaObject, I was at a loss for this linking error, but there was an #include <editeng/outlobj.hxx>. Since that is the location of OutlinerParaObject, I have commented out that include to see what would happen. The result is the system still compiled, but the linking failed again, this time in another location.
> 6. The new location that we got the same "Undefined symbol" error link message on was in the file sdrlinefillshadowtextattribute.o located in the attribute directory. This time I was unable to find a #include <editeng/outlobj.hxx> in either the header or source file. However sdrlinefillshadowtextattribute includes sdrlinesshadowtextattribute.hxx which includes sdrtextattribute.
> 7. sdrtextattribute was the first location we have found where the OutlinerParaObject is used and the #include <editeng/outlobj.hxx>. Since we had not found this object before (at least in the path that was failing), this was the first thing that made some sense in this problem.
> 8. We have reviewed your last email, but are having a difficult time understanding what you recommended. It appeared you were recommending we modify the OutlinerParaObject constructor, but how? You wanted us to remove the ParagraphDataVector parameter? Or did you want us to create a different constructor? What would the constructor look like?
I was suggesting to add another constructor that didn't have the problem of needing a ParagraphDataVector symbol. Does this patch work for you? Since this makes svx "binary incompatible" with its original you need to do a "build --prepare --from svx" when you apply it.
--- main/editeng/inc/editeng/outlobj.hxx
+++ main/editeng/inc/editeng/outlobj.hxx
@@ -46,10 +46,8 @@ private:
public:
// constructors/destructor
- OutlinerParaObject(
- const EditTextObject& rEditTextObject,
- const ParagraphDataVector& rParagraphDataVector = ParagraphDataVector(),
- bool bIsEditDoc = true);
+ OutlinerParaObject( const EditTextObject&, const ParagraphDataVector&, bool bIsEditDoc = true);
+ OutlinerParaObject( const EditTextObject&);
OutlinerParaObject(const OutlinerParaObject& rCandidate);
~OutlinerParaObject();
--- main/editeng/source/outliner/outlobj.cxx
+++ main/editeng/source/outliner/outlobj.cxx
@@ -98,6 +98,10 @@ OutlinerParaObject::OutlinerParaObject(const EditTextObject& rEditTextObject, co { }
+OutlinerParaObject::OutlinerParaObject( const EditTextObject&)
+: mpImplOutlinerParaObject( new ImplOutlinerParaObject( rEditTextObject.Clone(), ParagraphDataVector(), true))
+{}
+
OutlinerParaObject::OutlinerParaObject(const OutlinerParaObject& rCandidate)
: mpImplOutlinerParaObject(rCandidate.mpImplOutlinerParaObject)
{
> 9. Also even after all of this, do you think that if we modify the OutlinerParaObject that the rest of the svx will link correctly and that all these errors we have seen from this problem resulted from an error in the OutlinerParaObject and our compiler?
I sure hope so ;-)
> Once again, thanks for all your help in advance.
You're welcome!
> I hope you had a good holiday season. We look forward to hearing back from you.
BTW: I'll also be away next week.
Herbert
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
We found a work around for this problem, but believe it may be implemented incorrectly.
We added the following to the top of fmtatr2.cxx:
#ifndef _RWSTD_NO_MEMBER_TEMPLATES
#define _RWSTD_NO_MEMBER_TEMPLATES 1
#endif
The compile of sw then began compiling correctly. Any thoughts?
Raymond
-----Original Message-----
From: Steele, Raymond
Sent: Wednesday, January 08, 2014 5:03 PM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Hey Herbert,
Thanks for the quick response and your fix worked. The svx module built perfectly.
I don't know why we are having these errors appear now that we are recompiling in debug mode. Unfortunately we ran into another problem at the end of the day here (and after nearly a whole day of compiling and everything looking good) and we'd thought we'd send off a quick message to you to see if you might have an answer.
While rebuilding the "sw" module, the build of the "fmtatr2" file failed.
The first error message in the failure references the /usr/include/stdcxx4/rw/_autoptr.h file saying that the file "Could not find a match for std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> >>::auto_ptr_ref<std::auto_ptr_ref<const std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange>::_TypeU>(std::auto_ptr<conststd::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange>, const std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> *) needed in std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> > ::operator std::auto_ptr_ref<const std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange>><const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> >>() "
Raymond and I know that this reference is located in the memory.h file, but it doesn't appear that any of the files in the /main/sw/source/core/txtnode include the memory.h file even though it may be included in one of the other included files. Is it possible that something inside the OpenOffice files might be conflicting with the definition or usage of the auto_ptr_ref defined in the /usr/include/stdcxx4/memory.h? do we need to include memory.h inside any of the files inside /main/sw/source/core/txtnode? Is there a header definition that we need to change similar to the erf problems that we encountered previously?
Thanks,
David Meffe
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Wednesday, January 08, 2014 4:06 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond; Meffe, David K
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
Hi David,
On 07.01.2014 23:11, Steele, Raymond wrote:
> Raymond and I remain stuck on the last issue that we wrote to you about. We would like to better encapsulate our problem and see if you might be able to provide more clarification on what we might be able to try.
>
> 1. We have performed a directory clean and restarted the build --all process from the beginning with the debug flag set. This time we are not using the multi-processing commands.
> 2. The build process proceeds without error, even compiling all the files up to the svx module.
> 3. When the svx module is finished compiling and the LNK of the Library/libsvxcore.so is being performed the process stops with an "Undefined symbol" linking error.
> 4. The symbol is ParagraphData&ParagraphData::operator(const ParagraphData&) and it used to complain about this file in the e3dundo.o.
Wasn't it complaining about a missing ParagraphDataVector symbol originally?
> 5. Since the ParagraphData didn't appear in e3dundo neither did the OutlinerParaObject, I was at a loss for this linking error, but there was an #include <editeng/outlobj.hxx>. Since that is the location of OutlinerParaObject, I have commented out that include to see what would happen. The result is the system still compiled, but the linking failed again, this time in another location.
> 6. The new location that we got the same "Undefined symbol" error link message on was in the file sdrlinefillshadowtextattribute.o located in the attribute directory. This time I was unable to find a #include <editeng/outlobj.hxx> in either the header or source file. However sdrlinefillshadowtextattribute includes sdrlinesshadowtextattribute.hxx which includes sdrtextattribute.
> 7. sdrtextattribute was the first location we have found where the OutlinerParaObject is used and the #include <editeng/outlobj.hxx>. Since we had not found this object before (at least in the path that was failing), this was the first thing that made some sense in this problem.
> 8. We have reviewed your last email, but are having a difficult time understanding what you recommended. It appeared you were recommending we modify the OutlinerParaObject constructor, but how? You wanted us to remove the ParagraphDataVector parameter? Or did you want us to create a different constructor? What would the constructor look like?
I was suggesting to add another constructor that didn't have the problem of needing a ParagraphDataVector symbol. Does this patch work for you? Since this makes svx "binary incompatible" with its original you need to do a "build --prepare --from svx" when you apply it.
--- main/editeng/inc/editeng/outlobj.hxx
+++ main/editeng/inc/editeng/outlobj.hxx
@@ -46,10 +46,8 @@ private:
public:
// constructors/destructor
- OutlinerParaObject(
- const EditTextObject& rEditTextObject,
- const ParagraphDataVector& rParagraphDataVector = ParagraphDataVector(),
- bool bIsEditDoc = true);
+ OutlinerParaObject( const EditTextObject&, const ParagraphDataVector&, bool bIsEditDoc = true);
+ OutlinerParaObject( const EditTextObject&);
OutlinerParaObject(const OutlinerParaObject& rCandidate);
~OutlinerParaObject();
--- main/editeng/source/outliner/outlobj.cxx
+++ main/editeng/source/outliner/outlobj.cxx
@@ -98,6 +98,10 @@ OutlinerParaObject::OutlinerParaObject(const EditTextObject& rEditTextObject, co { }
+OutlinerParaObject::OutlinerParaObject( const EditTextObject&)
+: mpImplOutlinerParaObject( new ImplOutlinerParaObject( rEditTextObject.Clone(), ParagraphDataVector(), true))
+{}
+
OutlinerParaObject::OutlinerParaObject(const OutlinerParaObject& rCandidate)
: mpImplOutlinerParaObject(rCandidate.mpImplOutlinerParaObject)
{
> 9. Also even after all of this, do you think that if we modify the OutlinerParaObject that the rest of the svx will link correctly and that all these errors we have seen from this problem resulted from an error in the OutlinerParaObject and our compiler?
I sure hope so ;-)
> Once again, thanks for all your help in advance.
You're welcome!
> I hope you had a good holiday season. We look forward to hearing back from you.
BTW: I'll also be away next week.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi Raymond,
Hi David,
On 07.01.2014 23:11, Steele, Raymond wrote:
> Raymond and I remain stuck on the last issue that we wrote to you about. We would like to better encapsulate our problem and see if you might be able to provide more clarification on what we might be able to try.
>
> 1. We have performed a directory clean and restarted the build --all process from the beginning with the debug flag set. This time we are not using the multi-processing commands.
> 2. The build process proceeds without error, even compiling all the files up to the svx module.
> 3. When the svx module is finished compiling and the LNK of the Library/libsvxcore.so is being performed the process stops with an "Undefined symbol" linking error.
> 4. The symbol is ParagraphData&ParagraphData::operator(const ParagraphData&) and it used to complain about this file in the e3dundo.o.
Wasn't it complaining about a missing ParagraphDataVector symbol originally?
> 5. Since the ParagraphData didn't appear in e3dundo neither did the OutlinerParaObject, I was at a loss for this linking error, but there was an #include <editeng/outlobj.hxx>. Since that is the location of OutlinerParaObject, I have commented out that include to see what would happen. The result is the system still compiled, but the linking failed again, this time in another location.
> 6. The new location that we got the same "Undefined symbol" error link message on was in the file sdrlinefillshadowtextattribute.o located in the attribute directory. This time I was unable to find a #include <editeng/outlobj.hxx> in either the header or source file. However sdrlinefillshadowtextattribute includes sdrlinesshadowtextattribute.hxx which includes sdrtextattribute.
> 7. sdrtextattribute was the first location we have found where the OutlinerParaObject is used and the #include <editeng/outlobj.hxx>. Since we had not found this object before (at least in the path that was failing), this was the first thing that made some sense in this problem.
> 8. We have reviewed your last email, but are having a difficult time understanding what you recommended. It appeared you were recommending we modify the OutlinerParaObject constructor, but how? You wanted us to remove the ParagraphDataVector parameter? Or did you want us to create a different constructor? What would the constructor look like?
I was suggesting to add another constructor that didn't have the problem of needing a ParagraphDataVector symbol. Does this patch work for you? Since this makes svx "binary incompatible" with its original you need to do a "build --prepare --from svx" when you apply it.
--- main/editeng/inc/editeng/outlobj.hxx
+++ main/editeng/inc/editeng/outlobj.hxx
@@ -46,10 +46,8 @@ private:
public:
// constructors/destructor
- OutlinerParaObject(
- const EditTextObject& rEditTextObject,
- const ParagraphDataVector& rParagraphDataVector = ParagraphDataVector(),
- bool bIsEditDoc = true);
+ OutlinerParaObject( const EditTextObject&, const ParagraphDataVector&, bool bIsEditDoc = true);
+ OutlinerParaObject( const EditTextObject&);
OutlinerParaObject(const OutlinerParaObject& rCandidate);
~OutlinerParaObject();
--- main/editeng/source/outliner/outlobj.cxx
+++ main/editeng/source/outliner/outlobj.cxx
@@ -98,6 +98,10 @@ OutlinerParaObject::OutlinerParaObject(const EditTextObject& rEditTextObject, co
{
}
+OutlinerParaObject::OutlinerParaObject( const EditTextObject&)
+: mpImplOutlinerParaObject( new ImplOutlinerParaObject( rEditTextObject.Clone(), ParagraphDataVector(), true))
+{}
+
OutlinerParaObject::OutlinerParaObject(const OutlinerParaObject& rCandidate)
: mpImplOutlinerParaObject(rCandidate.mpImplOutlinerParaObject)
{
> 9. Also even after all of this, do you think that if we modify the OutlinerParaObject that the rest of the svx will link correctly and that all these errors we have seen from this problem resulted from an error in the OutlinerParaObject and our compiler?
I sure hope so ;-)
> Once again, thanks for all your help in advance.
You're welcome!
> I hope you had a good holiday season. We look forward to hearing back from you.
BTW: I'll also be away next week.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
Raymond and I remain stuck on the last issue that we wrote to you about. We would like to better encapsulate our problem and see if you might be able to provide more clarification on what we might be able to try.
1. We have performed a directory clean and restarted the build --all process from the beginning with the debug flag set. This time we are not using the multi-processing commands.
2. The build process proceeds without error, even compiling all the files up to the svx module.
3. When the svx module is finished compiling and the LNK of the Library/libsvxcore.so is being performed the process stops with an "Undefined symbol" linking error.
4. The symbol is ParagraphData&ParagraphData::operator(const ParagraphData&) and it used to complain about this file in the e3dundo.o.
5. Since the ParagraphData didn't appear in e3dundo neither did the OutlinerParaObject, I was at a loss for this linking error, but there was an #include <editeng/outlobj.hxx>. Since that is the location of OutlinerParaObject, I have commented out that include to see what would happen. The result is the system still compiled, but the linking failed again, this time in another location.
6. The new location that we got the same "Undefined symbol" error link message on was in the file sdrlinefillshadowtextattribute.o located in the attribute directory. This time I was unable to find a #include <editeng/outlobj.hxx> in either the header or source file. However sdrlinefillshadowtextattribute includes sdrlinesshadowtextattribute.hxx which includes sdrtextattribute.
7. sdrtextattribute was the first location we have found where the OutlinerParaObject is used and the #include <editeng/outlobj.hxx>. Since we had not found this object before (at least in the path that was failing), this was the first thing that made some sense in this problem.
8. We have reviewed your last email, but are having a difficult time understanding what you recommended. It appeared you were recommending we modify the OutlinerParaObject constructor, but how? You wanted us to remove the ParagraphDataVector parameter? Or did you want us to create a different constructor? What would the constructor look like?
9. Also even after all of this, do you think that if we modify the OutlinerParaObject that the rest of the svx will link correctly and that all these errors we have seen from this problem resulted from an error in the OutlinerParaObject and our compiler?
Once again, thanks for all your help in advance. I hope you had a good holiday season. We look forward to hearing back from you.
David Meffe
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Friday, December 20, 2013 6:41 AM
To: Steele, Raymond; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: Re: EXTERNAL: Re: Building comphelper
Hi David,
Hi Raymond,
On 20.12.2013 00:12, Steele, Raymond wrote:
> Raymond and I are in the process of rebuilding OpenOffice with the debug flags, but have run into some errors that didn't occur the first time through in the build. The current error has caused me quite a bit of problems.
>
> We are getting a link error, unrecognized symbol in /svx/source/engine3d/e3dundo.cxx. However the symbol that it is looking for is not present inside e3dundo.cxx. The symbol is "ParagraphData&ParagraphData::operator=(const ParagraphData&)" [sic] which we have located in /editeng/inc/editeng/paragraphdata.hxx and the implementation appears to in /editeng/source/outliner/paralist.cxx.
>
> There are some very odd things going on here.
>
> 1) paragraphdata.hxx is not included in paralist.cxx even though this is where the prototype is declared.
> 2) e3dundo.cxx doesn't seem to use the ParagraphData class at all.
> 3) e3dundo.cxx doesn't seem to include the libraries where these classes are used.
From what I can gather from the relevant parts of that code an OutlinerParaObject constructor has a ParagraphDataVector argument that is default initialized with an empty ParagraphDataVector. I guess the assignment in this default initialization needs ParagraphData's assignment operator.
Maybe removing the default argument for ParagraphDataVector in OutlinerParaObject's constructor helps? This can be done by creating another constructor that takes only one argument.
Most other compilers seem to optimize the assignment operator away even when compiling in debugging mode.
> I want to note that we first started the debug build using multiple processors (-P8) and perhaps that has caused problems in the ordering in which the libraries were compiled and linked. It is conceivable that this problem may be resolved with a complete system clean and rebuild in linear mode, but before we committed to another day of building the product, we wanted to check with you to see if this problem has occurred before, is it recognized or if there is a solution that you could recommend?
I wouldn't vouch for our build systems ordering at such high parallelism levels... if you want to increase parallelism I'd recommend to change from e.g.
build --all -P8
to e.g.
build --all -P2 -- -P4
The first -P is for build's parallelism, the second -P is for dmake's parallelism. I'm too polite to tell what I really feel about these mechanisms...
> We'd appreciate any help or insight you could provide.
I hope the above helps. If not just add the library that provides the missing symbol to the link list.
> P.S. I will be on holiday for the next two weeks and I believe Raymond will be as well so we may be out of communication.
I'll be (mostly) offline for the rest of the year too :-) Merry Christmas and a Happy New Year!
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi David,
Hi Raymond,
On 20.12.2013 00:12, Steele, Raymond wrote:
> Raymond and I are in the process of rebuilding OpenOffice with the debug flags, but have run into some errors that didn't occur the first time through in the build. The current error has caused me quite a bit of problems.
>
> We are getting a link error, unrecognized symbol in /svx/source/engine3d/e3dundo.cxx. However the symbol that it is looking for is not present inside e3dundo.cxx. The symbol is "ParagraphData&ParagraphData::operator=(const ParagraphData&)" [sic] which we have located in /editeng/inc/editeng/paragraphdata.hxx and the implementation appears to in /editeng/source/outliner/paralist.cxx.
>
> There are some very odd things going on here.
>
> 1) paragraphdata.hxx is not included in paralist.cxx even though this is where the prototype is declared.
> 2) e3dundo.cxx doesn't seem to use the ParagraphData class at all.
> 3) e3dundo.cxx doesn't seem to include the libraries where these classes are used.
From what I can gather from the relevant parts of that code an
OutlinerParaObject constructor has a ParagraphDataVector argument that
is default initialized with an empty ParagraphDataVector. I guess the
assignment in this default initialization needs ParagraphData's
assignment operator.
Maybe removing the default argument for ParagraphDataVector in
OutlinerParaObject's constructor helps? This can be done by creating
another constructor that takes only one argument.
Most other compilers seem to optimize the assignment operator away even
when compiling in debugging mode.
> I want to note that we first started the debug build using multiple processors (-P8) and perhaps that has caused problems in the ordering in which the libraries were compiled and linked. It is conceivable that this problem may be resolved with a complete system clean and rebuild in linear mode, but before we committed to another day of building the product, we wanted to check with you to see if this problem has occurred before, is it recognized or if there is a solution that you could recommend?
I wouldn't vouch for our build systems ordering at such high parallelism
levels... if you want to increase parallelism I'd recommend to change
from e.g.
build --all -P8
to e.g.
build --all -P2 -- -P4
The first -P is for build's parallelism, the second -P is for dmake's
parallelism. I'm too polite to tell what I really feel about these
mechanisms...
> We'd appreciate any help or insight you could provide.
I hope the above helps. If not just add the library that provides the
missing symbol to the link list.
> P.S. I will be on holiday for the next two weeks and I believe Raymond will be as well so we may be out of communication.
I'll be (mostly) offline for the rest of the year too :-)
Merry Christmas and a Happy New Year!
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
Raymond and I are in the process of rebuilding OpenOffice with the debug flags, but have run into some errors that didn't occur the first time through in the build. The current error has caused me quite a bit of problems.
We are getting a link error, unrecognized symbol in /svx/source/engine3d/e3dundo.cxx. However the symbol that it is looking for is not present inside e3dundo.cxx. The symbol is "ParagraphData&ParagraphData::operator=(const ParagraphData&)" [sic] which we have located in /editeng/inc/editeng/paragraphdata.hxx and the implementation appears to in /editeng/source/outliner/paralist.cxx.
There are some very odd things going on here.
1) paragraphdata.hxx is not included in paralist.cxx even though this is where the prototype is declared.
2) e3dundo.cxx doesn't seem to use the ParagraphData class at all.
3) e3dundo.cxx doesn't seem to include the libraries where these classes are used.
I want to note that we first started the debug build using multiple processors (-P8) and perhaps that has caused problems in the ordering in which the libraries were compiled and linked. It is conceivable that this problem may be resolved with a complete system clean and rebuild in linear mode, but before we committed to another day of building the product, we wanted to check with you to see if this problem has occurred before, is it recognized or if there is a solution that you could recommend?
We'd appreciate any help or insight you could provide.
David Meffe
P.S. I will be on holiday for the next two weeks and I believe Raymond will be as well so we may be out of communication.
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Wednesday, December 18, 2013 12:11 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond; Meffe, David K
Subject: Re: EXTERNAL: Re: Building comphelper
Hello David,
Hello Raymond,
On 17.12.2013 23:31, Steele, Raymond wrote:
> At long last Raymond and I have successfully gotten through the entire
> build script without a fault. The executable seemed to create just
> fine and we were able to launch soffice. We got the splash screen,
> then the executable started and the options window appeared and
> everything looked to be in order,
That's a great success!
> but when we selected one of the document types to open, the executable crashed with the memory error:
>
> ./soffice[121]: wait: 6980: Memory fault
I'm afraid we need a stack trace of this crash to understand what's going on. When the stack trace shows which libraries are involved then these libraries should be recompiled with debug infos (i.e. created with the "debug=1" option for "make" or for "build"). Then replace the libs in your installation with the debug libs and get the stack trace of this crash.
> I don't think Raymond or I was expecting everything to work right on first launch and we were happy to see the splash screen, the executable start and the option menu appear. However, have you seen this type of memory error before or has it been seen by others? Do you have an idea what might cause this?
If you single stepped through the huge amounts of code that is needed to get to there you'd see there is more than plenty of opportunity for something to go wrong ;-)
> My fear is that we have made too many modifications to the code in order to get the system to build correctly. We have removed, in small select areas, "const" as a qualifier to certain parameters to member functions because the system would not compile with these parameters declared as a const. We can provide a list of these locations that we have edited, I believe it is about 3 or 4 files that might have been edited in this way.
The changes in the few source files you mentioned in your other mail are probably uncritical. And e.g. Calc isn't changed at all, so if it doesn't work either then I suspect the problem in a deeper layer.
> If you have any ideas, it would greatly help us out. Thanks.
The stack trace of the crash when debug-enabled libraries were used would be very helpful
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hello David,
Hello Raymond,
On 17.12.2013 23:31, Steele, Raymond wrote:
> At long last Raymond and I have successfully gotten through the entire build script without a fault. The executable seemed to create just fine and we were able to launch soffice. We got the splash screen, then the executable started and the options window appeared and everything looked to be in order,
That's a great success!
> but when we selected one of the document types to open, the executable crashed with the memory error:
>
> ./soffice[121]: wait: 6980: Memory fault
I'm afraid we need a stack trace of this crash to understand what's
going on. When the stack trace shows which libraries are involved then
these libraries should be recompiled with debug infos (i.e. created with
the "debug=1" option for "make" or for "build"). Then replace the libs
in your installation with the debug libs and get the stack trace of this
crash.
> I don't think Raymond or I was expecting everything to work right on first launch and we were happy to see the splash screen, the executable start and the option menu appear. However, have you seen this type of memory error before or has it been seen by others? Do you have an idea what might cause this?
If you single stepped through the huge amounts of code that is needed to
get to there you'd see there is more than plenty of opportunity for
something to go wrong ;-)
> My fear is that we have made too many modifications to the code in order to get the system to build correctly. We have removed, in small select areas, "const" as a qualifier to certain parameters to member functions because the system would not compile with these parameters declared as a const. We can provide a list of these locations that we have edited, I believe it is about 3 or 4 files that might have been edited in this way.
The changes in the few source files you mentioned in your other mail are
probably uncritical. And e.g. Calc isn't changed at all, so if it
doesn't work either then I suspect the problem in a deeper layer.
> If you have any ideas, it would greatly help us out. Thanks.
The stack trace of the crash when debug-enabled libraries were used
would be very helpful
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
At long last Raymond and I have successfully gotten through the entire build script without a fault. The executable seemed to create just fine and we were able to launch soffice. We got the splash screen, then the executable started and the options window appeared and everything looked to be in order, but when we selected one of the document types to open, the executable crashed with the memory error:
./soffice[121]: wait: 6980: Memory fault
I don't think Raymond or I was expecting everything to work right on first launch and we were happy to see the splash screen, the executable start and the option menu appear. However, have you seen this type of memory error before or has it been seen by others? Do you have an idea what might cause this?
My fear is that we have made too many modifications to the code in order to get the system to build correctly. We have removed, in small select areas, "const" as a qualifier to certain parameters to member functions because the system would not compile with these parameters declared as a const. We can provide a list of these locations that we have edited, I believe it is about 3 or 4 files that might have been edited in this way.
If you have any ideas, it would greatly help us out. Thanks.
David Meffe
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Monday, December 16, 2013 4:46 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi David,
> Your idea worked. We were able to comment out those lines in the prex.h and the system was able to successfully build the VCL module as well as several others. We can almost taste the finish line.
Yay! I'm very glad to hear this 8-)
> However we have encountered another problem with the build that is a little more difficult than just sorting out the included header files and paths, this time in the slideshow module. The error is located in the c++ /usr/include/stdcxx4/deque.cc on line 569 and states that ShapeImporter::XShapeEntry has a const member mpGroupShape and cannot be reassigned. We can see in shapeimporter.cxx that line 181 is indeed a const definition of mpGroupShape, but it doesn't seem to tie directly to line 569 in deque.cc. This may be because deque.cc may be used as a template, and the assignment is forbidden because the value in XShapeEntry is a const, but is there a way around this?
This seems to be caused by a strange interaction of boost's shared_ptr and that const members can only be set in constructor. Maybe rvalue references come into play here too if your compiler has them enabled.
The exact error message could help...
> Do you have a thought as what we might try to continue with the build?
If the problem is in boost's shared_ptr then maybe updating to a later version could help. Please see my patch in issue 123817 if you want to update to the latest boost.
But maybe the shared_ptr problem is genuine when e.g. the reference counting requirements of such a shared_ptr require it to be non-const?
Anyway, the quickest workaround would be to remove the const from in line 119 of shapeimporter.hxx and line 193 of shapeimporter.cxx.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Hebert,
Here is a listing of the files that we modified because the build did not accept a "const" qualifier when defining a parameter or a member variable. The solution was to simply remove the "const" at the time to make the build continue. Since the build did not complain, we left the changes in until the end.
/sideshow/source/inc/shapeimporter.(hxx/cxx) - member variables: mpGroupShape, mxShape, and mnCount
/svx/source/sidebar/tools/ColorControl.(hxx/cxx) - member function: SetCurrColorSelect
/svx/source/sidebar/tools/ColorPopup.(hxx/cxx) - member function: SetCurrentColor
/sc/source/ui/drawfunc/drawsw2.cxx - member function: Activate
/sw/source/core/uno/unocore/unoportenum.cxx - member typedef: PortionList_t
David Meffe
-----Original Message-----
From: Steele, Raymond
Sent: Tuesday, December 17, 2013 3:36 PM
To: 'Herbert Duerr'; 'dev@openoffice.apache.org'
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Just wanted to add that it appears that the formula and database application are launching, but not Text Document, Spreadsheet, Presentation, or Drawing.
-----Original Message-----
From: Steele, Raymond
Sent: Tuesday, December 17, 2013 3:31 PM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Herbert,
At long last Raymond and I have successfully gotten through the entire build script without a fault. The executable seemed to create just fine and we were able to launch soffice. We got the splash screen, then the executable started and the options window appeared and everything looked to be in order, but when we selected one of the document types to open, the executable crashed with the memory error:
./soffice[121]: wait: 6980: Memory fault
I don't think Raymond or I was expecting everything to work right on first launch and we were happy to see the splash screen, the executable start and the option menu appear. However, have you seen this type of memory error before or has it been seen by others? Do you have an idea what might cause this?
My fear is that we have made too many modifications to the code in order to get the system to build correctly. We have removed, in small select areas, "const" as a qualifier to certain parameters to member functions because the system would not compile with these parameters declared as a const. We can provide a list of these locations that we have edited, I believe it is about 3 or 4 files that might have been edited in this way.
If you have any ideas, it would greatly help us out. Thanks.
David Meffe
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Monday, December 16, 2013 4:46 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi David,
> Your idea worked. We were able to comment out those lines in the prex.h and the system was able to successfully build the VCL module as well as several others. We can almost taste the finish line.
Yay! I'm very glad to hear this 8-)
> However we have encountered another problem with the build that is a little more difficult than just sorting out the included header files and paths, this time in the slideshow module. The error is located in the c++ /usr/include/stdcxx4/deque.cc on line 569 and states that ShapeImporter::XShapeEntry has a const member mpGroupShape and cannot be reassigned. We can see in shapeimporter.cxx that line 181 is indeed a const definition of mpGroupShape, but it doesn't seem to tie directly to line 569 in deque.cc. This may be because deque.cc may be used as a template, and the assignment is forbidden because the value in XShapeEntry is a const, but is there a way around this?
This seems to be caused by a strange interaction of boost's shared_ptr and that const members can only be set in constructor. Maybe rvalue references come into play here too if your compiler has them enabled.
The exact error message could help...
> Do you have a thought as what we might try to continue with the build?
If the problem is in boost's shared_ptr then maybe updating to a later version could help. Please see my patch in issue 123817 if you want to update to the latest boost.
But maybe the shared_ptr problem is genuine when e.g. the reference counting requirements of such a shared_ptr require it to be non-const?
Anyway, the quickest workaround would be to remove the const from in line 119 of shapeimporter.hxx and line 193 of shapeimporter.cxx.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Just wanted to add that it appears that the formula and database application are launching, but not Text Document, Spreadsheet, Presentation, or Drawing.
-----Original Message-----
From: Steele, Raymond
Sent: Tuesday, December 17, 2013 3:31 PM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Herbert,
At long last Raymond and I have successfully gotten through the entire build script without a fault. The executable seemed to create just fine and we were able to launch soffice. We got the splash screen, then the executable started and the options window appeared and everything looked to be in order, but when we selected one of the document types to open, the executable crashed with the memory error:
./soffice[121]: wait: 6980: Memory fault
I don't think Raymond or I was expecting everything to work right on first launch and we were happy to see the splash screen, the executable start and the option menu appear. However, have you seen this type of memory error before or has it been seen by others? Do you have an idea what might cause this?
My fear is that we have made too many modifications to the code in order to get the system to build correctly. We have removed, in small select areas, "const" as a qualifier to certain parameters to member functions because the system would not compile with these parameters declared as a const. We can provide a list of these locations that we have edited, I believe it is about 3 or 4 files that might have been edited in this way.
If you have any ideas, it would greatly help us out. Thanks.
David Meffe
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Monday, December 16, 2013 4:46 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi David,
> Your idea worked. We were able to comment out those lines in the prex.h and the system was able to successfully build the VCL module as well as several others. We can almost taste the finish line.
Yay! I'm very glad to hear this 8-)
> However we have encountered another problem with the build that is a little more difficult than just sorting out the included header files and paths, this time in the slideshow module. The error is located in the c++ /usr/include/stdcxx4/deque.cc on line 569 and states that ShapeImporter::XShapeEntry has a const member mpGroupShape and cannot be reassigned. We can see in shapeimporter.cxx that line 181 is indeed a const definition of mpGroupShape, but it doesn't seem to tie directly to line 569 in deque.cc. This may be because deque.cc may be used as a template, and the assignment is forbidden because the value in XShapeEntry is a const, but is there a way around this?
This seems to be caused by a strange interaction of boost's shared_ptr and that const members can only be set in constructor. Maybe rvalue references come into play here too if your compiler has them enabled.
The exact error message could help...
> Do you have a thought as what we might try to continue with the build?
If the problem is in boost's shared_ptr then maybe updating to a later version could help. Please see my patch in issue 123817 if you want to update to the latest boost.
But maybe the shared_ptr problem is genuine when e.g. the reference counting requirements of such a shared_ptr require it to be non-const?
Anyway, the quickest workaround would be to remove the const from in line 119 of shapeimporter.hxx and line 193 of shapeimporter.cxx.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi David,
> Your idea worked. We were able to comment out those lines in the prex.h and the system was able to successfully build the VCL module as well as several others. We can almost taste the finish line.
Yay! I'm very glad to hear this 8-)
> However we have encountered another problem with the build that is a little more difficult than just sorting out the included header files and paths, this time in the slideshow module. The error is located in the c++ /usr/include/stdcxx4/deque.cc on line 569 and states that ShapeImporter::XShapeEntry has a const member mpGroupShape and cannot be reassigned. We can see in shapeimporter.cxx that line 181 is indeed a const definition of mpGroupShape, but it doesn't seem to tie directly to line 569 in deque.cc. This may be because deque.cc may be used as a template, and the assignment is forbidden because the value in XShapeEntry is a const, but is there a way around this?
This seems to be caused by a strange interaction of boost's shared_ptr
and that const members can only be set in constructor. Maybe rvalue
references come into play here too if your compiler has them enabled.
The exact error message could help...
> Do you have a thought as what we might try to continue with the build?
If the problem is in boost's shared_ptr then maybe updating to a later
version could help. Please see my patch in issue 123817 if you want to
update to the latest boost.
But maybe the shared_ptr problem is genuine when e.g. the reference
counting requirements of such a shared_ptr require it to be non-const?
Anyway, the quickest workaround would be to remove the const from in
line 119 of shapeimporter.hxx and line 193 of shapeimporter.cxx.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
Your idea worked. We were able to comment out those lines in the prex.h and the system was able to successfully build the VCL module as well as several others. We can almost taste the finish line.
However we have encountered another problem with the build that is a little more difficult than just sorting out the included header files and paths, this time in the slideshow module. The error is located in the c++ /usr/include/stdcxx4/deque.cc on line 569 and states that ShapeImporter::XShapeEntry has a const member mpGroupShape and cannot be reassigned. We can see in shapeimporter.cxx that line 181 is indeed a const definition of mpGroupShape, but it doesn't seem to tie directly to line 569 in deque.cc. This may be because deque.cc may be used as a template, and the assignment is forbidden because the value in XShapeEntry is a const, but is there a way around this?
Do you have a thought as what we might try to continue with the build?
David
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Friday, December 13, 2013 1:25 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi David,
Hi Raymond,
On 12.12.2013 22:54, Steele, Raymond wrote:
> Raymond and I have made a lot of progress with the build of the Open Office Software on Solaris 11. We are now trying to compile the VCL module, but have found a problem that we hope you might be able to provide some insight on.
I'm very glad to hear that you already made it to VCL. It looks as if the compiler/STL problems are solved now in your AOO-dev environment.
> The build stopped in vcl while compiling /vcl/unx/generic/app/saldisp.cxx. The error was XkbKeycodeToKeysym must have a prototype, so I searched the system for the function and found it in <X11/XKBlib.h>. I added the header file into the saldisp.cxx file in the include area and continued the build, to which it no longer showed up as an error.
Investigating this problem suggests that the preprocessor-condition in line 42 of main/tools/inc/tools/prex.h may need to be updated for newer Solaris platforms.
I'm not sure whether this condition is still needed at all. It looks like a check to allow older platforms to run, but if all interesting unix targets like Linux and FreeBSD (and now Solaris?) don't need that condition for backward compatibility any any longer then that condition should be removed.
> However, the build stopped again, this time in compiling /vcl/unx/generic/dtrans/X11_selection.cxx. I added the same header file into the include area thinking that it would resolve the problem as the previous one had, but instead the compiler throws different errors depending on placement of where the <X11/KBlib.h> appears.
>
> If it appears at the bottom of the list of included headers it claims the Time and Window types in the XKBlib.h file are incomplete types, but if the included XKBlib.h header is included in the middle of the list, the compiler states that Typename was expected instead of "Time" in the XKBLib.h header.
The prex.h and post.x headers in main/tools/inc/tools/ do funny things to make the declarations from the X11 headers appear under a different name...
Adjusting line 42 of main/tools/inc/tools/prex.h may solve this problem too.
> Raymond and I are both somewhat hesitant to start messing with the X11 header files on the system.
I certainly agree with that!
> We see that the header <sys/time.h> is included in the file X11_selection.cxx. Do you have any advice for something we might try to continue with the build process?
Adjusting the line suggested above may solve this and many other problems.
Good luck!
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
As an experiment, we moved deque.c, deque.cc, and deque_spec to a backed up file name in /usr/include/stdcxx4, but kept deque as it was. Then the compile continued without error. We are not sure of the reason, but there seems to be some kind of conflict between those files. If you think we should put it back and address this some other way, please let us know. If you understand why the compile is not working after doing this, please share.
Thanks.
-----Original Message-----
From: Steele, Raymond
Sent: Friday, December 13, 2013 12:47 PM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Herbert,
Your idea worked. We were able to comment out those lines in the prex.h and the system was able to successfully build the VCL module as well as several others. We can almost taste the finish line.
However we have encountered another problem with the build that is a little more difficult than just sorting out the included header files and paths, this time in the slideshow module. The error is located in the c++ /usr/include/stdcxx4/deque.cc on line 569 and states that ShapeImporter::XShapeEntry has a const member mpGroupShape and cannot be reassigned. We can see in shapeimporter.cxx that line 181 is indeed a const definition of mpGroupShape, but it doesn't seem to tie directly to line 569 in deque.cc. This may be because deque.cc may be used as a template, and the assignment is forbidden because the value in XShapeEntry is a const, but is there a way around this?
Do you have a thought as what we might try to continue with the build?
David
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Friday, December 13, 2013 1:25 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi David,
Hi Raymond,
On 12.12.2013 22:54, Steele, Raymond wrote:
> Raymond and I have made a lot of progress with the build of the Open Office Software on Solaris 11. We are now trying to compile the VCL module, but have found a problem that we hope you might be able to provide some insight on.
I'm very glad to hear that you already made it to VCL. It looks as if the compiler/STL problems are solved now in your AOO-dev environment.
> The build stopped in vcl while compiling /vcl/unx/generic/app/saldisp.cxx. The error was XkbKeycodeToKeysym must have a prototype, so I searched the system for the function and found it in <X11/XKBlib.h>. I added the header file into the saldisp.cxx file in the include area and continued the build, to which it no longer showed up as an error.
Investigating this problem suggests that the preprocessor-condition in line 42 of main/tools/inc/tools/prex.h may need to be updated for newer Solaris platforms.
I'm not sure whether this condition is still needed at all. It looks like a check to allow older platforms to run, but if all interesting unix targets like Linux and FreeBSD (and now Solaris?) don't need that condition for backward compatibility any any longer then that condition should be removed.
> However, the build stopped again, this time in compiling /vcl/unx/generic/dtrans/X11_selection.cxx. I added the same header file into the include area thinking that it would resolve the problem as the previous one had, but instead the compiler throws different errors depending on placement of where the <X11/KBlib.h> appears.
>
> If it appears at the bottom of the list of included headers it claims the Time and Window types in the XKBlib.h file are incomplete types, but if the included XKBlib.h header is included in the middle of the list, the compiler states that Typename was expected instead of "Time" in the XKBLib.h header.
The prex.h and post.x headers in main/tools/inc/tools/ do funny things to make the declarations from the X11 headers appear under a different name...
Adjusting line 42 of main/tools/inc/tools/prex.h may solve this problem too.
> Raymond and I are both somewhat hesitant to start messing with the X11 header files on the system.
I certainly agree with that!
> We see that the header <sys/time.h> is included in the file X11_selection.cxx. Do you have any advice for something we might try to continue with the build process?
Adjusting the line suggested above may solve this and many other problems.
Good luck!
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Ok, nevermind. We are back to the original problem.
-----Original Message-----
From: Steele, Raymond
Sent: Friday, December 13, 2013 1:45 PM
To: 'Herbert Duerr'; 'dev@openoffice.apache.org'
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Herbert,
As an experiment, we moved deque.c, deque.cc, and deque_spec to a backed up file name in /usr/include/stdcxx4, but kept deque as it was. Then the compile continued without error. We are not sure of the reason, but there seems to be some kind of conflict between those files. If you think we should put it back and address this some other way, please let us know. If you understand why the compile is not working after doing this, please share.
Thanks.
-----Original Message-----
From: Steele, Raymond
Sent: Friday, December 13, 2013 12:47 PM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Herbert,
Your idea worked. We were able to comment out those lines in the prex.h and the system was able to successfully build the VCL module as well as several others. We can almost taste the finish line.
However we have encountered another problem with the build that is a little more difficult than just sorting out the included header files and paths, this time in the slideshow module. The error is located in the c++ /usr/include/stdcxx4/deque.cc on line 569 and states that ShapeImporter::XShapeEntry has a const member mpGroupShape and cannot be reassigned. We can see in shapeimporter.cxx that line 181 is indeed a const definition of mpGroupShape, but it doesn't seem to tie directly to line 569 in deque.cc. This may be because deque.cc may be used as a template, and the assignment is forbidden because the value in XShapeEntry is a const, but is there a way around this?
Do you have a thought as what we might try to continue with the build?
David
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Friday, December 13, 2013 1:25 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi David,
Hi Raymond,
On 12.12.2013 22:54, Steele, Raymond wrote:
> Raymond and I have made a lot of progress with the build of the Open Office Software on Solaris 11. We are now trying to compile the VCL module, but have found a problem that we hope you might be able to provide some insight on.
I'm very glad to hear that you already made it to VCL. It looks as if the compiler/STL problems are solved now in your AOO-dev environment.
> The build stopped in vcl while compiling /vcl/unx/generic/app/saldisp.cxx. The error was XkbKeycodeToKeysym must have a prototype, so I searched the system for the function and found it in <X11/XKBlib.h>. I added the header file into the saldisp.cxx file in the include area and continued the build, to which it no longer showed up as an error.
Investigating this problem suggests that the preprocessor-condition in line 42 of main/tools/inc/tools/prex.h may need to be updated for newer Solaris platforms.
I'm not sure whether this condition is still needed at all. It looks like a check to allow older platforms to run, but if all interesting unix targets like Linux and FreeBSD (and now Solaris?) don't need that condition for backward compatibility any any longer then that condition should be removed.
> However, the build stopped again, this time in compiling /vcl/unx/generic/dtrans/X11_selection.cxx. I added the same header file into the include area thinking that it would resolve the problem as the previous one had, but instead the compiler throws different errors depending on placement of where the <X11/KBlib.h> appears.
>
> If it appears at the bottom of the list of included headers it claims the Time and Window types in the XKBlib.h file are incomplete types, but if the included XKBlib.h header is included in the middle of the list, the compiler states that Typename was expected instead of "Time" in the XKBLib.h header.
The prex.h and post.x headers in main/tools/inc/tools/ do funny things to make the declarations from the X11 headers appear under a different name...
Adjusting line 42 of main/tools/inc/tools/prex.h may solve this problem too.
> Raymond and I are both somewhat hesitant to start messing with the X11 header files on the system.
I certainly agree with that!
> We see that the header <sys/time.h> is included in the file X11_selection.cxx. Do you have any advice for something we might try to continue with the build process?
Adjusting the line suggested above may solve this and many other problems.
Good luck!
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi David,
Hi Raymond,
On 12.12.2013 22:54, Steele, Raymond wrote:
> Raymond and I have made a lot of progress with the build of the Open Office Software on Solaris 11. We are now trying to compile the VCL module, but have found a problem that we hope you might be able to provide some insight on.
I'm very glad to hear that you already made it to VCL. It looks as if
the compiler/STL problems are solved now in your AOO-dev environment.
> The build stopped in vcl while compiling /vcl/unx/generic/app/saldisp.cxx. The error was XkbKeycodeToKeysym must have a prototype, so I searched the system for the function and found it in <X11/XKBlib.h>. I added the header file into the saldisp.cxx file in the include area and continued the build, to which it no longer showed up as an error.
Investigating this problem suggests that the preprocessor-condition in
line 42 of main/tools/inc/tools/prex.h may need to be updated for newer
Solaris platforms.
I'm not sure whether this condition is still needed at all. It looks
like a check to allow older platforms to run, but if all interesting
unix targets like Linux and FreeBSD (and now Solaris?) don't need that
condition for backward compatibility any any longer then that condition
should be removed.
> However, the build stopped again, this time in compiling /vcl/unx/generic/dtrans/X11_selection.cxx. I added the same header file into the include area thinking that it would resolve the problem as the previous one had, but instead the compiler throws different errors depending on placement of where the <X11/KBlib.h> appears.
>
> If it appears at the bottom of the list of included headers it claims the Time and Window types in the XKBlib.h file are incomplete types, but if the included XKBlib.h header is included in the middle of the list, the compiler states that Typename was expected instead of "Time" in the XKBLib.h header.
The prex.h and post.x headers in main/tools/inc/tools/ do funny things
to make the declarations from the X11 headers appear under a different
name...
Adjusting line 42 of main/tools/inc/tools/prex.h may solve this problem too.
> Raymond and I are both somewhat hesitant to start messing with the X11 header files on the system.
I certainly agree with that!
> We see that the header <sys/time.h> is included in the file X11_selection.cxx. Do you have any advice for something we might try to continue with the build process?
Adjusting the line suggested above may solve this and many other problems.
Good luck!
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
Raymond and I have made a lot of progress with the build of the Open Office Software on Solaris 11. We are now trying to compile the VCL module, but have found a problem that we hope you might be able to provide some insight on.
The build stopped in vcl while compiling /vcl/unx/generic/app/saldisp.cxx. The error was XkbKeycodeToKeysym must have a prototype, so I searched the system for the function and found it in <X11/XKBlib.h>. I added the header file into the saldisp.cxx file in the include area and continued the build, to which it no longer showed up as an error.
However, the build stopped again, this time in compiling /vcl/unx/generic/dtrans/X11_selection.cxx. I added the same header file into the include area thinking that it would resolve the problem as the previous one had, but instead the compiler throws different errors depending on placement of where the <X11/KBlib.h> appears.
If it appears at the bottom of the list of included headers it claims the Time and Window types in the XKBlib.h file are incomplete types, but if the included XKBlib.h header is included in the middle of the list, the compiler states that Typename was expected instead of "Time" in the XKBLib.h header.
Raymond and I are both somewhat hesitant to start messing with the X11 header files on the system. We see that the header <sys/time.h> is included in the file X11_selection.cxx. Do you have any advice for something we might try to continue with the build process?
David Meffe
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Wednesday, December 11, 2013 1:16 PM
To: dev@openoffice.apache.org
Cc: Steele, Raymond; Meffe, David K
Subject: Re: EXTERNAL: Re: Building comphelper
Steele, Raymond wrote:
> For select1st, we noticed that the <functional> header delivered with
> stdcxx4 did not define select1st,
Select1st didn't make it into the C++ standard, so good standard compliant libraries don't include it anymore.
> but the aoo delivered <functional> located in systemstl/tr1 did. Our Makefile flags are set to include the stdcxx4 <functional> instead of the systemstl/tr1 <functional>. To get around this we modified namedvaluecollection.cxx:
>
> #if defined(__SUNPRO_CC)
> #include "../systemstl/tr1/functional"
> #esle
> #include <functional>
> #endif
>
> Let us know if you think there is a better way to address this.
The systemstl/tr1/functional header is a wrapper around good standard compliant "functional" headers. Many parts of the AOO codebase still expect the obsoleted stlport4 semantics and the wrapper provides them.
The AOO codebase is being adjusted (e.g. [1],[2],[3]) to be more standard compliant, so obsolete parts will be replaced. When the emulation of an obsoleted construct is no longer needed by the codebase then that emulation can be removed from the wrappers. So the wrappers will become smaller and smaller until they can finally disappear.
[1] https://issues.apache.org/ooo/show_bug.cgi?id=123755
[2] https://issues.apache.org/ooo/show_bug.cgi?id=123770
[3] https://issues.apache.org/ooo/show_bug.cgi?id=123754
So in short: please make sure that systemstl/tr1/functional wrapper around the good standard compliant "functional" header can work.
> Now we are on to figuring out why comphelper's having a linking error. It is trying to build libcomphelperC52.so, but it cannot find -lstlport_sunpro.
lstlport_sunpro is no longer needed. If the header wrappers were used then the TR1 standard compliant C++ libraries cover everything that stlport was used for. Just find the Makefile that is responsible for the -lstlport_sunpro option and remove it.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Meffe, David K" <da...@lmco.com>.
Raymond and Herbet,
I found out where the make file was including the stlport libraries. It was in solaris.mk in the gb_Library_FILENAMES and gb_Library_LAYER. I commented out the STLLIBS in both of these sections and it was able to build comphelper. While I'm not sure this is the best solution, it was where the LinkTarget.mk was getting the location for the libcomphelperC52.so.
David Meffe
-----Original Message-----
From: Steele, Raymond
Sent: Wednesday, December 11, 2013 1:37 PM
To: Herbert Duerr; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Okay, we will look some more. We were commenting out all instances before you wrote, but were still not having luck. Is it possible that we have to do a clean build?
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Wednesday, December 11, 2013 1:16 PM
To: dev@openoffice.apache.org
Cc: Steele, Raymond; Meffe, David K
Subject: Re: EXTERNAL: Re: Building comphelper
Steele, Raymond wrote:
> For select1st, we noticed that the <functional> header delivered with
> stdcxx4 did not define select1st,
Select1st didn't make it into the C++ standard, so good standard compliant libraries don't include it anymore.
> but the aoo delivered <functional> located in systemstl/tr1 did. Our Makefile flags are set to include the stdcxx4 <functional> instead of the systemstl/tr1 <functional>. To get around this we modified namedvaluecollection.cxx:
>
> #if defined(__SUNPRO_CC)
> #include "../systemstl/tr1/functional"
> #esle
> #include <functional>
> #endif
>
> Let us know if you think there is a better way to address this.
The systemstl/tr1/functional header is a wrapper around good standard compliant "functional" headers. Many parts of the AOO codebase still expect the obsoleted stlport4 semantics and the wrapper provides them.
The AOO codebase is being adjusted (e.g. [1],[2],[3]) to be more standard compliant, so obsolete parts will be replaced. When the emulation of an obsoleted construct is no longer needed by the codebase then that emulation can be removed from the wrappers. So the wrappers will become smaller and smaller until they can finally disappear.
[1] https://issues.apache.org/ooo/show_bug.cgi?id=123755
[2] https://issues.apache.org/ooo/show_bug.cgi?id=123770
[3] https://issues.apache.org/ooo/show_bug.cgi?id=123754
So in short: please make sure that systemstl/tr1/functional wrapper around the good standard compliant "functional" header can work.
> Now we are on to figuring out why comphelper's having a linking error. It is trying to build libcomphelperC52.so, but it cannot find -lstlport_sunpro.
lstlport_sunpro is no longer needed. If the header wrappers were used then the TR1 standard compliant C++ libraries cover everything that stlport was used for. Just find the Makefile that is responsible for the -lstlport_sunpro option and remove it.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Okay, we will look some more. We were commenting out all instances before you wrote, but were still not having luck. Is it possible that we have to do a clean build?
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Wednesday, December 11, 2013 1:16 PM
To: dev@openoffice.apache.org
Cc: Steele, Raymond; Meffe, David K
Subject: Re: EXTERNAL: Re: Building comphelper
Steele, Raymond wrote:
> For select1st, we noticed that the <functional> header delivered with
> stdcxx4 did not define select1st,
Select1st didn't make it into the C++ standard, so good standard compliant libraries don't include it anymore.
> but the aoo delivered <functional> located in systemstl/tr1 did. Our Makefile flags are set to include the stdcxx4 <functional> instead of the systemstl/tr1 <functional>. To get around this we modified namedvaluecollection.cxx:
>
> #if defined(__SUNPRO_CC)
> #include "../systemstl/tr1/functional"
> #esle
> #include <functional>
> #endif
>
> Let us know if you think there is a better way to address this.
The systemstl/tr1/functional header is a wrapper around good standard compliant "functional" headers. Many parts of the AOO codebase still expect the obsoleted stlport4 semantics and the wrapper provides them.
The AOO codebase is being adjusted (e.g. [1],[2],[3]) to be more standard compliant, so obsolete parts will be replaced. When the emulation of an obsoleted construct is no longer needed by the codebase then that emulation can be removed from the wrappers. So the wrappers will become smaller and smaller until they can finally disappear.
[1] https://issues.apache.org/ooo/show_bug.cgi?id=123755
[2] https://issues.apache.org/ooo/show_bug.cgi?id=123770
[3] https://issues.apache.org/ooo/show_bug.cgi?id=123754
So in short: please make sure that systemstl/tr1/functional wrapper around the good standard compliant "functional" header can work.
> Now we are on to figuring out why comphelper's having a linking error. It is trying to build libcomphelperC52.so, but it cannot find -lstlport_sunpro.
lstlport_sunpro is no longer needed. If the header wrappers were used then the TR1 standard compliant C++ libraries cover everything that stlport was used for. Just find the Makefile that is responsible for the -lstlport_sunpro option and remove it.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Steele, Raymond wrote:
> For select1st, we noticed that the <functional> header delivered with stdcxx4 did not define select1st,
Select1st didn't make it into the C++ standard, so good standard
compliant libraries don't include it anymore.
> but the aoo delivered <functional> located in systemstl/tr1 did. Our Makefile flags are set to include the stdcxx4 <functional> instead of the systemstl/tr1 <functional>. To get around this we modified namedvaluecollection.cxx:
>
> #if defined(__SUNPRO_CC)
> #include "../systemstl/tr1/functional"
> #esle
> #include <functional>
> #endif
>
> Let us know if you think there is a better way to address this.
The systemstl/tr1/functional header is a wrapper around good standard
compliant "functional" headers. Many parts of the AOO codebase still
expect the obsoleted stlport4 semantics and the wrapper provides them.
The AOO codebase is being adjusted (e.g. [1],[2],[3]) to be more
standard compliant, so obsolete parts will be replaced. When the
emulation of an obsoleted construct is no longer needed by the codebase
then that emulation can be removed from the wrappers. So the wrappers
will become smaller and smaller until they can finally disappear.
[1] https://issues.apache.org/ooo/show_bug.cgi?id=123755
[2] https://issues.apache.org/ooo/show_bug.cgi?id=123770
[3] https://issues.apache.org/ooo/show_bug.cgi?id=123754
So in short: please make sure that systemstl/tr1/functional wrapper
around the good standard compliant "functional" header can work.
> Now we are on to figuring out why comphelper's having a linking error. It is trying to build libcomphelperC52.so, but it cannot find -lstlport_sunpro.
lstlport_sunpro is no longer needed. If the header wrappers were used
then the TR1 standard compliant C++ libraries cover everything that
stlport was used for. Just find the Makefile that is responsible for the
-lstlport_sunpro option and remove it.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
We are having trouble interpreting the boost preprocessor macros. We are receiving the following output when compiling sal/osl/all. I've attached the output as a pdf.
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Friday, November 22, 2013 2:14 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond; Meffe, David K
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 21.11.2013 22:27, Steele, Raymond wrote:
> Forget about my last report. We started over and figured out that an environment variable was causing the dmake issues. Once we cleared the environment of variables related to our other projects, the build took off. We will have to figure out what it was later.
Thanks for debugging and solving that problem!
The current way of configure writing a file for setting environments variables is too fragile. As can be seen in your example if configure is run in an environment that is already "contaminated" with such env vars then unnecessary causes of troubles exist.
IMHO build and config settings should be done via e.g. Makefile.config that should be created by configure. This config result should then be included by the other Makefiles.
So if in doubt better use a fresh shell before running configure.
Herbert
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, Dec 9, 2013 at 10:29 AM, Kay Schenk <ka...@gmail.com> wrote:
>
> On Mon, Dec 9, 2013 at 5:29 AM, Herbert Duerr <hd...@apache.org> wrote:
>
>> On 08.12.2013 19:26, Kay Schenk wrote:
>>
>>> [...]
>>>
>>> short story -- I couldn't get things to work with 1.49, so I decided to
>>> try
>>> 1.54. Errors, but different. At first I WAS using 1.49.
>>>
>>
>> Ok. That 1.49 didn't work is an interesting data point.
>>
>>
>> Is it OK to use this newer version because I'm getting errors [...]
>>>>>
>>>>
>> There should be no general problem, but boost 1.49 wasn't regularly used
>> for building AOO, so the AOO may need some adaptions to work with boost
>> 1.49.
>>
>>
>> The 1.54 boost version you are using is much newer than the AOO internal
>>>> version, which is version still at 1.48. We should upgrade our codebase
>>>> to work with the newer version and update the internal boost then. This
>>>> could solve many compile warnings that are spewed out for 1.48 and fix
>>>> some hard problems like the one with the Solaris compilers.
>>>>
>>>> But as you saw such support for newer boost versions is more than just a
>>>> recompile. Making AOO build with newer boost versions may be an
>>>> interesting topic for a volunteer. One could leverage the experience of
>>>> the very popular boost library to dive into many corners of the AOO
>>>> codebase.
>>>>
>>>
>>>
>>> I'm not sure what some of this statement really means... but definitely a
>>> worthwhile project for a volunteer!
>>>
>>
>> By the way I created an enhancement issue [1] for upgrading to the latest
>> boost version. I also developed a patch that already works with my systems
>> and attached it to that issue.
>>
>> [1] https://issues.apache.org/ooo/show_bug.cgi?id=123817
>>
>> It would be interesting to know if that experimental patch to support the
>> new boost version works better for e.g. our Solaris ports? Please test.
>> Maybe upgrading to boost 1.55 is a good idea for the AOO 4.1 release.
>>
>>
>> Herbert
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
> OK, good...I'll have a look soonish.
>
Well I applied this patch but decided to just continue with 1.54 (my local)
instead of downloading 1.55, or using supplied supplied boost with the
patch (I may try that next).
My traceback...
two items --
* In file included from ../../inc/osl/diagnose.hxx:41:0,
from
/home/kschenk/AOO_source/main/sal/osl/all/debugbase.cxx:31:
/home/kschenk/AOO_source/main/solver/410/unxlngi6.pro/inc/stl/hash_set:42:26:
error: 'hash' is already declared in this scope
and longer
* In file included from /usr/include/boost/functional/hash/hash.hpp:529:0,
from /usr/include/boost/functional/hash.hpp:6,
from /home/kschenk/AOO_source/main/solver/410/
unxlngi6.pro/inc/stl/functional:37,
from /usr/include/c++/4.7/memory:81,
from /usr/include/boost/unordered/unordered_set_fwd.hpp:14,
from /usr/include/boost/unordered/unordered_set.hpp:16,
from /usr/include/boost/unordered_set.hpp:16,
from /usr/include/boost/tr1/unordered_set.hpp:21,
from /usr/include/boost/tr1/tr1/unordered_set:28,
from /home/kschenk/AOO_source/main/solver/410/
unxlngi6.pro/inc/stl/hash_set:32,
from ../../inc/osl/diagnose.hxx:41,
from
/home/kschenk/AOO_source/main/sal/osl/all/debugbase.cxx:31:
The second one seems to center around the following from boost itself in --
In file included from /usr/include/boost/functional/hash/hash.hpp
#if !defined(BOOST_HASH_NO_EXTENSIONS) \
&& !defined(BOOST_FUNCTIONAL_HASH_EXTENSIONS_HPP)
#include <boost/functional/hash/extensions.hpp>
#endif
so I don't know if we need to do something about BOOST_HASH_NO_EXTENSIONS
so...no joy yet
>
> --
>
> -------------------------------------------------------------------------------------------------
> MzK
>
> "Cats do not have to be shown how to have a good time,
> for they are unfailing ingenious in that respect."
> -- James Mason
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, Dec 9, 2013 at 5:29 AM, Herbert Duerr <hd...@apache.org> wrote:
> On 08.12.2013 19:26, Kay Schenk wrote:
>
>> [...]
>>
>> short story -- I couldn't get things to work with 1.49, so I decided to
>> try
>> 1.54. Errors, but different. At first I WAS using 1.49.
>>
>
> Ok. That 1.49 didn't work is an interesting data point.
>
>
> Is it OK to use this newer version because I'm getting errors [...]
>>>>
>>>
> There should be no general problem, but boost 1.49 wasn't regularly used
> for building AOO, so the AOO may need some adaptions to work with boost
> 1.49.
>
>
> The 1.54 boost version you are using is much newer than the AOO internal
>>> version, which is version still at 1.48. We should upgrade our codebase
>>> to work with the newer version and update the internal boost then. This
>>> could solve many compile warnings that are spewed out for 1.48 and fix
>>> some hard problems like the one with the Solaris compilers.
>>>
>>> But as you saw such support for newer boost versions is more than just a
>>> recompile. Making AOO build with newer boost versions may be an
>>> interesting topic for a volunteer. One could leverage the experience of
>>> the very popular boost library to dive into many corners of the AOO
>>> codebase.
>>>
>>
>>
>> I'm not sure what some of this statement really means... but definitely a
>> worthwhile project for a volunteer!
>>
>
> By the way I created an enhancement issue [1] for upgrading to the latest
> boost version. I also developed a patch that already works with my systems
> and attached it to that issue.
>
> [1] https://issues.apache.org/ooo/show_bug.cgi?id=123817
>
> It would be interesting to know if that experimental patch to support the
> new boost version works better for e.g. our Solaris ports? Please test.
> Maybe upgrading to boost 1.55 is a good idea for the AOO 4.1 release.
>
>
> Herbert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
OK, good...I'll have a look soonish.
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Herbert Duerr <hd...@apache.org>.
On 08.12.2013 19:26, Kay Schenk wrote:
> [...]
> short story -- I couldn't get things to work with 1.49, so I decided to try
> 1.54. Errors, but different. At first I WAS using 1.49.
Ok. That 1.49 didn't work is an interesting data point.
>>> Is it OK to use this newer version because I'm getting errors [...]
There should be no general problem, but boost 1.49 wasn't regularly used
for building AOO, so the AOO may need some adaptions to work with boost
1.49.
>> The 1.54 boost version you are using is much newer than the AOO internal
>> version, which is version still at 1.48. We should upgrade our codebase
>> to work with the newer version and update the internal boost then. This
>> could solve many compile warnings that are spewed out for 1.48 and fix
>> some hard problems like the one with the Solaris compilers.
>>
>> But as you saw such support for newer boost versions is more than just a
>> recompile. Making AOO build with newer boost versions may be an
>> interesting topic for a volunteer. One could leverage the experience of
>> the very popular boost library to dive into many corners of the AOO
>> codebase.
>
>
> I'm not sure what some of this statement really means... but definitely a
> worthwhile project for a volunteer!
By the way I created an enhancement issue [1] for upgrading to the
latest boost version. I also developed a patch that already works with
my systems and attached it to that issue.
[1] https://issues.apache.org/ooo/show_bug.cgi?id=123817
It would be interesting to know if that experimental patch to support
the new boost version works better for e.g. our Solaris ports? Please
test. Maybe upgrading to boost 1.55 is a good idea for the AOO 4.1 release.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Kay Schenk <ka...@gmail.com>.
On Dec 5, 2013 10:28 PM, "Herbert Duerr" <hd...@apache.org> wrote:
>
> Hi Kay,
>
> Kay Schenk wrote:
> > OK, here's a related 'boost" question. I have installed boost 1.54, but
> > it's for my distro and not totally complete, so I will install the rest
of
> > the "config/test" items today and verify installation.
> >
> > I am using --with-system-boost
>
> Ah, I didn't know that you were using --with-system-boost and that
> version being 1.54. This is an interesting detail that I hadn't seen in
> your earlier mails. It could explain most of the trouble you are
> experiencing. Do things work better with the internal version?
short story -- I couldn't get things to work with 1.49, so I decided to try
1.54. Errors, but different. At first I WAS using 1.49.
>
> > Is it OK to use this newer version because I'm getting errors [...]
>
> The 1.54 boost version you are using is much newer than the AOO internal
> version, which is version still at 1.48. We should upgrade our codebase
> to work with the newer version and update the internal boost then. This
> could solve many compile warnings that are spewed out for 1.48 and fix
> some hard problems like the one with the Solaris compilers.
>
> But as you saw such support for newer boost versions is more than just a
> recompile. Making AOO build with newer boost versions may be an
> interesting topic for a volunteer. One could leverage the experience of
> the very popular boost library to dive into many corners of the AOO
> codebase.
I'm not sure what some of this statement really means... but definitely a
worthwhile project for a volunteer!
>
> Herbert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Posted by Herbert Duerr <hd...@apache.org>.
Hi Kay,
Kay Schenk wrote:
> OK, here's a related 'boost" question. I have installed boost 1.54, but
> it's for my distro and not totally complete, so I will install the rest of
> the "config/test" items today and verify installation.
>
> I am using --with-system-boost
Ah, I didn't know that you were using --with-system-boost and that
version being 1.54. This is an interesting detail that I hadn't seen in
your earlier mails. It could explain most of the trouble you are
experiencing. Do things work better with the internal version?
> Is it OK to use this newer version because I'm getting errors [...]
The 1.54 boost version you are using is much newer than the AOO internal
version, which is version still at 1.48. We should upgrade our codebase
to work with the newer version and update the internal boost then. This
could solve many compile warnings that are spewed out for 1.48 and fix
some hard problems like the one with the Solaris compilers.
But as you saw such support for newer boost versions is more than just a
recompile. Making AOO build with newer boost versions may be an
interesting topic for a volunteer. One could leverage the experience of
the very popular boost library to dive into many corners of the AOO
codebase.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Dec 5, 2013 at 1:41 AM, Herbert Duerr <hd...@apache.org> wrote:
> Hi Raymond,
>
>
> Thanks Herbert. Do you have any idea why we would be receiving the
>> following?
>>
>> Compiling: sal/rtl/source/unload.cxx
>> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199:
>> Error:Could not find a match for boost::tuples::get<boost::tuples::N,boost::tuples::HT,
>> boost::tuples::TT>(constboost::tuples::tuple<boost::tuples::null_type,
>> boost::tuples::null_type,boost::tuples::null_type,
>> boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type,
>> boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type,
>> boost::tuples::null_type>) needed inboost::unordered::detail::
>> construct_from_tuple<configmgr::Partial::Node,boost::tuples::null_type>(configmgr::Partial::Node*,
>> constboost::tuples::tuple<boost::tuples::null_type,
>> boost::tuples::null_type,boost::tuples::null_type,
>> boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type,
>> boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type,
>> boost::tuples::null_type>&).
>> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line
>> 350:Where: While instantiating"boost::unordered::detail::construct_
>> from_tuple<configmgr::Partial::Node,boost::tuples::null_
>> type>(configmgr::Partial::Node*, constboost::tuples::tuple<boost::tuples::null_type,
>> boost::tuples::null_type,boost::tuples::null_type,
>> boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type,
>> boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type,
>> boost::tuples::null_type>&)".
>> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line
>> 350:Where: Instantiated from boost::unordered::unordered_
>> map<rtl::OUString,configmgr::Partial::Node, boost::hash<rtl::OUString>,_STL::equal_to<rtl::OUString>,
>> _STL::allocator<_STL::pair<const rtl::OUString,configmgr::
>> Partial::Node>>>::operator[](const rtl::OUString&).
>> "/opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx ", line 217: Where:
>> Instantiated from non-template code.
>>
>
> Are you using the configure option --with-system-boost? If not, then the
> boost headers should be found in
> .../main/solenv/*/unx*/inc/boost/
> and not in
> /usr/local/include/boost/
>
> The top suspect for the actual problem you are seeing is a boost problem
> [1]. It was fixed in boost 1.49 with [2]. AOO is currently using boost 1.48
> but problems such as this indicate that an update is overdue.
>
> [1] https://svn.boost.org/trac/boost/ticket/6784
> [2] https://svn.boost.org/trac/boost/changeset/77972
>
> Could you try to apply the patch [2] to the problematic boost header to
> check whether this solves the problem? If yes, we could apply it to our
> local boost header with the patch mechanism. Or even better we could update
> our boost libs, but that would eventually open another can of worms...
>
>
> Herbert
>
OK, here's a related 'boost" question. I have installed boost 1.54, but
it's for my distro and not totally complete, so I will install the rest of
the "config/test" items today and verify installation.
I am using --with-system-boost
Is it OK to use this newer version because I'm getting errors originating
originating from
main/sal/osl/all/debugbase.cxx ...
main/solver/410/unxlngi6.pro/inc/stl/functional:37
from /usr/include/boost/functional/hash/hash.hpp:529:0, -->
/usr/include/boost/functional/hash/extensions.hpp (many errors)
Thanks..
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
Are you recommending that we use boost version 1_49 versus the one delivered with OpenOffice? If so, then we will reconfigure using the --with-system-boost flag. If we use 1_49, does it require any special configure / build steps?
Today, we replaced the 1_48 version of emplace_args.hpp with the 1_49 version, then implemented the patch [2] and the issues below went away, but the compile complains about an undefined boost type on line 220 :
BOOST_UNORDERED_CONSTRUCT_FROM_TUPLE(10, boost)
We are thinking that we need to pull in another file from 1_49, but that may snowball into needing more files, but we are not sure.
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Thursday, December 05, 2013 2:42 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
> Thanks Herbert. Do you have any idea why we would be receiving the following?
>
> Compiling: sal/rtl/source/unload.cxx
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199: Error:Could not find a match for boost::tuples::get<boost::tuples::N,boost::tuples::HT, boost::tuples::TT>(constboost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type>) needed inboost::unordered::detail::construct_from_tuple<configmgr::Partial::Node,boost::tuples::null_type>(configmgr::Partial::Node*, constboost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type>&).
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where: While instantiating"boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node,boost::tuples::null_type>(configmgr::Partial::Node*, constboost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type>&)".
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where: Instantiated from boost::unordered::unordered_map<rtl::OUString,configmgr::Partial::Node, boost::hash<rtl::OUString>,_STL::equal_to<rtl::OUString>, _STL::allocator<_STL::pair<const rtl::OUString,configmgr::Partial::Node>>>::operator[](const rtl::OUString&).
> "/opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx ", line 217: Where: Instantiated from non-template code.
Are you using the configure option --with-system-boost? If not, then the boost headers should be found in
.../main/solenv/*/unx*/inc/boost/
and not in
/usr/local/include/boost/
The top suspect for the actual problem you are seeing is a boost problem [1]. It was fixed in boost 1.49 with [2]. AOO is currently using boost
1.48 but problems such as this indicate that an update is overdue.
[1] https://svn.boost.org/trac/boost/ticket/6784
[2] https://svn.boost.org/trac/boost/changeset/77972
Could you try to apply the patch [2] to the problematic boost header to check whether this solves the problem? If yes, we could apply it to our local boost header with the patch mechanism. Or even better we could update our boost libs, but that would eventually open another can of worms...
Herbert
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Fantastic! We were actually looking at that [2] yesterday, but were concerned because it was dated 7 months ago. We will implement it and provide feedback.
Thanks again!
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Tuesday, December 10, 2013 11:25 PM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi David,
Hi Raymond,
On 11.12.2013 00:16, you wrote:
> Thanks for much of the help you have provided in this venture to help us get OpenOffice working in Solaris 11. Because of this we have gotten further into the compile of the OpenOffice software. We have moved past the external sources compile errors by using a newer version of Boost (1.49) and adding in the updates to the emplace_args.hpp file that have been posted on the web.
Speaking of newer boost versions please also see [1] (an enhancement issue I created to update to boost 1.55). I developed a patch to do that and added it there to do this. You might want to try it out.
[1] https://issues.apache.org/ooo/show_bug.cgi?id=123817
> However, we are now encountering a problem within the binaryurp in the bridge.cxx compile. The first error message is as follows:
>
> "../main/binaryurp/source/cache.hxx", line 113: Error: iterator is not a member of std::map<com:sun::star::uno::TypeDescription,binaryurp::Cache<com::sun::star::uno::TypeDescription>::Entry>.
>
> Looking at the code, it doesn't seem like an obvious error. The line it complains about is inside a struct Entry and the error occurs when defining a member variable named prev as a Map::iterator. We could use some insight into this problem and would appreciate any help. Thanks.
According to the C++ standard the compiler/STL is right to complain about that code: the Entry type is incomplete until the declaration is over and a Map iterator with Entry as its "mapped_type" can not be expected to work while Entry is being declared.
Some compiler/STL combinations allow it, but some don't. Especially the better ones (which don't treat all mapped_types the same but have optimized template specializations) run into problems here.
The good news is that I already developed a replacement for this problematic code to make it more compatible with standard complying compilers/STLs. Please try out the patch in [2]. I was about to merge this into trunk soon anyway, but if you could confirm that it solves the problem on your platform this would accelerate the integration.
[2] http://svn.apache.org/viewvc?view=revision&revision=1480367
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
The changes [2] worked perfectly for us. Now we are having issues compiling ::std::select1st in namedvaluecollection.cxx on line 175. Apparently, select1st is not a member of std. It appears that you may have created a ticket for this one.
https://issues.apache.org/ooo/show_bug.cgi?id=123754
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Tuesday, December 10, 2013 11:25 PM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi David,
Hi Raymond,
On 11.12.2013 00:16, you wrote:
> Thanks for much of the help you have provided in this venture to help us get OpenOffice working in Solaris 11. Because of this we have gotten further into the compile of the OpenOffice software. We have moved past the external sources compile errors by using a newer version of Boost (1.49) and adding in the updates to the emplace_args.hpp file that have been posted on the web.
Speaking of newer boost versions please also see [1] (an enhancement issue I created to update to boost 1.55). I developed a patch to do that and added it there to do this. You might want to try it out.
[1] https://issues.apache.org/ooo/show_bug.cgi?id=123817
> However, we are now encountering a problem within the binaryurp in the bridge.cxx compile. The first error message is as follows:
>
> "../main/binaryurp/source/cache.hxx", line 113: Error: iterator is not a member of std::map<com:sun::star::uno::TypeDescription,binaryurp::Cache<com::sun::star::uno::TypeDescription>::Entry>.
>
> Looking at the code, it doesn't seem like an obvious error. The line it complains about is inside a struct Entry and the error occurs when defining a member variable named prev as a Map::iterator. We could use some insight into this problem and would appreciate any help. Thanks.
According to the C++ standard the compiler/STL is right to complain about that code: the Entry type is incomplete until the declaration is over and a Map iterator with Entry as its "mapped_type" can not be expected to work while Entry is being declared.
Some compiler/STL combinations allow it, but some don't. Especially the better ones (which don't treat all mapped_types the same but have optimized template specializations) run into problems here.
The good news is that I already developed a replacement for this problematic code to make it more compatible with standard complying compilers/STLs. Please try out the patch in [2]. I was about to merge this into trunk soon anyway, but if you could confirm that it solves the problem on your platform this would accelerate the integration.
[2] http://svn.apache.org/viewvc?view=revision&revision=1480367
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
For select1st, we noticed that the <functional> header delivered with stdcxx4 did not define select1st, but the aoo delivered <functional> located in systemstl/tr1 did. Our Makefile flags are set to include the stdcxx4 <functional> instead of the systemstl/tr1 <functional>. To get around this we modified namedvaluecollection.cxx:
#if defined(__SUNPRO_CC)
#include "../systemstl/tr1/functional"
#esle
#include <functional>
#endif
Let us know if you think there is a better way to address this.
Now we are on to figuring out why comphelper's having a linking error. It is trying to build libcomphelperC52.so, but it cannot find -lstlport_sunpro.
Raymond
-----Original Message-----
From: Steele, Raymond
Sent: Wednesday, December 11, 2013 8:49 AM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Herbert,
The changes [2] worked perfectly for us. Now we are having issues compiling ::std::select1st in namedvaluecollection.cxx on line 175. Apparently, select1st is not a member of std. It appears that you may have created a ticket for this one.
https://issues.apache.org/ooo/show_bug.cgi?id=123754
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Tuesday, December 10, 2013 11:25 PM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi David,
Hi Raymond,
On 11.12.2013 00:16, you wrote:
> Thanks for much of the help you have provided in this venture to help us get OpenOffice working in Solaris 11. Because of this we have gotten further into the compile of the OpenOffice software. We have moved past the external sources compile errors by using a newer version of Boost (1.49) and adding in the updates to the emplace_args.hpp file that have been posted on the web.
Speaking of newer boost versions please also see [1] (an enhancement issue I created to update to boost 1.55). I developed a patch to do that and added it there to do this. You might want to try it out.
[1] https://issues.apache.org/ooo/show_bug.cgi?id=123817
> However, we are now encountering a problem within the binaryurp in the bridge.cxx compile. The first error message is as follows:
>
> "../main/binaryurp/source/cache.hxx", line 113: Error: iterator is not a member of std::map<com:sun::star::uno::TypeDescription,binaryurp::Cache<com::sun::star::uno::TypeDescription>::Entry>.
>
> Looking at the code, it doesn't seem like an obvious error. The line it complains about is inside a struct Entry and the error occurs when defining a member variable named prev as a Map::iterator. We could use some insight into this problem and would appreciate any help. Thanks.
According to the C++ standard the compiler/STL is right to complain about that code: the Entry type is incomplete until the declaration is over and a Map iterator with Entry as its "mapped_type" can not be expected to work while Entry is being declared.
Some compiler/STL combinations allow it, but some don't. Especially the better ones (which don't treat all mapped_types the same but have optimized template specializations) run into problems here.
The good news is that I already developed a replacement for this problematic code to make it more compatible with standard complying compilers/STLs. Please try out the patch in [2]. I was about to merge this into trunk soon anyway, but if you could confirm that it solves the problem on your platform this would accelerate the integration.
[2] http://svn.apache.org/viewvc?view=revision&revision=1480367
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi David,
Hi Raymond,
On 11.12.2013 00:16, you wrote:
> Thanks for much of the help you have provided in this venture to help us get OpenOffice working in Solaris 11. Because of this we have gotten further into the compile of the OpenOffice software. We have moved past the external sources compile errors by using a newer version of Boost (1.49) and adding in the updates to the emplace_args.hpp file that have been posted on the web.
Speaking of newer boost versions please also see [1] (an enhancement
issue I created to update to boost 1.55). I developed a patch to do that
and added it there to do this. You might want to try it out.
[1] https://issues.apache.org/ooo/show_bug.cgi?id=123817
> However, we are now encountering a problem within the binaryurp in the bridge.cxx compile. The first error message is as follows:
>
> "../main/binaryurp/source/cache.hxx", line 113: Error: iterator is not a member of std::map<com:sun::star::uno::TypeDescription,binaryurp::Cache<com::sun::star::uno::TypeDescription>::Entry>.
>
> Looking at the code, it doesn't seem like an obvious error. The line it complains about is inside a struct Entry and the error occurs when defining a member variable named prev as a Map::iterator. We could use some insight into this problem and would appreciate any help. Thanks.
According to the C++ standard the compiler/STL is right to complain
about that code: the Entry type is incomplete until the declaration is
over and a Map iterator with Entry as its "mapped_type" can not be
expected to work while Entry is being declared.
Some compiler/STL combinations allow it, but some don't. Especially the
better ones (which don't treat all mapped_types the same but have
optimized template specializations) run into problems here.
The good news is that I already developed a replacement for this
problematic code to make it more compatible with standard complying
compilers/STLs. Please try out the patch in [2]. I was about to merge
this into trunk soon anyway, but if you could confirm that it solves the
problem on your platform this would accelerate the integration.
[2] http://svn.apache.org/viewvc?view=revision&revision=1480367
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert Duerr,
Thanks for much of the help you have provided in this venture to help us get OpenOffice working in Solaris 11. Because of this we have gotten further into the compile of the OpenOffice software. We have moved past the external sources compile errors by using a newer version of Boost (1.49) and adding in the updates to the emplace_args.hpp file that have been posted on the web.
However, we are now encountering a problem within the binaryurp in the bridge.cxx compile. The first error message is as follows:
"../main/binaryurp/source/cache.hxx", line 113: Error: iterator is not a member of std::map<com:sun::star::uno::TypeDescription,binaryurp::Cache<com::sun::star::uno::TypeDescription>::Entry>.
Looking at the code, it doesn't seem like an obvious error. The line it complains about is inside a struct Entry and the error occurs when defining a member variable named prev as a Map::iterator. We could use some insight into this problem and would appreciate any help. Thanks.
David Meffe
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Thursday, December 05, 2013 2:42 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
> Thanks Herbert. Do you have any idea why we would be receiving the following?
>
> Compiling: sal/rtl/source/unload.cxx
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199: Error:Could not find a match for boost::tuples::get<boost::tuples::N,boost::tuples::HT, boost::tuples::TT>(constboost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type>) needed inboost::unordered::detail::construct_from_tuple<configmgr::Partial::Node,boost::tuples::null_type>(configmgr::Partial::Node*, constboost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type>&).
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where: While instantiating"boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node,boost::tuples::null_type>(configmgr::Partial::Node*, constboost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type>&)".
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where: Instantiated from boost::unordered::unordered_map<rtl::OUString,configmgr::Partial::Node, boost::hash<rtl::OUString>,_STL::equal_to<rtl::OUString>, _STL::allocator<_STL::pair<const rtl::OUString,configmgr::Partial::Node>>>::operator[](const rtl::OUString&).
> "/opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx ", line 217: Where: Instantiated from non-template code.
Are you using the configure option --with-system-boost? If not, then the boost headers should be found in
.../main/solenv/*/unx*/inc/boost/
and not in
/usr/local/include/boost/
The top suspect for the actual problem you are seeing is a boost problem [1]. It was fixed in boost 1.49 with [2]. AOO is currently using boost
1.48 but problems such as this indicate that an update is overdue.
[1] https://svn.boost.org/trac/boost/ticket/6784
[2] https://svn.boost.org/trac/boost/changeset/77972
Could you try to apply the patch [2] to the problematic boost header to check whether this solves the problem? If yes, we could apply it to our local boost header with the patch mechanism. Or even better we could update our boost libs, but that would eventually open another can of worms...
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi Raymond,
> Thanks Herbert. Do you have any idea why we would be receiving the following?
>
> Compiling: sal/rtl/source/unload.cxx
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199: Error:Could not find a match for boost::tuples::get<boost::tuples::N,boost::tuples::HT, boost::tuples::TT>(constboost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type>) needed inboost::unordered::detail::construct_from_tuple<configmgr::Partial::Node,boost::tuples::null_type>(configmgr::Partial::Node*, constboost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type>&).
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where: While instantiating"boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node,boost::tuples::null_type>(configmgr::Partial::Node*, constboost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type>&)".
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where: Instantiated from boost::unordered::unordered_map<rtl::OUString,configmgr::Partial::Node, boost::hash<rtl::OUString>,_STL::equal_to<rtl::OUString>, _STL::allocator<_STL::pair<const rtl::OUString,configmgr::Partial::Node>>>::operator[](const rtl::OUString&).
> "/opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx ", line 217: Where: Instantiated from non-template code.
Are you using the configure option --with-system-boost? If not, then the
boost headers should be found in
.../main/solenv/*/unx*/inc/boost/
and not in
/usr/local/include/boost/
The top suspect for the actual problem you are seeing is a boost problem
[1]. It was fixed in boost 1.49 with [2]. AOO is currently using boost
1.48 but problems such as this indicate that an update is overdue.
[1] https://svn.boost.org/trac/boost/ticket/6784
[2] https://svn.boost.org/trac/boost/changeset/77972
Could you try to apply the patch [2] to the problematic boost header to
check whether this solves the problem? If yes, we could apply it to our
local boost header with the patch mechanism. Or even better we could
update our boost libs, but that would eventually open another can of
worms...
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Thanks Herbert. Do you have any idea why we would be receiving the following?
Compiling: sal/rtl/source/unload.cxx
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199: Error:Could not find a match for boost::tuples::get<boost::tuples::N,boost::tuples::HT, boost::tuples::TT>(constboost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type>) needed inboost::unordered::detail::construct_from_tuple<configmgr::Partial::Node,boost::tuples::null_type>(configmgr::Partial::Node*, constboost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type>&).
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where: While instantiating"boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node,boost::tuples::null_type>(configmgr::Partial::Node*, constboost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type>&)".
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where: Instantiated from boost::unordered::unordered_map<rtl::OUString,configmgr::Partial::Node, boost::hash<rtl::OUString>,_STL::equal_to<rtl::OUString>, _STL::allocator<_STL::pair<const rtl::OUString,configmgr::Partial::Node>>>::operator[](const rtl::OUString&).
"/opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx ", line 217: Where: Instantiated from non-template code.
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Wednesday, December 04, 2013 3:54 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond; Meffe, David K
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
> Just to give you an update.
>
> We were able compile debugbase.cxx by including
> /opt/solarisstudios12.3/prod/include/CC/stlport4
Ah, please don't. Stlport4 is dead.
> , but the next module wanted ../include/CC/Cstd. Then it went back and forth.
> There seems to be a disconnect between which C/C++ implementation it wants and > I do not think they are compatible with each other.
Yes, they are not compatible to each other.
> As of now, we've loaded the Apache C++ stdcxx4 implementation so that
> we can retry
> using just the one implementation. However, we've noticed that
stdcxx4 does not provide
> hash_map and hash_set, among others,
Indeed: hash_map and hash_set were replaced by unordered_map and unordered_set in the C++ standardization process. In our codebase we'll have to replace them but for now they are already mapped to their newer counterparts using wrappers in the main/stlport/systemstl/hash_* headers. Please make sure that you are using --without-stlport in your configure option so that this wrapping becomes active.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi Raymond,
> Just to give you an update.
>
> We were able compile debugbase.cxx by including /opt/solarisstudios12.3/prod/include/CC/stlport4
Ah, please don't. Stlport4 is dead.
> , but the next module wanted ../include/CC/Cstd. Then it went back and forth.
> There seems to be a disconnect between which C/C++ implementation it
wants and
> I do not think they are compatible with each other.
Yes, they are not compatible to each other.
> As of now, we've loaded the Apache C++ stdcxx4 implementation so that we can retry
> using just the one implementation. However, we've noticed that
stdcxx4 does not provide
> hash_map and hash_set, among others,
Indeed: hash_map and hash_set were replaced by unordered_map and
unordered_set in the C++ standardization process. In our codebase we'll
have to replace them but for now they are already mapped to their newer
counterparts using wrappers in the main/stlport/systemstl/hash_*
headers. Please make sure that you are using --without-stlport in your
configure option so that this wrapping becomes active.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
A small correction for my patch suggestion:
On 03.12.2013 11:36, Herbert Duerr wrote:
> [...]
> + DEBUGBASE_ENSURE( !bOK, "### insertion failed!?" );
The condition there was inverted. It should have been
DEBUGBASE_ENSURE( bOK, "### insertion failed!?" );
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi Raymond,
> Thanks for the information. Sorry about the PDF. Unfortunately, we are unable to do a simple copy and paste because of the way are system is setup. The only other option that I have is to type the output, but that would have taken much longer.
Ok. I just wanted to make sure that its not a simple oversight.
C++ template errors are often very extensive and look quite scary. If
the problem hides in a little type difference of the n-th argument of a
multi-layer template specialization, then finding these miniscule
differences is hard enough even with regexp magic or with specialized
tools ("template error message decryptors") such as STLFilt.
Without the error message text but just images of this text it becomes
much harder to diagnose a problem.
> We just implemented the patch, but are still receiving the same
output. We are investigating now.
This cannot possibly be! The original error output was that construction
of the "insertion" object failed because of type and constness
mismatches. With the patch there is no insertion object anymore, so
there error output cannot possibly be the same!
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
Thanks for the information. Sorry about the PDF. Unfortunately, we are unable to do a simple copy and paste because of the way are system is setup. The only other option that I have is to type the output, but that would have taken much longer. We just implemented the patch, but are still receiving the same output. We are investigating now.
Thanks,
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Tuesday, December 03, 2013 3:36 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 02.12.2013 23:34, Steele, Raymond wrote:
> Let me know if you did not get the attachment.
Attachments usually get stripped on the mailing list, but I got it because was on CC. As the PDF only contained scanned text a simple
copy+paste of that text would have been better.
> We are having trouble interpreting the boost preprocessor macros. We are receiving the following output when compiling sal/osl/all. I've attached the output as a pdf.
Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a
hand-crafted map::value_type and const correctness. Please try
this patch to make the construct more digestible:
--- main/sal/osl/all/debugbase.cxx
+++ main/sal/osl/all/debugbase.cxx
@@ -129,10 +129,9 @@ void SAL_CALL osl_detail_ObjectRegistry_registerObject(
{
if (rData.m_bStoreAddresses) {
osl::MutexGuard const guard(
osl_detail_ObjectRegistry_getMutex() );
- std::pair<osl::detail::VoidPointerSet::iterator, bool> const
insertion(
- rData.m_addresses.insert(pObj) );
- DEBUGBASE_ENSURE( insertion.second, "### insertion failed!?" );
- static_cast<void>(insertion);
+ const bool bOK = rData.m_addresses.insert(pObj).second;
+ DEBUGBASE_ENSURE( !bOK, "### insertion failed!?" );
+ (void)bOK; // unused for non-debug
}
else {
osl_incrementInterlockedCount(&rData.m_nCount);
Please report whether this helps, I'll commit the change then.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Kay Schenk <ka...@gmail.com>.
On Tue, Dec 3, 2013 at 3:09 PM, Steele, Raymond <ra...@lmco.com>wrote:
> Here is what we ended the day with after making the changes to the
> includes.
>
> Compiling: sal/rtl/source/unload.cxx
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199:
> Error:Could not find a match for
> boost::tuples::get<boost::tuples::N,boost::tuples::HT,
> boost::tuples::TT>(constboost::tuples::tuple<boost::tuples::null_type,
> boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type,
> boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type,
> boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type>) needed
> inboost::unordered::detail::construct_from_tuple<configmgr::Partial::Node,boost::tuples::null_type>(configmgr::Partial::Node*,
> constboost::tuples::tuple<boost::tuples::null_type,
> boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type,
> boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type,
> boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type>&).
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line
> 350:Where: While
> instantiating"boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node,boost::tuples::null_type>(configmgr::Partial::Node*,
> constboost::tuples::tuple<boost::tuples::null_type,
> boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type,
> boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type,
> boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type>&)".
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line
> 350:Where: Instantiated from
> boost::unordered::unordered_map<rtl::OUString,configmgr::Partial::Node,
> boost::hash<rtl::OUString>,_STL::equal_to<rtl::OUString>,
> _STL::allocator<_STL::pair<const
> rtl::OUString,configmgr::Partial::Node>>>::operator[](const rtl::OUString&).
> "/opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx ", line 217: Where:
> Instantiated from non-template code.
>
I'm following this progress as well, since I, too, am having many problems
with boost disconnects in this same area. I did NOT include any additional
libraires as you did, so I'm still stuck in sal. :/
>
> -----Original Message-----
> From: Steele, Raymond
> Sent: Tuesday, December 03, 2013 2:41 PM
> To: 'Herbert Duerr'; 'dev@openoffice.apache.org'
> Cc: Meffe, David K
> Subject: RE: EXTERNAL: Re: Building comphelper
>
> Just to give you an update.
>
> We were able compile debugbase.cxx by including
> /opt/solarisstudios12.3/prod/include/CC/stlport4, but the next module
> wanted ../include/CC/Cstd. Then it went back and forth. There seems to be
> a disconnect between which C/C++ implementation it wants and I do not think
> they are compatible with each other. As of now, we've loaded the Apache
> C++ stdcxx4 implementation so that we can retry using just the one
> implementation. However, we've noticed that stdcxx4 does not provide
> hash_map and hash_set, among others, so we included
> ../main/stlport/system1/ files. Hopefully, this will work for us. If you
> have any comments ideas, please let us know.
>
> Raymond
>
> -----Original Message-----
> From: Steele, Raymond
> Sent: Tuesday, December 03, 2013 9:22 AM
> To: 'Herbert Duerr'; dev@openoffice.apache.org
> Cc: Meffe, David K
> Subject: RE: EXTERNAL: Re: Building comphelper
>
> Herbert,
>
> Thanks for the information. Sorry about the PDF. Unfortunately, we are
> unable to do a simple copy and paste because of the way are system is
> setup. The only other option that I have is to type the output, but that
> would have taken much longer. We just implemented the patch, but are still
> receiving the same output. We are investigating now.
>
> Thanks,
>
> Raymond
>
> -----Original Message-----
> From: Herbert Duerr [mailto:hdu@apache.org]
> Sent: Tuesday, December 03, 2013 3:36 AM
> To: dev@openoffice.apache.org
> Cc: Meffe, David K; Steele, Raymond
> Subject: Re: EXTERNAL: Re: Building comphelper
>
> Hi Raymond,
>
> On 02.12.2013 23:34, Steele, Raymond wrote:
> > Let me know if you did not get the attachment.
>
> Attachments usually get stripped on the mailing list, but I got it because
> was on CC. As the PDF only contained scanned text a simple
> copy+paste of that text would have been better.
>
> > We are having trouble interpreting the boost preprocessor macros. We are
> receiving the following output when compiling sal/osl/all. I've attached
> the output as a pdf.
>
> Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a
> hand-crafted map::value_type and const correctness. Please try this patch
> to make the construct more digestible:
>
> --- main/sal/osl/all/debugbase.cxx
> +++ main/sal/osl/all/debugbase.cxx
> @@ -129,10 +129,9 @@ void SAL_CALL
> osl_detail_ObjectRegistry_registerObject(
> {
> if (rData.m_bStoreAddresses) {
> osl::MutexGuard const guard(
> osl_detail_ObjectRegistry_getMutex() );
> - std::pair<osl::detail::VoidPointerSet::iterator, bool> const
> insertion(
> - rData.m_addresses.insert(pObj) );
> - DEBUGBASE_ENSURE( insertion.second, "### insertion failed!?" );
> - static_cast<void>(insertion);
> + const bool bOK = rData.m_addresses.insert(pObj).second;
> + DEBUGBASE_ENSURE( !bOK, "### insertion failed!?" );
> + (void)bOK; // unused for non-debug
> }
> else {
> osl_incrementInterlockedCount(&rData.m_nCount);
>
>
> Please report whether this helps, I'll commit the change then.
>
> Herbert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Here is what we ended the day with after making the changes to the includes.
Compiling: sal/rtl/source/unload.cxx
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199: Error:Could not find a match for boost::tuples::get<boost::tuples::N,boost::tuples::HT, boost::tuples::TT>(constboost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type>) needed inboost::unordered::detail::construct_from_tuple<configmgr::Partial::Node,boost::tuples::null_type>(configmgr::Partial::Node*, constboost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type>&).
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where: While instantiating"boost::unordered::detail::construct_from_tuple<configmgr::Partial::Node,boost::tuples::null_type>(configmgr::Partial::Node*, constboost::tuples::tuple<boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type>&)".
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where: Instantiated from boost::unordered::unordered_map<rtl::OUString,configmgr::Partial::Node, boost::hash<rtl::OUString>,_STL::equal_to<rtl::OUString>, _STL::allocator<_STL::pair<const rtl::OUString,configmgr::Partial::Node>>>::operator[](const rtl::OUString&).
"/opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx ", line 217: Where: Instantiated from non-template code.
-----Original Message-----
From: Steele, Raymond
Sent: Tuesday, December 03, 2013 2:41 PM
To: 'Herbert Duerr'; 'dev@openoffice.apache.org'
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Just to give you an update.
We were able compile debugbase.cxx by including /opt/solarisstudios12.3/prod/include/CC/stlport4, but the next module wanted ../include/CC/Cstd. Then it went back and forth. There seems to be a disconnect between which C/C++ implementation it wants and I do not think they are compatible with each other. As of now, we've loaded the Apache C++ stdcxx4 implementation so that we can retry using just the one implementation. However, we've noticed that stdcxx4 does not provide hash_map and hash_set, among others, so we included ../main/stlport/system1/ files. Hopefully, this will work for us. If you have any comments ideas, please let us know.
Raymond
-----Original Message-----
From: Steele, Raymond
Sent: Tuesday, December 03, 2013 9:22 AM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Herbert,
Thanks for the information. Sorry about the PDF. Unfortunately, we are unable to do a simple copy and paste because of the way are system is setup. The only other option that I have is to type the output, but that would have taken much longer. We just implemented the patch, but are still receiving the same output. We are investigating now.
Thanks,
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Tuesday, December 03, 2013 3:36 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 02.12.2013 23:34, Steele, Raymond wrote:
> Let me know if you did not get the attachment.
Attachments usually get stripped on the mailing list, but I got it because was on CC. As the PDF only contained scanned text a simple
copy+paste of that text would have been better.
> We are having trouble interpreting the boost preprocessor macros. We are receiving the following output when compiling sal/osl/all. I've attached the output as a pdf.
Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a hand-crafted map::value_type and const correctness. Please try this patch to make the construct more digestible:
--- main/sal/osl/all/debugbase.cxx
+++ main/sal/osl/all/debugbase.cxx
@@ -129,10 +129,9 @@ void SAL_CALL osl_detail_ObjectRegistry_registerObject(
{
if (rData.m_bStoreAddresses) {
osl::MutexGuard const guard(
osl_detail_ObjectRegistry_getMutex() );
- std::pair<osl::detail::VoidPointerSet::iterator, bool> const
insertion(
- rData.m_addresses.insert(pObj) );
- DEBUGBASE_ENSURE( insertion.second, "### insertion failed!?" );
- static_cast<void>(insertion);
+ const bool bOK = rData.m_addresses.insert(pObj).second;
+ DEBUGBASE_ENSURE( !bOK, "### insertion failed!?" );
+ (void)bOK; // unused for non-debug
}
else {
osl_incrementInterlockedCount(&rData.m_nCount);
Please report whether this helps, I'll commit the change then.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Just to give you an update.
We were able compile debugbase.cxx by including /opt/solarisstudios12.3/prod/include/CC/stlport4, but the next module wanted ../include/CC/Cstd. Then it went back and forth. There seems to be a disconnect between which C/C++ implementation it wants and I do not think they are compatible with each other. As of now, we've loaded the Apache C++ stdcxx4 implementation so that we can retry using just the one implementation. However, we've noticed that stdcxx4 does not provide hash_map and hash_set, among others, so we included ../main/stlport/system1/ files. Hopefully, this will work for us. If you have any comments ideas, please let us know.
Raymond
-----Original Message-----
From: Steele, Raymond
Sent: Tuesday, December 03, 2013 9:22 AM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Herbert,
Thanks for the information. Sorry about the PDF. Unfortunately, we are unable to do a simple copy and paste because of the way are system is setup. The only other option that I have is to type the output, but that would have taken much longer. We just implemented the patch, but are still receiving the same output. We are investigating now.
Thanks,
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Tuesday, December 03, 2013 3:36 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 02.12.2013 23:34, Steele, Raymond wrote:
> Let me know if you did not get the attachment.
Attachments usually get stripped on the mailing list, but I got it because was on CC. As the PDF only contained scanned text a simple
copy+paste of that text would have been better.
> We are having trouble interpreting the boost preprocessor macros. We are receiving the following output when compiling sal/osl/all. I've attached the output as a pdf.
Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a hand-crafted map::value_type and const correctness. Please try this patch to make the construct more digestible:
--- main/sal/osl/all/debugbase.cxx
+++ main/sal/osl/all/debugbase.cxx
@@ -129,10 +129,9 @@ void SAL_CALL osl_detail_ObjectRegistry_registerObject(
{
if (rData.m_bStoreAddresses) {
osl::MutexGuard const guard(
osl_detail_ObjectRegistry_getMutex() );
- std::pair<osl::detail::VoidPointerSet::iterator, bool> const
insertion(
- rData.m_addresses.insert(pObj) );
- DEBUGBASE_ENSURE( insertion.second, "### insertion failed!?" );
- static_cast<void>(insertion);
+ const bool bOK = rData.m_addresses.insert(pObj).second;
+ DEBUGBASE_ENSURE( !bOK, "### insertion failed!?" );
+ (void)bOK; // unused for non-debug
}
else {
osl_incrementInterlockedCount(&rData.m_nCount);
Please report whether this helps, I'll commit the change then.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi Raymond,
On 02.12.2013 23:34, Steele, Raymond wrote:
> Let me know if you did not get the attachment.
Attachments usually get stripped on the mailing list, but I got it
because was on CC. As the PDF only contained scanned text a simple
copy+paste of that text would have been better.
> We are having trouble interpreting the boost preprocessor macros. We are receiving the following output when compiling sal/osl/all. I've attached the output as a pdf.
Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a
hand-crafted map::value_type and const correctness. Please try
this patch to make the construct more digestible:
--- main/sal/osl/all/debugbase.cxx
+++ main/sal/osl/all/debugbase.cxx
@@ -129,10 +129,9 @@ void SAL_CALL osl_detail_ObjectRegistry_registerObject(
{
if (rData.m_bStoreAddresses) {
osl::MutexGuard const guard(
osl_detail_ObjectRegistry_getMutex() );
- std::pair<osl::detail::VoidPointerSet::iterator, bool> const
insertion(
- rData.m_addresses.insert(pObj) );
- DEBUGBASE_ENSURE( insertion.second, "### insertion failed!?" );
- static_cast<void>(insertion);
+ const bool bOK = rData.m_addresses.insert(pObj).second;
+ DEBUGBASE_ENSURE( !bOK, "### insertion failed!?" );
+ (void)bOK; // unused for non-debug
}
else {
osl_incrementInterlockedCount(&rData.m_nCount);
Please report whether this helps, I'll commit the change then.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by "Keith N. McKenna" <ke...@comcast.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Steele, Raymond wrote:
> Herbert,
>
> Let me know if you did not get the attachment.
>
> -----Original Message----- From: Steele, Raymond Sent: Monday,
> December 02, 2013 3:29 PM To: 'Herbert Duerr';
> dev@openoffice.apache.org Cc: Meffe, David K Subject: RE: EXTERNAL:
> Re: Building comphelper
>
> Herbert,
>
> We are having trouble interpreting the boost preprocessor macros.
> We are receiving the following output when compiling sal/osl/all.
> I've attached the output as a pdf.
>
> Raymond
>
>
> -----Original Message----- From: Herbert Duerr
> [mailto:hdu@apache.org] Sent: Friday, November 22, 2013 2:14 AM To:
> dev@openoffice.apache.org Cc: Steele, Raymond; Meffe, David K
> Subject: Re: EXTERNAL: Re: Building comphelper
>
> Hi Raymond,
>
> On 21.11.2013 22:27, Steele, Raymond wrote:
>> Forget about my last report. We started over and figured out that
>> an environment variable was causing the dmake issues. Once we
>> cleared the environment of variables related to our other
>> projects, the build took off. We will have to figure out what it
>> was later.
>
> Thanks for debugging and solving that problem!
>
> The current way of configure writing a file for setting
> environments variables is too fragile. As can be seen in your
> example if configure is run in an environment that is already
> "contaminated" with such env vars then unnecessary causes of
> troubles exist.
>
> IMHO build and config settings should be done via e.g.
> Makefile.config that should be created by configure. This config
> result should then be included by the other Makefiles.
>
> So if in doubt better use a fresh shell before running configure.
>
> Herbert
>
Raymond;
The list strips most attachments. The best method to share would be to
put it on-line with a link to it in separate reply to the list.
Regards
Keith
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSnTeqAAoJEH0fu5UhGmBCL1IH/jfVz8UYC6Z5FEHqN6NYlDHa
27Jpcc2QPWk20CA5Wb7Psj7W6EWPrAOCx5lBTNlDiMojxUYjswCBMP09kA4BiyCE
fYZXK1tiLzbs2/YlYvNjf7RCWfE//dIpXMAoe0L17bSIR7dEPFD8b9ItrebD780e
/wa6FN0DRVZ4PbzWXm3opKoDMwIvrjofTIffRvz3WJoJO364iY7S09NSGI6cyc7Z
s+TdM/tcJpw0tr2XozgDPJGcReY2C2gechiZ5ox1YDHqXMjuk9MOR8xqcijLnTys
rqL+SzIovTgBfb/IhAQARCq774B5vn4vM8qk7A9yrhugvCQ4MhP89qbmTjerZY8=
=RfR3
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
Let me know if you did not get the attachment.
-----Original Message-----
From: Steele, Raymond
Sent: Monday, December 02, 2013 3:29 PM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Herbert,
We are having trouble interpreting the boost preprocessor macros. We are receiving the following output when compiling sal/osl/all. I've attached the output as a pdf.
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Friday, November 22, 2013 2:14 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond; Meffe, David K
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 21.11.2013 22:27, Steele, Raymond wrote:
> Forget about my last report. We started over and figured out that an environment variable was causing the dmake issues. Once we cleared the environment of variables related to our other projects, the build took off. We will have to figure out what it was later.
Thanks for debugging and solving that problem!
The current way of configure writing a file for setting environments variables is too fragile. As can be seen in your example if configure is run in an environment that is already "contaminated" with such env vars then unnecessary causes of troubles exist.
IMHO build and config settings should be done via e.g. Makefile.config that should be created by configure. This config result should then be included by the other Makefiles.
So if in doubt better use a fresh shell before running configure.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi Raymond,
On 21.11.2013 22:27, Steele, Raymond wrote:
> Forget about my last report. We started over and figured out that an environment variable was causing the dmake issues. Once we cleared the environment of variables related to our other projects, the build took off. We will have to figure out what it was later.
Thanks for debugging and solving that problem!
The current way of configure writing a file for setting environments
variables is too fragile. As can be seen in your example if configure is
run in an environment that is already "contaminated" with such env vars
then unnecessary causes of troubles exist.
IMHO build and config settings should be done via e.g. Makefile.config
that should be created by configure. This config result should then be
included by the other Makefiles.
So if in doubt better use a fresh shell before running configure.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
-----Original Message-----
From: Steele, Raymond
Sent: Wednesday, November 20, 2013 4:57 PM
To: 'Herbert Duerr'
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Thanks,
We've run into some errors with dmake and are trying to understand it. First, the startup.mk and makefile.mk could not find settings.mk and some others that are located in solenv/inc even though dmake -v seems to be looking there. We created a link of all the files in solenv/inc to solenv where makefile.mk is to overcome the problem. Although this does not seem to be a good solution.
Then dmake could not find seem to find minor.mk. For example, on line 1665 in target.mk we have the following:
ALLTAR: \
"$(SOLARVERSION)/$(INPATH)/inc$/$(UPDMINOREXT)/$(UPD)minor.mk"
This would be interpreted by dmake as '//inc/minor.mk' as if the variables were not expanded. If I hardcode the full path to minor.mk , then dmake is fine.
I eventually got past building solenv by performing the above hacks. I have a feeling I should not have to do that stuff.
Now, building 'afms', dmake complains that "SHELL could not find macro" on line 64. I think it has to do with the function macro 'find', but I am not sure.
Any help would be great!!
Thanks,
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Wednesday, November 20, 2013 1:02 AM
To: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
> I just wanted to give you a heads up that I am beginning to start work on compiling for Solaris 11 x86. Hopefully, you will be able to assist if needed.
Thanks for the heads up! I'm looking forward to this and will try to help.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
Forget about my last report. We started over and figured out that an environment variable was causing the dmake issues. Once we cleared the environment of variables related to our other projects, the build took off. We will have to figure out what it was later.
-----Original Message-----
From: Steele, Raymond
Sent: Thursday, November 21, 2013 9:28 AM
To: 'Herbert Duerr'
Cc: dev@openoffice.apache.org
Subject: RE: EXTERNAL: Re: Building comphelper
-----Original Message-----
From: Steele, Raymond
Sent: Wednesday, November 20, 2013 4:57 PM
To: 'Herbert Duerr'
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Thanks,
We've run into some errors with dmake and are trying to understand it. First, the startup.mk and makefile.mk could not find settings.mk and some others that are located in solenv/inc even though dmake -v seems to be looking there. We created a link of all the files in solenv/inc to solenv where makefile.mk is to overcome the problem. Although this does not seem to be a good solution.
Then dmake could not find seem to find minor.mk. For example, on line 1665 in target.mk we have the following:
ALLTAR: \
"$(SOLARVERSION)/$(INPATH)/inc$/$(UPDMINOREXT)/$(UPD)minor.mk"
This would be interpreted by dmake as '//inc/minor.mk' as if the variables were not expanded. If I hardcode the full path to minor.mk , then dmake is fine.
I eventually got past building solenv by performing the above hacks. I have a feeling I should not have to do that stuff.
Now, building 'afms', dmake complains that "SHELL could not find macro" on line 64. I think it has to do with the function macro 'find', but I am not sure.
Any help would be great!!
Thanks,
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Wednesday, November 20, 2013 1:02 AM
To: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
> I just wanted to give you a heads up that I am beginning to start work on compiling for Solaris 11 x86. Hopefully, you will be able to assist if needed.
Thanks for the heads up! I'm looking forward to this and will try to help.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi Raymond,
On 20.09.2013 19:52, Steele, Raymond wrote:
> No problems on the delay. I am very greatful for your assistance!!
>
> Here is my compiler command and below are locations of my utility file. Hopefully this may help. I added utility to the include path, but still no luck.
>
> bash-3.2# /opt/solarisstudio12.3/bin/CC -c -temp=/tmp -xarch=generic -xO3 -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -D_FILE_OFFSET_BITS=64 -I. -I../../unxsoli4.pro/inc/oslall -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/externa l -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/unx soli4.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/rasqal -I/usr/include/stdcxx4 -I/opt/aoo-4.0.0/main/stlport/systemstl/: -I/usr/local/include -I/usr/include -I/usr/local/i nclude/rasqal -I/usr/include/stdcxx4 -I/opt/a
oo-4.0.0/main/stlport/systemstl/: -I/usr/local/include -I/usr/include -I/usr/local/inclue/rasqal -I/opt/aoo-4.0.0/main/stlport/systemstl/ -I/opt /solarisstudio12.3/prod/include/CC/Cstd/ -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/offuh -I. -I../../res -I. -features=no%altspell "-features=rvalueref" +w2 -erroff=doubunder,ident expected,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 -DEXCEPTIONS_ON -o . ./../unxsoli4.pro/obj/debugbase.o /opt/aoo-4.0.0/main/sal/osl/all/debugbase.cxx
> "/usr/local/include/boost/tr1/detail/config_all.hpp", line 161: Error: Could not open include file<../include/utility>.
>
> [...]
> /usr/include/stdcxx4/utility
> [...]
> /opt/solarisstudio12.3/prod/include/CC/Cstd/utility
I think one of these two header files is the one we are looking for.
Boost is using the "relative include path" trick with its
BOOST_TR1_STD_HEADER() macro because the neat "include_next" extension
is not supported in the solaris compiler.
One of the BOOST_TR1_STD_HEADER defines in config_all.hpp is looking for
the stdcxx4 path. I wonder why it isn't picked up. Either
1. one of the defines is wrong (__SUNPRO_CC,__STD_RWCOMPILER_H,
___RWSTD_VER) or boost erroneously doesn't pick it up
2. the -I/opt/solarisstudio12.3/prod/include/CC/Cstd/ part of the
compile options should be changed to find /usr/include/stdcxx4/ instead
3. the BOOST_TR1_STD_HEADER define should be changed to "../Cstd/"
Which of the alternatives 2. or 3. is better depends on which of both
STL header sets better implements C++'s std templates as defined in TR1.
From the name I'd guess the Cstd one is better.
> /opt/solarisstudio12.3/prod/include/CC/stlport4/utility
>
> I found this about Solaris 11, but the fix appears to be included in boost version 1_48 (Mine is attached).
>
> https://svn.boost.org/trac/boost/ticket/5111
Interesting. Maybe the above and this are related.
Hope that helps. Have a nice weekend!
Herbert
(about to upload AOO401rc3 to the snapshot page)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
No problems on the delay. I am very greatful for your assistance!!
Here is my compiler command and below are locations of my utility file. Hopefully this may help. I added utility to the include path, but still no luck.
bash-3.2# /opt/solarisstudio12.3/bin/CC -c -temp=/tmp -xarch=generic -xO3 -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -D_FILE_OFFSET_BITS=64 -I. -I../../unxsoli4.pro/inc/oslall -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/externa l -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/unx soli4.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/rasqal -I/usr/include/stdcxx4 -I/opt/aoo-4.0.0/main/stlport/systemstl/: -I/usr/local/include -I/usr/include -I/usr/local/i nclude/rasqal -I/usr/include/stdcxx4 -I/opt/aoo-4.0.0/main/stlport/systemstl/: -I/usr/local/include -I/usr/include -I/usr/local/inclue/rasqal -I/opt/aoo-4.0.0/main/stlport/systemstl/ -I/opt /solarisstudio12.3/prod/include/CC/Cstd/ -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/offuh -I. -I../../res -I. -features=no%altspell "-features=rvalueref" +w2 -erroff=doubunder,ident expected,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 -DEXCEPTIONS_ON -o . ./../unxsoli4.pro/obj/debugbase.o /opt/aoo-4.0.0/main/sal/osl/all/debugbase.cxx
"/usr/local/include/boost/tr1/detail/config_all.hpp", line 161: Error: Could not open include file<../include/utility>.
/usr/sfw/include/c++/3.4.3/utility
/usr/include/stdcxx4/utility
/usr/local/include/boost/tr1/tr1/utility
/usr/local/include/boost/spirit/home/classic/utility
/usr/local/include/boost/spirit/utility
/usr/local/include/boost/utility
/usr/local/include/boost/xpressive/detail/utility
/usr/local/gcc-4.8.1/include/c++/4.8.1/tr1/utility
/usr/local/gcc-4.8.1/include/c++/4.8.1/utility
/export/home/aoo-4.0.0/main/i18nutil/source/utility
/opt/aoo-4.0.0/main/i18nutil/source/utility
/opt/aoo-4.0.0/main/vigra/unxsoli4.pro/misc/build/vigra1.6.0/include/IRIX/utility
/opt/aoo-4.0.0/ext_sources/boost_1_48_0/boost/tr1/tr1/utility
/opt/aoo-4.0.0/ext_sources/boost_1_48_0/boost/spirit/home/classic/utility
/opt/aoo-4.0.0/ext_sources/boost_1_48_0/boost/spirit/utility
/opt/aoo-4.0.0/ext_sources/boost_1_48_0/boost/utility
/opt/aoo-4.0.0/ext_sources/boost_1_48_0/boost/xpressive/detail/utility
/opt/aoo-4.0.0/ext_sources/boost_1_48_0/libs/utility
/opt/solarisstudio12.3/prod/include/CC/Cstd/utility
/opt/solarisstudio12.3/prod/include/CC/stlport4/utility
I found this about Solaris 11, but the fix appears to be included in boost version 1_48 (Mine is attached).
https://svn.boost.org/trac/boost/ticket/5111
________________________________________
From: Herbert Duerr [hdu@apache.org]
Sent: Friday, September 20, 2013 8:53 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
> I found hash_set in ../main/stlport/systemstl
>
> Is that where it is supposed to be.
Yes.
> Once, I added this to my SOLARINC and SOLARINV environment variables, everything was okay, but then I received a
>
> "/usr/local/include/boost/tr1/detail/config_all.hpp", line 161: Error: Could not open include file<../include/utility>
The <utility> header should come somewhere from your c++ compiler
includes. According to [1] it should be there somewhere. If it is not
found we need to put its path at the end of the include paths.
[1] http://docs.oracle.com/cd/E19205-01/819-5267/bkajw/index.html
Sorry for the late answer. I was busy with AOO401rc3.
Herbert
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi Raymond,
> I found hash_set in ../main/stlport/systemstl
>
> Is that where it is supposed to be.
Yes.
> Once, I added this to my SOLARINC and SOLARINV environment variables, everything was okay, but then I received a
>
> "/usr/local/include/boost/tr1/detail/config_all.hpp", line 161: Error: Could not open include file<../include/utility>
The <utility> header should come somewhere from your c++ compiler
includes. According to [1] it should be there somewhere. If it is not
found we need to put its path at the end of the include paths.
[1] http://docs.oracle.com/cd/E19205-01/819-5267/bkajw/index.html
Sorry for the late answer. I was busy with AOO401rc3.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
I found hash_set in ../main/stlport/systemstl
Is that where it is supposed to be. Once, I added this to my SOLARINC and SOLARINV environment variables, everything was okay, but then I received a
"/usr/local/include/boost/tr1/detail/config_all.hpp", line 161: Error: Could not open include file<../include/utility>
________________________________________
From: Herbert Dürr [hdu@apache.org]
Sent: Wednesday, September 18, 2013 3:44 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 16.09.2013 22:04, Steele, Raymond wrote:
> I was wrong I thought the I set the --without-stlport flag, but did not. I just set it and reconfigured. Now I am receiving this.
>
> Entering /opt/aoo-4.0.0/main/sal/rtl/source
>
> --- ALWAYSDBGFILES ---
> --- ALWAYSDBGFILES OVER ---
> Compiling: sal/rtl/source/hash.cxx
> "/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 32: Error: Could not open include file<hash_set>.
This missing file (hash_set) should be in
main/solver/400/unxsoli4.pro/inc/stl/
as soon as the module main/stlport was built. What are the include paths
(the "-Ixxx" options) for hash.cxx when when you build with the
"verbose=true" build option?
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Dürr <hd...@apache.org>.
Hi Raymond,
On 16.09.2013 22:04, Steele, Raymond wrote:
> I was wrong I thought the I set the --without-stlport flag, but did not. I just set it and reconfigured. Now I am receiving this.
>
> Entering /opt/aoo-4.0.0/main/sal/rtl/source
>
> --- ALWAYSDBGFILES ---
> --- ALWAYSDBGFILES OVER ---
> Compiling: sal/rtl/source/hash.cxx
> "/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 32: Error: Could not open include file<hash_set>.
This missing file (hash_set) should be in
main/solver/400/unxsoli4.pro/inc/stl/
as soon as the module main/stlport was built. What are the include paths
(the "-Ixxx" options) for hash.cxx when when you build with the
"verbose=true" build option?
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
I was wrong I thought the I set the --without-stlport flag, but did not. I just set it and reconfigured. Now I am receiving this.
Entering /opt/aoo-4.0.0/main/sal/rtl/source
--- ALWAYSDBGFILES ---
--- ALWAYSDBGFILES OVER ---
Compiling: sal/rtl/source/hash.cxx
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 32: Error: Could not open include file<hash_set>.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 56: Error: hash_set is not a member of std.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 56: Error: A declaration does not specify a tag or an identifier.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 56: Error: Use ";" to terminate declarations.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 56: Error: A declaration was expected instead of "<".
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 56: Error: There must be an identifier to declare.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 59: Warning: Implicit int is not supported in C++.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 59: Error: "," expected instead of "*".
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 63: Error: A declaration was expected instead of "if".
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 63: Error: No direct declarator preceding "(".
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 65: Warning: Implicit int is not supported in C++.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 65: Error: Multiple declaration for pInternPool.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 65: Error: aImpl is not defined.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 67: Error: A declaration was expected instead of "return".
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 67: Warning: Implicit int is not supported in C++.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 68: Error: A declaration was expected instead of "}".
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 70: Error: A declaration was expected instead of "}".
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 78: Error: pHash is not defined.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 78: Error: The function "getHashTable" must have a prototype.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 79: Error: StringHashTable is not defined.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 79: Error: iterator is not defined.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 79: Error: aIter is not defined.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 79: Error: Badly formed expression.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 80: Error: aIter is not defined.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 80: Error: pHash is not defined.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 81: Error: aIter is not defined.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 81: Error: pHash is not defined.
"/opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx", line 83: Error: aIter is not defined.
Compilation aborted, too many Error messages.
dmake: Error code 2, while making '../../unxsoli4.pro/obj/hash.obj'
1 module(s):
sal
need(s) to be rebuilt
Reason(s):
ERROR: error 65280 occurred while making /opt/aoo-4.0.0/main/sal/rtl/source
When you have fixed the errors in that module you can resume the build by running:
build --all:sal
Also, here is my configuration and env.
#!/bin/bash
export ANT_HOME=/usr/local/ant/
export JAVA_HOME=/usr/jdk/latest
export PATH=$ANT_HOME:/usr/local/ant/bin/:/usr/local/bin:/usr/local/include:/opt/solarisstudio12.3/bin:/usr/sfw/bin:/usr/xpg4/bin:/usr/ccs/bin/:/usr/sbin:/usr/bin:/usr/dt/bin:/usr/openwin/bin:/usr/ucb:/usr/local/sbin:/usr/local/ssl:/opt/aoo-4.0.0/main/solenv/bin/
export M4=/usr/local/bin/m4
export LD_LIBRARY_PATH=$LD_LIBRAY_PATH:/usr/lib:$ANT_HOME/lib:/opt/solarisstudio12.3/lib:/usr/jdk/instances/jdk1.7.0/jre/lib/i386/client:/usr/sfw/lib/
export CC=/opt/solarisstudio12.3/bin/cc
export CXX=/opt/solarisstudio12.3/bin/CC
export CXXFLAGS="-I/usr/local/include -I/usr/include -I/opt/solarisstudio12.3/prod/include/CC/Cstd -I/usr/local/include/rasqal -I-I/usr/local/include/mdds"
export APR_LIBS=/usr/local/apr/lib
export APR_CFLAGS=/usr/local/apr/include/
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/apr/lib/pkgconfig/:/usr/local/lib/pkgconfig/:/usr/local/serf/lib/pkgconfig/:/usr/local/share/pkgconfig
export REDLAND_LIBS=/usr/local/lib/
export REDLAND_CFLAGS=/usr/local/include
export HUNSPELL_LIBS=/usr/local/lib/
export HUNSPELL_CFLAGS=/usr/local/include/hunspell
export SERF_LIBS=/usr/local/serf/lib
export SERF_CFLAGS=/usr/local/serf/include
export SOLARINV=$SOLARINV:" -I/usr/local/include -I/usr/include -I/usr/local/include/rasqal -I/usr/include/stdcxx4"
export SOLARINC=$SOLARINC:" -I/usr/local/include -I/usr/include -I/usr/local/include/rasqal -I/usr/include/stdcxx4"
#!/bin/bash
./configure \
--includedir=/usr/local/include \
--oldincludedir=/usr/local/include \
--with-dmake-path="/usr/local/bin/dmake" \
--with-epm-url=http://www.msweet.org/files/project2/epm-3.7-source.tar.gz \
--with-gnu-patch=/usr/bin/gpatch \
--with-gnu-cp=/usr/local/bin/cp \
--with-gperf=/usr/local/bin/gperf \
--with-system-serf \
--with-system-zlib \
--with-system-openssl \
--with-system-jpeg \
--with-system-libxml \
--with-system-python \
--with-system-icu \
--with-system-poppler \
--with-system-lucene \
--with-lucene-core-jar=/usr/local/lib/lucene-core-2.9.4.jar \
--with-lucene-analyzers-jar=/usr/local/lib/lucene-analyzers-2.9.4.jar \
--with-commons-codec-jar=/usr/local/lib/commons-codec-1.8.jar \
--with-commons-lang-jar=/usr/local/lib/commons-lang3-3.1.jar \
--with-commons-httpclient-jar=/usr/local/lib/httpclient-4.2.5.jar \
--with-commons-logging-jar=/usr/local/lib/commons-logging-1.1.3.jar \
--with-system-mysql \
--with-system-mysql-cppconn \
--with-system-hsqldb \
--with-hsqldb-jar=/usr/local/lib/hsqldb.jar \
--with-system-libxslt \
--with-system-curl \
--with-system-mythes \
--with-system-cppunit \
--with-system-redland \
--with-system-boost \
--without-stlport \
--with-system-apr \
--with-system-apr-util \
--with-system-apache-commons \
--with-system-cairo \
--disable-cups \
--with-jdk-home=/usr/jdk/latest/ \
--with-ant-home=/usr/local/ant/bin/ant \
--with-system-openssl=/usr/sfw/bin/openssl \
--with-junit=/usr/local/java/lib/junit-4.11.jar \
--disable-Xaw \
--disable-randr \
--disable-report-builder \
--disable-mozilla \
--disable-systray \
--disable-category-b \
--enable-pdfimport \
--enable-wiki-publisher \
--with-lang="en" \
--with-dict=ALL \
--with-package-format="installed"
________________________________________
From: Steele, Raymond
Sent: Monday, September 16, 2013 11:40 AM
To: Herbert Duerr; dev@openoffice.apache.org
Subject: RE: EXTERNAL: Re: Building comphelper
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 [hdu@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
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 [hdu@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
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 [hdu@apache.org]
Sent: Wednesday, September 11, 2013 7:02 AM
To: dev@openoffice.apache.org
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: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
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: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
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.
bash-3.2# make
mkdir -p /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/workdir/Dep/CxxObject/comphelper/source/misc/ && echo '/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/workdir/CxxObject/comphelper/source/misc/scopeguard.o : $(gb_Helper_PHONY)' > /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/workdir/Dep/CxxObject/comphelper/source/misc/scopeguard.d
[ build DEP ] LNK:Library/libcomphelpC52.so
R=/opt/aoo-4.0.0 && S=$R/main && O=$S/solver/400/unxsoli4.pro && W=$O/workdir && mkdir -p $W/Dep/LinkTarget/Library/ && RESPONSEFILE=/tmp/gbuild.roTO8o && cat ${RESPONSEFILE} /dev/null | xargs -n 200 cat > $W/Dep/LinkTarget/Library/libcomphelpC52.so.d && rm -f ${RESPONSEFILE}
[ build CXX ] comphelper/source/misc/scopeguard
R=/opt/aoo-4.0.0 && S=$R/main && O=$S/solver/400/unxsoli4.pro && W=$O/workdir && mkdir -p $W/CxxObject/comphelper/source/misc/ && mkdir -p $W/Dep/CxxObject/comphelper/source/misc/ && /opt/solarisstudio12.3/bin/CC -DC52 -DCPPU_ENV=sunpro5 -DCUI -DENABLE_GTK -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -DINTEL -DNDEBUG -DOPTIMIZE -DOSL_DEBUG_LEVEL=0 -DPRODUCT -DPRODUCT_FULL -DSOLARIS -DSOLAR_JAVA -DSTLPORT_VERSION=400 -DSUN -DSUN4 -DSUPD=400 -DSYSV -DUNIX -DUNX -DVCL -D_POSIX_PTHREAD_SEMANTICS -D_PTHREADS -D_REENTRANT -DCOMPHELPER_DLLIMPLEMENTATION -DUNX -temp=/tmp -KPIC -mt -xldscope=hidden -features=no%altspell -library=no%Cstd +w2 -erroff=doubunder,identexpected,inllargeuse,inllargeint,notemsource,reftotemp,truncwarn,wnoretvalue,anonnotype -DEXCEPTIONS_ON -xarch=generic -xO3 -c $S/comphelper/source/misc/scopeguard.cxx -o $W/CxxObject/comphelper/source/misc/scopeguard.o -xMMD -xMF $W/Dep/CxxObject/comphelper/source/misc/scopeguard.d -I$S/comphelper/source/misc/ -I$O/inc/stl -I$O/inc/stl -I$S/comphelper/inc/pch -I$S/comphelper/source/inc -I$O/inc/external -I$O/inc -I$S/solenv/unxsoli4/inc -I$S/solenv/inc -I$S/res -I/opt/solarisstudio12.3/include -I$S/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$O/inc/offuh
"/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.
3 Error(s) detected.
make: *** [/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/workdir/CxxObject/comphelper/source/misc/scopeguard.o] Error 2
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
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?
///////////////////////////////////////////////////////////
// //
// Sun C++ ??? //
// //
///////////////////////////////////////////////////////////
-#if defined(__sun) && !defined(__GNUC__)
- #define VIGRA_HAS_ERF
-#endif // __sun
+#if 0 // #i123228# let vigra provide the erf() function
+#if defined(__sun) && !defined(__GNUC__)
+ #define VIGRA_HAS_ERF
+ #endif // __sun
+#endif
________________________________________
From: Herbert Duerr [hdu@apache.org]
Sent: Tuesday, September 10, 2013 4:29 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 09.09.2013 19:13, Steele, Raymond wrote:
> Thanks for the information. I attached the new mathconf.h file with your
> patch. I then did a clean build and it compiles without error.
Good. I created an issue ("Adaptions for building AOO 4.0.0 on Solaris")
for all such adaptions that we'll find. I already attached the patch for
mathconf.h there.
[1] https://issues.apache.org/ooo/show_bug.cgi?id=123228
> I am
> not sure about what you'd like me to provide when you say , " Of course
> it would also interesting to know what type
> ::std::numeric_limits<unsigned char>::digits on that platform." Could
> you provide more details? Thanks.
In your platform's <limits> include file there are probably
specializations for numeric_limits template. The symptoms of the error
message look as if there was no template specialization for
numeric_limits<unsigned char>. Is this so? Please check the <limits>
include file. In case you are using gcc then you could use the "-E"
option to see the preprocessed source (with the <limits> file included).
Another trick is to create a line
struct Dummy{} dummy = ::std::numeric_limits<unsigned char>::digits;
in one of the functions and when compiling there will be an error
message about an invalid assignment that hopefully provides enough
detail about the type of this digits member.
> Also,
>
> I've found a couple other things that you may be interested in.
Sure. I suggest to collect these findings in the newly created task
123228 I referenced above [1].
> 1. The generated bootstrap script will not execute after configure
> because of like 64. I've had to change it like this:
>
> - dmake_full_package_name=$(find $TARFILE_LOCATION
> -type f -name "*-$dmake_package_name")
>
> + dmake_full_package_name=`find $TARFILE_LOCATION
> -type f -name "*-$dmake_package_name"`
Good. I attached this patch to issue [1] too. It replaces the bash-ism
with generic shell code.
> 2. I keep receiving the following each time I do a clean build:
> [...]
> Compiling: basebmp/source/bitmapdevice.cxx
> "/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/mathutil.hxx",
> line 801: Error: erf is not a member of _STL.
According to the C99 standard the error function erf() should be
provided via math.h. If this is not so then vigra could provide the
function itself if the macro VIGRA_HAS_ERF was not defined. For some
reason that macro gets defined for Solaris in
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/config.hxx
for __sun && !__GNUC__ Vigra's commit message regarding this was
"added configs for Sun C++ (very incomplete)
which shows that there is room for improvement. I added an experimental
patch for vigra to the issue [1]. Please try it out.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi Raymond,
On 09.09.2013 19:13, Steele, Raymond wrote:
> Thanks for the information. I attached the new mathconf.h file with your
> patch. I then did a clean build and it compiles without error.
Good. I created an issue ("Adaptions for building AOO 4.0.0 on Solaris")
for all such adaptions that we'll find. I already attached the patch for
mathconf.h there.
[1] https://issues.apache.org/ooo/show_bug.cgi?id=123228
> I am
> not sure about what you'd like me to provide when you say , " Of course
> it would also interesting to know what type
> ::std::numeric_limits<unsigned char>::digits on that platform." Could
> you provide more details? Thanks.
In your platform's <limits> include file there are probably
specializations for numeric_limits template. The symptoms of the error
message look as if there was no template specialization for
numeric_limits<unsigned char>. Is this so? Please check the <limits>
include file. In case you are using gcc then you could use the "-E"
option to see the preprocessed source (with the <limits> file included).
Another trick is to create a line
struct Dummy{} dummy = ::std::numeric_limits<unsigned char>::digits;
in one of the functions and when compiling there will be an error
message about an invalid assignment that hopefully provides enough
detail about the type of this digits member.
> Also,
>
> I've found a couple other things that you may be interested in.
Sure. I suggest to collect these findings in the newly created task
123228 I referenced above [1].
> 1. The generated bootstrap script will not execute after configure
> because of like 64. I've had to change it like this:
>
> - dmake_full_package_name=$(find $TARFILE_LOCATION
> -type f -name "*-$dmake_package_name")
>
> + dmake_full_package_name=`find $TARFILE_LOCATION
> -type f -name "*-$dmake_package_name"`
Good. I attached this patch to issue [1] too. It replaces the bash-ism
with generic shell code.
> 2. I keep receiving the following each time I do a clean build:
> [...]
> Compiling: basebmp/source/bitmapdevice.cxx
> "/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/mathutil.hxx",
> line 801: Error: erf is not a member of _STL.
According to the C99 standard the error function erf() should be
provided via math.h. If this is not so then vigra could provide the
function itself if the macro VIGRA_HAS_ERF was not defined. For some
reason that macro gets defined for Solaris in
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/config.hxx
for __sun && !__GNUC__ Vigra's commit message regarding this was
"added configs for Sun C++ (very incomplete)
which shows that there is room for improvement. I added an experimental
patch for vigra to the issue [1]. Please try it out.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
Thanks for the information. I attached the new mathconf.h file with your patch. I then did a clean build and it compiles without error. I am not sure about what you'd like me to provide when you say , " Of course it would also interesting to know what type ::std::numeric_limits<unsigned char>::digits on that platform." Could you provide more details? Thanks.
Also,
I've found a couple other things that you may be interested in.
1. The generated bootstrap script will not execute after configure because of like 64. I've had to change it like this:
- dmake_full_package_name=$(find $TARFILE_LOCATION -type f -name "*-$dmake_package_name")
+ dmake_full_package_name=`find $TARFILE_LOCATION -type f -name "*-$dmake_package_name"`
2. I keep receiving the following each time I do a clean build:
=============
Building module basebmp
=============
Entering /opt/aoo-4.0.0/main/basebmp/source
Compiling: basebmp/source/bitmapdevice.cxx
"/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/mathutil.hxx", line 801: Error: erf is not a member of _STL.
1 Error(s) detected.
dmake: Error code 2, while making '../unxsoli4.pro/slo/bitmapdevice.obj'
1 module(s):
basebmp
need(s) to be rebuilt
Reason(s):
ERROR: error 65280 occurred while making /opt/aoo-4.0.0/main/basebmp/source
When you have fixed the errors in that module you can resume the build by running:
build --all:basebmp
I can resolve this by changing /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/mathutil.hxx to the following on line 801:
- using VIGRA_CSTD::erf;
+ using ::erf;
This file is generated by the build. As of now, I have not determined what is generating it.
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Monday, September 09, 2013 12:58 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
On 07.09.2013 00:17, Steele, Raymond wrote:
> To address the isfinite() issue I added the following to rtl/math.hxx:
>
> #ifdef SOLARIS
> #undef SAL_MATH_FINITE
> #define SAL_MATH_FINITE(d) finite(d)
> #endf
>
> Your links were very helpful. Thanks so much.
Wonderful, so this problem is mostly solved. We just need to get it cleanly into the mathconf.h. How about this patch?
--- main/sal/inc/sal/mathconf.h
+++ main/sal/inc/sal/mathconf.h
@@ -55,7 +55,9 @@ extern "C" {
/* SAL_MATH_FINITE(d): test double d on INFINITY, NaN et al. */ -#if defined(__GNUC__) // workaround gcc bug 14608
+#if defined(OS2) || defined(SOLARIS)
+ #define SAL_MATH_FINITE(d) finite(d)
+#elif defined(__GNUC__) // workaround gcc bug 14608
#if (__GNUC_MINOR__ >= 3) // gcc>=4.3 has a builtin
#define SAL_MATH_FINITE(d) __builtin_isfinite(d)
#else
@@ -67,8 +69,6 @@ extern "C" {
#define SAL_MATH_FINITE(d) isfinite(d)
#elif defined( WNT)
#define SAL_MATH_FINITE(d) _finite(d)
-#elif defined OS2
-#define SAL_MATH_FINITE(d) finite(d)
#elif defined LINUX || defined UNX
#define SAL_MATH_FINITE(d) finite(d)
#else /* WNT, LINUX, UNX */
> Now onto:
>
> integer_fwd.cpp contains the following on line 136 and 137:
>
> 136: template < > 137: struct low_bits_mask_t<
> ::std::numeric_limits<unsigned
> char>::digits>;
I'm not sure whether you saw my mail from September 2nd
(http://markmail.org/message/bt7bazzvb6zionee):
https://issues.apache.org/jira/browse/STDCXX-937 might have to do with this. It mentions a compiler bug 6703971 but that doesn't seem to be available any more. I suggest to update the compiler to its latest patch level.
Of course it would also interesting to know what type ::std::numeric_limits<unsigned char>::digits on that platform. The error message looks as if this was not an integer but a class. The C++ spec requires that the type should be an int. Please check the <limits> include file.
Herbert
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
On 07.09.2013 00:17, Steele, Raymond wrote:
> To address the isfinite() issue I added the following to rtl/math.hxx:
>
> #ifdef SOLARIS
> #undef SAL_MATH_FINITE
> #define SAL_MATH_FINITE(d) finite(d)
> #endf
>
> Your links were very helpful. Thanks so much.
Wonderful, so this problem is mostly solved. We just need to get it
cleanly into the mathconf.h. How about this patch?
--- main/sal/inc/sal/mathconf.h
+++ main/sal/inc/sal/mathconf.h
@@ -55,7 +55,9 @@ extern "C" {
/* SAL_MATH_FINITE(d): test double d on INFINITY, NaN et al. */
-#if defined(__GNUC__) // workaround gcc bug 14608
+#if defined(OS2) || defined(SOLARIS)
+ #define SAL_MATH_FINITE(d) finite(d)
+#elif defined(__GNUC__) // workaround gcc bug 14608
#if (__GNUC_MINOR__ >= 3) // gcc>=4.3 has a builtin
#define SAL_MATH_FINITE(d) __builtin_isfinite(d)
#else
@@ -67,8 +69,6 @@ extern "C" {
#define SAL_MATH_FINITE(d) isfinite(d)
#elif defined( WNT)
#define SAL_MATH_FINITE(d) _finite(d)
-#elif defined OS2
-#define SAL_MATH_FINITE(d) finite(d)
#elif defined LINUX || defined UNX
#define SAL_MATH_FINITE(d) finite(d)
#else /* WNT, LINUX, UNX */
> Now onto:
>
> integer_fwd.cpp contains the following on line 136 and 137:
>
> 136: template < > 137: struct low_bits_mask_t< ::std::numeric_limits<unsigned
> char>::digits>;
I'm not sure whether you saw my mail from September 2nd
(http://markmail.org/message/bt7bazzvb6zionee):
https://issues.apache.org/jira/browse/STDCXX-937 might have to do with
this. It mentions a compiler bug 6703971 but that doesn't seem to be
available any more. I suggest to update the compiler to its latest patch
level.
Of course it would also interesting to know what type
::std::numeric_limits<unsigned char>::digits on that platform. The error
message looks as if this was not an integer but a class. The C++ spec
requires that the type should be an int. Please check the <limits>
include file.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
To address the isfinite() issue I added the following to rtl/math.hxx:
#ifdef SOLARIS
#undef SAL_MATH_FINITE
#define SAL_MATH_FINITE(d) finite(d)
#endf
Your links were very helpful. Thanks so much.
Now onto:
integer_fwd.cpp contains the following on line 136 and 137:
136: template < > 137: struct low_bits_mask_t< ::std::numeric_limits<unsigned
char>::digits>;
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Thursday, September 05, 2013 12:34 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hy Raymond,
On 04.09.2013 18:33, Steele, Raymond wrote:
> You are right, I completely missed your post. I am updating my compiler (SolarisStudio 12.3) now. As far as I can see now, I do not have isfinite is not a member of std on my system. Although, Netbeans allows me to choose C++ Standard C++11. What do you mean by " experiment with the different SAL_MATH_FINITE definitions"?
mathconf.h is a C header file, so we need the C definition of isfinite.
According to [1] the "C" isfinite() should be defined in <math.h>. Maybe on your platform there is a bug similar to [2] that undefines it later.
But we can assume that isfinite() is available in one form or the other on your system. Maybe it is called finite(), _finite(), or __builtin_isfinite()? Assuming [3] applies here then finite() may be the pre-standard equivalent to the isfinite() function that we are looking for.
[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/isfinite.html
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608
[3] https://www.varnish-cache.org/trac/ticket/464
What I meant with "experiment with the different SAL_MATH_FINITE definitions" is to check whether one of the above pre-standard
isfinite() alternatives work. If you found one then add a define for SOLARIS only that doesn't break the other platforms.
By the way std::isfinite() should be provided via <cmath> for C++11. But as the mathconf.h header is a "C" header this C++11 header is not available in this context.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
I am targeting x86. We really need to get this build because of a Java 7 requirement. I've build some add-ons to AOO version 3.3 that use Java 6, but our customer is requiring us to move to Java 7. My add-ons will not work because AOO 3.3 does not recognize the Java 7 JRE. I reverted back to using Solaris 12.3 compilers. Hopefully that reduces your worry about the bridges. I really do appreciate you assistance and hope to overcome this very shortly.
-----Original Message-----
From: Steele, Raymond
Sent: Thursday, September 05, 2013 9:37 AM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Subject: RE: EXTERNAL: Re: Building comphelper
Thanks for the information. I will give this a try if my current strategy does not work. Apparently, SolarisStudios 12.3 compiler is not compatible with c++11. I just finished building GCC 4.8.1 so that I can attempt to build with that. Now, I am having the issue described here: http://wiki.openoffice.org/wiki/OpenSolaris_Build_Instructions/Configure_Errors#Error:_GCC_Linker because I have CC and CXX pointing to my new gcc and g++. How can I point these variables to SolarisStudio compilers for linking, but use gcc for compiling?
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Thursday, September 05, 2013 12:34 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hy Raymond,
On 04.09.2013 18:33, Steele, Raymond wrote:
> You are right, I completely missed your post. I am updating my compiler (SolarisStudio 12.3) now. As far as I can see now, I do not have isfinite is not a member of std on my system. Although, Netbeans allows me to choose C++ Standard C++11. What do you mean by " experiment with the different SAL_MATH_FINITE definitions"?
mathconf.h is a C header file, so we need the C definition of isfinite.
According to [1] the "C" isfinite() should be defined in <math.h>. Maybe on your platform there is a bug similar to [2] that undefines it later.
But we can assume that isfinite() is available in one form or the other on your system. Maybe it is called finite(), _finite(), or __builtin_isfinite()? Assuming [3] applies here then finite() may be the pre-standard equivalent to the isfinite() function that we are looking for.
[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/isfinite.html
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608
[3] https://www.varnish-cache.org/trac/ticket/464
What I meant with "experiment with the different SAL_MATH_FINITE definitions" is to check whether one of the above pre-standard
isfinite() alternatives work. If you found one then add a define for SOLARIS only that doesn't break the other platforms.
By the way std::isfinite() should be provided via <cmath> for C++11. But as the mathconf.h header is a "C" header this C++11 header is not available in this context.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hy Raymond,
On 04.09.2013 18:33, Steele, Raymond wrote:
> You are right, I completely missed your post. I am updating my compiler (SolarisStudio 12.3) now. As far as I can see now, I do not have isfinite is not a member of std on my system. Although, Netbeans allows me to choose C++ Standard C++11. What do you mean by " experiment with the different SAL_MATH_FINITE definitions"?
mathconf.h is a C header file, so we need the C definition of isfinite.
According to [1] the "C" isfinite() should be defined in <math.h>. Maybe
on your platform there is a bug similar to [2] that undefines it later.
But we can assume that isfinite() is available in one form or the other
on your system. Maybe it is called finite(), _finite(), or
__builtin_isfinite()? Assuming [3] applies here then finite() may be the
pre-standard equivalent to the isfinite() function that we are looking for.
[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/isfinite.html
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608
[3] https://www.varnish-cache.org/trac/ticket/464
What I meant with "experiment with the different SAL_MATH_FINITE
definitions" is to check whether one of the above pre-standard
isfinite() alternatives work. If you found one then add a define for
SOLARIS only that doesn't break the other platforms.
By the way std::isfinite() should be provided via <cmath> for C++11. But
as the mathconf.h header is a "C" header this C++11 header is not
available in this context.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Herbert,
You are right, I completely missed your post. I am updating my compiler (SolarisStudio 12.3) now. As far as I can see now, I do not have isfinite is not a member of std on my system. Although, Netbeans allows me to choose C++ Standard C++11. What do you mean by " experiment with the different SAL_MATH_FINITE definitions"?
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Wednesday, September 04, 2013 12:14 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: EXTERNAL: Re: Building comphelper
On 03.09.2013 18:10, Steele, Raymond wrote:
> Anyone? This seems to pertain to the GNU bug described here since mathconf.h included in the AOO source has a comment about it.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608
In case you missed my replies to your questions please see http://markmail.org/thread/5gnsk7hmehxfdthx
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
On 03.09.2013 18:10, Steele, Raymond wrote:
> Anyone? This seems to pertain to the GNU bug described here since mathconf.h included in the AOO source has a comment about it.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608
In case you missed my replies to your questions please see
http://markmail.org/thread/5gnsk7hmehxfdthx
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org