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: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
