Re: EXTERNAL: Re: Building comphelper
Hi David, I just wanted to share the basics of what I have found so far. I still have no idea on how to solve the issue. Any help would be great! Observed Behaviour 1. OpenOffice starts, the splash screen with logo appears and then closes replaced with the full application window and choices for specific OpenOffice projects. 2. Selecting either the Word or Spreadsheet project causes a segmentation fault and closes the application. 3. Following the start of the application with the debugger, we can see the SidebarController is created in a first pass without error (known because first time to this stop point does not error). 4. As the process continues, the SidebarController constructor is called a second time (unknown why, but could be understood with more familiarity with the system). 5. The failure doesn't appear in the constructor, but the trace follows down SidebarController constructor call of WeakReferenceSidebarController WeakController (this); 6. This template definition for WeakController uses ReferenceTemplate::Refrence( interface_type *pInterface) as its definition in ::com::sun::star::uno::Reference.hxx. 7. The function will try to convert the pInterface parameter to a XInterface type called _pInterface. 8. If it succeeds in converting the pInterface to _pInterface then the function will try to acquire a new reference. 9. Assumption: Creating this new reference calls SidebarController::notifyContextChangeEvent with a corrupt or bad rEvent. This assumption is based on the stack where the immediate next routine after the Reference function call is the notifyContextChangeEvent, also while following along in the debugger, the rEvent parameter at this point is already corrupted with the value ERROR stored in the structure. 10. It is later after the notifyContextChangeEvent calls Context and then ustring that the segmentation fault occurs, but I believe the error located in rEvent is what causes this later problem. I haven't fully caught up with everything, but if I had to debug this I'd watch out for exceptions thrown in step 5 and later. In gdb I'd use the command catch throw to find the throwing code. Is there a similar facility in Solaris Studio? Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Thanks for the information Herbert. We continued looking at this today, but we
still have not determined the reason it is crashing. The application crashes at
SidebarController::notifyContextChangeEvent in SidebarController.cxx at
maRequestedContext =Context {...}. Our debugger says that eEvent is of the
value ERROR.
Raymond
-Original Message-
From: Herbert Duerr [mailto:h...@apache.org]
Sent: Tuesday, January 21, 2014 5:11 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi David,
I just wanted to share the basics of what I have found so far. I still have
no idea on how to solve the issue. Any help would be great!
Observed Behaviour
1.OpenOffice starts, the splash screen with logo appears and then closes
replaced with the full application window and choices for specific OpenOffice
projects.
2.Selecting either the Word or Spreadsheet project causes a segmentation
fault and closes the application.
3.Following the start of the application with the debugger, we can see
the SidebarController is created in a first pass without error (known because
first time to this stop point does not error).
4.As the process continues, the SidebarController constructor is called a
second time (unknown why, but could be understood with more familiarity with
the system).
5.The failure doesn't appear in the constructor, but the trace follows
down SidebarController constructor call of WeakReferenceSidebarController
WeakController (this);
6.This template definition for WeakController uses
ReferenceTemplate::Refrence( interface_type *pInterface) as its definition
in ::com::sun::star::uno::Reference.hxx.
7.The function will try to convert the pInterface parameter to a
XInterface type called _pInterface.
8.If it succeeds in converting the pInterface to _pInterface then the
function will try to acquire a new reference.
9.Assumption: Creating this new reference calls
SidebarController::notifyContextChangeEvent with a corrupt or bad rEvent.
This assumption is based on the stack where the immediate next routine after
the Reference function call is the notifyContextChangeEvent, also while
following along in the debugger, the rEvent parameter at this point is
already corrupted with the value ERROR stored in the structure.
10. It is later after the notifyContextChangeEvent calls Context and then
ustring that the segmentation fault occurs, but I believe the error located
in rEvent is what causes this later problem.
I haven't fully caught up with everything, but if I had to debug this I'd watch
out for exceptions thrown in step 5 and later. In gdb I'd use the command
catch throw
to find the throwing code. Is there a similar facility in Solaris Studio?
Herbert
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Hey, I just wanted to share the basics of what I have found so far. I still have no idea on how to solve the issue. Any help would be great! Observed Behaviour 1. OpenOffice starts, the splash screen with logo appears and then closes replaced with the full application window and choices for specific OpenOffice projects. 2. Selecting either the Word or Spreadsheet project causes a segmentation fault and closes the application. 3. Following the start of the application with the debugger, we can see the SidebarController is created in a first pass without error (known because first time to this stop point does not error). 4. As the process continues, the SidebarController constructor is called a second time (unknown why, but could be understood with more familiarity with the system). 5. The failure doesn't appear in the constructor, but the trace follows down SidebarController constructor call of WeakReferenceSidebarController WeakController (this); 6. This template definition for WeakController uses ReferenceTemplate::Refrence( interface_type *pInterface) as its definition in ::com::sun::star::uno::Reference.hxx. 7. The function will try to convert the pInterface parameter to a XInterface type called _pInterface. 8. If it succeeds in converting the pInterface to _pInterface then the function will try to acquire a new reference. 9. Assumption: Creating this new reference calls SidebarController::notifyContextChangeEvent with a corrupt or bad rEvent. This assumption is based on the stack where the immediate next routine after the Reference function call is the notifyContextChangeEvent, also while following along in the debugger, the rEvent parameter at this point is already corrupted with the value ERROR stored in the structure. 10. It is later after the notifyContextChangeEvent calls Context and then ustring that the segmentation fault occurs, but I believe the error located in rEvent is what causes this later problem. Thanks, David Meffe -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Friday, January 10, 2014 3:29 AM To: dev@openoffice.apache.org Cc: Meffe, David K; Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper On 09.01.2014 22:48, Steele, Raymond wrote: Attached is a copy of the stack trace when we tried to launch both the Word Processor and the Spreadsheet application in OpenOffice. We are going to attempt to resolve the crash based on this information, but if anything pops out at you, please let us know. The crashes in Writer and Calc you are seeing both happen when copy constructing an OUString from one provided by the SidebarController, so the provided string must be bad. I suggest to set a breakpoint at SidebarController.cxx:257 and examine the rEvent.ApplicationName and rEvent.ContextName whether these are good strings. From the stack I'd say they probably are not. Then go up the stack and check where they come from and why their are bad. Good luck! (I'll be away next week, starting this weekend) Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
On 09.01.2014 16:47, Steele, Raymond wrote: We found a work around for this problem, but believe it may be implemented incorrectly. We added the following to the top of fmtatr2.cxx: #ifndef _RWSTD_NO_MEMBER_TEMPLATES #define _RWSTD_NO_MEMBER_TEMPLATES 1 #endif A good find! And indeed [1] also ran into such a problem and defining that to disable templatized version of std::vectorT::assign() was a workaround needed by the SunStudio compiler. http://trac.osgeo.org/geos/ticket/224 The compile of sw then began compiling correctly. Any thoughts? I'd say that all such defines that make boost less aggressive in using advanced template magic are fine, so don't worry about it. But I'd use such an option consistently then, not only in one file. I suggest to add a -D_RWSTD_NO_MEMBER_TEMPLATES=1 into the solaris makefiles in solenv. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
On 09.01.2014 22:48, Steele, Raymond wrote: Attached is a copy of the stack trace when we tried to launch both the Word Processor and the Spreadsheet application in OpenOffice. We are going to attempt to resolve the crash based on this information, but if anything pops out at you, please let us know. The crashes in Writer and Calc you are seeing both happen when copy constructing an OUString from one provided by the SidebarController, so the provided string must be bad. I suggest to set a breakpoint at SidebarController.cxx:257 and examine the rEvent.ApplicationName and rEvent.ContextName whether these are good strings. From the stack I'd say they probably are not. Then go up the stack and check where they come from and why their are bad. Good luck! (I'll be away next week, starting this weekend) Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Herbert, We found a work around for this problem, but believe it may be implemented incorrectly. We added the following to the top of fmtatr2.cxx: #ifndef _RWSTD_NO_MEMBER_TEMPLATES #define _RWSTD_NO_MEMBER_TEMPLATES 1 #endif The compile of sw then began compiling correctly. Any thoughts? Raymond -Original Message- From: Steele, Raymond Sent: Wednesday, January 08, 2014 5:03 PM To: 'Herbert Duerr'; dev@openoffice.apache.org Cc: Meffe, David K Subject: RE: EXTERNAL: Re: Building comphelper Hey Herbert, Thanks for the quick response and your fix worked. The svx module built perfectly. I don't know why we are having these errors appear now that we are recompiling in debug mode. Unfortunately we ran into another problem at the end of the day here (and after nearly a whole day of compiling and everything looking good) and we'd thought we'd send off a quick message to you to see if you might have an answer. While rebuilding the sw module, the build of the fmtatr2 file failed. The first error message in the failure references the /usr/include/stdcxx4/rw/_autoptr.h file saying that the file Could not find a match for std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange ::auto_ptr_refstd::auto_ptr_refconst std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange::_TypeU(std::auto_ptrconststd::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange, const std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange *) needed in std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange ::operator std::auto_ptr_refconst std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRangeconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange () Raymond and I know that this reference is located in the memory.h file, but it doesn't appear that any of the files in the /main/sw/source/core/txtnode include the memory.h file even though it may be included in one of the other included files. Is it possible that something inside the OpenOffice files might be conflicting with the definition or usage of the auto_ptr_ref defined in the /usr/include/stdcxx4/memory.h? do we need to include memory.h inside any of the files inside /main/sw/source/core/txtnode? Is there a header definition that we need to change similar to the erf problems that we encountered previously? Thanks, David Meffe -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Wednesday, January 08, 2014 4:06 AM To: dev@openoffice.apache.org Cc: Steele, Raymond; Meffe, David K Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, Hi David, On 07.01.2014 23:11, Steele, Raymond wrote: Raymond and I remain stuck on the last issue that we wrote to you about. We would like to better encapsulate our problem and see if you might be able to provide more clarification on what we might be able to try. 1.We have performed a directory clean and restarted the build --all process from the beginning with the debug flag set. This time we are not using the multi-processing commands. 2.The build process proceeds without error, even compiling all the files up to the svx module. 3.When the svx module is finished compiling and the LNK of the Library/libsvxcore.so is being performed the process stops with an Undefined symbol linking error. 4.The symbol is ParagraphDataParagraphData::operator(const ParagraphData) and it used to complain about this file in the e3dundo.o. Wasn't it complaining about a missing ParagraphDataVector symbol originally? 5.Since the ParagraphData didn't appear in e3dundo neither did the OutlinerParaObject, I was at a loss for this linking error, but there was an #include editeng/outlobj.hxx. Since that is the location of OutlinerParaObject, I have commented out that include to see what would happen. The result is the system still compiled, but the linking failed again, this time in another location. 6.The new location that we got the same Undefined symbol error link message on was in the file sdrlinefillshadowtextattribute.o located in the attribute directory. This time I was unable to find a #include editeng/outlobj.hxx in either the header or source file. However sdrlinefillshadowtextattribute includes sdrlinesshadowtextattribute.hxx which includes sdrtextattribute. 7.sdrtextattribute was the first location we have found where the OutlinerParaObject is used and the #include editeng/outlobj.hxx. Since we had not found this object before (at least in the path that was failing), this was the first thing that made some sense in this problem. 8.We have reviewed your last email, but are having a difficult time understanding what you recommended
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: EXTERNAL: Re: Building comphelper
Herbert, Attached is a copy of the stack trace when we tried to launch both the Word Processor and the Spreadsheet application in OpenOffice. We are going to attempt to resolve the crash based on this information, but if anything pops out at you, please let us know. Thanks, David Meffe -Original Message- From: Steele, Raymond Sent: Thursday, January 09, 2014 8:47 AM To: 'Herbert Duerr'; 'dev@openoffice.apache.org' Cc: Meffe, David K Subject: RE: EXTERNAL: Re: Building comphelper Herbert, We found a work around for this problem, but believe it may be implemented incorrectly. We added the following to the top of fmtatr2.cxx: #ifndef _RWSTD_NO_MEMBER_TEMPLATES #define _RWSTD_NO_MEMBER_TEMPLATES 1 #endif The compile of sw then began compiling correctly. Any thoughts? Raymond -Original Message- From: Steele, Raymond Sent: Wednesday, January 08, 2014 5:03 PM To: 'Herbert Duerr'; dev@openoffice.apache.org Cc: Meffe, David K Subject: RE: EXTERNAL: Re: Building comphelper Hey Herbert, Thanks for the quick response and your fix worked. The svx module built perfectly. I don't know why we are having these errors appear now that we are recompiling in debug mode. Unfortunately we ran into another problem at the end of the day here (and after nearly a whole day of compiling and everything looking good) and we'd thought we'd send off a quick message to you to see if you might have an answer. While rebuilding the sw module, the build of the fmtatr2 file failed. The first error message in the failure references the /usr/include/stdcxx4/rw/_autoptr.h file saying that the file Could not find a match for std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange ::auto_ptr_refstd::auto_ptr_refconst std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange::_TypeU(std::auto_ptrconststd::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange, const std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange *) needed in std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange ::operator std::auto_ptr_refconst std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRangeconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange () Raymond and I know that this reference is located in the memory.h file, but it doesn't appear that any of the files in the /main/sw/source/core/txtnode include the memory.h file even though it may be included in one of the other included files. Is it possible that something inside the OpenOffice files might be conflicting with the definition or usage of the auto_ptr_ref defined in the /usr/include/stdcxx4/memory.h? do we need to include memory.h inside any of the files inside /main/sw/source/core/txtnode? Is there a header definition that we need to change similar to the erf problems that we encountered previously? Thanks, David Meffe -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Wednesday, January 08, 2014 4:06 AM To: dev@openoffice.apache.org Cc: Steele, Raymond; Meffe, David K Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, Hi David, On 07.01.2014 23:11, Steele, Raymond wrote: Raymond and I remain stuck on the last issue that we wrote to you about. We would like to better encapsulate our problem and see if you might be able to provide more clarification on what we might be able to try. 1.We have performed a directory clean and restarted the build --all process from the beginning with the debug flag set. This time we are not using the multi-processing commands. 2.The build process proceeds without error, even compiling all the files up to the svx module. 3.When the svx module is finished compiling and the LNK of the Library/libsvxcore.so is being performed the process stops with an Undefined symbol linking error. 4.The symbol is ParagraphDataParagraphData::operator(const ParagraphData) and it used to complain about this file in the e3dundo.o. Wasn't it complaining about a missing ParagraphDataVector symbol originally? 5.Since the ParagraphData didn't appear in e3dundo neither did the OutlinerParaObject, I was at a loss for this linking error, but there was an #include editeng/outlobj.hxx. Since that is the location of OutlinerParaObject, I have commented out that include to see what would happen. The result is the system still compiled, but the linking failed again, this time in another location. 6.The new location that we got the same Undefined symbol error link message on was in the file sdrlinefillshadowtextattribute.o located in the attribute directory. This time I was unable to find a #include editeng/outlobj.hxx in either the header or source file. However
Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
Hi David,
On 07.01.2014 23:11, Steele, Raymond wrote:
Raymond and I remain stuck on the last issue that we wrote to you about. We
would like to better encapsulate our problem and see if you might be able to
provide more clarification on what we might be able to try.
1.We have performed a directory clean and restarted the build --all
process from the beginning with the debug flag set. This time we are not
using the multi-processing commands.
2.The build process proceeds without error, even compiling all the files
up to the svx module.
3.When the svx module is finished compiling and the LNK of the
Library/libsvxcore.so is being performed the process stops with an Undefined
symbol linking error.
4.The symbol is ParagraphDataParagraphData::operator(const
ParagraphData) and it used to complain about this file in the e3dundo.o.
Wasn't it complaining about a missing ParagraphDataVector symbol originally?
5.Since the ParagraphData didn't appear in e3dundo neither did the
OutlinerParaObject, I was at a loss for this linking error, but there was an
#include editeng/outlobj.hxx. Since that is the location of
OutlinerParaObject, I have commented out that include to see what would
happen. The result is the system still compiled, but the linking failed
again, this time in another location.
6.The new location that we got the same Undefined symbol error link
message on was in the file sdrlinefillshadowtextattribute.o located in the
attribute directory. This time I was unable to find a #include
editeng/outlobj.hxx in either the header or source file. However
sdrlinefillshadowtextattribute includes sdrlinesshadowtextattribute.hxx which
includes sdrtextattribute.
7.sdrtextattribute was the first location we have found where the
OutlinerParaObject is used and the #include editeng/outlobj.hxx. Since we
had not found this object before (at least in the path that was failing),
this was the first thing that made some sense in this problem.
8.We have reviewed your last email, but are having a difficult time
understanding what you recommended. It appeared you were recommending we
modify the OutlinerParaObject constructor, but how? You wanted us to remove
the ParagraphDataVector parameter? Or did you want us to create a different
constructor? What would the constructor look like?
I was suggesting to add another constructor that didn't have the problem of
needing a ParagraphDataVector symbol. Does this patch work for you? Since this
makes svx binary incompatible with its original you need to do a build
--prepare --from svx when you apply it.
--- main/editeng/inc/editeng/outlobj.hxx
+++ main/editeng/inc/editeng/outlobj.hxx
@@ -46,10 +46,8 @@ private:
public:
// constructors/destructor
-OutlinerParaObject(
-const EditTextObject rEditTextObject,
-const ParagraphDataVector rParagraphDataVector =
ParagraphDataVector(),
-bool bIsEditDoc = true);
+OutlinerParaObject( const EditTextObject, const ParagraphDataVector,
bool bIsEditDoc = true);
+OutlinerParaObject( const EditTextObject);
OutlinerParaObject(const OutlinerParaObject rCandidate);
~OutlinerParaObject();
--- main/editeng/source/outliner/outlobj.cxx
+++ main/editeng/source/outliner/outlobj.cxx
@@ -98,6 +98,10 @@ OutlinerParaObject::OutlinerParaObject(const EditTextObject
rEditTextObject, co
{
}
+OutlinerParaObject::OutlinerParaObject( const EditTextObject)
+: mpImplOutlinerParaObject( new ImplOutlinerParaObject(
rEditTextObject.Clone(), ParagraphDataVector(), true))
+{}
+
OutlinerParaObject::OutlinerParaObject(const OutlinerParaObject rCandidate)
: mpImplOutlinerParaObject(rCandidate.mpImplOutlinerParaObject)
{
9.Also even after all of this, do you think that if we modify the
OutlinerParaObject that the rest of the svx will link correctly and that all
these errors we have seen from this problem resulted from an error in the
OutlinerParaObject and our compiler?
I sure hope so ;-)
Once again, thanks for all your help in advance.
You're welcome!
I hope you had a good holiday season. We look forward to hearing back from
you.
BTW: I'll also be away next week.
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 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: EXTERNAL: Re: Building comphelper
Hey Herbert, Thanks for the quick response and your fix worked. The svx module built perfectly. I don't know why we are having these errors appear now that we are recompiling in debug mode. Unfortunately we ran into another problem at the end of the day here (and after nearly a whole day of compiling and everything looking good) and we'd thought we'd send off a quick message to you to see if you might have an answer. While rebuilding the sw module, the build of the fmtatr2 file failed. The first error message in the failure references the /usr/include/stdcxx4/rw/_autoptr.h file saying that the file Could not find a match for std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange ::auto_ptr_refstd::auto_ptr_refconst std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange::_TypeU(std::auto_ptrconststd::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange, const std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange *) needed in std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange ::operator std::auto_ptr_refconst std::auto_ptr_refconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRangeconst std::dequecom::sun::star::uno::Referencecom::sun::star::text::XTextRange () Raymond and I know that this reference is located in the memory.h file, but it doesn't appear that any of the files in the /main/sw/source/core/txtnode include the memory.h file even though it may be included in one of the other included files. Is it possible that something inside the OpenOffice files might be conflicting with the definition or usage of the auto_ptr_ref defined in the /usr/include/stdcxx4/memory.h? do we need to include memory.h inside any of the files inside /main/sw/source/core/txtnode? Is there a header definition that we need to change similar to the erf problems that we encountered previously? Thanks, David Meffe -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Wednesday, January 08, 2014 4:06 AM To: dev@openoffice.apache.org Cc: Steele, Raymond; Meffe, David K Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, Hi David, On 07.01.2014 23:11, Steele, Raymond wrote: Raymond and I remain stuck on the last issue that we wrote to you about. We would like to better encapsulate our problem and see if you might be able to provide more clarification on what we might be able to try. 1.We have performed a directory clean and restarted the build --all process from the beginning with the debug flag set. This time we are not using the multi-processing commands. 2.The build process proceeds without error, even compiling all the files up to the svx module. 3.When the svx module is finished compiling and the LNK of the Library/libsvxcore.so is being performed the process stops with an Undefined symbol linking error. 4.The symbol is ParagraphDataParagraphData::operator(const ParagraphData) and it used to complain about this file in the e3dundo.o. Wasn't it complaining about a missing ParagraphDataVector symbol originally? 5.Since the ParagraphData didn't appear in e3dundo neither did the OutlinerParaObject, I was at a loss for this linking error, but there was an #include editeng/outlobj.hxx. Since that is the location of OutlinerParaObject, I have commented out that include to see what would happen. The result is the system still compiled, but the linking failed again, this time in another location. 6.The new location that we got the same Undefined symbol error link message on was in the file sdrlinefillshadowtextattribute.o located in the attribute directory. This time I was unable to find a #include editeng/outlobj.hxx in either the header or source file. However sdrlinefillshadowtextattribute includes sdrlinesshadowtextattribute.hxx which includes sdrtextattribute. 7.sdrtextattribute was the first location we have found where the OutlinerParaObject is used and the #include editeng/outlobj.hxx. Since we had not found this object before (at least in the path that was failing), this was the first thing that made some sense in this problem. 8.We have reviewed your last email, but are having a difficult time understanding what you recommended. It appeared you were recommending we modify the OutlinerParaObject constructor, but how? You wanted us to remove the ParagraphDataVector parameter? Or did you want us to create a different constructor? What would the constructor look like? I was suggesting to add another constructor that didn't have the problem of needing a ParagraphDataVector symbol. Does this patch work for you? Since this makes svx binary incompatible with its original you need to do a build --prepare --from svx when you apply
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: EXTERNAL: Re: Building comphelper
Herbert, Raymond and I remain stuck on the last issue that we wrote to you about. We would like to better encapsulate our problem and see if you might be able to provide more clarification on what we might be able to try. 1. We have performed a directory clean and restarted the build --all process from the beginning with the debug flag set. This time we are not using the multi-processing commands. 2. The build process proceeds without error, even compiling all the files up to the svx module. 3. When the svx module is finished compiling and the LNK of the Library/libsvxcore.so is being performed the process stops with an Undefined symbol linking error. 4. The symbol is ParagraphDataParagraphData::operator(const ParagraphData) and it used to complain about this file in the e3dundo.o. 5. Since the ParagraphData didn't appear in e3dundo neither did the OutlinerParaObject, I was at a loss for this linking error, but there was an #include editeng/outlobj.hxx. Since that is the location of OutlinerParaObject, I have commented out that include to see what would happen. The result is the system still compiled, but the linking failed again, this time in another location. 6. The new location that we got the same Undefined symbol error link message on was in the file sdrlinefillshadowtextattribute.o located in the attribute directory. This time I was unable to find a #include editeng/outlobj.hxx in either the header or source file. However sdrlinefillshadowtextattribute includes sdrlinesshadowtextattribute.hxx which includes sdrtextattribute. 7. sdrtextattribute was the first location we have found where the OutlinerParaObject is used and the #include editeng/outlobj.hxx. Since we had not found this object before (at least in the path that was failing), this was the first thing that made some sense in this problem. 8. We have reviewed your last email, but are having a difficult time understanding what you recommended. It appeared you were recommending we modify the OutlinerParaObject constructor, but how? You wanted us to remove the ParagraphDataVector parameter? Or did you want us to create a different constructor? What would the constructor look like? 9. Also even after all of this, do you think that if we modify the OutlinerParaObject that the rest of the svx will link correctly and that all these errors we have seen from this problem resulted from an error in the OutlinerParaObject and our compiler? Once again, thanks for all your help in advance. I hope you had a good holiday season. We look forward to hearing back from you. David Meffe -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Friday, December 20, 2013 6:41 AM To: Steele, Raymond; dev@openoffice.apache.org Cc: Meffe, David K Subject: Re: EXTERNAL: Re: Building comphelper Hi David, Hi Raymond, On 20.12.2013 00:12, Steele, Raymond wrote: Raymond and I are in the process of rebuilding OpenOffice with the debug flags, but have run into some errors that didn't occur the first time through in the build. The current error has caused me quite a bit of problems. We are getting a link error, unrecognized symbol in /svx/source/engine3d/e3dundo.cxx. However the symbol that it is looking for is not present inside e3dundo.cxx. The symbol is ParagraphDataParagraphData::operator=(const ParagraphData) [sic] which we have located in /editeng/inc/editeng/paragraphdata.hxx and the implementation appears to in /editeng/source/outliner/paralist.cxx. There are some very odd things going on here. 1)paragraphdata.hxx is not included in paralist.cxx even though this is where the prototype is declared. 2)e3dundo.cxx doesn't seem to use the ParagraphData class at all. 3)e3dundo.cxx doesn't seem to include the libraries where these classes are used. From what I can gather from the relevant parts of that code an OutlinerParaObject constructor has a ParagraphDataVector argument that is default initialized with an empty ParagraphDataVector. I guess the assignment in this default initialization needs ParagraphData's assignment operator. Maybe removing the default argument for ParagraphDataVector in OutlinerParaObject's constructor helps? This can be done by creating another constructor that takes only one argument. Most other compilers seem to optimize the assignment operator away even when compiling in debugging mode. I want to note that we first started the debug build using multiple processors (-P8) and perhaps that has caused problems in the ordering in which the libraries were compiled and linked. It is conceivable that this problem may be resolved with a complete system clean and rebuild in linear mode, but before we committed to another day of building the product, we wanted to check with you to see if this problem has occurred before, is it recognized or if there is a solution that you could recommend? I
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: EXTERNAL: Re: Building comphelper
Hi David, Hi Raymond, On 20.12.2013 00:12, Steele, Raymond wrote: Raymond and I are in the process of rebuilding OpenOffice with the debug flags, but have run into some errors that didn't occur the first time through in the build. The current error has caused me quite a bit of problems. We are getting a link error, unrecognized symbol in /svx/source/engine3d/e3dundo.cxx. However the symbol that it is looking for is not present inside e3dundo.cxx. The symbol is ParagraphDataParagraphData::operator=(const ParagraphData) [sic] which we have located in /editeng/inc/editeng/paragraphdata.hxx and the implementation appears to in /editeng/source/outliner/paralist.cxx. There are some very odd things going on here. 1) paragraphdata.hxx is not included in paralist.cxx even though this is where the prototype is declared. 2) e3dundo.cxx doesn't seem to use the ParagraphData class at all. 3) e3dundo.cxx doesn't seem to include the libraries where these classes are used. From what I can gather from the relevant parts of that code an OutlinerParaObject constructor has a ParagraphDataVector argument that is default initialized with an empty ParagraphDataVector. I guess the assignment in this default initialization needs ParagraphData's assignment operator. Maybe removing the default argument for ParagraphDataVector in OutlinerParaObject's constructor helps? This can be done by creating another constructor that takes only one argument. Most other compilers seem to optimize the assignment operator away even when compiling in debugging mode. I want to note that we first started the debug build using multiple processors (-P8) and perhaps that has caused problems in the ordering in which the libraries were compiled and linked. It is conceivable that this problem may be resolved with a complete system clean and rebuild in linear mode, but before we committed to another day of building the product, we wanted to check with you to see if this problem has occurred before, is it recognized or if there is a solution that you could recommend? I wouldn't vouch for our build systems ordering at such high parallelism levels... if you want to increase parallelism I'd recommend to change from e.g. build --all -P8 to e.g. build --all -P2 -- -P4 The first -P is for build's parallelism, the second -P is for dmake's parallelism. I'm too polite to tell what I really feel about these mechanisms... We'd appreciate any help or insight you could provide. I hope the above helps. If not just add the library that provides the missing symbol to the link list. P.S. I will be on holiday for the next two weeks and I believe Raymond will be as well so we may be out of communication. I'll be (mostly) offline for the rest of the year too :-) 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: EXTERNAL: Re: Building comphelper
Herbert, Raymond and I are in the process of rebuilding OpenOffice with the debug flags, but have run into some errors that didn't occur the first time through in the build. The current error has caused me quite a bit of problems. We are getting a link error, unrecognized symbol in /svx/source/engine3d/e3dundo.cxx. However the symbol that it is looking for is not present inside e3dundo.cxx. The symbol is ParagraphDataParagraphData::operator=(const ParagraphData) [sic] which we have located in /editeng/inc/editeng/paragraphdata.hxx and the implementation appears to in /editeng/source/outliner/paralist.cxx. There are some very odd things going on here. 1) paragraphdata.hxx is not included in paralist.cxx even though this is where the prototype is declared. 2) e3dundo.cxx doesn't seem to use the ParagraphData class at all. 3) e3dundo.cxx doesn't seem to include the libraries where these classes are used. I want to note that we first started the debug build using multiple processors (-P8) and perhaps that has caused problems in the ordering in which the libraries were compiled and linked. It is conceivable that this problem may be resolved with a complete system clean and rebuild in linear mode, but before we committed to another day of building the product, we wanted to check with you to see if this problem has occurred before, is it recognized or if there is a solution that you could recommend? We'd appreciate any help or insight you could provide. David Meffe P.S. I will be on holiday for the next two weeks and I believe Raymond will be as well so we may be out of communication. -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Wednesday, December 18, 2013 12:11 AM To: dev@openoffice.apache.org Cc: Steele, Raymond; Meffe, David K Subject: Re: EXTERNAL: Re: Building comphelper Hello David, Hello Raymond, On 17.12.2013 23:31, Steele, Raymond wrote: At long last Raymond and I have successfully gotten through the entire build script without a fault. The executable seemed to create just fine and we were able to launch soffice. We got the splash screen, then the executable started and the options window appeared and everything looked to be in order, That's a great success! but when we selected one of the document types to open, the executable crashed with the memory error: ./soffice[121]: wait: 6980: Memory fault I'm afraid we need a stack trace of this crash to understand what's going on. When the stack trace shows which libraries are involved then these libraries should be recompiled with debug infos (i.e. created with the debug=1 option for make or for build). Then replace the libs in your installation with the debug libs and get the stack trace of this crash. I don't think Raymond or I was expecting everything to work right on first launch and we were happy to see the splash screen, the executable start and the option menu appear. However, have you seen this type of memory error before or has it been seen by others? Do you have an idea what might cause this? If you single stepped through the huge amounts of code that is needed to get to there you'd see there is more than plenty of opportunity for something to go wrong ;-) My fear is that we have made too many modifications to the code in order to get the system to build correctly. We have removed, in small select areas, const as a qualifier to certain parameters to member functions because the system would not compile with these parameters declared as a const. We can provide a list of these locations that we have edited, I believe it is about 3 or 4 files that might have been edited in this way. The changes in the few source files you mentioned in your other mail are probably uncritical. And e.g. Calc isn't changed at all, so if it doesn't work either then I suspect the problem in a deeper layer. If you have any ideas, it would greatly help us out. Thanks. The stack trace of the crash when debug-enabled libraries were used would be very helpful Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Herbert, At long last Raymond and I have successfully gotten through the entire build script without a fault. The executable seemed to create just fine and we were able to launch soffice. We got the splash screen, then the executable started and the options window appeared and everything looked to be in order, but when we selected one of the document types to open, the executable crashed with the memory error: ./soffice[121]: wait: 6980: Memory fault I don't think Raymond or I was expecting everything to work right on first launch and we were happy to see the splash screen, the executable start and the option menu appear. However, have you seen this type of memory error before or has it been seen by others? Do you have an idea what might cause this? My fear is that we have made too many modifications to the code in order to get the system to build correctly. We have removed, in small select areas, const as a qualifier to certain parameters to member functions because the system would not compile with these parameters declared as a const. We can provide a list of these locations that we have edited, I believe it is about 3 or 4 files that might have been edited in this way. If you have any ideas, it would greatly help us out. Thanks. David Meffe -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Monday, December 16, 2013 4:46 AM To: dev@openoffice.apache.org Cc: Meffe, David K; Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi David, Your idea worked. We were able to comment out those lines in the prex.h and the system was able to successfully build the VCL module as well as several others. We can almost taste the finish line. Yay! I'm very glad to hear this 8-) However we have encountered another problem with the build that is a little more difficult than just sorting out the included header files and paths, this time in the slideshow module. The error is located in the c++ /usr/include/stdcxx4/deque.cc on line 569 and states that ShapeImporter::XShapeEntry has a const member mpGroupShape and cannot be reassigned. We can see in shapeimporter.cxx that line 181 is indeed a const definition of mpGroupShape, but it doesn't seem to tie directly to line 569 in deque.cc. This may be because deque.cc may be used as a template, and the assignment is forbidden because the value in XShapeEntry is a const, but is there a way around this? This seems to be caused by a strange interaction of boost's shared_ptr and that const members can only be set in constructor. Maybe rvalue references come into play here too if your compiler has them enabled. The exact error message could help... Do you have a thought as what we might try to continue with the build? If the problem is in boost's shared_ptr then maybe updating to a later version could help. Please see my patch in issue 123817 if you want to update to the latest boost. But maybe the shared_ptr problem is genuine when e.g. the reference counting requirements of such a shared_ptr require it to be non-const? Anyway, the quickest workaround would be to remove the const from in line 119 of shapeimporter.hxx and line 193 of shapeimporter.cxx. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Just wanted to add that it appears that the formula and database application are launching, but not Text Document, Spreadsheet, Presentation, or Drawing. -Original Message- From: Steele, Raymond Sent: Tuesday, December 17, 2013 3:31 PM To: 'Herbert Duerr'; dev@openoffice.apache.org Cc: Meffe, David K Subject: RE: EXTERNAL: Re: Building comphelper Herbert, At long last Raymond and I have successfully gotten through the entire build script without a fault. The executable seemed to create just fine and we were able to launch soffice. We got the splash screen, then the executable started and the options window appeared and everything looked to be in order, but when we selected one of the document types to open, the executable crashed with the memory error: ./soffice[121]: wait: 6980: Memory fault I don't think Raymond or I was expecting everything to work right on first launch and we were happy to see the splash screen, the executable start and the option menu appear. However, have you seen this type of memory error before or has it been seen by others? Do you have an idea what might cause this? My fear is that we have made too many modifications to the code in order to get the system to build correctly. We have removed, in small select areas, const as a qualifier to certain parameters to member functions because the system would not compile with these parameters declared as a const. We can provide a list of these locations that we have edited, I believe it is about 3 or 4 files that might have been edited in this way. If you have any ideas, it would greatly help us out. Thanks. David Meffe -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Monday, December 16, 2013 4:46 AM To: dev@openoffice.apache.org Cc: Meffe, David K; Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi David, Your idea worked. We were able to comment out those lines in the prex.h and the system was able to successfully build the VCL module as well as several others. We can almost taste the finish line. Yay! I'm very glad to hear this 8-) However we have encountered another problem with the build that is a little more difficult than just sorting out the included header files and paths, this time in the slideshow module. The error is located in the c++ /usr/include/stdcxx4/deque.cc on line 569 and states that ShapeImporter::XShapeEntry has a const member mpGroupShape and cannot be reassigned. We can see in shapeimporter.cxx that line 181 is indeed a const definition of mpGroupShape, but it doesn't seem to tie directly to line 569 in deque.cc. This may be because deque.cc may be used as a template, and the assignment is forbidden because the value in XShapeEntry is a const, but is there a way around this? This seems to be caused by a strange interaction of boost's shared_ptr and that const members can only be set in constructor. Maybe rvalue references come into play here too if your compiler has them enabled. The exact error message could help... Do you have a thought as what we might try to continue with the build? If the problem is in boost's shared_ptr then maybe updating to a later version could help. Please see my patch in issue 123817 if you want to update to the latest boost. But maybe the shared_ptr problem is genuine when e.g. the reference counting requirements of such a shared_ptr require it to be non-const? Anyway, the quickest workaround would be to remove the const from in line 119 of shapeimporter.hxx and line 193 of shapeimporter.cxx. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Hebert, Here is a listing of the files that we modified because the build did not accept a const qualifier when defining a parameter or a member variable. The solution was to simply remove the const at the time to make the build continue. Since the build did not complain, we left the changes in until the end. /sideshow/source/inc/shapeimporter.(hxx/cxx) - member variables: mpGroupShape, mxShape, and mnCount /svx/source/sidebar/tools/ColorControl.(hxx/cxx) - member function: SetCurrColorSelect /svx/source/sidebar/tools/ColorPopup.(hxx/cxx) - member function: SetCurrentColor /sc/source/ui/drawfunc/drawsw2.cxx - member function: Activate /sw/source/core/uno/unocore/unoportenum.cxx - member typedef: PortionList_t David Meffe -Original Message- From: Steele, Raymond Sent: Tuesday, December 17, 2013 3:36 PM To: 'Herbert Duerr'; 'dev@openoffice.apache.org' Cc: Meffe, David K Subject: RE: EXTERNAL: Re: Building comphelper Just wanted to add that it appears that the formula and database application are launching, but not Text Document, Spreadsheet, Presentation, or Drawing. -Original Message- From: Steele, Raymond Sent: Tuesday, December 17, 2013 3:31 PM To: 'Herbert Duerr'; dev@openoffice.apache.org Cc: Meffe, David K Subject: RE: EXTERNAL: Re: Building comphelper Herbert, At long last Raymond and I have successfully gotten through the entire build script without a fault. The executable seemed to create just fine and we were able to launch soffice. We got the splash screen, then the executable started and the options window appeared and everything looked to be in order, but when we selected one of the document types to open, the executable crashed with the memory error: ./soffice[121]: wait: 6980: Memory fault I don't think Raymond or I was expecting everything to work right on first launch and we were happy to see the splash screen, the executable start and the option menu appear. However, have you seen this type of memory error before or has it been seen by others? Do you have an idea what might cause this? My fear is that we have made too many modifications to the code in order to get the system to build correctly. We have removed, in small select areas, const as a qualifier to certain parameters to member functions because the system would not compile with these parameters declared as a const. We can provide a list of these locations that we have edited, I believe it is about 3 or 4 files that might have been edited in this way. If you have any ideas, it would greatly help us out. Thanks. David Meffe -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Monday, December 16, 2013 4:46 AM To: dev@openoffice.apache.org Cc: Meffe, David K; Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi David, Your idea worked. We were able to comment out those lines in the prex.h and the system was able to successfully build the VCL module as well as several others. We can almost taste the finish line. Yay! I'm very glad to hear this 8-) However we have encountered another problem with the build that is a little more difficult than just sorting out the included header files and paths, this time in the slideshow module. The error is located in the c++ /usr/include/stdcxx4/deque.cc on line 569 and states that ShapeImporter::XShapeEntry has a const member mpGroupShape and cannot be reassigned. We can see in shapeimporter.cxx that line 181 is indeed a const definition of mpGroupShape, but it doesn't seem to tie directly to line 569 in deque.cc. This may be because deque.cc may be used as a template, and the assignment is forbidden because the value in XShapeEntry is a const, but is there a way around this? This seems to be caused by a strange interaction of boost's shared_ptr and that const members can only be set in constructor. Maybe rvalue references come into play here too if your compiler has them enabled. The exact error message could help... Do you have a thought as what we might try to continue with the build? If the problem is in boost's shared_ptr then maybe updating to a later version could help. Please see my patch in issue 123817 if you want to update to the latest boost. But maybe the shared_ptr problem is genuine when e.g. the reference counting requirements of such a shared_ptr require it to be non-const? Anyway, the quickest workaround would be to remove the const from in line 119 of shapeimporter.hxx and line 193 of shapeimporter.cxx. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Hello David, Hello Raymond, On 17.12.2013 23:31, Steele, Raymond wrote: At long last Raymond and I have successfully gotten through the entire build script without a fault. The executable seemed to create just fine and we were able to launch soffice. We got the splash screen, then the executable started and the options window appeared and everything looked to be in order, That's a great success! but when we selected one of the document types to open, the executable crashed with the memory error: ./soffice[121]: wait: 6980: Memory fault I'm afraid we need a stack trace of this crash to understand what's going on. When the stack trace shows which libraries are involved then these libraries should be recompiled with debug infos (i.e. created with the debug=1 option for make or for build). Then replace the libs in your installation with the debug libs and get the stack trace of this crash. I don't think Raymond or I was expecting everything to work right on first launch and we were happy to see the splash screen, the executable start and the option menu appear. However, have you seen this type of memory error before or has it been seen by others? Do you have an idea what might cause this? If you single stepped through the huge amounts of code that is needed to get to there you'd see there is more than plenty of opportunity for something to go wrong ;-) My fear is that we have made too many modifications to the code in order to get the system to build correctly. We have removed, in small select areas, const as a qualifier to certain parameters to member functions because the system would not compile with these parameters declared as a const. We can provide a list of these locations that we have edited, I believe it is about 3 or 4 files that might have been edited in this way. The changes in the few source files you mentioned in your other mail are probably uncritical. And e.g. Calc isn't changed at all, so if it doesn't work either then I suspect the problem in a deeper layer. If you have any ideas, it would greatly help us out. Thanks. The stack trace of the crash when debug-enabled libraries were used would be very helpful Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Hi David, Your idea worked. We were able to comment out those lines in the prex.h and the system was able to successfully build the VCL module as well as several others. We can almost taste the finish line. Yay! I'm very glad to hear this 8-) However we have encountered another problem with the build that is a little more difficult than just sorting out the included header files and paths, this time in the slideshow module. The error is located in the c++ /usr/include/stdcxx4/deque.cc on line 569 and states that ShapeImporter::XShapeEntry has a const member mpGroupShape and cannot be reassigned. We can see in shapeimporter.cxx that line 181 is indeed a const definition of mpGroupShape, but it doesn't seem to tie directly to line 569 in deque.cc. This may be because deque.cc may be used as a template, and the assignment is forbidden because the value in XShapeEntry is a const, but is there a way around this? This seems to be caused by a strange interaction of boost's shared_ptr and that const members can only be set in constructor. Maybe rvalue references come into play here too if your compiler has them enabled. The exact error message could help... Do you have a thought as what we might try to continue with the build? If the problem is in boost's shared_ptr then maybe updating to a later version could help. Please see my patch in issue 123817 if you want to update to the latest boost. But maybe the shared_ptr problem is genuine when e.g. the reference counting requirements of such a shared_ptr require it to be non-const? Anyway, the quickest workaround would be to remove the const from in line 119 of shapeimporter.hxx and line 193 of shapeimporter.cxx. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Hi David, Hi Raymond, On 12.12.2013 22:54, Steele, Raymond wrote: 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. I'm very glad to hear that you already made it to VCL. It looks as if the compiler/STL problems are solved now in your AOO-dev environment. 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. Investigating this problem suggests that the preprocessor-condition in line 42 of main/tools/inc/tools/prex.h may need to be updated for newer Solaris platforms. I'm not sure whether this condition is still needed at all. It looks like a check to allow older platforms to run, but if all interesting unix targets like Linux and FreeBSD (and now Solaris?) don't need that condition for backward compatibility any any longer then that condition should be removed. 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. The prex.h and post.x headers in main/tools/inc/tools/ do funny things to make the declarations from the X11 headers appear under a different name... Adjusting line 42 of main/tools/inc/tools/prex.h may solve this problem too. Raymond and I are both somewhat hesitant to start messing with the X11 header files on the system. I certainly agree with that! 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? Adjusting the line suggested above may solve this and many other problems. Good luck! 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)
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: EXTERNAL: Re: Building comphelper
Herbert, Your idea worked. We were able to comment out those lines in the prex.h and the system was able to successfully build the VCL module as well as several others. We can almost taste the finish line. However we have encountered another problem with the build that is a little more difficult than just sorting out the included header files and paths, this time in the slideshow module. The error is located in the c++ /usr/include/stdcxx4/deque.cc on line 569 and states that ShapeImporter::XShapeEntry has a const member mpGroupShape and cannot be reassigned. We can see in shapeimporter.cxx that line 181 is indeed a const definition of mpGroupShape, but it doesn't seem to tie directly to line 569 in deque.cc. This may be because deque.cc may be used as a template, and the assignment is forbidden because the value in XShapeEntry is a const, but is there a way around this? Do you have a thought as what we might try to continue with the build? David -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Friday, December 13, 2013 1:25 AM To: dev@openoffice.apache.org Cc: Meffe, David K; Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi David, Hi Raymond, On 12.12.2013 22:54, Steele, Raymond wrote: 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. I'm very glad to hear that you already made it to VCL. It looks as if the compiler/STL problems are solved now in your AOO-dev environment. 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. Investigating this problem suggests that the preprocessor-condition in line 42 of main/tools/inc/tools/prex.h may need to be updated for newer Solaris platforms. I'm not sure whether this condition is still needed at all. It looks like a check to allow older platforms to run, but if all interesting unix targets like Linux and FreeBSD (and now Solaris?) don't need that condition for backward compatibility any any longer then that condition should be removed. 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. The prex.h and post.x headers in main/tools/inc/tools/ do funny things to make the declarations from the X11 headers appear under a different name... Adjusting line 42 of main/tools/inc/tools/prex.h may solve this problem too. Raymond and I are both somewhat hesitant to start messing with the X11 header files on the system. I certainly agree with that! 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? Adjusting the line suggested above may solve this and many other problems. Good luck! Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Herbert, As an experiment, we moved deque.c, deque.cc, and deque_spec to a backed up file name in /usr/include/stdcxx4, but kept deque as it was. Then the compile continued without error. We are not sure of the reason, but there seems to be some kind of conflict between those files. If you think we should put it back and address this some other way, please let us know. If you understand why the compile is not working after doing this, please share. Thanks. -Original Message- From: Steele, Raymond Sent: Friday, December 13, 2013 12:47 PM To: 'Herbert Duerr'; dev@openoffice.apache.org Cc: Meffe, David K Subject: RE: EXTERNAL: Re: Building comphelper Herbert, Your idea worked. We were able to comment out those lines in the prex.h and the system was able to successfully build the VCL module as well as several others. We can almost taste the finish line. However we have encountered another problem with the build that is a little more difficult than just sorting out the included header files and paths, this time in the slideshow module. The error is located in the c++ /usr/include/stdcxx4/deque.cc on line 569 and states that ShapeImporter::XShapeEntry has a const member mpGroupShape and cannot be reassigned. We can see in shapeimporter.cxx that line 181 is indeed a const definition of mpGroupShape, but it doesn't seem to tie directly to line 569 in deque.cc. This may be because deque.cc may be used as a template, and the assignment is forbidden because the value in XShapeEntry is a const, but is there a way around this? Do you have a thought as what we might try to continue with the build? David -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Friday, December 13, 2013 1:25 AM To: dev@openoffice.apache.org Cc: Meffe, David K; Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi David, Hi Raymond, On 12.12.2013 22:54, Steele, Raymond wrote: 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. I'm very glad to hear that you already made it to VCL. It looks as if the compiler/STL problems are solved now in your AOO-dev environment. 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. Investigating this problem suggests that the preprocessor-condition in line 42 of main/tools/inc/tools/prex.h may need to be updated for newer Solaris platforms. I'm not sure whether this condition is still needed at all. It looks like a check to allow older platforms to run, but if all interesting unix targets like Linux and FreeBSD (and now Solaris?) don't need that condition for backward compatibility any any longer then that condition should be removed. 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. The prex.h and post.x headers in main/tools/inc/tools/ do funny things to make the declarations from the X11 headers appear under a different name... Adjusting line 42 of main/tools/inc/tools/prex.h may solve this problem too. Raymond and I are both somewhat hesitant to start messing with the X11 header files on the system. I certainly agree with that! 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? Adjusting the line suggested above may solve this and many other problems. Good luck! Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Ok, nevermind. We are back to the original problem. -Original Message- From: Steele, Raymond Sent: Friday, December 13, 2013 1:45 PM To: 'Herbert Duerr'; 'dev@openoffice.apache.org' Cc: Meffe, David K Subject: RE: EXTERNAL: Re: Building comphelper Herbert, As an experiment, we moved deque.c, deque.cc, and deque_spec to a backed up file name in /usr/include/stdcxx4, but kept deque as it was. Then the compile continued without error. We are not sure of the reason, but there seems to be some kind of conflict between those files. If you think we should put it back and address this some other way, please let us know. If you understand why the compile is not working after doing this, please share. Thanks. -Original Message- From: Steele, Raymond Sent: Friday, December 13, 2013 12:47 PM To: 'Herbert Duerr'; dev@openoffice.apache.org Cc: Meffe, David K Subject: RE: EXTERNAL: Re: Building comphelper Herbert, Your idea worked. We were able to comment out those lines in the prex.h and the system was able to successfully build the VCL module as well as several others. We can almost taste the finish line. However we have encountered another problem with the build that is a little more difficult than just sorting out the included header files and paths, this time in the slideshow module. The error is located in the c++ /usr/include/stdcxx4/deque.cc on line 569 and states that ShapeImporter::XShapeEntry has a const member mpGroupShape and cannot be reassigned. We can see in shapeimporter.cxx that line 181 is indeed a const definition of mpGroupShape, but it doesn't seem to tie directly to line 569 in deque.cc. This may be because deque.cc may be used as a template, and the assignment is forbidden because the value in XShapeEntry is a const, but is there a way around this? Do you have a thought as what we might try to continue with the build? David -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Friday, December 13, 2013 1:25 AM To: dev@openoffice.apache.org Cc: Meffe, David K; Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi David, Hi Raymond, On 12.12.2013 22:54, Steele, Raymond wrote: 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. I'm very glad to hear that you already made it to VCL. It looks as if the compiler/STL problems are solved now in your AOO-dev environment. 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. Investigating this problem suggests that the preprocessor-condition in line 42 of main/tools/inc/tools/prex.h may need to be updated for newer Solaris platforms. I'm not sure whether this condition is still needed at all. It looks like a check to allow older platforms to run, but if all interesting unix targets like Linux and FreeBSD (and now Solaris?) don't need that condition for backward compatibility any any longer then that condition should be removed. 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. The prex.h and post.x headers in main/tools/inc/tools/ do funny things to make the declarations from the X11 headers appear under a different name... Adjusting line 42 of main/tools/inc/tools/prex.h may solve this problem too. Raymond and I are both somewhat hesitant to start messing with the X11 header files on the system. I certainly agree with that! 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? Adjusting the line suggested above may solve this and many other problems. Good luck! Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
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
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: EXTERNAL: Re: Building comphelper
Fantastic! We were actually looking at that [2] yesterday, but were concerned because it was dated 7 months ago. We will implement it and provide feedback. Thanks again! Raymond -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Tuesday, December 10, 2013 11:25 PM To: dev@openoffice.apache.org Cc: Meffe, David K; Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi David, Hi Raymond, On 11.12.2013 00:16, you wrote: Thanks for much of the help you have provided in this venture to help us get OpenOffice working in Solaris 11. Because of this we have gotten further into the compile of the OpenOffice software. We have moved past the external sources compile errors by using a newer version of Boost (1.49) and adding in the updates to the emplace_args.hpp file that have been posted on the web. Speaking of newer boost versions please also see [1] (an enhancement issue I created to update to boost 1.55). I developed a patch to do that and added it there to do this. You might want to try it out. [1] https://issues.apache.org/ooo/show_bug.cgi?id=123817 However, we are now encountering a problem within the binaryurp in the bridge.cxx compile. The first error message is as follows: ../main/binaryurp/source/cache.hxx, line 113: Error: iterator is not a member of std::mapcom:sun::star::uno::TypeDescription,binaryurp::Cachecom::sun::star::uno::TypeDescription::Entry. Looking at the code, it doesn't seem like an obvious error. The line it complains about is inside a struct Entry and the error occurs when defining a member variable named prev as a Map::iterator. We could use some insight into this problem and would appreciate any help. Thanks. According to the C++ standard the compiler/STL is right to complain about that code: the Entry type is incomplete until the declaration is over and a Map iterator with Entry as its mapped_type can not be expected to work while Entry is being declared. Some compiler/STL combinations allow it, but some don't. Especially the better ones (which don't treat all mapped_types the same but have optimized template specializations) run into problems here. The good news is that I already developed a replacement for this problematic code to make it more compatible with standard complying compilers/STLs. Please try out the patch in [2]. I was about to merge this into trunk soon anyway, but if you could confirm that it solves the problem on your platform this would accelerate the integration. [2] http://svn.apache.org/viewvc?view=revisionrevision=1480367 Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Herbert, The changes [2] worked perfectly for us. Now we are having issues compiling ::std::select1st in namedvaluecollection.cxx on line 175. Apparently, select1st is not a member of std. It appears that you may have created a ticket for this one. https://issues.apache.org/ooo/show_bug.cgi?id=123754 Raymond -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Tuesday, December 10, 2013 11:25 PM To: dev@openoffice.apache.org Cc: Meffe, David K; Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi David, Hi Raymond, On 11.12.2013 00:16, you wrote: Thanks for much of the help you have provided in this venture to help us get OpenOffice working in Solaris 11. Because of this we have gotten further into the compile of the OpenOffice software. We have moved past the external sources compile errors by using a newer version of Boost (1.49) and adding in the updates to the emplace_args.hpp file that have been posted on the web. Speaking of newer boost versions please also see [1] (an enhancement issue I created to update to boost 1.55). I developed a patch to do that and added it there to do this. You might want to try it out. [1] https://issues.apache.org/ooo/show_bug.cgi?id=123817 However, we are now encountering a problem within the binaryurp in the bridge.cxx compile. The first error message is as follows: ../main/binaryurp/source/cache.hxx, line 113: Error: iterator is not a member of std::mapcom:sun::star::uno::TypeDescription,binaryurp::Cachecom::sun::star::uno::TypeDescription::Entry. Looking at the code, it doesn't seem like an obvious error. The line it complains about is inside a struct Entry and the error occurs when defining a member variable named prev as a Map::iterator. We could use some insight into this problem and would appreciate any help. Thanks. According to the C++ standard the compiler/STL is right to complain about that code: the Entry type is incomplete until the declaration is over and a Map iterator with Entry as its mapped_type can not be expected to work while Entry is being declared. Some compiler/STL combinations allow it, but some don't. Especially the better ones (which don't treat all mapped_types the same but have optimized template specializations) run into problems here. The good news is that I already developed a replacement for this problematic code to make it more compatible with standard complying compilers/STLs. Please try out the patch in [2]. I was about to merge this into trunk soon anyway, but if you could confirm that it solves the problem on your platform this would accelerate the integration. [2] http://svn.apache.org/viewvc?view=revisionrevision=1480367 Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
For select1st, we noticed that the functional header delivered with stdcxx4 did not define select1st, 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. 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. Raymond -Original Message- From: Steele, Raymond Sent: Wednesday, December 11, 2013 8:49 AM To: 'Herbert Duerr'; dev@openoffice.apache.org Cc: Meffe, David K Subject: RE: EXTERNAL: Re: Building comphelper Herbert, The changes [2] worked perfectly for us. Now we are having issues compiling ::std::select1st in namedvaluecollection.cxx on line 175. Apparently, select1st is not a member of std. It appears that you may have created a ticket for this one. https://issues.apache.org/ooo/show_bug.cgi?id=123754 Raymond -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Tuesday, December 10, 2013 11:25 PM To: dev@openoffice.apache.org Cc: Meffe, David K; Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi David, Hi Raymond, On 11.12.2013 00:16, you wrote: Thanks for much of the help you have provided in this venture to help us get OpenOffice working in Solaris 11. Because of this we have gotten further into the compile of the OpenOffice software. We have moved past the external sources compile errors by using a newer version of Boost (1.49) and adding in the updates to the emplace_args.hpp file that have been posted on the web. Speaking of newer boost versions please also see [1] (an enhancement issue I created to update to boost 1.55). I developed a patch to do that and added it there to do this. You might want to try it out. [1] https://issues.apache.org/ooo/show_bug.cgi?id=123817 However, we are now encountering a problem within the binaryurp in the bridge.cxx compile. The first error message is as follows: ../main/binaryurp/source/cache.hxx, line 113: Error: iterator is not a member of std::mapcom:sun::star::uno::TypeDescription,binaryurp::Cachecom::sun::star::uno::TypeDescription::Entry. Looking at the code, it doesn't seem like an obvious error. The line it complains about is inside a struct Entry and the error occurs when defining a member variable named prev as a Map::iterator. We could use some insight into this problem and would appreciate any help. Thanks. According to the C++ standard the compiler/STL is right to complain about that code: the Entry type is incomplete until the declaration is over and a Map iterator with Entry as its mapped_type can not be expected to work while Entry is being declared. Some compiler/STL combinations allow it, but some don't. Especially the better ones (which don't treat all mapped_types the same but have optimized template specializations) run into problems here. The good news is that I already developed a replacement for this problematic code to make it more compatible with standard complying compilers/STLs. Please try out the patch in [2]. I was about to merge this into trunk soon anyway, but if you could confirm that it solves the problem on your platform this would accelerate the integration. [2] http://svn.apache.org/viewvc?view=revisionrevision=1480367 Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
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
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
RE: EXTERNAL: Re: Building comphelper
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
RE: EXTERNAL: Re: Building comphelper
Herbert Duerr, Thanks for much of the help you have provided in this venture to help us get OpenOffice working in Solaris 11. Because of this we have gotten further into the compile of the OpenOffice software. We have moved past the external sources compile errors by using a newer version of Boost (1.49) and adding in the updates to the emplace_args.hpp file that have been posted on the web. However, we are now encountering a problem within the binaryurp in the bridge.cxx compile. The first error message is as follows: ../main/binaryurp/source/cache.hxx, line 113: Error: iterator is not a member of std::mapcom:sun::star::uno::TypeDescription,binaryurp::Cachecom::sun::star::uno::TypeDescription::Entry. Looking at the code, it doesn't seem like an obvious error. The line it complains about is inside a struct Entry and the error occurs when defining a member variable named prev as a Map::iterator. We could use some insight into this problem and would appreciate any help. Thanks. David Meffe -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Thursday, December 05, 2013 2:42 AM To: dev@openoffice.apache.org Cc: Meffe, David K; Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, Thanks Herbert. Do you have any idea why we would be receiving the following? Compiling: sal/rtl/source/unload.cxx /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 199: Error:Could not find a match for boost::tuples::getboost::tuples::N,boost::tuples::HT, boost::tuples::TT(constboost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type) needed inboost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node,boost::tuples::null_type(configmgr::Partial::Node*, constboost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350:Where: While instantiatingboost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node,boost::tuples::null_type(configmgr::Partial::Node*, constboost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350:Where: Instantiated from boost::unordered::unordered_maprtl::OUString,configmgr::Partial::Node, boost::hashrtl::OUString,_STL::equal_tortl::OUString, _STL::allocator_STL::pairconst rtl::OUString,configmgr::Partial::Node::operator[](const rtl::OUString). /opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx , line 217: Where: Instantiated from non-template code. Are you using the configure option --with-system-boost? If not, then the boost headers should be found in .../main/solenv/*/unx*/inc/boost/ and not in /usr/local/include/boost/ The top suspect for the actual problem you are seeing is a boost problem [1]. It was fixed in boost 1.49 with [2]. AOO is currently using boost 1.48 but problems such as this indicate that an update is overdue. [1] https://svn.boost.org/trac/boost/ticket/6784 [2] https://svn.boost.org/trac/boost/changeset/77972 Could you try to apply the patch [2] to the problematic boost header to check whether this solves the problem? If yes, we could apply it to our local boost header with the patch mechanism. Or even better we could update our boost libs, but that would eventually open another can of worms... Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Hi David, Hi Raymond, On 11.12.2013 00:16, you wrote: Thanks for much of the help you have provided in this venture to help us get OpenOffice working in Solaris 11. Because of this we have gotten further into the compile of the OpenOffice software. We have moved past the external sources compile errors by using a newer version of Boost (1.49) and adding in the updates to the emplace_args.hpp file that have been posted on the web. Speaking of newer boost versions please also see [1] (an enhancement issue I created to update to boost 1.55). I developed a patch to do that and added it there to do this. You might want to try it out. [1] https://issues.apache.org/ooo/show_bug.cgi?id=123817 However, we are now encountering a problem within the binaryurp in the bridge.cxx compile. The first error message is as follows: ../main/binaryurp/source/cache.hxx, line 113: Error: iterator is not a member of std::mapcom:sun::star::uno::TypeDescription,binaryurp::Cachecom::sun::star::uno::TypeDescription::Entry. Looking at the code, it doesn't seem like an obvious error. The line it complains about is inside a struct Entry and the error occurs when defining a member variable named prev as a Map::iterator. We could use some insight into this problem and would appreciate any help. Thanks. According to the C++ standard the compiler/STL is right to complain about that code: the Entry type is incomplete until the declaration is over and a Map iterator with Entry as its mapped_type can not be expected to work while Entry is being declared. Some compiler/STL combinations allow it, but some don't. Especially the better ones (which don't treat all mapped_types the same but have optimized template specializations) run into problems here. The good news is that I already developed a replacement for this problematic code to make it more compatible with standard complying compilers/STLs. Please try out the patch in [2]. I was about to merge this into trunk soon anyway, but if you could confirm that it solves the problem on your platform this would accelerate the integration. [2] http://svn.apache.org/viewvc?view=revisionrevision=1480367 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 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
Re: EXTERNAL: Re: Building comphelper
On Thu, Dec 5, 2013 at 10:56 PM, Herbert Duerr h...@apache.org wrote: Hi Raymond, Steele, Raymond wrote: Are you recommending that we use boost version 1_49 versus the one delivered with OpenOffice? Please see my other mail (Using system boost 1.54) from today. It is desirable that AOO should build with newer system boost versions too, but it requires probably more than just a recompile to make everything work. Volunteers are invited to work on this interesting topic. If so, then we will reconfigure using the --with-system-boost flag. If we use 1_49, does it require any special configure / build steps? I'm not sure whether anyone actually built AOO with boost 1.49, 1.50, 1.51, 1.52, 1.53 or the 1.54 versions, so you're in unexplored territory. Maybe 1.49 is close enough to 1.48 so using it could work out of the box with AOO. But as Kay noticed 1.54 is already so different that more work is needed for sure. oh boy and thanks...I guess I missed your earlier post...I will revert to 1.49 with the patch as well. Keeping my fingers crossed. Today, we replaced the 1_48 version of emplace_args.hpp with the 1_49 version, then implemented the patch [2] and the issues below went away, Thanks for checking: It proves that we're on the right track! but the compile complains about an undefined boost type on line 220 : BOOST_UNORDERED_CONSTRUCT_FROM_TUPLE(10, boost) We are thinking that we need to pull in another file from 1_49, but that may snowball into needing more files, but we are not sure. That snowball/domino effect is a real problem. And we always prefer to work with off-the-shelf releases of external libraries if possible. In your case I'd try to - replace the missing boost type, but as [1] shows they are using some magic there especially for Solaris compilers - rebuild with system-boost 1.49 - rebuild with system-boost 1.50 [1] http://lists.boost.org/boost-commit/2012/04/40663.php If these alternatives don't work then we really need a volunteer who solves the build problems with the latest 1.55 version so that AOO's internal version can be upgraded to that. 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: EXTERNAL: Re: Building comphelper
Hi Raymond, Thanks Herbert. Do you have any idea why we would be receiving the following? Compiling: sal/rtl/source/unload.cxx /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 199: Error:Could not find a match for boost::tuples::getboost::tuples::N,boost::tuples::HT, boost::tuples::TT(constboost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type) needed inboost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node,boost::tuples::null_type(configmgr::Partial::Node*, constboost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350:Where: While instantiatingboost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node,boost::tuples::null_type(configmgr::Partial::Node*, constboost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350:Where: Instantiated from boost::unordered::unordered_maprtl::OUString,configmgr::Partial::Node, boost::hashrtl::OUString,_STL::equal_tortl::OUString, _STL::allocator_STL::pairconst rtl::OUString,configmgr::Partial::Node::operator[](const rtl::OUString). /opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx , line 217: Where: Instantiated from non-template code. Are you using the configure option --with-system-boost? If not, then the boost headers should be found in .../main/solenv/*/unx*/inc/boost/ and not in /usr/local/include/boost/ The top suspect for the actual problem you are seeing is a boost problem [1]. It was fixed in boost 1.49 with [2]. AOO is currently using boost 1.48 but problems such as this indicate that an update is overdue. [1] https://svn.boost.org/trac/boost/ticket/6784 [2] https://svn.boost.org/trac/boost/changeset/77972 Could you try to apply the patch [2] to the problematic boost header to check whether this solves the problem? If yes, we could apply it to our local boost header with the patch mechanism. Or even better we could update our boost libs, but that would eventually open another can of worms... Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
On Thu, Dec 5, 2013 at 1:41 AM, Herbert Duerr h...@apache.org wrote: Hi Raymond, Thanks Herbert. Do you have any idea why we would be receiving the following? Compiling: sal/rtl/source/unload.cxx /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 199: Error:Could not find a match for boost::tuples::getboost::tuples::N,boost::tuples::HT, boost::tuples::TT(constboost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type) needed inboost::unordered::detail:: construct_from_tupleconfigmgr::Partial::Node,boost::tuples::null_type(configmgr::Partial::Node*, constboost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350:Where: While instantiatingboost::unordered::detail::construct_ from_tupleconfigmgr::Partial::Node,boost::tuples::null_ type(configmgr::Partial::Node*, constboost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350:Where: Instantiated from boost::unordered::unordered_ maprtl::OUString,configmgr::Partial::Node, boost::hashrtl::OUString,_STL::equal_tortl::OUString, _STL::allocator_STL::pairconst rtl::OUString,configmgr:: Partial::Node::operator[](const rtl::OUString). /opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx , line 217: Where: Instantiated from non-template code. Are you using the configure option --with-system-boost? If not, then the boost headers should be found in .../main/solenv/*/unx*/inc/boost/ and not in /usr/local/include/boost/ The top suspect for the actual problem you are seeing is a boost problem [1]. It was fixed in boost 1.49 with [2]. AOO is currently using boost 1.48 but problems such as this indicate that an update is overdue. [1] https://svn.boost.org/trac/boost/ticket/6784 [2] https://svn.boost.org/trac/boost/changeset/77972 Could you try to apply the patch [2] to the problematic boost header to check whether this solves the problem? If yes, we could apply it to our local boost header with the patch mechanism. Or even better we could update our boost libs, but that would eventually open another can of worms... Herbert 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 Is it OK to use this newer version because I'm getting errors originating originating from main/sal/osl/all/debugbase.cxx ... main/solver/410/unxlngi6.pro/inc/stl/functional:37 from /usr/include/boost/functional/hash/hash.hpp:529:0, -- /usr/include/boost/functional/hash/extensions.hpp (many errors) Thanks.. - 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: EXTERNAL: Re: Building comphelper
Herbert, Are you recommending that we use boost version 1_49 versus the one delivered with OpenOffice? If so, then we will reconfigure using the --with-system-boost flag. If we use 1_49, does it require any special configure / build steps? Today, we replaced the 1_48 version of emplace_args.hpp with the 1_49 version, then implemented the patch [2] and the issues below went away, but the compile complains about an undefined boost type on line 220 : BOOST_UNORDERED_CONSTRUCT_FROM_TUPLE(10, boost) We are thinking that we need to pull in another file from 1_49, but that may snowball into needing more files, but we are not sure. -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Thursday, December 05, 2013 2:42 AM To: dev@openoffice.apache.org Cc: Meffe, David K; Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, Thanks Herbert. Do you have any idea why we would be receiving the following? Compiling: sal/rtl/source/unload.cxx /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 199: Error:Could not find a match for boost::tuples::getboost::tuples::N,boost::tuples::HT, boost::tuples::TT(constboost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type) needed inboost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node,boost::tuples::null_type(configmgr::Partial::Node*, constboost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350:Where: While instantiatingboost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node,boost::tuples::null_type(configmgr::Partial::Node*, constboost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350:Where: Instantiated from boost::unordered::unordered_maprtl::OUString,configmgr::Partial::Node, boost::hashrtl::OUString,_STL::equal_tortl::OUString, _STL::allocator_STL::pairconst rtl::OUString,configmgr::Partial::Node::operator[](const rtl::OUString). /opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx , line 217: Where: Instantiated from non-template code. Are you using the configure option --with-system-boost? If not, then the boost headers should be found in .../main/solenv/*/unx*/inc/boost/ and not in /usr/local/include/boost/ The top suspect for the actual problem you are seeing is a boost problem [1]. It was fixed in boost 1.49 with [2]. AOO is currently using boost 1.48 but problems such as this indicate that an update is overdue. [1] https://svn.boost.org/trac/boost/ticket/6784 [2] https://svn.boost.org/trac/boost/changeset/77972 Could you try to apply the patch [2] to the problematic boost header to check whether this solves the problem? If yes, we could apply it to our local boost header with the patch mechanism. Or even better we could update our boost libs, but that would eventually open another can of worms... Herbert
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
Re: EXTERNAL: Re: Building comphelper
Hi Raymond, Thanks for the information. Sorry about the PDF. Unfortunately, we are unable to do a simple copy and paste because of the way are system is setup. The only other option that I have is to type the output, but that would have taken much longer. Ok. I just wanted to make sure that its not a simple oversight. C++ template errors are often very extensive and look quite scary. If the problem hides in a little type difference of the n-th argument of a multi-layer template specialization, then finding these miniscule differences is hard enough even with regexp magic or with specialized tools (template error message decryptors) such as STLFilt. Without the error message text but just images of this text it becomes much harder to diagnose a problem. We just implemented the patch, but are still receiving the same output. We are investigating now. This cannot possibly be! The original error output was that construction of the insertion object failed because of type and constness mismatches. With the patch there is no insertion object anymore, so there error output cannot possibly be the same! Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Hi Raymond, Just to give you an update. We were able compile debugbase.cxx by including /opt/solarisstudios12.3/prod/include/CC/stlport4 Ah, please don't. Stlport4 is dead. , but the next module wanted ../include/CC/Cstd. Then it went back and forth. There seems to be a disconnect between which C/C++ implementation it wants and I do not think they are compatible with each other. Yes, they are not compatible to each other. As of now, we've loaded the Apache C++ stdcxx4 implementation so that we can retry using just the one implementation. However, we've noticed that stdcxx4 does not provide hash_map and hash_set, among others, Indeed: hash_map and hash_set were replaced by unordered_map and unordered_set in the C++ standardization process. In our codebase we'll have to replace them but for now they are already mapped to their newer counterparts using wrappers in the main/stlport/systemstl/hash_* headers. Please make sure that you are using --without-stlport in your configure option so that this wrapping becomes active. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Thanks Herbert. Do you have any idea why we would be receiving the following? Compiling: sal/rtl/source/unload.cxx /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 199: Error:Could not find a match for boost::tuples::getboost::tuples::N,boost::tuples::HT, boost::tuples::TT(constboost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type) needed inboost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node,boost::tuples::null_type(configmgr::Partial::Node*, constboost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350:Where: While instantiatingboost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node,boost::tuples::null_type(configmgr::Partial::Node*, constboost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350:Where: Instantiated from boost::unordered::unordered_maprtl::OUString,configmgr::Partial::Node, boost::hashrtl::OUString,_STL::equal_tortl::OUString, _STL::allocator_STL::pairconst rtl::OUString,configmgr::Partial::Node::operator[](const rtl::OUString). /opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx , line 217: Where: Instantiated from non-template code. -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Wednesday, December 04, 2013 3:54 AM To: dev@openoffice.apache.org Cc: Steele, Raymond; Meffe, David K Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, Just to give you an update. We were able compile debugbase.cxx by including /opt/solarisstudios12.3/prod/include/CC/stlport4 Ah, please don't. Stlport4 is dead. , but the next module wanted ../include/CC/Cstd. Then it went back and forth. There seems to be a disconnect between which C/C++ implementation it wants and I do not think they are compatible with each other. Yes, they are not compatible to each other. As of now, we've loaded the Apache C++ stdcxx4 implementation so that we can retry using just the one implementation. However, we've noticed that stdcxx4 does not provide hash_map and hash_set, among others, Indeed: hash_map and hash_set were replaced by unordered_map and unordered_set in the C++ standardization process. In our codebase we'll have to replace them but for now they are already mapped to their newer counterparts using wrappers in the main/stlport/systemstl/hash_* headers. Please make sure that you are using --without-stlport in your configure option so that this wrapping becomes active. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
A small correction for my patch suggestion: On 03.12.2013 11:36, Herbert Duerr wrote: [...] +DEBUGBASE_ENSURE( !bOK, ### insertion failed!? ); The condition there was inverted. It should have been DEBUGBASE_ENSURE( bOK, ### insertion failed!? ); Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 02.12.2013 23:34, Steele, Raymond wrote:
Let me know if you did not get the attachment.
Attachments usually get stripped on the mailing list, but I got it
because was on CC. As the PDF only contained scanned text a simple
copy+paste of that text would have been better.
We are having trouble interpreting the boost preprocessor macros. We are
receiving the following output when compiling sal/osl/all. I've attached the
output as a pdf.
Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a
hand-crafted map::value_type and const correctness. Please try
this patch to make the construct more digestible:
--- main/sal/osl/all/debugbase.cxx
+++ main/sal/osl/all/debugbase.cxx
@@ -129,10 +129,9 @@ void SAL_CALL osl_detail_ObjectRegistry_registerObject(
{
if (rData.m_bStoreAddresses) {
osl::MutexGuard const guard(
osl_detail_ObjectRegistry_getMutex() );
-std::pairosl::detail::VoidPointerSet::iterator, bool const
insertion(
-rData.m_addresses.insert(pObj) );
-DEBUGBASE_ENSURE( insertion.second, ### insertion failed!? );
-static_castvoid(insertion);
+const bool bOK = rData.m_addresses.insert(pObj).second;
+DEBUGBASE_ENSURE( !bOK, ### insertion failed!? );
+(void)bOK; // unused for non-debug
}
else {
osl_incrementInterlockedCount(rData.m_nCount);
Please report whether this helps, I'll commit the change then.
Herbert
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Herbert,
Thanks for the information. Sorry about the PDF. Unfortunately, we are unable
to do a simple copy and paste because of the way are system is setup. The only
other option that I have is to type the output, but that would have taken much
longer. We just implemented the patch, but are still receiving the same
output. We are investigating now.
Thanks,
Raymond
-Original Message-
From: Herbert Duerr [mailto:h...@apache.org]
Sent: Tuesday, December 03, 2013 3:36 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 02.12.2013 23:34, Steele, Raymond wrote:
Let me know if you did not get the attachment.
Attachments usually get stripped on the mailing list, but I got it because was
on CC. As the PDF only contained scanned text a simple
copy+paste of that text would have been better.
We are having trouble interpreting the boost preprocessor macros. We are
receiving the following output when compiling sal/osl/all. I've attached the
output as a pdf.
Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a
hand-crafted map::value_type and const correctness. Please try
this patch to make the construct more digestible:
--- main/sal/osl/all/debugbase.cxx
+++ main/sal/osl/all/debugbase.cxx
@@ -129,10 +129,9 @@ void SAL_CALL osl_detail_ObjectRegistry_registerObject(
{
if (rData.m_bStoreAddresses) {
osl::MutexGuard const guard(
osl_detail_ObjectRegistry_getMutex() );
-std::pairosl::detail::VoidPointerSet::iterator, bool const
insertion(
-rData.m_addresses.insert(pObj) );
-DEBUGBASE_ENSURE( insertion.second, ### insertion failed!? );
-static_castvoid(insertion);
+const bool bOK = rData.m_addresses.insert(pObj).second;
+DEBUGBASE_ENSURE( !bOK, ### insertion failed!? );
+(void)bOK; // unused for non-debug
}
else {
osl_incrementInterlockedCount(rData.m_nCount);
Please report whether this helps, I'll commit the change then.
Herbert
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Just to give you an update.
We were able compile debugbase.cxx by including
/opt/solarisstudios12.3/prod/include/CC/stlport4, but the next module wanted
../include/CC/Cstd. Then it went back and forth. There seems to be a
disconnect between which C/C++ implementation it wants and I do not think they
are compatible with each other. As of now, we've loaded the Apache C++ stdcxx4
implementation so that we can retry using just the one implementation. However,
we've noticed that stdcxx4 does not provide hash_map and hash_set, among
others, so we included ../main/stlport/system1/ files. Hopefully, this will
work for us. If you have any comments ideas, please let us know.
Raymond
-Original Message-
From: Steele, Raymond
Sent: Tuesday, December 03, 2013 9:22 AM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Herbert,
Thanks for the information. Sorry about the PDF. Unfortunately, we are unable
to do a simple copy and paste because of the way are system is setup. The only
other option that I have is to type the output, but that would have taken much
longer. We just implemented the patch, but are still receiving the same
output. We are investigating now.
Thanks,
Raymond
-Original Message-
From: Herbert Duerr [mailto:h...@apache.org]
Sent: Tuesday, December 03, 2013 3:36 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 02.12.2013 23:34, Steele, Raymond wrote:
Let me know if you did not get the attachment.
Attachments usually get stripped on the mailing list, but I got it because was
on CC. As the PDF only contained scanned text a simple
copy+paste of that text would have been better.
We are having trouble interpreting the boost preprocessor macros. We are
receiving the following output when compiling sal/osl/all. I've attached the
output as a pdf.
Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a hand-crafted
map::value_type and const correctness. Please try this patch to make the
construct more digestible:
--- main/sal/osl/all/debugbase.cxx
+++ main/sal/osl/all/debugbase.cxx
@@ -129,10 +129,9 @@ void SAL_CALL osl_detail_ObjectRegistry_registerObject(
{
if (rData.m_bStoreAddresses) {
osl::MutexGuard const guard(
osl_detail_ObjectRegistry_getMutex() );
-std::pairosl::detail::VoidPointerSet::iterator, bool const
insertion(
-rData.m_addresses.insert(pObj) );
-DEBUGBASE_ENSURE( insertion.second, ### insertion failed!? );
-static_castvoid(insertion);
+const bool bOK = rData.m_addresses.insert(pObj).second;
+DEBUGBASE_ENSURE( !bOK, ### insertion failed!? );
+(void)bOK; // unused for non-debug
}
else {
osl_incrementInterlockedCount(rData.m_nCount);
Please report whether this helps, I'll commit the change then.
Herbert
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Here is what we ended the day with after making the changes to the includes.
Compiling: sal/rtl/source/unload.cxx
/usr/local/include/boost/unordered/detail/emplace_args.hpp, line 199:
Error:Could not find a match for
boost::tuples::getboost::tuples::N,boost::tuples::HT,
boost::tuples::TT(constboost::tuples::tupleboost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type)
needed
inboost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node,boost::tuples::null_type(configmgr::Partial::Node*,
constboost::tuples::tupleboost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type).
/usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350:Where:
While
instantiatingboost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node,boost::tuples::null_type(configmgr::Partial::Node*,
constboost::tuples::tupleboost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type, boost::tuples::null_type).
/usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350:Where:
Instantiated from
boost::unordered::unordered_maprtl::OUString,configmgr::Partial::Node,
boost::hashrtl::OUString,_STL::equal_tortl::OUString,
_STL::allocator_STL::pairconst
rtl::OUString,configmgr::Partial::Node::operator[](const rtl::OUString).
/opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx , line 217: Where:
Instantiated from non-template code.
-Original Message-
From: Steele, Raymond
Sent: Tuesday, December 03, 2013 2:41 PM
To: 'Herbert Duerr'; 'dev@openoffice.apache.org'
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Just to give you an update.
We were able compile debugbase.cxx by including
/opt/solarisstudios12.3/prod/include/CC/stlport4, but the next module wanted
../include/CC/Cstd. Then it went back and forth. There seems to be a
disconnect between which C/C++ implementation it wants and I do not think they
are compatible with each other. As of now, we've loaded the Apache C++ stdcxx4
implementation so that we can retry using just the one implementation. However,
we've noticed that stdcxx4 does not provide hash_map and hash_set, among
others, so we included ../main/stlport/system1/ files. Hopefully, this will
work for us. If you have any comments ideas, please let us know.
Raymond
-Original Message-
From: Steele, Raymond
Sent: Tuesday, December 03, 2013 9:22 AM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Herbert,
Thanks for the information. Sorry about the PDF. Unfortunately, we are unable
to do a simple copy and paste because of the way are system is setup. The only
other option that I have is to type the output, but that would have taken much
longer. We just implemented the patch, but are still receiving the same
output. We are investigating now.
Thanks,
Raymond
-Original Message-
From: Herbert Duerr [mailto:h...@apache.org]
Sent: Tuesday, December 03, 2013 3:36 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 02.12.2013 23:34, Steele, Raymond wrote:
Let me know if you did not get the attachment.
Attachments usually get stripped on the mailing list, but I got it because was
on CC. As the PDF only contained scanned text a simple
copy+paste of that text would have been better.
We are having trouble interpreting the boost preprocessor macros. We are
receiving the following output when compiling sal/osl/all. I've attached the
output as a pdf.
Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a hand-crafted
map::value_type and const correctness. Please try this patch to make the
construct more digestible:
--- main/sal/osl/all/debugbase.cxx
+++ main/sal/osl/all/debugbase.cxx
@@ -129,10 +129,9 @@ void SAL_CALL osl_detail_ObjectRegistry_registerObject(
{
if (rData.m_bStoreAddresses) {
osl::MutexGuard const guard(
osl_detail_ObjectRegistry_getMutex() );
-std::pairosl::detail::VoidPointerSet::iterator, bool const
insertion(
-rData.m_addresses.insert(pObj) );
-DEBUGBASE_ENSURE( insertion.second, ### insertion failed!? );
-static_castvoid(insertion);
+const bool bOK = rData.m_addresses.insert(pObj).second;
+DEBUGBASE_ENSURE( !bOK, ### insertion failed!? );
+(void)bOK; // unused for non-debug
}
else
Re: EXTERNAL: Re: Building comphelper
On Tue, Dec 3, 2013 at 3:09 PM, Steele, Raymond raymond.ste...@lmco.comwrote:
Here is what we ended the day with after making the changes to the
includes.
Compiling: sal/rtl/source/unload.cxx
/usr/local/include/boost/unordered/detail/emplace_args.hpp, line 199:
Error:Could not find a match for
boost::tuples::getboost::tuples::N,boost::tuples::HT,
boost::tuples::TT(constboost::tuples::tupleboost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type,
boost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type,
boost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type,
boost::tuples::null_type) needed
inboost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node,boost::tuples::null_type(configmgr::Partial::Node*,
constboost::tuples::tupleboost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type,
boost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type,
boost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type,
boost::tuples::null_type).
/usr/local/include/boost/unordered/detail/emplace_args.hpp, line
350:Where: While
instantiatingboost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node,boost::tuples::null_type(configmgr::Partial::Node*,
constboost::tuples::tupleboost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type,
boost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type,
boost::tuples::null_type,
boost::tuples::null_type,boost::tuples::null_type,
boost::tuples::null_type).
/usr/local/include/boost/unordered/detail/emplace_args.hpp, line
350:Where: Instantiated from
boost::unordered::unordered_maprtl::OUString,configmgr::Partial::Node,
boost::hashrtl::OUString,_STL::equal_tortl::OUString,
_STL::allocator_STL::pairconst
rtl::OUString,configmgr::Partial::Node::operator[](const rtl::OUString).
/opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx , line 217: Where:
Instantiated from non-template code.
I'm following this progress as well, since I, too, am having many problems
with boost disconnects in this same area. I did NOT include any additional
libraires as you did, so I'm still stuck in sal. :/
-Original Message-
From: Steele, Raymond
Sent: Tuesday, December 03, 2013 2:41 PM
To: 'Herbert Duerr'; 'dev@openoffice.apache.org'
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Just to give you an update.
We were able compile debugbase.cxx by including
/opt/solarisstudios12.3/prod/include/CC/stlport4, but the next module
wanted ../include/CC/Cstd. Then it went back and forth. There seems to be
a disconnect between which C/C++ implementation it wants and I do not think
they are compatible with each other. As of now, we've loaded the Apache
C++ stdcxx4 implementation so that we can retry using just the one
implementation. However, we've noticed that stdcxx4 does not provide
hash_map and hash_set, among others, so we included
../main/stlport/system1/ files. Hopefully, this will work for us. If you
have any comments ideas, please let us know.
Raymond
-Original Message-
From: Steele, Raymond
Sent: Tuesday, December 03, 2013 9:22 AM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Herbert,
Thanks for the information. Sorry about the PDF. Unfortunately, we are
unable to do a simple copy and paste because of the way are system is
setup. The only other option that I have is to type the output, but that
would have taken much longer. We just implemented the patch, but are still
receiving the same output. We are investigating now.
Thanks,
Raymond
-Original Message-
From: Herbert Duerr [mailto:h...@apache.org]
Sent: Tuesday, December 03, 2013 3:36 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 02.12.2013 23:34, Steele, Raymond wrote:
Let me know if you did not get the attachment.
Attachments usually get stripped on the mailing list, but I got it because
was on CC. As the PDF only contained scanned text a simple
copy+paste of that text would have been better.
We are having trouble interpreting the boost preprocessor macros. We are
receiving the following output when compiling sal/osl/all. I've attached
the output as a pdf.
Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a
hand-crafted map::value_type and const correctness. Please try this patch
to make the construct more digestible:
--- main/sal/osl/all/debugbase.cxx
+++ main/sal/osl/all/debugbase.cxx
@@ -129,10 +129,9 @@ void SAL_CALL
osl_detail_ObjectRegistry_registerObject(
{
if (rData.m_bStoreAddresses) {
osl::MutexGuard const guard(
osl_detail_ObjectRegistry_getMutex() );
-std::pairosl::detail::VoidPointerSet::iterator, bool const
insertion
RE: EXTERNAL: Re: Building comphelper
Herbert, We are having trouble interpreting the boost preprocessor macros. We are receiving the following output when compiling sal/osl/all. I've attached the output as a pdf. Raymond -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Friday, November 22, 2013 2:14 AM To: dev@openoffice.apache.org Cc: Steele, Raymond; Meffe, David K Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, On 21.11.2013 22:27, Steele, Raymond wrote: Forget about my last report. We started over and figured out that an environment variable was causing the dmake issues. Once we cleared the environment of variables related to our other projects, the build took off. We will have to figure out what it was later. Thanks for debugging and solving that problem! The current way of configure writing a file for setting environments variables is too fragile. As can be seen in your example if configure is run in an environment that is already contaminated with such env vars then unnecessary causes of troubles exist. IMHO build and config settings should be done via e.g. Makefile.config that should be created by configure. This config result should then be included by the other Makefiles. So if in doubt better use a fresh shell before running configure. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Herbert, Let me know if you did not get the attachment. -Original Message- From: Steele, Raymond Sent: Monday, December 02, 2013 3:29 PM To: 'Herbert Duerr'; dev@openoffice.apache.org Cc: Meffe, David K Subject: RE: EXTERNAL: Re: Building comphelper Herbert, We are having trouble interpreting the boost preprocessor macros. We are receiving the following output when compiling sal/osl/all. I've attached the output as a pdf. Raymond -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Friday, November 22, 2013 2:14 AM To: dev@openoffice.apache.org Cc: Steele, Raymond; Meffe, David K Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, On 21.11.2013 22:27, Steele, Raymond wrote: Forget about my last report. We started over and figured out that an environment variable was causing the dmake issues. Once we cleared the environment of variables related to our other projects, the build took off. We will have to figure out what it was later. Thanks for debugging and solving that problem! The current way of configure writing a file for setting environments variables is too fragile. As can be seen in your example if configure is run in an environment that is already contaminated with such env vars then unnecessary causes of troubles exist. IMHO build and config settings should be done via e.g. Makefile.config that should be created by configure. This config result should then be included by the other Makefiles. So if in doubt better use a fresh shell before running configure. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steele, Raymond wrote: Herbert, Let me know if you did not get the attachment. -Original Message- From: Steele, Raymond Sent: Monday, December 02, 2013 3:29 PM To: 'Herbert Duerr'; dev@openoffice.apache.org Cc: Meffe, David K Subject: RE: EXTERNAL: Re: Building comphelper Herbert, We are having trouble interpreting the boost preprocessor macros. We are receiving the following output when compiling sal/osl/all. I've attached the output as a pdf. Raymond -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Friday, November 22, 2013 2:14 AM To: dev@openoffice.apache.org Cc: Steele, Raymond; Meffe, David K Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, On 21.11.2013 22:27, Steele, Raymond wrote: Forget about my last report. We started over and figured out that an environment variable was causing the dmake issues. Once we cleared the environment of variables related to our other projects, the build took off. We will have to figure out what it was later. Thanks for debugging and solving that problem! The current way of configure writing a file for setting environments variables is too fragile. As can be seen in your example if configure is run in an environment that is already contaminated with such env vars then unnecessary causes of troubles exist. IMHO build and config settings should be done via e.g. Makefile.config that should be created by configure. This config result should then be included by the other Makefiles. So if in doubt better use a fresh shell before running configure. Herbert Raymond; The list strips most attachments. The best method to share would be to put it on-line with a link to it in separate reply to the list. Regards Keith -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSnTeqAAoJEH0fu5UhGmBCL1IH/jfVz8UYC6Z5FEHqN6NYlDHa 27Jpcc2QPWk20CA5Wb7Psj7W6EWPrAOCx5lBTNlDiMojxUYjswCBMP09kA4BiyCE fYZXK1tiLzbs2/YlYvNjf7RCWfE//dIpXMAoe0L17bSIR7dEPFD8b9ItrebD780e /wa6FN0DRVZ4PbzWXm3opKoDMwIvrjofTIffRvz3WJoJO364iY7S09NSGI6cyc7Z s+TdM/tcJpw0tr2XozgDPJGcReY2C2gechiZ5ox1YDHqXMjuk9MOR8xqcijLnTys rqL+SzIovTgBfb/IhAQARCq774B5vn4vM8qk7A9yrhugvCQ4MhP89qbmTjerZY8= =RfR3 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Herbert, Forget about my last report. We started over and figured out that an environment variable was causing the dmake issues. Once we cleared the environment of variables related to our other projects, the build took off. We will have to figure out what it was later. -Original Message- From: Steele, Raymond Sent: Thursday, November 21, 2013 9:28 AM To: 'Herbert Duerr' Cc: dev@openoffice.apache.org Subject: RE: EXTERNAL: Re: Building comphelper -Original Message- From: Steele, Raymond Sent: Wednesday, November 20, 2013 4:57 PM To: 'Herbert Duerr' Cc: Meffe, David K Subject: RE: EXTERNAL: Re: Building comphelper Thanks, We've run into some errors with dmake and are trying to understand it. First, the startup.mk and makefile.mk could not find settings.mk and some others that are located in solenv/inc even though dmake -v seems to be looking there. We created a link of all the files in solenv/inc to solenv where makefile.mk is to overcome the problem. Although this does not seem to be a good solution. Then dmake could not find seem to find minor.mk. For example, on line 1665 in target.mk we have the following: ALLTAR: \ $(SOLARVERSION)/$(INPATH)/inc$/$(UPDMINOREXT)/$(UPD)minor.mk This would be interpreted by dmake as '//inc/minor.mk' as if the variables were not expanded. If I hardcode the full path to minor.mk , then dmake is fine. I eventually got past building solenv by performing the above hacks. I have a feeling I should not have to do that stuff. Now, building 'afms', dmake complains that SHELL could not find macro on line 64. I think it has to do with the function macro 'find', but I am not sure. Any help would be great!! Thanks, Raymond -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Wednesday, November 20, 2013 1:02 AM To: Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, I just wanted to give you a heads up that I am beginning to start work on compiling for Solaris 11 x86. Hopefully, you will be able to assist if needed. Thanks for the heads up! I'm looking forward to this and will try to help. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Herbert, I have hit a stop work on the Solaris 10 port for now. We are in the process of moving over to Solaris 11. I will probably need to port OpenOffice to Solaris 11 soon. -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Friday, September 20, 2013 11:58 AM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, On 20.09.2013 19:52, Steele, Raymond wrote: No problems on the delay. I am very greatful for your assistance!! Here is my compiler command and below are locations of my utility file. Hopefully this may help. I added utility to the include path, but still no luck. bash-3.2# /opt/solarisstudio12.3/bin/CC -c -temp=/tmp -xarch=generic -xO3 -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -D_FILE_OFFSET_BITS=64 -I. -I../../unxsoli4.pro/inc/oslall -I.. /inc -I../../inc/pch -I../../inc -I../../unx/inc -I../../unxsoli4.pro/inc -I. -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/externa l -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc -I/opt/aoo-4.0.0/main/solenv/unxsoli4/inc -I/opt/aoo-4.0.0/main/solenv/inc -I/opt/aoo-4.0.0/main/res -I/opt/aoo-4.0.0/main/solver/400/unx soli4.pro/inc/stl -I/opt/solarisstudio12.3/include -I/opt/aoo-4.0.0/main/solenv/inc/Xp31 -I/usr/jdk/latest/include -I/usr/jdk/latest/include/solaris -I/usr/jdk/latest/include/native_threads /include: -I/usr/local/include -I/usr/include -I/usr/local/include/rasqal -I/usr/include/stdcxx4 -I/opt/aoo-4.0.0/main/stlport/systemstl/: -I/usr/local/include -I/usr/include -I/usr/local/i nclude/rasqal -I/usr/include/stdcxx4 -I/opt/a oo-4.0.0/main/stlport/systemstl/: -I/usr/local/include -I/usr/include -I/usr/local/inclue/rasqal -I/opt/aoo-4.0.0/main/stlport/systemstl/ -I/opt /solarisstudio12.3/prod/include/CC/Cstd/ -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/offuh -I. -I../../res -I. -features=no%altspell -features=rvalueref +w2 -erroff=doubunder,ident expected,inllargeuse,inllargeint,notemsource,reftotemp,truncwarn,wnoretvalue,anonnotype -KPIC -mt -DSOLARIS -DUNX -DVCL -DC52 -DC52 -DINTEL -D_PTHREADS -DSYSV -DSUN -DSUN4 -D_REENTRANT -D _POSIX_PTHREAD_SEMANTICS -DSTLPORT_VERSION=400 -D__DMAKE -DUNIX -DCPPU_ENV=sunpro5 -DSUPD=400 -DPRODUCT -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI -DSOLAR_JAVA -DEXCEPTIONS_ON -o . ./../unxsoli4.pro/obj/debugbase.o /opt/aoo-4.0.0/main/sal/osl/all/debugbase.cxx /usr/local/include/boost/tr1/detail/config_all.hpp, line 161: Error: Could not open include file../include/utility. [...] /usr/include/stdcxx4/utility [...] /opt/solarisstudio12.3/prod/include/CC/Cstd/utility I think one of these two header files is the one we are looking for. Boost is using the relative include path trick with its BOOST_TR1_STD_HEADER() macro because the neat include_next extension is not supported in the solaris compiler. One of the BOOST_TR1_STD_HEADER defines in config_all.hpp is looking for the stdcxx4 path. I wonder why it isn't picked up. Either 1. one of the defines is wrong (__SUNPRO_CC,__STD_RWCOMPILER_H, ___RWSTD_VER) or boost erroneously doesn't pick it up 2. the -I/opt/solarisstudio12.3/prod/include/CC/Cstd/ part of the compile options should be changed to find /usr/include/stdcxx4/ instead 3. the BOOST_TR1_STD_HEADER define should be changed to ../Cstd/ Which of the alternatives 2. or 3. is better depends on which of both STL header sets better implements C++'s std templates as defined in TR1. From the name I'd guess the Cstd one is better. /opt/solarisstudio12.3/prod/include/CC/stlport4/utility I found this about Solaris 11, but the fix appears to be included in boost version 1_48 (Mine is attached). https://svn.boost.org/trac/boost/ticket/5111 Interesting. Maybe the above and this are related. Hope that helps. Have a nice weekend! Herbert (about to upload AOO401rc3 to the snapshot page) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Hi Raymond, On 02.10.2013 17:26, Steele, Raymond wrote: I have hit a stop work on the Solaris 10 port for now. We are in the process of moving over to Solaris 11. I will probably need to port OpenOffice to Solaris 11 soon. Thanks for the update! With the newer build environment there things should be easier... Hope springs eternal ;-) Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Hi Raymond, I found hash_set in ../main/stlport/systemstl Is that where it is supposed to be. Yes. Once, I added this to my SOLARINC and SOLARINV environment variables, everything was okay, but then I received a /usr/local/include/boost/tr1/detail/config_all.hpp, line 161: Error: Could not open include file../include/utility The utility header should come somewhere from your c++ compiler includes. According to [1] it should be there somewhere. If it is not found we need to put its path at the end of the include paths. [1] http://docs.oracle.com/cd/E19205-01/819-5267/bkajw/index.html Sorry for the late answer. I was busy with AOO401rc3. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
No problems on the delay. I am very greatful for your assistance!! Here is my compiler command and below are locations of my utility file. Hopefully this may help. I added utility to the include path, but still no luck. bash-3.2# /opt/solarisstudio12.3/bin/CC -c -temp=/tmp -xarch=generic -xO3 -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -D_FILE_OFFSET_BITS=64 -I. -I../../unxsoli4.pro/inc/oslall -I.. /inc -I../../inc/pch -I../../inc -I../../unx/inc -I../../unxsoli4.pro/inc -I. -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/externa l -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc -I/opt/aoo-4.0.0/main/solenv/unxsoli4/inc -I/opt/aoo-4.0.0/main/solenv/inc -I/opt/aoo-4.0.0/main/res -I/opt/aoo-4.0.0/main/solver/400/unx soli4.pro/inc/stl -I/opt/solarisstudio12.3/include -I/opt/aoo-4.0.0/main/solenv/inc/Xp31 -I/usr/jdk/latest/include -I/usr/jdk/latest/include/solaris -I/usr/jdk/latest/include/native_threads /include: -I/usr/local/include -I/usr/include -I/usr/local/include/rasqal -I/usr/include/stdcxx4 -I/opt/aoo-4.0.0/main/stlport/systemstl/: -I/usr/local/include -I/usr/include -I/usr/local/i nclude/rasqal -I/usr/include/stdcxx4 -I/opt/aoo-4.0.0/main/stlport/systemstl/: -I/usr/local/include -I/usr/include -I/usr/local/inclue/rasqal -I/opt/aoo-4.0.0/main/stlport/systemstl/ -I/opt /solarisstudio12.3/prod/include/CC/Cstd/ -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/offuh -I. -I../../res -I. -features=no%altspell -features=rvalueref +w2 -erroff=doubunder,ident expected,inllargeuse,inllargeint,notemsource,reftotemp,truncwarn,wnoretvalue,anonnotype -KPIC -mt -DSOLARIS -DUNX -DVCL -DC52 -DC52 -DINTEL -D_PTHREADS -DSYSV -DSUN -DSUN4 -D_REENTRANT -D _POSIX_PTHREAD_SEMANTICS -DSTLPORT_VERSION=400 -D__DMAKE -DUNIX -DCPPU_ENV=sunpro5 -DSUPD=400 -DPRODUCT -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI -DSOLAR_JAVA -DEXCEPTIONS_ON -o . ./../unxsoli4.pro/obj/debugbase.o /opt/aoo-4.0.0/main/sal/osl/all/debugbase.cxx /usr/local/include/boost/tr1/detail/config_all.hpp, line 161: Error: Could not open include file../include/utility. /usr/sfw/include/c++/3.4.3/utility /usr/include/stdcxx4/utility /usr/local/include/boost/tr1/tr1/utility /usr/local/include/boost/spirit/home/classic/utility /usr/local/include/boost/spirit/utility /usr/local/include/boost/utility /usr/local/include/boost/xpressive/detail/utility /usr/local/gcc-4.8.1/include/c++/4.8.1/tr1/utility /usr/local/gcc-4.8.1/include/c++/4.8.1/utility /export/home/aoo-4.0.0/main/i18nutil/source/utility /opt/aoo-4.0.0/main/i18nutil/source/utility /opt/aoo-4.0.0/main/vigra/unxsoli4.pro/misc/build/vigra1.6.0/include/IRIX/utility /opt/aoo-4.0.0/ext_sources/boost_1_48_0/boost/tr1/tr1/utility /opt/aoo-4.0.0/ext_sources/boost_1_48_0/boost/spirit/home/classic/utility /opt/aoo-4.0.0/ext_sources/boost_1_48_0/boost/spirit/utility /opt/aoo-4.0.0/ext_sources/boost_1_48_0/boost/utility /opt/aoo-4.0.0/ext_sources/boost_1_48_0/boost/xpressive/detail/utility /opt/aoo-4.0.0/ext_sources/boost_1_48_0/libs/utility /opt/solarisstudio12.3/prod/include/CC/Cstd/utility /opt/solarisstudio12.3/prod/include/CC/stlport4/utility I found this about Solaris 11, but the fix appears to be included in boost version 1_48 (Mine is attached). https://svn.boost.org/trac/boost/ticket/5111 From: Herbert Duerr [h...@apache.org] Sent: Friday, September 20, 2013 8:53 AM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, I found hash_set in ../main/stlport/systemstl Is that where it is supposed to be. Yes. Once, I added this to my SOLARINC and SOLARINV environment variables, everything was okay, but then I received a /usr/local/include/boost/tr1/detail/config_all.hpp, line 161: Error: Could not open include file../include/utility The utility header should come somewhere from your c++ compiler includes. According to [1] it should be there somewhere. If it is not found we need to put its path at the end of the include paths. [1] http://docs.oracle.com/cd/E19205-01/819-5267/bkajw/index.html Sorry for the late answer. I was busy with AOO401rc3. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
I am not sure why my attachments are not going through, but here is the preprocessor output. I filtered on utility. /opt/solarisstudio12.3/bin/CC -E -temp=/tmp -xarch=generic -xO3 -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -D_FILE_OFFSET_BITS=64 -I/usr/local/include/boost/ -I. -I../../unxsoli4.pro/inc/oslall -I../inc -I../../inc/pch -I../../inc -I../../unx/inc -I../../unxsoli4.pro/inc -I. -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/external -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc -I/opt/aoo-4.0.0/main/solenv/unxsoli4/inc -I/opt/aoo-4.0.0/main/solenv/inc -I/opt/aoo-4.0.0/main/res -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl -I/opt/solarisstudio12.3/include -I/opt/aoo-4.0.0/main/solenv/inc/Xp31 -I/usr/jdk/latest/include -I/usr/jdk/latest/include/solaris -I/usr/jdk/latest/include/native_threads/include: -I/usr/local/include -I/usr/include -I/usr/local/include/rasqal -I/usr/include/stdcxx4 -I/opt/aoo-4.0.0/main/stlport/systemstl/: -I/usr/local/include -I/usr/include -I/usr/local/include/rasqal -I/usr/include/stdcxx4 -I/opt/aoo-4.0.0/main/stlport/systemstl/: -I/usr/local/include -I/usr/include -I/usr/local/inclue/rasqal -I/opt/aoo-4.0.0/main/stlport/systemstl/ -I/opt/solarisstudio12.3/prod/include/CC/Cstd/ -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/offuh -I. -I../../res -I. -features=no%altspell -features=rvalueref +w2 -erroff=doubunder,identexpected,inllargeuse,inllargeint,notemsource,reftotemp,truncwarn,wnoretvalue,anonnotype -KPIC -mt -DSOLARIS -DUNX -DVCL -DC52 -DC52 -DINTEL -D_PTHREADS -DSYSV -DSUN -DSUN4 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DSTLPORT_VERSION=400 -D__DMAKE -DUNIX -DCPPU_ENV=sunpro5 -DSUPD=400 -DPRODUCT -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI -DSOLAR_JAVA -DEXCEPTIONS_ON -o /tmp/file /opt/aoo-4.0.0/main/sal/osl/all/debugbase.cxx|grep utility #1 /usr/local/include/boost/config/no_tr1/utility.hpp #1 /opt/solarisstudio12.3/prod/include/CC/Cstd/utility #52 /opt/solarisstudio12.3/prod/include/CC/Cstd/utility #1 /usr/local/include/boost/utility/enable_if.hpp #1 /usr/local/include/boost/utility/addressof.hpp #1 /usr/local/include/boost/utility/swap.hpp /usr/local/include/boost/tr1/detail/config_all.hpp, line 161: Error: Could not open include file../include/utility. From: Herbert Duerr [h...@apache.org] Sent: Friday, September 20, 2013 8:53 AM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, I found hash_set in ../main/stlport/systemstl Is that where it is supposed to be. Yes. Once, I added this to my SOLARINC and SOLARINV environment variables, everything was okay, but then I received a /usr/local/include/boost/tr1/detail/config_all.hpp, line 161: Error: Could not open include file../include/utility The utility header should come somewhere from your c++ compiler includes. According to [1] it should be there somewhere. If it is not found we need to put its path at the end of the include paths. [1] http://docs.oracle.com/cd/E19205-01/819-5267/bkajw/index.html Sorry for the late answer. I was busy with AOO401rc3. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Hi Raymond, On 16.09.2013 19:40, Steele, Raymond wrote: I removed the -library=no%Cstd from the two files and performed a clean build, but still have the same issues. Also, I am untarring the BOOST package version 1.48 so I downloaded the zipped version and unzipped it, placed the resulting boost directory in /usr/local/include after using --with-system-boost configuration. Still no luck. I also reconfigured with --without-stlport. It still appears that I it is using /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/climits.SUNWCCh. This file should and cannot be there if the --without-stlport build was clean. For its recipe see main/stlport/makefile.mk. Please retry doing the --without-stlport clean build, i.e. main/solver and */unxsoli4.pro output directories removed. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
 I was doing a dmake clean in the main directory. Apparently, it was not removing the solver dir.  From: Herbert Duerr [h...@apache.org] Sent: Wednesday, September 18, 2013 3:33 AM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, On 16.09.2013 19:40, Steele, Raymond wrote: I removed the -library=no%Cstd from the two files and performed a clean build, but still have the same issues. Also, I am untarring the BOOST package version 1.48 so I downloaded the zipped version and unzipped it, placed the resulting boost directory in /usr/local/include after using --with-system-boost configuration. Still no luck. I also reconfigured with --without-stlport. It still appears that I it is using /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/climits.SUNWCCh. This file should and cannot be there if the --without-stlport build was clean. For its recipe see main/stlport/makefile.mk. Please retry doing the --without-stlport clean build, i.e. main/solver and */unxsoli4.pro output directories removed. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
I found hash_set in ../main/stlport/systemstl Is that where it is supposed to be. Once, I added this to my SOLARINC and SOLARINV environment variables, everything was okay, but then I received a /usr/local/include/boost/tr1/detail/config_all.hpp, line 161: Error: Could not open include file../include/utility From: Herbert Dürr [h...@apache.org] Sent: Wednesday, September 18, 2013 3:44 AM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, On 16.09.2013 22:04, Steele, Raymond wrote: I was wrong I thought the I set the --without-stlport flag, but did not. I just set it and reconfigured. Now I am receiving this. Entering /opt/aoo-4.0.0/main/sal/rtl/source --- ALWAYSDBGFILES --- --- ALWAYSDBGFILES OVER --- Compiling: sal/rtl/source/hash.cxx /opt/aoo-4.0.0/main/sal/rtl/source/hash.cxx, line 32: Error: Could not open include filehash_set. This missing file (hash_set) should be in main/solver/400/unxsoli4.pro/inc/stl/ as soon as the module main/stlport was built. What are the include paths (the -Ixxx options) for hash.cxx when when you build with the verbose=true build option? Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
I removed the -library=no%Cstd from the two files and performed a clean build, but still have the same issues. Also, I am untarring the BOOST package version 1.48 so I downloaded the zipped version and unzipped it, placed the resulting boost directory in /usr/local/include after using --with-system-boost configuration. Still no luck. I also reconfigured with --without-stlport. It still appears that I it is using /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/climits.SUNWCCh. From: Herbert Duerr [h...@apache.org] Sent: Friday, September 13, 2013 3:40 AM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper On 12.09.2013 20:15, Steele, Raymond wrote: Yes, the modified vigra config.hxx allowed basebmp to be built. I am using --with-system-boost, however, I just did a reconfigure after removing it and ran into issues during the boost build. I receive the following hundreds of times until it fails. Good, so the vigra erf() problem can be considered as solved. /usr/sfw/bin/gtar: Archive value 4294967295 is out of gid_t range -2147483648..2147483647 [...] I am not sure why. Looking into it now. I found [1] (Whoever created that tar file did so on a platform that allows gid_t values of 32bits.), and this probably means the boost tarball was packed on a too new system. Or that gtar on your system needs to be updated. [1] http://comments.gmane.org/gmane.comp.gnu.mingw.msys/4816 Also, here is filtered output from the CC -E of partial.cxx. I grep'd for limits, as you can see in the command I issued. bash-3.2# /opt/solarisstudio12.3/bin/CC -E -temp=/tmp -xarch=generic -xO3 -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -xldscope=hidden -I. -I../unxsoli4.pro/inc/configmgr -I../inc -I../inc/pch -I../inc -I../unx/inc -I../unxsoli4.pro/inc -I. -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/external -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc -I/opt/aoo-4.0.0/main/solenv/unxsoli4/inc -I/opt/aoo-4.0.0/main/solenv/inc -I/opt/aoo-4.0.0/main/res -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl -I/opt/solarisstudio12.3/include -I/opt/aoo-4.0.0/main/solenv/inc/Xp31 -I/usr/jdk/latest/include -I/usr/jdk/latest/include/solaris -I/usr/jdk/latest/include/native_threads/include: -I/usr/local/include -I/usr/include -I/usr/local/include/boost -I/opt/solarisstudio12.3/prod/include/CC/Cstd/ -I/usr/local/include/rasqal: -I/usr/local/include -I/usr/include -I/usr/local/include/boost -I/usr/local/include/rasqal -I/usr/include/std cxx4 -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/offuh -I. -I../res -I. -features=no%altspell -library=no%Cstd -features=rvalueref +w2 -erroff=doubunder,identexpected,inllargeuse,inllargeint,notemsource,reftotemp,truncwarn,wnoretvalue,anonnotype -KPIC -mt -DSOLARIS -DUNX -DVCL -DC52 -DC52 -DINTEL -D_PTHREADS -DSYSV -DSUN -DSUN4 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DSTLPORT_VERSION=400 -D__DMAKE -DUNIX -DCPPU_ENV=sunpro5 -DSUPD=400 -DPRODUCT -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI -DSOLAR_JAVA -DSHAREDLIB -D_DLL_-DEXCEPTIONS_ON -o /tmp/file /opt/aoo-4.0.0/main/configmgr/source/partial.cxx|grep -i limit The compiler option -library=no%Cstd could have introduced some trouble. In AOO 4.0 we want to use this compiler STL (wrapped with boost's TR1 library to fill the missing TR1 pieces and for easier porting). I see this flag is set in main/solenv/inc/unxsol*.mk and in main/solenv/gbuild/platform/solaris.mk and suggest to remove it in all places. #1 /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/climits.SUNWCCh This header shouldn't be there if your configure step used the --without-stlport option. If you didn't use the option then please reconfigure the AOO build using it. Please see e.g. the Linux configure options in [2] as a reference. [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds [other lines matching a grep for limit] These other grepped lines are interesting too, but with the two suggestions I made things could change considerably here. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
=http://www.msweet.org/files/project2/epm-3.7-source.tar.gz \ --with-gnu-patch=/usr/bin/gpatch \ --with-gnu-cp=/usr/local/bin/cp \ --with-gperf=/usr/local/bin/gperf \ --with-system-serf \ --with-system-zlib \ --with-system-openssl \ --with-system-jpeg \ --with-system-libxml \ --with-system-python \ --with-system-icu \ --with-system-poppler \ --with-system-lucene \ --with-lucene-core-jar=/usr/local/lib/lucene-core-2.9.4.jar \ --with-lucene-analyzers-jar=/usr/local/lib/lucene-analyzers-2.9.4.jar \ --with-commons-codec-jar=/usr/local/lib/commons-codec-1.8.jar \ --with-commons-lang-jar=/usr/local/lib/commons-lang3-3.1.jar \ --with-commons-httpclient-jar=/usr/local/lib/httpclient-4.2.5.jar \ --with-commons-logging-jar=/usr/local/lib/commons-logging-1.1.3.jar \ --with-system-mysql \ --with-system-mysql-cppconn \ --with-system-hsqldb \ --with-hsqldb-jar=/usr/local/lib/hsqldb.jar \ --with-system-libxslt \ --with-system-curl \ --with-system-mythes \ --with-system-cppunit \ --with-system-redland \ --with-system-boost \ --without-stlport \ --with-system-apr \ --with-system-apr-util \ --with-system-apache-commons \ --with-system-cairo \ --disable-cups \ --with-jdk-home=/usr/jdk/latest/ \ --with-ant-home=/usr/local/ant/bin/ant \ --with-system-openssl=/usr/sfw/bin/openssl \ --with-junit=/usr/local/java/lib/junit-4.11.jar \ --disable-Xaw \ --disable-randr \ --disable-report-builder \ --disable-mozilla \ --disable-systray \ --disable-category-b \ --enable-pdfimport \ --enable-wiki-publisher \ --with-lang=en \ --with-dict=ALL \ --with-package-format=installed From: Steele, Raymond Sent: Monday, September 16, 2013 11:40 AM To: Herbert Duerr; dev@openoffice.apache.org Subject: RE: EXTERNAL: Re: Building comphelper I removed the -library=no%Cstd from the two files and performed a clean build, but still have the same issues. Also, I am untarring the BOOST package version 1.48 so I downloaded the zipped version and unzipped it, placed the resulting boost directory in /usr/local/include after using --with-system-boost configuration. Still no luck. I also reconfigured with --without-stlport. It still appears that I it is using /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/climits.SUNWCCh. From: Herbert Duerr [h...@apache.org] Sent: Friday, September 13, 2013 3:40 AM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper On 12.09.2013 20:15, Steele, Raymond wrote: Yes, the modified vigra config.hxx allowed basebmp to be built. I am using --with-system-boost, however, I just did a reconfigure after removing it and ran into issues during the boost build. I receive the following hundreds of times until it fails. Good, so the vigra erf() problem can be considered as solved. /usr/sfw/bin/gtar: Archive value 4294967295 is out of gid_t range -2147483648..2147483647 [...] I am not sure why. Looking into it now. I found [1] (Whoever created that tar file did so on a platform that allows gid_t values of 32bits.), and this probably means the boost tarball was packed on a too new system. Or that gtar on your system needs to be updated. [1] http://comments.gmane.org/gmane.comp.gnu.mingw.msys/4816 Also, here is filtered output from the CC -E of partial.cxx. I grep'd for limits, as you can see in the command I issued. bash-3.2# /opt/solarisstudio12.3/bin/CC -E -temp=/tmp -xarch=generic -xO3 -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -xldscope=hidden -I. -I../unxsoli4.pro/inc/configmgr -I../inc -I../inc/pch -I../inc -I../unx/inc -I../unxsoli4.pro/inc -I. -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/external -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc -I/opt/aoo-4.0.0/main/solenv/unxsoli4/inc -I/opt/aoo-4.0.0/main/solenv/inc -I/opt/aoo-4.0.0/main/res -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl -I/opt/solarisstudio12.3/include -I/opt/aoo-4.0.0/main/solenv/inc/Xp31 -I/usr/jdk/latest/include -I/usr/jdk/latest/include/solaris -I/usr/jdk/latest/include/native_threads/include: -I/usr/local/include -I/usr/include -I/usr/local/include/boost -I/opt/solarisstudio12.3/prod/include/CC/Cstd/ -I/usr/local/include/rasqal: -I/usr/local/include -I/usr/include -I/usr/local/include/boost -I/usr/local/include/rasqal -I/usr/include/std cxx4 -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/offuh -I. -I../res -I. -features=no%altspell -library=no%Cstd -features=rvalueref +w2 -erroff=doubunder
Re: EXTERNAL: Re: Building comphelper
On 12.09.2013 20:15, Steele, Raymond wrote: Yes, the modified vigra config.hxx allowed basebmp to be built. I am using --with-system-boost, however, I just did a reconfigure after removing it and ran into issues during the boost build. I receive the following hundreds of times until it fails. Good, so the vigra erf() problem can be considered as solved. /usr/sfw/bin/gtar: Archive value 4294967295 is out of gid_t range -2147483648..2147483647 [...] I am not sure why. Looking into it now. I found [1] (Whoever created that tar file did so on a platform that allows gid_t values of 32bits.), and this probably means the boost tarball was packed on a too new system. Or that gtar on your system needs to be updated. [1] http://comments.gmane.org/gmane.comp.gnu.mingw.msys/4816 Also, here is filtered output from the CC -E of partial.cxx. I grep'd for limits, as you can see in the command I issued. bash-3.2# /opt/solarisstudio12.3/bin/CC -E -temp=/tmp -xarch=generic -xO3 -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -xldscope=hidden -I. -I../unxsoli4.pro/inc/configmgr -I../inc -I../inc/pch -I../inc -I../unx/inc -I../unxsoli4.pro/inc -I. -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/external -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc -I/opt/aoo-4.0.0/main/solenv/unxsoli4/inc -I/opt/aoo-4.0.0/main/solenv/inc -I/opt/aoo-4.0.0/main/res -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl -I/opt/solarisstudio12.3/include -I/opt/aoo-4.0.0/main/solenv/inc/Xp31 -I/usr/jdk/latest/include -I/usr/jdk/latest/include/solaris -I/usr/jdk/latest/include/native_threads/include: -I/usr/local/include -I/usr/include -I/usr/local/include/boost -I/opt/solarisstudio12.3/prod/include/CC/Cstd/ -I/usr/local/include/rasqal: -I/usr/local/include -I/usr/include -I/usr/local/include/boost -I/usr/local/include/rasqal -I/usr/include/std cxx4 -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/offuh -I. -I../res -I. -features=no%altspell -library=no%Cstd -features=rvalueref +w2 -erroff=doubunder,identexpected,inllargeuse,inllargeint,notemsource,reftotemp,truncwarn,wnoretvalue,anonnotype -KPIC -mt -DSOLARIS -DUNX -DVCL -DC52 -DC52 -DINTEL -D_PTHREADS -DSYSV -DSUN -DSUN4 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DSTLPORT_VERSION=400 -D__DMAKE -DUNIX -DCPPU_ENV=sunpro5 -DSUPD=400 -DPRODUCT -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI -DSOLAR_JAVA -DSHAREDLIB -D_DLL_-DEXCEPTIONS_ON -o /tmp/file /opt/aoo-4.0.0/main/configmgr/source/partial.cxx|grep -i limit The compiler option -library=no%Cstd could have introduced some trouble. In AOO 4.0 we want to use this compiler STL (wrapped with boost's TR1 library to fill the missing TR1 pieces and for easier porting). I see this flag is set in main/solenv/inc/unxsol*.mk and in main/solenv/gbuild/platform/solaris.mk and suggest to remove it in all places. #1 /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/climits.SUNWCCh This header shouldn't be there if your configure step used the --without-stlport option. If you didn't use the option then please reconfigure the AOO build using it. Please see e.g. the Linux configure options in [2] as a reference. [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds [other lines matching a grep for limit] These other grepped lines are interesting too, but with the two suggestions I made things could change considerably here. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
long double ,
return ( _STL :: numeric_limits SizeType :: max ) ( ) ;
#1 /usr/local/include/boost/mpl/limits/arity.hpp
_Size __depth_limit ) ;
_Size __depth_limit , _Compare __comp ) ;
( _STL :: numeric_limits _STL :: size_t :: max ) ( ) ) ?
( _STL :: numeric_limits _STL :: size_t :: max ) ( ) :
#1 /usr/local/include/boost/functional/hash/detail/limits.hpp
struct limits : _STL :: numeric_limits T { } ;
#1 /usr/local/include/boost/functional/hash/detail/limits.hpp
exp += limits T :: max_exponent -
limits T :: min_exponent ;
v = ldexp ( v , limits _STL :: size_t :: digits ) ;
= ( limits T :: digits *
boost :: static_log2 limits T :: radix :: value
+ limits _STL :: size_t :: digits - 1 )
/ limits _STL :: size_t :: digits ;
v = ldexp ( v , limits _STL :: size_t :: digits ) ;
const int size_t_bits = _STL :: numeric_limits _STL :: size_t :: digits ;
const int length = ( _STL :: numeric_limits T :: digits - 1 )
const int size_t_bits = _STL :: numeric_limits _STL :: size_t :: digits ;
const int length = ( _STL :: numeric_limits T :: digits - 1 )
From: Herbert Duerr [h...@apache.org]
Sent: Wednesday, September 11, 2013 7:02 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
On 10.09.2013 19:29, Steele, Raymond wrote:
I cannot seem to figure out which limits integer_fw.hpp is using on my
system. I put the following in scopeguard.cxx and received a
void ScopeGuard::dismiss()
{
struct Dummy{} dummy = ::std::numeric_limitsunsigned char::digits;
m_func.clear();
}
Here is the output.
[...]
/usr/local/include/boost/integer_fwd.hpp, line 138: Error: Illegal value
for template parameter.
/usr/local/include/boost/integer_fwd.hpp, line 138: Error: Cannot use class
specialization with non-classes.
/opt/aoo-4.0.0/main/comphelper/source/misc/scopeguard.cxx, line 63: Error:
Cannot use const int to initialize Dummy.
Ah, so this shows that the digits member is a const int as it should be.
Why low_bit_mask_t doesn't like the specialization with int is
strange, because in my boost/integer/integer_mask.hpp only allows
integer specializations (for std::size_t)!
What is also interesting is the location of the integer_fwd.hpp header
file: /usr/local/include/boost/
Are you using --with-system-boost or --with-system-headers? What
version of boost is installed on your system? AOO's current reference
implementation of boost is 1.48.
I did a search for all the limits files on my system. Here are the results.:
bash-3.2# find / -name limits
/usr/sfw/include/c++/3.4.3/limits
/usr/include/stdcxx4/limits
/usr/local/include/boost/mpl/limits
/usr/local/include/boost/tr1/tr1/limits
/usr/local/include/boost_52/mpl/limits
/usr/local/include/boost_52/tr1/tr1/limits
/usr/local/gcc-4.8.1/include/c++/4.8.1/limits
/opt/aoo-4.0.0/main/stlport/unxsoli4.pro/inc/stlport/limits
/opt/aoo-4.0.0/main/stlport/unxsoli4.pro/inc/stlport/SC5/limits
/opt/aoo-4.0.0/main/stlport/unxsoli4.pro/misc/build/STLport-4.0/stlport/limits
/opt/aoo-4.0.0/main/stlport/unxsoli4.pro/misc/build/STLport-4.0/stlport/SC5/limits
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/limits
/opt/aoodeps/perl-5.18.1/cpan/Devel-PPPort/parts/inc/limits
/opt/aoodeps/STLport-5.2.1/stlport/limits
/opt/aoodeps/boost_1_48_0/boost/mpl/limits
/opt/aoodeps/boost_1_48_0/boost/tr1/tr1/limits
/opt/aoodeps/gcc-4.8.1/libstdc++-v3/testsuite/18_support/headers/limits
/opt/aoodeps/gcc-4.8.1/libstdc++-v3/include/std/limits
/opt/solarisstudio12.3/prod/include/CC/Cstd/limits
/opt/solarisstudio12.3/prod/include/CC/stlport4/limits
/boost_1_54_0/boost/mpl/limits
/boost_1_54_0/boost/tr1/tr1/limits
/gcc-4.8.1.OLD/include/c++/4.8.1/limits
Darn, these are a lot of limits file. If the compiler picks one that
is not consistent with the related include files then all kinds of
troubles are not surprising.
To find out which limits file is included you could use the gcc option
-E, that tells the compiler to just preprocess a source file and
output the preprocessed result to the output file specified by -o.
As an example change into the configmgr directory and
build verbose=true
there. You'll see the exact command line for the compiler building e.g.
partial.cxx. Change the -c option (compile) to -E (preprocess
only) and run this one command line. The resulting partial.o is the
preprocessed source that will show you which limits was included.
Lastly,
The following patch seems to address the erf() issue. I edited
/opt/aoo-4.0./main/solver/400/unxsoli4.pro/inc/vigra/config.hxx with the
following and it seems to compile without error. However, isn't
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/config.hxx generated by
the build. Should this be modified somewhere else?
When external libraries are built the process is as follows:
1. the tarball of the library is unpacked
2. some patches are applied (for vigra its
Re: EXTERNAL: Re: Building comphelper
On 10.09.2013 19:29, Steele, Raymond wrote:
I cannot seem to figure out which limits integer_fw.hpp is using on my
system. I put the following in scopeguard.cxx and received a
void ScopeGuard::dismiss()
{
struct Dummy{} dummy = ::std::numeric_limitsunsigned char::digits;
m_func.clear();
}
Here is the output.
[...]
/usr/local/include/boost/integer_fwd.hpp, line 138: Error: Illegal value for
template parameter.
/usr/local/include/boost/integer_fwd.hpp, line 138: Error: Cannot use class
specialization with non-classes.
/opt/aoo-4.0.0/main/comphelper/source/misc/scopeguard.cxx, line 63: Error:
Cannot use const int to initialize Dummy.
Ah, so this shows that the digits member is a const int as it should be.
Why low_bit_mask_t doesn't like the specialization with int is
strange, because in my boost/integer/integer_mask.hpp only allows
integer specializations (for std::size_t)!
What is also interesting is the location of the integer_fwd.hpp header
file: /usr/local/include/boost/
Are you using --with-system-boost or --with-system-headers? What
version of boost is installed on your system? AOO's current reference
implementation of boost is 1.48.
I did a search for all the limits files on my system. Here are the results.:
bash-3.2# find / -name limits
/usr/sfw/include/c++/3.4.3/limits
/usr/include/stdcxx4/limits
/usr/local/include/boost/mpl/limits
/usr/local/include/boost/tr1/tr1/limits
/usr/local/include/boost_52/mpl/limits
/usr/local/include/boost_52/tr1/tr1/limits
/usr/local/gcc-4.8.1/include/c++/4.8.1/limits
/opt/aoo-4.0.0/main/stlport/unxsoli4.pro/inc/stlport/limits
/opt/aoo-4.0.0/main/stlport/unxsoli4.pro/inc/stlport/SC5/limits
/opt/aoo-4.0.0/main/stlport/unxsoli4.pro/misc/build/STLport-4.0/stlport/limits
/opt/aoo-4.0.0/main/stlport/unxsoli4.pro/misc/build/STLport-4.0/stlport/SC5/limits
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/limits
/opt/aoodeps/perl-5.18.1/cpan/Devel-PPPort/parts/inc/limits
/opt/aoodeps/STLport-5.2.1/stlport/limits
/opt/aoodeps/boost_1_48_0/boost/mpl/limits
/opt/aoodeps/boost_1_48_0/boost/tr1/tr1/limits
/opt/aoodeps/gcc-4.8.1/libstdc++-v3/testsuite/18_support/headers/limits
/opt/aoodeps/gcc-4.8.1/libstdc++-v3/include/std/limits
/opt/solarisstudio12.3/prod/include/CC/Cstd/limits
/opt/solarisstudio12.3/prod/include/CC/stlport4/limits
/boost_1_54_0/boost/mpl/limits
/boost_1_54_0/boost/tr1/tr1/limits
/gcc-4.8.1.OLD/include/c++/4.8.1/limits
Darn, these are a lot of limits file. If the compiler picks one that
is not consistent with the related include files then all kinds of
troubles are not surprising.
To find out which limits file is included you could use the gcc option
-E, that tells the compiler to just preprocess a source file and
output the preprocessed result to the output file specified by -o.
As an example change into the configmgr directory and
build verbose=true
there. You'll see the exact command line for the compiler building e.g.
partial.cxx. Change the -c option (compile) to -E (preprocess
only) and run this one command line. The resulting partial.o is the
preprocessed source that will show you which limits was included.
Lastly,
The following patch seems to address the erf() issue. I edited
/opt/aoo-4.0./main/solver/400/unxsoli4.pro/inc/vigra/config.hxx with the
following and it seems to compile without error. However, isn't
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/config.hxx generated by
the build. Should this be modified somewhere else?
When external libraries are built the process is as follows:
1. the tarball of the library is unpacked
2. some patches are applied (for vigra its the file vigra-1.6.0.patch)
3. the library is built
4. the library is delivered to solver
Though modifying the header in solver can temporarily solve a compile
problem in a dependent module (e.g. basebmp) it is better to do the
needed modification before the library is built to get a consistent
state. To get the patch in as early as possible the patch file has to be
modified. As mentioned yesterday I already attached a patch against
vigra-1.6.0.patch to issue 123228.
By the way, did the modified vigra config.hxx allow basebmp to be built?
Herbert
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
On 09.09.2013 19:59, Steele, Raymond wrote: I am using trying to build the source code that I pulled from here: http://www.apache.org/dist/openoffice/4.0.0/source/ Thanks for the info. Now I know better what to patch. I make the changes to my local copy of the files specified at http://svn.apache.org/viewvc?view=revisionrevision=1515285 Now, I am receiving the following. Looking into the cause now. [...] /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_tree.c, line 590: Error: Too many arguments in call to rtl::OUStringHash::operator()(const rtl::OUString) const. [...] The patch in the revision I mentioned was for a newer branch than AOO400: To adapt it to your tree please keep the patched partial.hxx and revert modifications.hxx to its original. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 09.09.2013 19:13, Steele, Raymond wrote:
Thanks for the information. I attached the new mathconf.h file with your
patch. I then did a clean build and it compiles without error.
Good. I created an issue (Adaptions for building AOO 4.0.0 on Solaris)
for all such adaptions that we'll find. I already attached the patch for
mathconf.h there.
[1] https://issues.apache.org/ooo/show_bug.cgi?id=123228
I am
not sure about what you'd like me to provide when you say , Of course
it would also interesting to know what type
::std::numeric_limitsunsigned char::digits on that platform. Could
you provide more details? Thanks.
In your platform's limits include file there are probably
specializations for numeric_limits template. The symptoms of the error
message look as if there was no template specialization for
numeric_limitsunsigned char. Is this so? Please check the limits
include file. In case you are using gcc then you could use the -E
option to see the preprocessed source (with the limits file included).
Another trick is to create a line
struct Dummy{} dummy = ::std::numeric_limitsunsigned char::digits;
in one of the functions and when compiling there will be an error
message about an invalid assignment that hopefully provides enough
detail about the type of this digits member.
Also,
I've found a couple other things that you may be interested in.
Sure. I suggest to collect these findings in the newly created task
123228 I referenced above [1].
1. The generated bootstrap script will not execute after configure
because of like 64. I've had to change it like this:
- dmake_full_package_name=$(find $TARFILE_LOCATION
-type f -name *-$dmake_package_name)
+ dmake_full_package_name=`find $TARFILE_LOCATION
-type f -name *-$dmake_package_name`
Good. I attached this patch to issue [1] too. It replaces the bash-ism
with generic shell code.
2. I keep receiving the following each time I do a clean build:
[...]
Compiling: basebmp/source/bitmapdevice.cxx
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/mathutil.hxx,
line 801: Error: erf is not a member of _STL.
According to the C99 standard the error function erf() should be
provided via math.h. If this is not so then vigra could provide the
function itself if the macro VIGRA_HAS_ERF was not defined. For some
reason that macro gets defined for Solaris in
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/config.hxx
for __sun !__GNUC__ Vigra's commit message regarding this was
added configs for Sun C++ (very incomplete)
which shows that there is room for improvement. I added an experimental
patch for vigra to the issue [1]. Please try it out.
Herbert
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
VIGRA_HAS_ERF
-#endif // __sun
+#if 0 // #i123228# let vigra provide the erf() function
+#if defined(__sun) !defined(__GNUC__)
+ #define VIGRA_HAS_ERF
+ #endif // __sun
+#endif
From: Herbert Duerr [h...@apache.org]
Sent: Tuesday, September 10, 2013 4:29 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
On 09.09.2013 19:13, Steele, Raymond wrote:
Thanks for the information. I attached the new mathconf.h file with your
patch. I then did a clean build and it compiles without error.
Good. I created an issue (Adaptions for building AOO 4.0.0 on Solaris)
for all such adaptions that we'll find. I already attached the patch for
mathconf.h there.
[1] https://issues.apache.org/ooo/show_bug.cgi?id=123228
I am
not sure about what you'd like me to provide when you say , Of course
it would also interesting to know what type
::std::numeric_limitsunsigned char::digits on that platform. Could
you provide more details? Thanks.
In your platform's limits include file there are probably
specializations for numeric_limits template. The symptoms of the error
message look as if there was no template specialization for
numeric_limitsunsigned char. Is this so? Please check the limits
include file. In case you are using gcc then you could use the -E
option to see the preprocessed source (with the limits file included).
Another trick is to create a line
struct Dummy{} dummy = ::std::numeric_limitsunsigned char::digits;
in one of the functions and when compiling there will be an error
message about an invalid assignment that hopefully provides enough
detail about the type of this digits member.
Also,
I've found a couple other things that you may be interested in.
Sure. I suggest to collect these findings in the newly created task
123228 I referenced above [1].
1. The generated bootstrap script will not execute after configure
because of like 64. I've had to change it like this:
- dmake_full_package_name=$(find $TARFILE_LOCATION
-type f -name *-$dmake_package_name)
+ dmake_full_package_name=`find $TARFILE_LOCATION
-type f -name *-$dmake_package_name`
Good. I attached this patch to issue [1] too. It replaces the bash-ism
with generic shell code.
2. I keep receiving the following each time I do a clean build:
[...]
Compiling: basebmp/source/bitmapdevice.cxx
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/mathutil.hxx,
line 801: Error: erf is not a member of _STL.
According to the C99 standard the error function erf() should be
provided via math.h. If this is not so then vigra could provide the
function itself if the macro VIGRA_HAS_ERF was not defined. For some
reason that macro gets defined for Solaris in
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/config.hxx
for __sun !__GNUC__ Vigra's commit message regarding this was
added configs for Sun C++ (very incomplete)
which shows that there is room for improvement. I added an experimental
patch for vigra to the issue [1]. Please try it out.
Herbert
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
On 07.09.2013 00:17, Steele, Raymond wrote:
To address the isfinite() issue I added the following to rtl/math.hxx:
#ifdef SOLARIS
#undef SAL_MATH_FINITE
#define SAL_MATH_FINITE(d) finite(d)
#endf
Your links were very helpful. Thanks so much.
Wonderful, so this problem is mostly solved. We just need to get it
cleanly into the mathconf.h. How about this patch?
--- main/sal/inc/sal/mathconf.h
+++ main/sal/inc/sal/mathconf.h
@@ -55,7 +55,9 @@ extern C {
/* SAL_MATH_FINITE(d): test double d on INFINITY, NaN et al. */
-#if defined(__GNUC__) // workaround gcc bug 14608
+#if defined(OS2) || defined(SOLARIS)
+ #define SAL_MATH_FINITE(d) finite(d)
+#elif defined(__GNUC__) // workaround gcc bug 14608
#if (__GNUC_MINOR__ = 3) // gcc=4.3 has a builtin
#define SAL_MATH_FINITE(d) __builtin_isfinite(d)
#else
@@ -67,8 +69,6 @@ extern C {
#define SAL_MATH_FINITE(d) isfinite(d)
#elif defined( WNT)
#define SAL_MATH_FINITE(d) _finite(d)
-#elif defined OS2
-#define SAL_MATH_FINITE(d) finite(d)
#elif defined LINUX || defined UNX
#define SAL_MATH_FINITE(d) finite(d)
#else /* WNT, LINUX, UNX */
Now onto:
integer_fwd.cpp contains the following on line 136 and 137:
136: template 137: struct low_bits_mask_t ::std::numeric_limitsunsigned
char::digits;
I'm not sure whether you saw my mail from September 2nd
(http://markmail.org/message/bt7bazzvb6zionee):
https://issues.apache.org/jira/browse/STDCXX-937 might have to do with
this. It mentions a compiler bug 6703971 but that doesn't seem to be
available any more. I suggest to update the compiler to its latest patch
level.
Of course it would also interesting to know what type
::std::numeric_limitsunsigned char::digits on that platform. The error
message looks as if this was not an integer but a class. The C++ spec
requires that the type should be an int. Please check the limits
include file.
Herbert
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Hi Raymond, On 07.09.2013 02:17, Steele, Raymond wrote: Problem after problem. So far the problems where quite trivial platform differences. Of course the problems only become simple after their root cause is understood ;-) Now I am getting: Entering /opt/aoo-4.0.0/main/configmgr/source Compiling: configmgr/source/partial.cxx /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 199: Error: Could not find a match for boost::tuples::getboost::tuples::N, boost::tuples::HT, boost::tuples::TT(const boost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type) needed in boost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node, boost::tuples::null_type(configmgr::Partial::Node*, const boost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350: Where: While instantiating boost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node, boost::tuples::null_type(configmgr::Partial::Node*, const boost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350: Where: Instantiated from boost::unordered::unordered_maprtl::OUString, configmgr::Partial::Node, boost::hashrtl::OUString, _STL::equal_tortl::OUString, _STL::allocator_STL::pairconst rtl::OUString, configmgr::Partial::Node::operator[](const rtl::OUString). /opt/aoo-4.0.0/main/configmgr/source/partial.cxx, line 82: Where: Instantiated from non-template code. 1 Error(s) detected. dmake: Error code 2, while making '../unxsoli4.pro/slo/partial.obj' What version of AOO are you building? AOO trunk? AOO400 or AOO401? If you're not building AOO trunk I suggest to apply my change from revision 1515285 to it and recompile configmgr. If it helps then the change is a candidate to be merged into the release branch as well. [1] http://svn.apache.org/viewvc?view=revisionrevision=1515285 Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Herbert,
Thanks for the information. I attached the new mathconf.h file with your patch.
I then did a clean build and it compiles without error.I am not sure about
what you'd like me to provide when you say , Of course it would also
interesting to know what type ::std::numeric_limitsunsigned char::digits on
that platform. Could you provide more details? Thanks.
Also,
I've found a couple other things that you may be interested in.
1. The generated bootstrap script will not execute after configure because of
like 64. I've had to change it like this:
- dmake_full_package_name=$(find $TARFILE_LOCATION -type f
-name *-$dmake_package_name)
+ dmake_full_package_name=`find $TARFILE_LOCATION -type f
-name *-$dmake_package_name`
2. I keep receiving the following each time I do a clean build:
=
Building module basebmp
=
Entering /opt/aoo-4.0.0/main/basebmp/source
Compiling: basebmp/source/bitmapdevice.cxx
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/mathutil.hxx, line 801:
Error: erf is not a member of _STL.
1 Error(s) detected.
dmake: Error code 2, while making '../unxsoli4.pro/slo/bitmapdevice.obj'
1 module(s):
basebmp
need(s) to be rebuilt
Reason(s):
ERROR: error 65280 occurred while making /opt/aoo-4.0.0/main/basebmp/source
When you have fixed the errors in that module you can resume the build by
running:
build --all:basebmp
I can resolve this by changing
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/mathutil.hxx to the
following on line 801:
- using VIGRA_CSTD::erf;
+ using ::erf;
This file is generated by the build. As of now, I have not determined what is
generating it.
-Original Message-
From: Herbert Duerr [mailto:h...@apache.org]
Sent: Monday, September 09, 2013 12:58 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
On 07.09.2013 00:17, Steele, Raymond wrote:
To address the isfinite() issue I added the following to rtl/math.hxx:
#ifdef SOLARIS
#undef SAL_MATH_FINITE
#define SAL_MATH_FINITE(d) finite(d)
#endf
Your links were very helpful. Thanks so much.
Wonderful, so this problem is mostly solved. We just need to get it cleanly
into the mathconf.h. How about this patch?
--- main/sal/inc/sal/mathconf.h
+++ main/sal/inc/sal/mathconf.h
@@ -55,7 +55,9 @@ extern C {
/* SAL_MATH_FINITE(d): test double d on INFINITY, NaN et al. */ -#if
defined(__GNUC__) // workaround gcc bug 14608
+#if defined(OS2) || defined(SOLARIS)
+ #define SAL_MATH_FINITE(d) finite(d)
+#elif defined(__GNUC__) // workaround gcc bug 14608
#if (__GNUC_MINOR__ = 3) // gcc=4.3 has a builtin
#define SAL_MATH_FINITE(d) __builtin_isfinite(d)
#else
@@ -67,8 +69,6 @@ extern C {
#define SAL_MATH_FINITE(d) isfinite(d)
#elif defined( WNT)
#define SAL_MATH_FINITE(d) _finite(d)
-#elif defined OS2
-#define SAL_MATH_FINITE(d) finite(d)
#elif defined LINUX || defined UNX
#define SAL_MATH_FINITE(d) finite(d)
#else /* WNT, LINUX, UNX */
Now onto:
integer_fwd.cpp contains the following on line 136 and 137:
136: template 137: struct low_bits_mask_t
::std::numeric_limitsunsigned
char::digits;
I'm not sure whether you saw my mail from September 2nd
(http://markmail.org/message/bt7bazzvb6zionee):
https://issues.apache.org/jira/browse/STDCXX-937 might have to do with this. It
mentions a compiler bug 6703971 but that doesn't seem to be available any more.
I suggest to update the compiler to its latest patch level.
Of course it would also interesting to know what type
::std::numeric_limitsunsigned char::digits on that platform. The error
message looks as if this was not an integer but a class. The C++ spec requires
that the type should be an int. Please check the limits include file.
Herbert
/**
*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* License); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*
*/
#if !defined
RE: EXTERNAL: Re: Building comphelper
I am using trying to build the source code that I pulled from here: http://www.apache.org/dist/openoffice/4.0.0/source/ I make the changes to my local copy of the files specified at http://svn.apache.org/viewvc?view=revisionrevision=1515285 Now, I am receiving the following. Looking into the cause now. = Building module configmgr = Entering /opt/aoo-4.0.0/main/configmgr/qa/unoapi Entering /opt/aoo-4.0.0/main/configmgr/inc Entering /opt/aoo-4.0.0/main/configmgr/source Compiling: configmgr/source/components.cxx /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_tree.c, line 590: Error: Too many arguments in call to rtl::OUStringHash::operator()(const rtl::OUString) const. /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_map.h, line 192: Where: While instantiating _STL::_Rb_treertl::OUString, _STL::pairconst rtl::OUString, configmgr::Modifications::Node, _STL::_Select1st_STL::pairconst rtl::OUString, configmgr::Modifications::Node, rtl::OUStringHash, _STL::allocator_STL::pairconst rtl::OUString, configmgr::Modifications::Node::find(const rtl::OUString) const. /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_map.h, line 192: Where: Instantiated from non-template code. /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_tree.c, line 596: Error: Too many arguments in call to rtl::OUStringHash::operator()(const rtl::OUString) const. /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_map.h, line 192: Where: While instantiating _STL::_Rb_treertl::OUString, _STL::pairconst rtl::OUString, configmgr::Modifications::Node, _STL::_Select1st_STL::pairconst rtl::OUString, configmgr::Modifications::Node, rtl::OUStringHash, _STL::allocator_STL::pairconst rtl::OUString, configmgr::Modifications::Node::find(const rtl::OUString) const. /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_map.h, line 192: Where: Instantiated from non-template code. 2 Error(s) detected. dmake: Error code 2, while making '../unxsoli4.pro/slo/components.obj' 1 module(s): configmgr need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /opt/aoo-4.0.0/main/configmgr/source When you have fixed the errors in that module you can resume the build by running: build --all:configmgr -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Monday, September 09, 2013 2:28 AM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, On 07.09.2013 02:17, Steele, Raymond wrote: Problem after problem. So far the problems where quite trivial platform differences. Of course the problems only become simple after their root cause is understood ;-) Now I am getting: Entering /opt/aoo-4.0.0/main/configmgr/source Compiling: configmgr/source/partial.cxx /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 199: Error: Could not find a match for boost::tuples::getboost::tuples::N, boost::tuples::HT, boost::tuples::TT(const boost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type) needed in boost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node, boost::tuples::null_type(configmgr::Partial::Node*, const boost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350: Where: While instantiating boost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node, boost::tuples::null_type(configmgr::Partial::Node*, const boost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350: Where: Instantiated from boost::unordered::unordered_maprtl::OUString, configmgr::Partial::Node, boost::hashrtl::OUString, _STL::equal_tortl::OUString, _STL::allocator_STL::pairconst rtl::OUString, configmgr::Partial::Node::operator[](const rtl::OUString). /opt/aoo-4.0.0/main/configmgr/source/partial.cxx, line 82: Where: Instantiated from non-template code. 1 Error(s) detected. dmake: Error code 2, while making '../unxsoli4.pro/slo/partial.obj' What version of AOO are you building? AOO trunk? AOO400 or AOO401? If you're not building AOO trunk I suggest to apply my change from revision
Re: EXTERNAL: Re: Building comphelper
On 05.09.2013 18:37, Steele, Raymond wrote: Thanks for the information. I will give this a try if my current strategy does not work. Apparently, SolarisStudios 12.3 compiler is not compatible with c++11. We don't build in C++11 mode for (most of) our target platforms yet. I just finished building GCC 4.8.1 so that I can attempt to build with that. I'm a bit worried about our UNO bridges when I hear this. This code in main/bridges/source/cpp_uno is very sensitive to platform/compiler changes. GCC 4.8 is quite new and I'm also afraid that the gcc-solaris bridges are not as well exercised as their suncc counterparts. By the way, are you targeting sparc or x86 CPUs? Now, I am having the issue described here: http://wiki.openoffice.org/wiki/OpenSolaris_Build_Instructions/Configure_Errors#Error:_GCC_Linker because I have CC and CXX pointing to my new gcc and g++. How can I point these variables to SolarisStudio compilers for linking, but use gcc for compiling? If I understand the error message in the referenced Wiki section correctly you'd want to link with GNU ld on Solaris if you built with gcc and link with Sun ld if you built with Sun CC, so all should be fine with CC and CXX being set. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
I am targeting x86. We really need to get this build because of a Java 7 requirement. I've build some add-ons to AOO version 3.3 that use Java 6, but our customer is requiring us to move to Java 7. My add-ons will not work because AOO 3.3 does not recognize the Java 7 JRE. I reverted back to using Solaris 12.3 compilers. Hopefully that reduces your worry about the bridges. I really do appreciate you assistance and hope to overcome this very shortly. -Original Message- From: Steele, Raymond Sent: Thursday, September 05, 2013 9:37 AM To: 'Herbert Duerr'; dev@openoffice.apache.org Subject: RE: EXTERNAL: Re: Building comphelper Thanks for the information. I will give this a try if my current strategy does not work. Apparently, SolarisStudios 12.3 compiler is not compatible with c++11. I just finished building GCC 4.8.1 so that I can attempt to build with that.Now, I am having the issue described here: http://wiki.openoffice.org/wiki/OpenSolaris_Build_Instructions/Configure_Errors#Error:_GCC_Linker because I have CC and CXX pointing to my new gcc and g++. How can I point these variables to SolarisStudio compilers for linking, but use gcc for compiling? Raymond -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Thursday, September 05, 2013 12:34 AM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hy Raymond, On 04.09.2013 18:33, Steele, Raymond wrote: You are right, I completely missed your post. I am updating my compiler (SolarisStudio 12.3) now. As far as I can see now, I do not have isfinite is not a member of std on my system. Although, Netbeans allows me to choose C++ Standard C++11. What do you mean by experiment with the different SAL_MATH_FINITE definitions? mathconf.h is a C header file, so we need the C definition of isfinite. According to [1] the C isfinite() should be defined in math.h. Maybe on your platform there is a bug similar to [2] that undefines it later. But we can assume that isfinite() is available in one form or the other on your system. Maybe it is called finite(), _finite(), or __builtin_isfinite()? Assuming [3] applies here then finite() may be the pre-standard equivalent to the isfinite() function that we are looking for. [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/isfinite.html [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608 [3] https://www.varnish-cache.org/trac/ticket/464 What I meant with experiment with the different SAL_MATH_FINITE definitions is to check whether one of the above pre-standard isfinite() alternatives work. If you found one then add a define for SOLARIS only that doesn't break the other platforms. By the way std::isfinite() should be provided via cmath for C++11. But as the mathconf.h header is a C header this C++11 header is not available in this context. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Herbert, To address the isfinite() issue I added the following to rtl/math.hxx: #ifdef SOLARIS #undef SAL_MATH_FINITE #define SAL_MATH_FINITE(d) finite(d) #endf Your links were very helpful. Thanks so much. Now onto: integer_fwd.cpp contains the following on line 136 and 137: 136: template 137: struct low_bits_mask_t ::std::numeric_limitsunsigned char::digits; -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Thursday, September 05, 2013 12:34 AM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hy Raymond, On 04.09.2013 18:33, Steele, Raymond wrote: You are right, I completely missed your post. I am updating my compiler (SolarisStudio 12.3) now. As far as I can see now, I do not have isfinite is not a member of std on my system. Although, Netbeans allows me to choose C++ Standard C++11. What do you mean by experiment with the different SAL_MATH_FINITE definitions? mathconf.h is a C header file, so we need the C definition of isfinite. According to [1] the C isfinite() should be defined in math.h. Maybe on your platform there is a bug similar to [2] that undefines it later. But we can assume that isfinite() is available in one form or the other on your system. Maybe it is called finite(), _finite(), or __builtin_isfinite()? Assuming [3] applies here then finite() may be the pre-standard equivalent to the isfinite() function that we are looking for. [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/isfinite.html [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608 [3] https://www.varnish-cache.org/trac/ticket/464 What I meant with experiment with the different SAL_MATH_FINITE definitions is to check whether one of the above pre-standard isfinite() alternatives work. If you found one then add a define for SOLARIS only that doesn't break the other platforms. By the way std::isfinite() should be provided via cmath for C++11. But as the mathconf.h header is a C header this C++11 header is not available in this context. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Problem after problem. Now I am getting: Entering /opt/aoo-4.0.0/main/configmgr/source Compiling: configmgr/source/partial.cxx /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 199: Error: Could not find a match for boost::tuples::getboost::tuples::N, boost::tuples::HT, boost::tuples::TT(const boost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type) needed in boost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node, boost::tuples::null_type(configmgr::Partial::Node*, const boost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350: Where: While instantiating boost::unordered::detail::construct_from_tupleconfigmgr::Partial::Node, boost::tuples::null_type(configmgr::Partial::Node*, const boost::tuples::tupleboost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type). /usr/local/include/boost/unordered/detail/emplace_args.hpp, line 350: Where: Instantiated from boost::unordered::unordered_maprtl::OUString, configmgr::Partial::Node, boost::hashrtl::OUString, _STL::equal_tortl::OUString, _STL::allocator_STL::pairconst rtl::OUString, configmgr::Partial::Node::operator[](const rtl::OUString). /opt/aoo-4.0.0/main/configmgr/source/partial.cxx, line 82: Where: Instantiated from non-template code. 1 Error(s) detected. dmake: Error code 2, while making '../unxsoli4.pro/slo/partial.obj' 1 module(s): configmgr need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /opt/aoo-4.0.0/main/configmgr/source When you have fixed the errors in that module you can resume the build by running: build --all:configmgr I thought I paste it here to see if you could help. Thanks! -Original Message- From: Steele, Raymond Sent: Friday, September 06, 2013 3:17 PM To: 'Herbert Duerr'; dev@openoffice.apache.org Subject: RE: EXTERNAL: Re: Building comphelper Herbert, To address the isfinite() issue I added the following to rtl/math.hxx: #ifdef SOLARIS #undef SAL_MATH_FINITE #define SAL_MATH_FINITE(d) finite(d) #endf Your links were very helpful. Thanks so much. Now onto: integer_fwd.cpp contains the following on line 136 and 137: 136: template 137: struct low_bits_mask_t ::std::numeric_limitsunsigned char::digits; -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Thursday, September 05, 2013 12:34 AM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hy Raymond, On 04.09.2013 18:33, Steele, Raymond wrote: You are right, I completely missed your post. I am updating my compiler (SolarisStudio 12.3) now. As far as I can see now, I do not have isfinite is not a member of std on my system. Although, Netbeans allows me to choose C++ Standard C++11. What do you mean by experiment with the different SAL_MATH_FINITE definitions? mathconf.h is a C header file, so we need the C definition of isfinite. According to [1] the C isfinite() should be defined in math.h. Maybe on your platform there is a bug similar to [2] that undefines it later. But we can assume that isfinite() is available in one form or the other on your system. Maybe it is called finite(), _finite(), or __builtin_isfinite()? Assuming [3] applies here then finite() may be the pre-standard equivalent to the isfinite() function that we are looking for. [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/isfinite.html [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608 [3] https://www.varnish-cache.org/trac/ticket/464 What I meant with experiment with the different SAL_MATH_FINITE definitions is to check whether one of the above pre-standard isfinite() alternatives work. If you found one then add a define for SOLARIS only that doesn't break the other platforms. By the way std::isfinite() should be provided via cmath for C++11. But as the mathconf.h header is a C header this C++11 header is not available in this context. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Hy Raymond, On 04.09.2013 18:33, Steele, Raymond wrote: You are right, I completely missed your post. I am updating my compiler (SolarisStudio 12.3) now. As far as I can see now, I do not have isfinite is not a member of std on my system. Although, Netbeans allows me to choose C++ Standard C++11. What do you mean by experiment with the different SAL_MATH_FINITE definitions? mathconf.h is a C header file, so we need the C definition of isfinite. According to [1] the C isfinite() should be defined in math.h. Maybe on your platform there is a bug similar to [2] that undefines it later. But we can assume that isfinite() is available in one form or the other on your system. Maybe it is called finite(), _finite(), or __builtin_isfinite()? Assuming [3] applies here then finite() may be the pre-standard equivalent to the isfinite() function that we are looking for. [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/isfinite.html [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608 [3] https://www.varnish-cache.org/trac/ticket/464 What I meant with experiment with the different SAL_MATH_FINITE definitions is to check whether one of the above pre-standard isfinite() alternatives work. If you found one then add a define for SOLARIS only that doesn't break the other platforms. By the way std::isfinite() should be provided via cmath for C++11. But as the mathconf.h header is a C header this C++11 header is not available in this context. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Thanks for the information. I will give this a try if my current strategy does not work. Apparently, SolarisStudios 12.3 compiler is not compatible with c++11. I just finished building GCC 4.8.1 so that I can attempt to build with that.Now, I am having the issue described here: http://wiki.openoffice.org/wiki/OpenSolaris_Build_Instructions/Configure_Errors#Error:_GCC_Linker because I have CC and CXX pointing to my new gcc and g++. How can I point these variables to SolarisStudio compilers for linking, but use gcc for compiling? Raymond -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Thursday, September 05, 2013 12:34 AM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hy Raymond, On 04.09.2013 18:33, Steele, Raymond wrote: You are right, I completely missed your post. I am updating my compiler (SolarisStudio 12.3) now. As far as I can see now, I do not have isfinite is not a member of std on my system. Although, Netbeans allows me to choose C++ Standard C++11. What do you mean by experiment with the different SAL_MATH_FINITE definitions? mathconf.h is a C header file, so we need the C definition of isfinite. According to [1] the C isfinite() should be defined in math.h. Maybe on your platform there is a bug similar to [2] that undefines it later. But we can assume that isfinite() is available in one form or the other on your system. Maybe it is called finite(), _finite(), or __builtin_isfinite()? Assuming [3] applies here then finite() may be the pre-standard equivalent to the isfinite() function that we are looking for. [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/isfinite.html [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608 [3] https://www.varnish-cache.org/trac/ticket/464 What I meant with experiment with the different SAL_MATH_FINITE definitions is to check whether one of the above pre-standard isfinite() alternatives work. If you found one then add a define for SOLARIS only that doesn't break the other platforms. By the way std::isfinite() should be provided via cmath for C++11. But as the mathconf.h header is a C header this C++11 header is not available in this context. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Herbert, You are right, I completely missed your post. I am updating my compiler (SolarisStudio 12.3) now. As far as I can see now, I do not have isfinite is not a member of std on my system. Although, Netbeans allows me to choose C++ Standard C++11. What do you mean by experiment with the different SAL_MATH_FINITE definitions? Raymond -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Wednesday, September 04, 2013 12:14 AM To: dev@openoffice.apache.org Cc: Steele, Raymond Subject: EXTERNAL: Re: Building comphelper On 03.09.2013 18:10, Steele, Raymond wrote: Anyone? This seems to pertain to the GNU bug described here since mathconf.h included in the AOO source has a comment about it. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608 In case you missed my replies to your questions please see http://markmail.org/thread/5gnsk7hmehxfdthx Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
