Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
On Wed, Jan 8, 2014 at 11:14 PM, Herbert Duerr h...@apache.org wrote: On 01/08/2014 07:52 PM, Kay Schenk wrote: On Wed, Jan 8, 2014 at 2:32 AM, Herbert Duerr h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@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)
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
On Wed, Jan 8, 2014 at 2:32 AM, Herbert Duerr h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@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)
On 01/08/2014 07:52 PM, Kay Schenk wrote: On Wed, Jan 8, 2014 at 2:32 AM, Herbert Duerr h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
On Thu, Jan 2, 2014 at 2:44 PM, Kay Schenk kay.sch...@gmail.com wrote: On Thu, Jan 2, 2014 at 10:28 AM, Kay Schenk kay.sch...@gmail.com wrote: On Thu, Jan 2, 2014 at 6:32 AM, Herbert Duerr h...@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 h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@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 //
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 h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
On Thu, Jan 2, 2014 at 10:28 AM, Kay Schenk kay.sch...@gmail.com wrote: On Thu, Jan 2, 2014 at 6:32 AM, Herbert Duerr h...@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 h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@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)
Kay Schenk wrote: On Fri, Dec 13, 2013 at 6:04 AM, Herbert Duerr h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
On Fri, Dec 13, 2013 at 6:04 AM, Herbert Duerr h...@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 kay.sch...@gmail.com wrote: On Mon, Dec 9, 2013 at 5:29 AM, Herbert Duerr h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@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)
Hi Kay, On 13.12.2013 01:20, Kay Schenk wrote: On Mon, Dec 9, 2013 at 10:29 AM, Kay Schenk kay.sch...@gmail.com wrote: On Mon, Dec 9, 2013 at 5:29 AM, Herbert Duerr h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
On Mon, Dec 9, 2013 at 10:29 AM, Kay Schenk kay.sch...@gmail.com wrote: On Mon, Dec 9, 2013 at 5:29 AM, Herbert Duerr h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@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)
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
On Mon, Dec 9, 2013 at 5:29 AM, Herbert Duerr h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@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)
On Dec 5, 2013 10:28 PM, Herbert Duerr h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
