On Wed, Nov 20, 2013 at 9:34 AM, Kay Schenk <kay.sch...@gmail.com> wrote:
> > On Tue, Nov 19, 2013 at 11:33 PM, Herbert Duerr <h...@apache.org> wrote: > >> On 20.11.2013 02:00, Kay Schenk wrote: >> >>> I installed the stlport provided by opensuse for my version -- it is >>> 4.6.2, >>> whereas the latest one at Sourceforge is 5.2.1. >>> >> >> Yes. Stlport 4.6.2 was getting a bit old. As the latest maintenance >> version of the stlport4 series it was released in 2004. So Stlport 4 has >> been unmaintained for almost ten years now. >> >> Since AOO 4 we are using the compiler/system provided STL and not stlport >> 4. We are lucky that the STL variants have been standardized with [1], so >> we can rely on them. Stlport 5.x follows this standard too, but Stlport 4 >> didn't, so it was no longer maintained. With AOO 4 we have abandoned it too. >> >> Please use the --without-stlport configure switch. Stlport 4 was great >> for its time. OOo and AOO 3.x still used it many years after its last >> maintenance version which is a reverence to stlport4. But with AOO 4 it was >> overdue that we finally let it rest in peace. This gives AOO the chance to >> become more compliant with the rest of the C++ world. >> >> [1] http://en.wikipedia.org/wiki/C++_Technical_Report_1 >> > > OK, I will look at this and thanks for this clarification. I got really > confused over this. I did use --without- stlport, but for some reason I > thought this meant use a system supplied one -- different from stdlibs, > which I normally install, so that's why all this tangle. So, I will > deinstall stlport 4.x, and see what happens. > > >> A lot more work is needed to change all the many parts of the source code >> that use pre-standard STL constructs to their standard compliant >> counterparts. But the heavy lifting is already done and the individual >> adaptions can be done automatically by some scripting. >> >> >> Should I install the newer version -- with gcc 4.7.2 in use. >>> >> >> You don't need stlport4 any longer. Please use the --without-stlport >> configure switch. The gcc provided libstdc++ library, boost/tr1 [2] and our >> stl wrappers will replace it just fine. >> >> [2] http://www.boost.org/doc/libs/1_54_0/doc/html/boost_tr1.html >> >> >> Also, I see this page: >>> http://www.stlport.org/doc/vendor_interface.html >>> >>> and since I seem to be getting a LOT of redefinition errors from what I'm >>> seeing, is this a namespace problem on my system? I also have C stdlib >>> installed. >>> >> >> Yes, the stdlib and the stdc++ libs are the standard libraries available >> on almost all Unixes nowadays. > > > OK, I will recheck. > > >> That's why we prefer using these libraries to provide the STL >> functionality we need. Having such native libs is much better than us >> shipping some an old stlport4 binary that is based on long unmaintained >> versions of a non-standard compliant library. >> >> >> Finally, in order to do anything, I had to muck with the include (-I) >>> definitions since stlport was not in the generated includes. Maybe we >>> need >>> to fix this since it's no longer provided locally? >>> >>> All was more or less fine with my setup until this change -- now things >>> are >>> not happy. >>> >> >> Please use the --without-stlport configure switch. >> >> This option is the new default. Thanks to Jan for fixing configure.in. >> But you'd need to update to the newest trunk version to benefit from Jan's >> fix. >> > > right -- I did that... > > > OK, thanks -- I'll get back to this... > > >> >> Herbert >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> > > > -- > > ------------------------------------------------------------------------------------------------- > MzK > > “Unless someone like you cares a whole awful lot, > Nothing is going to get better. It's not.” > -- Dr. Seuss, The Lorax > short update...in building xml2cmp/source/finder the reference to # include BOOST_TR1_STD_HEADER(utility) in ../boost/tr1/detail/config_all.hpp fails for me either from the externally installed boost or my local install. I have no idea why this never happened before the stlport removal but there you have it. I guess to make this work, I will need to define BOOST_TR1_STD_HEADER properly at least. -- ------------------------------------------------------------------------------------------------- MzK “Unless someone like you cares a whole awful lot, Nothing is going to get better. It's not.” -- Dr. Seuss, The Lorax
