You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Herbert Duerr <hd...@apache.org> on 2014/01/02 15:32:40 UTC
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
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 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