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:h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
