RE: EXTERNAL: Re: NSS Module
Just wanted to let you know that I resolved this by pointing xmlsecurity to the
local NSS libraries installed with firefox. This was done by adding it to the
LD_LIBRARY_PATH env variable.
-Original Message-
From: Herbert Duerr [mailto:h...@apache.org]
Sent: Thursday, June 26, 2014 4:11 AM
To: dev@openoffice.apache.org
Subject: Re: EXTERNAL: Re: NSS Module
On 26.06.2014 02:32, Steele, Raymond wrote:
> Where is the build output located?
It is emitted to stdout unless you used the --html option in your build
command. To capture stdout either redirect it with e.g.
build --all -P2 >stdout.log -- -P2
or use a pipe and the tee command
build --all -P2 -- -P2 | tee stdout.log to capture it and watch the progress
at the same time.
> I have NSS on my system, but the --with-system-nss flag is not an option. If
> I use --with-system-libs, wouldn't that enable system-libs for all software?
I'm no expert on AOO's configure system but as far as I know the option
--with-system-libs should only enable the system libs where development headers
and libraries are available on the build system.
There is still the question on whether the system-nss is being used:
The makefile output ("NSS is not being built because...") would be one
important piece of information containing the relevant environment variables
"ENABLE_NSS_MODULE" and "SYSTEM_NSS". The environment variables are of course
also visible in the... environment once you sourced the platform specific file
mentioned by the configure script.
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: EXTERNAL: Re: NSS Module
After source SolarisX86Env.Set.sh
env|grep -I nss displays the following:
NSS_LIB=-L/usr/lib/mps
OPENSSL_LIBS=-lssl -lcrypto
MOZ_NSS_CFLAGS=-I/usr/include/mps
OPENSSL_CFLAGS=
ENABLE_NSS_MODULE=NO
SYSTEM_OPENSSL=YES
I no longer want AOO to build it since I have it installed on my system.
However, when I build xmlsecurity, it cannot find the NSS libraries.
-Original Message-
From: Herbert Duerr [mailto:h...@apache.org]
Sent: Thursday, June 26, 2014 4:11 AM
To: dev@openoffice.apache.org
Subject: Re: EXTERNAL: Re: NSS Module
On 26.06.2014 02:32, Steele, Raymond wrote:
> Where is the build output located?
It is emitted to stdout unless you used the --html option in your build
command. To capture stdout either redirect it with e.g.
build --all -P2 >stdout.log -- -P2
or use a pipe and the tee command
build --all -P2 -- -P2 | tee stdout.log to capture it and watch the progress
at the same time.
> I have NSS on my system, but the --with-system-nss flag is not an option. If
> I use --with-system-libs, wouldn't that enable system-libs for all software?
I'm no expert on AOO's configure system but as far as I know the option
--with-system-libs should only enable the system libs where development headers
and libraries are available on the build system.
There is still the question on whether the system-nss is being used:
The makefile output ("NSS is not being built because...") would be one
important piece of information containing the relevant environment variables
"ENABLE_NSS_MODULE" and "SYSTEM_NSS". The environment variables are of course
also visible in the... environment once you sourced the platform specific file
mentioned by the configure script.
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: EXTERNAL: Re: NSS Module
Herbert, Where is the build output located? I have NSS on my system, but the --with-system-nss flag is not an option. If I use --with-system-libs, wouldn't that enable system-libs for all software? -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Monday, June 23, 2014 11:52 PM To: dev@openoffice.apache.org Subject: EXTERNAL: Re: NSS Module Hi Raymond, On 23.06.2014 18:42, Steele, Raymond wrote: > After running the configure, the ENABLE_NSS_MODULE environment variable is > set to yes, but for some reason NSS is not built. The build fails in > xmlsecurity because the NSS libraries were not built and copied over to > solver. I have to manually run dmake on NSS then copy them to the lib > directory in solver. Any ideas why? Looking into main/nss/makefile.mk the logic on whether the builtin nss is built is right there: If nss is disabled or if the system-provided nss is selected, then the builtin nss will not be built. In that case there would be an info: "NSS will not be built because..." I guess this was the case. Please search the build output for this line. The system provided nss is preferred over the builtin nss if you configured with --with-system-nss or --with-system-libs. Please check whether any of these configure options were active. 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: EXTERNAL: RE: NSS Module
Thanks for the information. What platform are you compiling for? What problem are you having at runtime? -Original Message- From: Απόστολος Συρόπουλος [mailto:asyropoulos...@hotmail.com] Sent: Wednesday, June 25, 2014 12:24 AM To: dev@openoffice.apache.org Subject: EXTERNAL: RE: NSS Module Hello, I have found a "solution" to this and other problems: http://asyropoulos.wordpress.com/2014/02/05/compiling-openoffice4/ Of course the final binaries do nor run but this is something I will resume working on this autumn. A.S. -- Apostolos Syropoulos Xanthi, Greece http://asyropoulos.eu http://asyropoulos.wordpress.com http://hypercomputation.blogspot.com/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Macro Security Button Crash (shlib.cxx)
The OpenOffice application crashes when I click the Macro Security button in Options. I've traced the crash to line 364 in shlib.cxx. It appears that the library libsec_xml.so is trying to be loaded with osl_loadModule(), but that function and osl_loadAsciiModule() return NULL, causing the loader::CannotActivateFactoryException to be thrown, which results in a crash. The following dlerror() is printed to screen. ../libsec_xmlsec.so: symbol CERT_NameTemplate:referenced symbol not found. I really just need to set Macro security setting and this is preventing this. Please let me know if anyone can or cannot help. Thanks again, Raymond
NSS Module
After running the configure, the ENABLE_NSS_MODULE environment variable is set to yes, but for some reason NSS is not built. The build fails in xmlsecurity because the NSS libraries were not built and copied over to solver. I have to manually run dmake on NSS then copy them to the lib directory in solver. Any ideas why? Thanks, Raymond
RE: EXTERNAL: Re: Macro Security Button
Thanks. Is coinMP and Hunspell needed for security features? -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Friday, June 13, 2014 2:50 AM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Macro Security Button Hi Raymond, On 12.06.2014 17:39, Steele, Raymond wrote: > I am just trying to set ENABLE_NSS_MODULE=YES.I thought enabling category-b > would do this, but that does not seem to be the case. How does one go about > enabling the security macros button? I thought it was by enabling NSS and > category-b, but that does not seem to work. I could manually force it , or > change the configure script, but that does not seem to be the correct > solution. According to main/configure.in line 330 the nss module is enabled by default. It gets disabled though in line 1422 of the same file unless category-b licensed code is explicitly enabled. This is so for policy reasons, see [1] for details. So if you enabled category-b licensed code and didn't disable nss, then nss should be enabled. If this isn't so please check and eventually update your system's autoconf tool. If that doesn't help then enabling the ENABLE_NSS_MODULE option by force may be the fastest solution. [1] http://markmail.org/thread/erh6leykxwygio2k Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Macro Security Button
I am just trying to set ENABLE_NSS_MODULE=YES.I thought enabling category-b would do this, but that does not seem to be the case. How does one go about enabling the security macros button? I thought it was by enabling NSS and category-b, but that does not seem to work. I could manually force it , or change the configure script, but that does not seem to be the correct solution. -Original Message- From: Jürgen Schmidt [mailto:jogischm...@gmail.com] Sent: Wednesday, June 11, 2014 11:24 PM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Macro Security Button On 12/06/14 01:41, Steele, Raymond wrote: > I am not sure if this is desired, but it appears the configure.in script > does set’s ENABLE_NSS_MODULE=NO if the category-b flag is enabled. Is this > wrong or right? I need the security features enabled. > It is correct, we enable some features that depend on category b with only one switch. Take them all or none. If catgory-b is ok why should somebody drop a feature? In your case potentially other category-b feature make problems as well but this is a different topic. Juergen > http://svn.apache.org/viewvc/openoffice/branches/AOO401/main/configure > .in?view=markup > > AC_MSG_CHECKING([whether to enable category B components]) > > 1430 > > # Category B modules (libraries): > > 1431 > > # moz (seamonkey) > > 1432 > > # nss (nss) > > 1433 > > # hunspell (hunspell) > > 1434 > > # hyphen (hyphen) > > 1435 > > # saxon (saxon) > > 1436 > > # rhino (rhino) > > 1437 > > # beanshell (beanshell) > > 1438 > > # graphite (silgraphite) > > 1439 > > if test "$enable_category_b" = "yes"; then > > 1440 > > ENABLE_CATEGORY_B=YES > > 1441 > > enable_hunspell="yes" > > 1442 > > enable_hyphen="yes" > > 1443 > > enable_saxon="yes" > > 1444 > > enable_javascript="yes" > > 1445 > > enable_beanshell="yes" > > 1446 > > enable_graphite="yes" > > 1447 > > enable_coinmp="yes" > > 1448 > > enable_category_b_fonts="yes" > > 1449 > > 1450 > > AC_MSG_RESULT([yes: allow modules moz, nss, hunspell, hyphen, saxon, > rhino, beanshell, graphite, coinmp to be built]) > > 1451 > > else > > 1452 > > # Disable libaries. > > 1453 > > enable_mozilla="no" > > 1454 > > enable_nss_module="no" > > 1455 > > enable_hunspell="no" > > 1456 > > enable_hyphen="no" > > 1457 > > enable_saxon="no" > > 1458 > > enable_javascript="no" > > 1459 > > enable_beanshell="no" > > 1460 > > enable_graphite="no" > > 1461 > > enable_coinmp="no" > > 1462 > > enable_category_b_fonts="no" > > > > > -Original Message- > From: Kay Schenk [mailto:kay.sch...@gmail.com] > Sent: Tuesday, June 10, 2014 8:48 AM > To: OOo Apache > Subject: Re: EXTERNAL: Re: Macro Security Button > > > > On Mon, Jun 9, 2014 at 3:12 PM, Steele, Raymond > mailto:raymond.ste...@lmco.com>> > > wrote: > > > >> I will give this a try. However, I noticed that when I > >> -enable-category-b and -enable-nss-module, the environment variable > >> ENABLE_NSS_MODULE is set to NO. Is this correct? > >> > > > > This doesn't sound right to me, but typically I don't "-enable-category-b" > > so ENABLE_NSS_MODULE=NO on my setup typically. Looking at > configure.in, to me it seems -enable-nss-module is set to "yes" unless > you set it to no, if you use enable-category-b, > > > > If I were you I would try dmake clean (source your shell file first before > doing this), followed by a fresh configure with just "-enable-category-b" > > added and then see what you get on ENABLE_NSS_MODULE. > > > > > > > >> -Original Message- > >> From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com] > >> Sent: Friday, June 06, 2014 4:25 AM > >> To: dev@openoffice.apache.org<mailto:dev@openoffice.apache.org> > >> Subject: EXTERNAL: Re: Macro Security Button > >> > >> Hi, > >> > >> On 05.06.2014 20:24, Steele, Raymond wrote: > >>> In reference to the following thread, is setting the > >>> -enable-category-b switch and re-compiling the only way to get the > >&g
RE: EXTERNAL: Re: Macro Security Button
I am not sure if this is desired, but it appears the configure.in script does set’s ENABLE_NSS_MODULE=NO if the category-b flag is enabled. Is this wrong or right? I need the security features enabled. http://svn.apache.org/viewvc/openoffice/branches/AOO401/main/configure.in?view=markup AC_MSG_CHECKING([whether to enable category B components]) 1430 # Category B modules (libraries): 1431 # moz (seamonkey) 1432 # nss (nss) 1433 # hunspell (hunspell) 1434 # hyphen (hyphen) 1435 # saxon (saxon) 1436 # rhino (rhino) 1437 # beanshell (beanshell) 1438 # graphite (silgraphite) 1439 if test "$enable_category_b" = "yes"; then 1440 ENABLE_CATEGORY_B=YES 1441 enable_hunspell="yes" 1442 enable_hyphen="yes" 1443 enable_saxon="yes" 1444 enable_javascript="yes" 1445 enable_beanshell="yes" 1446 enable_graphite="yes" 1447 enable_coinmp="yes" 1448 enable_category_b_fonts="yes" 1449 1450 AC_MSG_RESULT([yes: allow modules moz, nss, hunspell, hyphen, saxon, rhino, beanshell, graphite, coinmp to be built]) 1451 else 1452 # Disable libaries. 1453 enable_mozilla="no" 1454 enable_nss_module="no" 1455 enable_hunspell="no" 1456 enable_hyphen="no" 1457 enable_saxon="no" 1458 enable_javascript="no" 1459 enable_beanshell="no" 1460 enable_graphite="no" 1461 enable_coinmp="no" 1462 enable_category_b_fonts="no" -Original Message- From: Kay Schenk [mailto:kay.sch...@gmail.com] Sent: Tuesday, June 10, 2014 8:48 AM To: OOo Apache Subject: Re: EXTERNAL: Re: Macro Security Button On Mon, Jun 9, 2014 at 3:12 PM, Steele, Raymond mailto:raymond.ste...@lmco.com>> wrote: > I will give this a try. However, I noticed that when I > -enable-category-b and -enable-nss-module, the environment variable > ENABLE_NSS_MODULE is set to NO. Is this correct? > This doesn't sound right to me, but typically I don't "-enable-category-b" so ENABLE_NSS_MODULE=NO on my setup typically. Looking at configure.in, to me it seems -enable-nss-module is set to "yes" unless you set it to no, if you use enable-category-b, If I were you I would try dmake clean (source your shell file first before doing this), followed by a fresh configure with just "-enable-category-b" added and then see what you get on ENABLE_NSS_MODULE. > -Original Message----- > From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com] > Sent: Friday, June 06, 2014 4:25 AM > To: dev@openoffice.apache.org<mailto:dev@openoffice.apache.org> > Subject: EXTERNAL: Re: Macro Security Button > > Hi, > > On 05.06.2014 20:24, Steele, Raymond wrote: > > In reference to the following thread, is setting the > > -enable-category-b switch and re-compiling the only way to get the > > macro security button to work in OpenOffice? > > > > http://markmail.org/thread/etx2btp74xaazc3p > > > > configure option -enable-category-b activates the build of nss which > is needed for security related stuff in AOO. > > Thus, you can use -enable-category-b to get the macro security stuff. > I think you can also -enable-nss-module top get it work. > > Best regards, Oliver. > > > Raymond > > > > > > - > To unsubscribe, e-mail: > dev-unsubscr...@openoffice.apache.org<mailto:dev-unsubscr...@openoffice.apache.org> > For additional commands, e-mail: > dev-h...@openoffice.apache.org<mailto:dev-h...@openoffice.apache.org> > > > - > To unsubscribe, e-mail: > dev-unsubscr...@openoffice.apache.org<mailto:dev-unsubscr...@openoffice.apache.org> > For additional commands, e-mail: > dev-h...@openoffice.apache.org<mailto:dev-h...@openoffice.apache.org> > > -- - MzK "In the midst of winter, I found there was, within me, an invincible summer." -- Albert Camus
Bug 668130 - Remove auditing code in fipstokn.c which breaks Solaris 11
I wanted to share this bug that I came across during my AOO 4.0.1 compile. https://bugzilla.mozilla.org/show_bug.cgi?id=668130 Raymond
RE: xmlsecurity
After further looking by doing, ldd check_libxsec_xmlsec.so, it appears that libnss3.so, libnspr4.so, and others cannot be found. I wonder why? From: Steele, Raymond Sent: Monday, June 09, 2014 5:06 PM To: dev@openoffice.apache.org Subject: xmlsecurity When building xmlsecurity, I receive the following error: : ERROR ld.so.1: checkdll: fatal: relocation error: file ../unxsoli4.pro/lib/check_libxsec_xmlsec.so: symbol CERT_NameTemplate: reference symbol not found Anyone understand what is going on here? Thanks, Raymond
xmlsecurity
When building xmlsecurity, I receive the following error: : ERROR ld.so.1: checkdll: fatal: relocation error: file ../unxsoli4.pro/lib/check_libxsec_xmlsec.so: symbol CERT_NameTemplate: reference symbol not found Anyone understand what is going on here? Thanks, Raymond
RE: EXTERNAL: Re: Macro Security Button
I will give this a try. However, I noticed that when I -enable-category-b and -enable-nss-module, the environment variable ENABLE_NSS_MODULE is set to NO. Is this correct? -Original Message- From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com] Sent: Friday, June 06, 2014 4:25 AM To: dev@openoffice.apache.org Subject: EXTERNAL: Re: Macro Security Button Hi, On 05.06.2014 20:24, Steele, Raymond wrote: > In reference to the following thread, is setting the > -enable-category-b switch and re-compiling the only way to get the > macro security button to work in OpenOffice? > > http://markmail.org/thread/etx2btp74xaazc3p > configure option -enable-category-b activates the build of nss which is needed for security related stuff in AOO. Thus, you can use -enable-category-b to get the macro security stuff. I think you can also -enable-nss-module top get it work. Best regards, Oliver. > Raymond > > - 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
Macro Security Button
In reference to the following thread, is setting the -enable-category-b switch and re-compiling the only way to get the macro security button to work in OpenOffice? http://markmail.org/thread/etx2btp74xaazc3p Raymond
RE: EXTERNAL: Re: Seperate User Directories
Perfect. Thanks. -Original Message- From: Ariel Constenla-Haile [mailto:arie...@apache.org] Sent: Tuesday, May 20, 2014 10:08 AM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Seperate User Directories Hi On Tue, May 20, 2014 at 03:49:50PM +, Steele, Raymond wrote: > What do you mean, support for pkg? Are you saying that there used to > be a mechanism to automatically generate a Solaris package? --with-package-format="pkg" according to http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/configure.in#136 http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/configure.in#3412 http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/configure.in#3453 Regards -- Ariel Constenla-Haile La Plata, Argentina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Seperate User Directories
What do you mean, support for pkg? Are you saying that there used to be a
mechanism to automatically generate a Solaris package?
-Original Message-
From: Jürgen Schmidt [mailto:jogischm...@gmail.com]
Sent: Tuesday, May 20, 2014 12:17 AM
To: dev@openoffice.apache.org
Subject: Re: EXTERNAL: Re: Seperate User Directories
On 19/05/14 18:22, Steele, Raymond wrote:
> Thanks for the response. Is there a preferred version (other than the
> archived) that I should be using for installation? Also, I notice there is
> only one directory, openoffiice4, versus two (openoffice3 & openoffice.org)
> in previous versions. Is this by design?
>
I haven't compiled Solaris for a long time but I assume that we still have
support for pkg.
Juergen
> -Original Message-
> From: Jürgen Schmidt [mailto:jogischm...@gmail.com]
> Sent: Monday, May 19, 2014 12:41 AM
> To: dev@openoffice.apache.org
> Subject: EXTERNAL: Re: Seperate User Directories
>
> On 17/05/14 13:27, Andrea Pescetti wrote:
>> On 15/05/2014 Steele, Raymond wrote:
>>> I compiled OpenOffice and extracted the archive located at
>>> main/instsetoo_native/unxsoli4.pro/Apache_OpenOffice/archive/install
>>> /
>>> en-US/
>>>
>>> top my /opt directory. However, it appears that during runtime of
>>> the Application the user private directory is located in
>>> /opt/openoffice4/.openoffice/4/user, which is global to all users.
>>> How do I configure the private user directories to be created in the
>>> users home directory to prevent a .lock file from preventing another
>>> user access to using the application?
>>
>> I know from previous discussions here that you are doing a huge
>> effort to port OpenOffice to Solaris (and I apologize if others have
>> already answered; mail delivery is still delayed due to technical
>> problems); anyway, assuming that the basics are the same as in other
>> UNIX-like systems, the "archived" build define their own location for
>> the user profile and this is why you see a common one.
>>
>> The profile location is defined in a file named "bootstraprc", which
>> you will find at something like:
>> /opt/openoffice4/program/bootstraprc
>>
>> This is the content of a bootstraprc file with per-user profile settings:
>>
>> [Bootstrap]
>> BaseInstallation=${OOO_BASE_DIR}
>> InstallMode=
>> ProductKey=OpenOffice 4.1.0
>> UserInstallation=$SYSUSERCONFIG/.openoffice/4/user
>> [ErrorReport]
>> ErrorReportPort=80
>> ErrorReportServer=
>>
>
> The archive version is for testing mainly and it stores the user directory
> inside the installation itself to avoid conflicts with the normal user
> directory of other installations.
>
> This is correct and intended, if you want install an archive version manually
> in your system you have to change the user directory as Andrea has already
> described.
>
>
> Juergen
>
>
>
>
> -
> 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
>
-
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: EXTERNAL: Re: Seperate User Directories
Thanks Kay.
-Original Message-
From: Kay Schenk [mailto:kay.sch...@gmail.com]
Sent: Monday, May 19, 2014 9:46 AM
To: OOo Apache
Subject: Re: EXTERNAL: Re: Seperate User Directories
On Mon, May 19, 2014 at 9:22 AM, Steele, Raymond wrote:
> Thanks for the response. Is there a preferred version (other than the
> archived) that I should be using for installation? Also, I notice
> there is only one directory, openoffiice4, versus two (openoffice3 &
> openoffice.org) in previous versions. Is this by design?
>
yes...the structure was reworked for version 4.
>
> -Original Message-
> From: Jürgen Schmidt [mailto:jogischm...@gmail.com]
> Sent: Monday, May 19, 2014 12:41 AM
> To: dev@openoffice.apache.org
> Subject: EXTERNAL: Re: Seperate User Directories
>
> On 17/05/14 13:27, Andrea Pescetti wrote:
> > On 15/05/2014 Steele, Raymond wrote:
> >> I compiled OpenOffice and extracted the archive located at
> >> main/instsetoo_native/unxsoli4.pro/Apache_OpenOffice/archive/instal
> >> l/
> >> en-US/
> >>
> >> top my /opt directory. However, it appears that during runtime of
> >> the Application the user private directory is located in
> >> /opt/openoffice4/.openoffice/4/user, which is global to all users.
> >> How do I configure the private user directories to be created in
> >> the users home directory to prevent a .lock file from preventing
> >> another user access to using the application?
> >
> > I know from previous discussions here that you are doing a huge
> > effort to port OpenOffice to Solaris (and I apologize if others have
> > already answered; mail delivery is still delayed due to technical
> > problems); anyway, assuming that the basics are the same as in other
> > UNIX-like systems, the "archived" build define their own location
> > for the user profile and this is why you see a common one.
> >
> > The profile location is defined in a file named "bootstraprc", which
> > you will find at something like:
> > /opt/openoffice4/program/bootstraprc
> >
> > This is the content of a bootstraprc file with per-user profile settings:
> >
> > [Bootstrap]
> > BaseInstallation=${OOO_BASE_DIR}
> > InstallMode=
> > ProductKey=OpenOffice 4.1.0
> > UserInstallation=$SYSUSERCONFIG/.openoffice/4/user
> > [ErrorReport]
> > ErrorReportPort=80
> > ErrorReportServer=
> >
>
> The archive version is for testing mainly and it stores the user
> directory inside the installation itself to avoid conflicts with the
> normal user directory of other installations.
>
> This is correct and intended, if you want install an archive version
> manually in your system you have to change the user directory as
> Andrea has already described.
>
>
> Juergen
>
>
>
>
> -
> 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
>
>
--
-
MzK
"Life is either a daring adventure, or nothing."
-- Helen Keller
RE: EXTERNAL: Re: Seperate User Directories
This worked perfectly, thanks!
-Original Message-
From: Andrea Pescetti [mailto:pesce...@apache.org]
Sent: Saturday, May 17, 2014 4:27 AM
To: dev@openoffice.apache.org
Cc: Steele, Raymond
Subject: EXTERNAL: Re: Seperate User Directories
On 15/05/2014 Steele, Raymond wrote:
> I compiled OpenOffice and extracted the archive located at
> main/instsetoo_native/unxsoli4.pro/Apache_OpenOffice/archive/install/e
> n-US/ top my /opt directory. However, it appears that during runtime
> of the Application the user private directory is located in
> /opt/openoffice4/.openoffice/4/user, which is global to all users.
> How do I configure the private user directories to be created in the
> users home directory to prevent a .lock file from preventing another
> user access to using the application?
I know from previous discussions here that you are doing a huge effort to port
OpenOffice to Solaris (and I apologize if others have already answered; mail
delivery is still delayed due to technical problems); anyway, assuming that the
basics are the same as in other UNIX-like systems, the "archived" build define
their own location for the user profile and this is why you see a common one.
The profile location is defined in a file named "bootstraprc", which you will
find at something like:
/opt/openoffice4/program/bootstraprc
This is the content of a bootstraprc file with per-user profile settings:
[Bootstrap]
BaseInstallation=${OOO_BASE_DIR}
InstallMode=
ProductKey=OpenOffice 4.1.0
UserInstallation=$SYSUSERCONFIG/.openoffice/4/user
[ErrorReport]
ErrorReportPort=80
ErrorReportServer=
Regards,
Andrea.
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Seperate User Directories
Thanks for the response. Is there a preferred version (other than the
archived) that I should be using for installation? Also, I notice there is only
one directory, openoffiice4, versus two (openoffice3 & openoffice.org) in
previous versions. Is this by design?
-Original Message-
From: Jürgen Schmidt [mailto:jogischm...@gmail.com]
Sent: Monday, May 19, 2014 12:41 AM
To: dev@openoffice.apache.org
Subject: EXTERNAL: Re: Seperate User Directories
On 17/05/14 13:27, Andrea Pescetti wrote:
> On 15/05/2014 Steele, Raymond wrote:
>> I compiled OpenOffice and extracted the archive located at
>> main/instsetoo_native/unxsoli4.pro/Apache_OpenOffice/archive/install/
>> en-US/
>>
>> top my /opt directory. However, it appears that during runtime of the
>> Application the user private directory is located in
>> /opt/openoffice4/.openoffice/4/user, which is global to all users.
>> How do I configure the private user directories to be created in the
>> users home directory to prevent a .lock file from preventing another
>> user access to using the application?
>
> I know from previous discussions here that you are doing a huge effort
> to port OpenOffice to Solaris (and I apologize if others have already
> answered; mail delivery is still delayed due to technical problems);
> anyway, assuming that the basics are the same as in other UNIX-like
> systems, the "archived" build define their own location for the user
> profile and this is why you see a common one.
>
> The profile location is defined in a file named "bootstraprc", which
> you will find at something like:
> /opt/openoffice4/program/bootstraprc
>
> This is the content of a bootstraprc file with per-user profile settings:
>
> [Bootstrap]
> BaseInstallation=${OOO_BASE_DIR}
> InstallMode=
> ProductKey=OpenOffice 4.1.0
> UserInstallation=$SYSUSERCONFIG/.openoffice/4/user
> [ErrorReport]
> ErrorReportPort=80
> ErrorReportServer=
>
The archive version is for testing mainly and it stores the user directory
inside the installation itself to avoid conflicts with the normal user
directory of other installations.
This is correct and intended, if you want install an archive version manually
in your system you have to change the user directory as Andrea has already
described.
Juergen
-
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
Seperate User Directories
I compiled OpenOffice and extracted the archive located at main/instsetoo_native/unxsoli4.pro/Apache_OpenOffice/archive/install/en-US/ top my /opt directory. However, it appears that during runtime of the Application the user private directory is located in /opt/openoffice4/.openoffice/4/user, which is global to all users. How do I configure the private user directories to be created in the users home directory to prevent a .lock file from preventing another user access to using the application? Raymond
Separate User Directories
I am sending this question again because I did not see that it posted to the mailing list yesterday. From: Steele, Raymond Sent: Thursday, May 15, 2014 2:35 PM To: dev@openoffice.apache.org Subject: Seperate User Directories I compiled OpenOffice and extracted the archive located at main/instsetoo_native/unxsoli4.pro/Apache_OpenOffice/archive/install/en-US/ top my /opt directory. However, it appears that during runtime of the Application the user private directory is located in /opt/openoffice4/.openoffice/4/user, which is global to all users. How do I configure the private user directories to be created in the users home directory to prevent a .lock file from preventing another user access to using the application? Raymond
Incomplete Initialization of typelib_interfaceTypeDescription Causing Segementation Fault
I am hoping that someone could provide some information to me about how to deal with this problem. When adding an Extension Add-on which was written in Java the application crashes. in cpp2uno.cxx on line 256 after the RuntimeException is thrown at line 247. Apparently, the type_libInterfaceTypeDescription struct (named pTypeDescr) was not initialized completely. According to the documentation for that struct in typedescription.h and typelib.cxx, not all of the members in that struct are always initialized, depending on the situation. However, in the case where I am adding the extension, the RuntimeException on line 252 is thrown, then it appears the code attempts to access pMapFunctionIndexToMemberIndex element of the struct. This is when the application crashes. I've tried to track down the creation of the struct for this case, but am having some difficulty since this happen many times throughout regular runtime. I've received the following from another developer, but I still cannot determine how to address it. "Possibly there was an error finding the UNOIDL type data, either compiled into the cppumaker-generated headers , or obtained from .rdb file." Please see related message: http://markmail.org/message/elyx4immy3ivsjwt Raymond
RE: EXTERNAL: Re: Extension Manager Add Crashes
Anyone out their willing and able to assist with this issue? We are not making any progress. -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Wednesday, April 16, 2014 12:12 AM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 16.04.2014 01:16, Steele, Raymond wrote: > Why do you mention the Solaris Sparc UNO C++ bridge below. Is it related to > the x86/intel bridge. I am running Solaris 11 x86_64. Ah, ok. Looking at the directory main/bridges/source/cpp_uno there is no UNO bridge yet for Solaris Studio on a x86-64 CPU. But apparently your compile got through, so in order to know where to tweak you need to find out which bridge was actually used. Then you can adapt it to your platform (operating system, compiler, cpu architecture, ABI). As I mentioned the platform independence of AOO's UNO subsystem was unfortunately not designed in e.g. by using plain programming language constructs or using portable mechanisms like C-linking. Getting a bridge to work was accomplished by brute force :-/ (reverse engineering the vtable layouts, symbol mangling, calling conventions, implementation details of exception handling, etc.) but if we're lucky a few tweaks to the currently active bridge could suffice. For an idea on what tweaks might be needed please check the evolution of the related x86-64 bridges for Linux, FreeBSD or MacOSX. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
Also, it only seems to happen when the symbol names are component_canUnload and
component_getImplementationEnvironment. Is this really a problem? If not, why
would the trace output report it as an error? Why would the code check for
these symbols in ld.so.1? Isn't that the linker library?
-Original Message-
From: Steele, Raymond
Sent: Thursday, April 17, 2014 3:58 PM
To: 'a...@openoffice.apache.org'; 'dev@openoffice.apache.org'
Cc: Meffe, David K; Marks, Jeffrie
Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes
I traced this osl_getAsciiFunctionSymbol issues down to sal/osl/unx/module.c
line 154.
Apparently, the function osl_getAsciiDunctionSymbol is calling "dlsym" (fcnAddr
= dlsym(Module, pSymbol) which attempts to get the address of a symbol in a
shared object or executable. NULL is returned if address of the symbol's name
as a character string cannot be found.
In the case of "error: osl_getAsciiFunctionSymbol failed with ld.so.1:
soffice.bin: fatal: component_getImplementationEnvironmnet: can't find symbol"
I received in my trace output, null is returned.
(from dbx dump)
fcnAddr = (nil)
pSymbol = 0xfdc7710 " component_getImplementationEnvironmnet"
Module = 0xf80008e0
Also, I noticed this call to dlsym is wraped in an #ifndef NO_DL_FUNCTIONS,
however this is not defined in my environment. What is the significance of
calling dlsym, can't I simple define NO_DL_FUNCTIONS to prevent this from
occurring or will this have a negative impact on my underlying issue with the
bridge?
Raymond
-Original Message-
From: Steele, Raymond
Sent: Tuesday, April 15, 2014 12:28 PM
To: a...@openoffice.apache.org; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes
Thanks AGAIN, Herbert.
Is there any significance to the following trace output:
Trace 23946/1: "error: osl_getAsciiFunctionSympol failed with ld.so.1:
soffice.bin: fatal: component_getImplementationEnvironmnet: can't find symbol
I see this a lot while OpenOffice is launching. It appears to happen right
before SAL_CALL uno_getMapping is called.
-Original Message-
From: Herbert Duerr [mailto:h...@apache.org]
Sent: Tuesday, April 15, 2014 7:14 AM
To: dev@openoffice.apache.org
Cc: a...@openoffice.apache.org
Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes
On 14.04.2014 17:59, Steele, Raymond wrote:
> Anyone available that understands the OpenOffice bridges or could point me to
> the correct documentation so that I can begin to understand the problem
> myself? This has been a road block for me.
The OpenOffice bridges are part of the UNO framework. An overview [1] and FAQ
[2] can help to get started into this topic. Especially see the FAQ's chapter
2.9 ("Why is it so annoying to write a compiler version dependent C++ bridge?")
on the deliberate design decisions that lead to this unfortunate fragility.
There are other applications in the same league as OpenOffice that use plain
implementation languages and thus avoid these extreme platform dependencies.
[1] https://wiki.openoffice.org/wiki/Uno/Article/Understanding_Uno
[2] https://wiki.openoffice.org/wiki/Uno/FAQ
[3] http://www.openoffice.org/udk/cpp/man/cpp_bridges.html
[4]
https://wiki.openoffice.org/w/images/5/5e/DevelopersGuide_OOo3.1.0_05AdvancedUNO.odt
There is a good chance that the ABI hasn't much changed and that the different
compiler versions produces similar enough code so that one could eventually get
along with minor tweaks to the Sparc Solaris UNO bridge. But finding the right
knobs to tweak is a bit tricky. I hope the references above help to solve this.
Herbert
-
To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org
For additional commands, e-mail: api-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
I traced this osl_getAsciiFunctionSymbol issues down to sal/osl/unx/module.c
line 154.
Apparently, the function osl_getAsciiDunctionSymbol is calling "dlsym" (fcnAddr
= dlsym(Module, pSymbol) which attempts to get the address of a symbol in a
shared object or executable. NULL is returned if address of the symbol's name
as a character string cannot be found.
In the case of "error: osl_getAsciiFunctionSymbol failed with ld.so.1:
soffice.bin: fatal: component_getImplementationEnvironmnet: can't find symbol"
I received in my trace output, null is returned.
(from dbx dump)
fcnAddr = (nil)
pSymbol = 0xfdc7710 " component_getImplementationEnvironmnet"
Module = 0xf80008e0
Also, I noticed this call to dlsym is wraped in an #ifndef NO_DL_FUNCTIONS,
however this is not defined in my environment. What is the significance of
calling dlsym, can't I simple define NO_DL_FUNCTIONS to prevent this from
occurring or will this have a negative impact on my underlying issue with the
bridge?
Raymond
-----Original Message-
From: Steele, Raymond
Sent: Tuesday, April 15, 2014 12:28 PM
To: a...@openoffice.apache.org; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes
Thanks AGAIN, Herbert.
Is there any significance to the following trace output:
Trace 23946/1: "error: osl_getAsciiFunctionSympol failed with ld.so.1:
soffice.bin: fatal: component_getImplementationEnvironmnet: can't find symbol
I see this a lot while OpenOffice is launching. It appears to happen right
before SAL_CALL uno_getMapping is called.
-Original Message-
From: Herbert Duerr [mailto:h...@apache.org]
Sent: Tuesday, April 15, 2014 7:14 AM
To: dev@openoffice.apache.org
Cc: a...@openoffice.apache.org
Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes
On 14.04.2014 17:59, Steele, Raymond wrote:
> Anyone available that understands the OpenOffice bridges or could point me to
> the correct documentation so that I can begin to understand the problem
> myself? This has been a road block for me.
The OpenOffice bridges are part of the UNO framework. An overview [1] and FAQ
[2] can help to get started into this topic. Especially see the FAQ's chapter
2.9 ("Why is it so annoying to write a compiler version dependent C++ bridge?")
on the deliberate design decisions that lead to this unfortunate fragility.
There are other applications in the same league as OpenOffice that use plain
implementation languages and thus avoid these extreme platform dependencies.
[1] https://wiki.openoffice.org/wiki/Uno/Article/Understanding_Uno
[2] https://wiki.openoffice.org/wiki/Uno/FAQ
[3] http://www.openoffice.org/udk/cpp/man/cpp_bridges.html
[4]
https://wiki.openoffice.org/w/images/5/5e/DevelopersGuide_OOo3.1.0_05AdvancedUNO.odt
There is a good chance that the ABI hasn't much changed and that the different
compiler versions produces similar enough code so that one could eventually get
along with minor tweaks to the Sparc Solaris UNO bridge. But finding the right
knobs to tweak is a bit tricky. I hope the references above help to solve this.
Herbert
-
To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org
For additional commands, e-mail: api-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
I am still trying to process all of this stuff and it is quite difficult for me so far, but I wanted to share that I do receive trace output during runtime. These exceptions are thrown continuously after cpp2uno.cxx cpp_vtable_call is called as the OpenOffice application starts and during regular operation, including adding an extension. trace > inserting new mapping: ;uno[965efd8];sunpro5[9168010] >unoi exception occurred: com.sun.star.ucb.InteractiveAugmentedIOException >revoking mapping ;uno[965efd8];sunpro5[9168010] module.c::osl_getMpduleURLFromAddress openoffice4/progam/libuno_cpp.so.3 " trace > inserting new mapping: ;uno[965efd8];sunpro5[9168010] >unoi exception occurred: com.sun.star.ucb.InteractiveNetworkGeneralException >revoking mapping ;uno[965efd8];sunpro5[9168010] module.c::osl_getMpduleURLFromAddress openoffice4/progam/libuno_cpp.so.3 " trace > inserting new mapping: ;uno[965efd8];sunpro5[9168010] >unoi exception occurred: com.sun.star.ucb.InteractiveAugmentedIOException >revoking mapping ;uno[965efd8];sunpro5[9168010] module.c::osl_getMpduleURLFromAddress openoffice4/progam/libuno_cpp.so.3 " Any significance? Also, how is call.s used? Raymond -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Wednesday, April 16, 2014 12:12 AM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 16.04.2014 01:16, Steele, Raymond wrote: > Why do you mention the Solaris Sparc UNO C++ bridge below. Is it related to > the x86/intel bridge. I am running Solaris 11 x86_64. Ah, ok. Looking at the directory main/bridges/source/cpp_uno there is no UNO bridge yet for Solaris Studio on a x86-64 CPU. But apparently your compile got through, so in order to know where to tweak you need to find out which bridge was actually used. Then you can adapt it to your platform (operating system, compiler, cpu architecture, ABI). As I mentioned the platform independence of AOO's UNO subsystem was unfortunately not designed in e.g. by using plain programming language constructs or using portable mechanisms like C-linking. Getting a bridge to work was accomplished by brute force :-/ (reverse engineering the vtable layouts, symbol mangling, calling conventions, implementation details of exception handling, etc.) but if we're lucky a few tweaks to the currently active bridge could suffice. For an idea on what tweaks might be needed please check the evolution of the related x86-64 bridges for Linux, FreeBSD or MacOSX. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
Herbert, My system appears to be using the bridge located here. I will try to see if I can look at the evolution of the other bridges as you suggested. https://svn.apache.org/repos/asf/openoffice/branches/AOO401/main/bridges/source/cpp_uno/cc50_solaris_intel/ Thanks again for all you assistance!! -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Wednesday, April 16, 2014 12:12 AM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 16.04.2014 01:16, Steele, Raymond wrote: > Why do you mention the Solaris Sparc UNO C++ bridge below. Is it related to > the x86/intel bridge. I am running Solaris 11 x86_64. Ah, ok. Looking at the directory main/bridges/source/cpp_uno there is no UNO bridge yet for Solaris Studio on a x86-64 CPU. But apparently your compile got through, so in order to know where to tweak you need to find out which bridge was actually used. Then you can adapt it to your platform (operating system, compiler, cpu architecture, ABI). As I mentioned the platform independence of AOO's UNO subsystem was unfortunately not designed in e.g. by using plain programming language constructs or using portable mechanisms like C-linking. Getting a bridge to work was accomplished by brute force :-/ (reverse engineering the vtable layouts, symbol mangling, calling conventions, implementation details of exception handling, etc.) but if we're lucky a few tweaks to the currently active bridge could suffice. For an idea on what tweaks might be needed please check the evolution of the related x86-64 bridges for Linux, FreeBSD or MacOSX. 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: EXTERNAL: Re: Extension Manager Add Crashes
Herbert,
Why do you mention the Solaris Sparc UNO C++ bridge below. Is it related to the
x86/intel bridge. I am running Solaris 11 x86_64.
Raymond
-Original Message-
From: Herbert Duerr [mailto:h...@apache.org]
Sent: Tuesday, April 15, 2014 7:56 AM
To: dev@openoffice.apache.org
Cc: a...@openoffice.apache.org
Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes
On 14.04.2014 17:59, Steele, Raymond wrote:
> Anyone available that understands the OpenOffice bridges or could point me to
> the correct documentation so that I can begin to understand the problem
> myself? This has been a road block for me.
The OpenOffice bridges are part of the UNO framework. An overview [1] and FAQ
[2] can help to get started into this topic. Especially see the FAQ's chapter
2.9 ("Why is it so annoying to write a compiler version dependent C++ bridge?")
on the deliberate design decisions that lead to this unfortunate fragility.
There are other applications in the same league as OpenOffice that use their
implementation languages plainly avoiding this extreme platform dependency.
[1] https://wiki.openoffice.org/wiki/Uno/Article/Understanding_Uno
[2] https://wiki.openoffice.org/wiki/Uno/FAQ
[3] http://www.openoffice.org/udk/cpp/man/cpp_bridges.html
[4]
https://wiki.openoffice.org/w/images/5/5e/DevelopersGuide_OOo3.1.0_05AdvancedUNO.odt
There is a good chance that the ABI hasn't much changed and that the different
compiler versions produces similar enough code so that one could eventually get
along with minor tweaks to the Solaris Sparc UNO
C++ bridge. The links above hopefully help to find the knobs in
main/bridges/source/cpp_uno/cc*solaris_sparc* source. The related tests in
main/testtools/source/bridgetest can eventually help too.
Herbert
-
To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org
For additional commands, e-mail: api-h...@openoffice.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
Thanks AGAIN, Herbert.
Is there any significance to the following trace output:
Trace 23946/1: "error: osl_getAsciiFunctionSympol failed with ld.so.1:
soffice.bin: fatal: component_getImplementationEnvironmnet: can't find symbol
I see this a lot while OpenOffice is launching. It appears to happen right
before SAL_CALL uno_getMapping is called.
-Original Message-
From: Herbert Duerr [mailto:h...@apache.org]
Sent: Tuesday, April 15, 2014 7:14 AM
To: dev@openoffice.apache.org
Cc: a...@openoffice.apache.org
Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes
On 14.04.2014 17:59, Steele, Raymond wrote:
> Anyone available that understands the OpenOffice bridges or could point me to
> the correct documentation so that I can begin to understand the problem
> myself? This has been a road block for me.
The OpenOffice bridges are part of the UNO framework. An overview [1] and FAQ
[2] can help to get started into this topic. Especially see the FAQ's chapter
2.9 ("Why is it so annoying to write a compiler version dependent C++ bridge?")
on the deliberate design decisions that lead to this unfortunate fragility.
There are other applications in the same league as OpenOffice that use plain
implementation languages and thus avoid these extreme platform dependencies.
[1] https://wiki.openoffice.org/wiki/Uno/Article/Understanding_Uno
[2] https://wiki.openoffice.org/wiki/Uno/FAQ
[3] http://www.openoffice.org/udk/cpp/man/cpp_bridges.html
[4]
https://wiki.openoffice.org/w/images/5/5e/DevelopersGuide_OOo3.1.0_05AdvancedUNO.odt
There is a good chance that the ABI hasn't much changed and that the different
compiler versions produces similar enough code so that one could eventually get
along with minor tweaks to the Sparc Solaris UNO bridge. But finding the right
knobs to tweak is a bit tricky. I hope the references above help to solve this.
Herbert
-
To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org
For additional commands, e-mail: api-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
Ariel, Do you think it may fix the bridge if I try to use the compiler Sun used? -Original Message- From: Ariel Constenla-Haile [mailto:arie...@apache.org] Sent: Thursday, April 10, 2014 3:40 PM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes This e-mail message contained a file attachment that was blocked per Lockheed Martin Corporate Information Security Requirements. Certain file types are being blocked from entering Lockheed Martin in order to minimize risk to Corporate computing and information resources. If a business need exists and you must receive this file, alternate methods have been approved for use by Corporate Information Security for receipt and review of files/attachments. For more information and options for handling blocked attachments, visit E-mail Attachment Security, at http://protection.global.lmco.com/protection/isafe/topics.e-attachments.cfm The current list of allowed attachment types is located at: http://protection.global.lmco.com/protection/awareness/e-msging/allowed_attachments.cfm If additional assistance is required, please contact the Lockheed Martin Service Desk at 1-800-435-7063. == On Thu, Apr 10, 2014 at 10:01:22PM +, Steele, Raymond wrote: > Thanks Ariel. I compiled the code myself for Solaris 11 using Solaris Studio > 12.3 compilers. This might be the difference between OOo 3.3 and the AOO 4 you built yourself: OOo 3.3 was compiled with Sun Studio 12 / C++-5.9 according to https://wiki.openoffice.org/wiki/Compiler_versions_used_by_port_maintainers_and_release_engineers Studio 12.3 comes with C++ 5.12 according to http://docs.oracle.com/cd/E24457_01/html/E21991/bkabe.html#scrolltoc The compiler might have changed in a way that broke the bridge. Regards -- Ariel Constenla-Haile La Plata, Argentina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
Anyone available that understands the OpenOffice bridges or could point me to the correct documentation so that I can begin to understand the problem myself? This has been a road block for me. Thanks! -Original Message- From: Steele, Raymond Sent: Friday, April 11, 2014 5:00 PM To: dev@openoffice.apache.org Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes I compiled the sdk example Addon ProtocolHandlerAddon_cpp and attempted to install the generated OXT. Here is the stack trace of the crash. It seems to get past the cpp_vtable_call, but the problem still seems to be related to the bridge? [1] com::sun::stat::uno::Reference::iquery(pInterface = 0xf32a0eec)) line 64 in "Reference.hxx" [2] s_stub_computeObjectIdentifier(pParm = 0xf15dc288), line 117 in "component.cxx" [3] s_environemen_invokeV(pCurrentEnv = (nil), pTargetEnv = 0x918f3e8, pCallee = 0xf824244b0 = &`libsunpro5_uno.so` component.cxx's s_stub_computeObjectIdentifier, pParm = 0xf15dc288), line288 in EnvStack.cxx" [4] uno_Enviornment_invoke_v(pTargetEnv = 0x918f3e8, pCallee = 0xf824244b0 = &`libsunpro5_uno.so` component.cxx's s_stub_computeObjectIdentifier, pParm = 0xf15dc288), line307 in "EnvStack.cxx" [5] uno_Enviornment_invoke(pEnv = 0x918f3e8, pCallee = 0xf824244b0 = &`libsunpro5_uno.so` component.cxx's s_stub_computeObjectIdentifier, ..), line 316 in "EnvStack.cxx" [6] computeObjectIdentifier(pExtEnv = 0x918f3e8. ppOId = 0xf15dc39c, pInterface = 0xfe2a0eec), line 156 in "component.cxx" [7] defenv_getObjectIdentifier(pEnv = 0x918f3e8. ppOId = 0xf15dc39c, pInterface = 0xfe2a0eec), line 475 in "lbenv.cxx" [8] bridges::cpp_uno::shared::cpp2unoMapping(pMapping = 0x99e156c, ppUnoI = 0xf15dc448, pCppI = 0xfe2a0eec, pTypeDescr = 0x80e21do), line 78 in "bridge.cxx" [9] cppu_::_map(p = ..) lin 69 in "prim.hxx" [10]cppu::_copyConstructData(.), line 871 in "copy.hxx" [11]uno_copyAndConvertData(..), line 264 in "data.cxx" [12] _unamed_Aja7vq::cpp2uno_Call(..) line 135 in "cpp2uno.cxx" [13] cpp_vtable_call(.) line 332 in "cpp2uno.cxx" 14] privateSnippetExecutorGeneral(), at 0xf82416a2 -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Thursday, April 10, 2014 5:51 PM To: a...@openoffice.apache.org; dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 04/10/2014 07:15 PM, Steele, Raymond wrote: > Carl, > > I have the new Netbeans plugin. I created a new Add-on project (just an empty > one that does nothing), compiled and generated the .OXT. The Extension > manager still rejects it and OpenOffice crashes. I was able to install the > extension mentioned here with success. > > https://issues.apache.org/ooo/show_bug.cgi?id=121577 > > -Original Message- > From: Carl Marcum [mailto:cmar...@apache.org] > Sent: Thursday, April 10, 2014 2:55 PM > To: dev@openoffice.apache.org > Cc: a...@openoffice.apache.org > Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes > > On 04/10/2014 03:31 PM, Steele, Raymond wrote: >> I am cross posting here since I am not getting much traction on the >> dev list and it appears it may be API related. I have an add-on that >> I developed using the Netbeans Openiffice module. This .oxt file >> works fine on AOO 3.3, but since I switched to AOO 4.0.1 and after a >> recompile, the Extension Manager will not take my add-on (see below >> please). However, the extension manager will take the module located >> http://extensions.openoffice.org/en/project/english-dictionaries-apac >> h >> e-openoffice >> >> Is there anything that the new AOO needs configured within the .oxt that was >> not needed in 3.3? Any help would be great! >> >> -Original Message- >> From: Steele, Raymond >> Sent: Wednesday, April 09, 2014 8:08 AM >> To: dev@openoffice.apache.org >> Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes >> >> Thanks. I am using Java. The extension I have works on my Solaris 10 >> OpenOffice 3.3 instance, but not on my Solaris 11 4.0.1 instance. I used the >> OpenOffice Netbeans module to create the Add-on. >> >> -Original Message- >> From: Jürgen Schmidt [mailto:jogischm...@gmail.com] >> Sent: Tuesday, April 08, 2014 11:16 PM >> To: dev@openoffice.apache.org >> Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes >> >> On 4/8/14 11:49 PM, Steele, Raymond wrote: >>> I installed the extension located at the following link with success, so >>> what is wrong with my exten
RE: EXTERNAL: Re: Extension Manager Add Crashes
I compiled the sdk example Addon ProtocolHandlerAddon_cpp and attempted to install the generated OXT. Here is the stack trace of the crash. It seems to get past the cpp_vtable_call, but the problem still seems to be related to the bridge? [1] com::sun::stat::uno::Reference::iquery(pInterface = 0xf32a0eec)) line 64 in "Reference.hxx" [2] s_stub_computeObjectIdentifier(pParm = 0xf15dc288), line 117 in "component.cxx" [3] s_environemen_invokeV(pCurrentEnv = (nil), pTargetEnv = 0x918f3e8, pCallee = 0xf824244b0 = &`libsunpro5_uno.so` component.cxx's s_stub_computeObjectIdentifier, pParm = 0xf15dc288), line288 in EnvStack.cxx" [4] uno_Enviornment_invoke_v(pTargetEnv = 0x918f3e8, pCallee = 0xf824244b0 = &`libsunpro5_uno.so` component.cxx's s_stub_computeObjectIdentifier, pParm = 0xf15dc288), line307 in "EnvStack.cxx" [5] uno_Enviornment_invoke(pEnv = 0x918f3e8, pCallee = 0xf824244b0 = &`libsunpro5_uno.so` component.cxx's s_stub_computeObjectIdentifier, ..), line 316 in "EnvStack.cxx" [6] computeObjectIdentifier(pExtEnv = 0x918f3e8. ppOId = 0xf15dc39c, pInterface = 0xfe2a0eec), line 156 in "component.cxx" [7] defenv_getObjectIdentifier(pEnv = 0x918f3e8. ppOId = 0xf15dc39c, pInterface = 0xfe2a0eec), line 475 in "lbenv.cxx" [8] bridges::cpp_uno::shared::cpp2unoMapping(pMapping = 0x99e156c, ppUnoI = 0xf15dc448, pCppI = 0xfe2a0eec, pTypeDescr = 0x80e21do), line 78 in "bridge.cxx" [9] cppu_::_map(p = ..) lin 69 in "prim.hxx" [10]cppu::_copyConstructData(.), line 871 in "copy.hxx" [11]uno_copyAndConvertData(..), line 264 in "data.cxx" [12] _unamed_Aja7vq::cpp2uno_Call(..) line 135 in "cpp2uno.cxx" [13] cpp_vtable_call(.) line 332 in "cpp2uno.cxx" 14] privateSnippetExecutorGeneral(), at 0xf82416a2 -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Thursday, April 10, 2014 5:51 PM To: a...@openoffice.apache.org; dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 04/10/2014 07:15 PM, Steele, Raymond wrote: > Carl, > > I have the new Netbeans plugin. I created a new Add-on project (just an empty > one that does nothing), compiled and generated the .OXT. The Extension > manager still rejects it and OpenOffice crashes. I was able to install the > extension mentioned here with success. > > https://issues.apache.org/ooo/show_bug.cgi?id=121577 > > -Original Message- > From: Carl Marcum [mailto:cmar...@apache.org] > Sent: Thursday, April 10, 2014 2:55 PM > To: dev@openoffice.apache.org > Cc: a...@openoffice.apache.org > Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes > > On 04/10/2014 03:31 PM, Steele, Raymond wrote: >> I am cross posting here since I am not getting much traction on the >> dev list and it appears it may be API related. I have an add-on that >> I developed using the Netbeans Openiffice module. This .oxt file >> works fine on AOO 3.3, but since I switched to AOO 4.0.1 and after a >> recompile, the Extension Manager will not take my add-on (see below >> please). However, the extension manager will take the module located >> http://extensions.openoffice.org/en/project/english-dictionaries-apac >> h >> e-openoffice >> >> Is there anything that the new AOO needs configured within the .oxt that was >> not needed in 3.3? Any help would be great! >> >> -Original Message- >> From: Steele, Raymond >> Sent: Wednesday, April 09, 2014 8:08 AM >> To: dev@openoffice.apache.org >> Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes >> >> Thanks. I am using Java. The extension I have works on my Solaris 10 >> OpenOffice 3.3 instance, but not on my Solaris 11 4.0.1 instance. I used the >> OpenOffice Netbeans module to create the Add-on. >> >> -Original Message- >> From: Jürgen Schmidt [mailto:jogischm...@gmail.com] >> Sent: Tuesday, April 08, 2014 11:16 PM >> To: dev@openoffice.apache.org >> Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes >> >> On 4/8/14 11:49 PM, Steele, Raymond wrote: >>> I installed the extension located at the following link with success, so >>> what is wrong with my extension >>> >>> http://extensions.openoffice.org/en/project/english-dictionaries-apa >>> c >>> h >>> e-openoffice >> >> it's difficult to say without having the code, you can easy make mistakes >> with extensions. >> >> I haven't followed the thread in detail but maybe you can describe in
RE: EXTERNAL: Re: Extension Manager Add Crashes
Ariel, In the bug quoted below, there is a mention of testtool/unxlngi4.pro/lib/bridgetest_inprocess which seems to have been used to diagnose/fix the related issue. Do you or anyone else know how to use this tool? -Original Message- From: Ariel Constenla-Haile [mailto:arie...@apache.org] Sent: Thursday, April 10, 2014 2:58 PM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes This e-mail message contained a file attachment that was blocked per Lockheed Martin Corporate Information Security Requirements. Certain file types are being blocked from entering Lockheed Martin in order to minimize risk to Corporate computing and information resources. If a business need exists and you must receive this file, alternate methods have been approved for use by Corporate Information Security for receipt and review of files/attachments. For more information and options for handling blocked attachments, visit E-mail Attachment Security, at http://protection.global.lmco.com/protection/isafe/topics.e-attachments.cfm The current list of allowed attachment types is located at: http://protection.global.lmco.com/protection/awareness/e-msging/allowed_attachments.cfm If additional assistance is required, please contact the Lockheed Martin Service Desk at 1-800-435-7063. == On Thu, Apr 10, 2014 at 07:31:39PM +, Steele, Raymond wrote: > I am cross posting here since I am not getting much traction on the > dev list and it appears it may be API related. I have an add-on that I > developed using the Netbeans Openiffice module. This .oxt file works > fine on AOO 3.3, but since I switched to AOO 4.0.1 and after a > recompile, the Extension Manager will not take my add-on (see below > please). However, the extension manager will take the module located > http://extensions.openoffice.org/en/project/english-dictionaries-apach > e-openoffice > > Is there anything that the new AOO needs configured within the .oxt > that was not needed in 3.3? Any help would be great! You don't mention from where you got that AOO 4 for Solaris; nobody here builds on Solaris, so all that strange crashes you mention on your mails sound like a broken bridge on that platform (and that's where the bug you quote in one of your mails is pointing to, but in that case to a broken bridge after a GCC version update on Linux). That said, I know nothing about the bridge related code, so sorry I cannot help. Regards -- Ariel Constenla-Haile La Plata, Argentina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
I'm not sure how to address this. If it is broken, is there a way for me to not have to use the bridge? My add-on extension calls Java code via the CentralRegistrationClass.java that is generated from the Netbeans module. It possible to do this in C++ and possible avoid the bridge? -Original Message- From: Jürgen Schmidt [mailto:jogischm...@gmail.com] Sent: Friday, April 11, 2014 12:18 AM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 4/11/14 1:11 AM, Steele, Raymond wrote: > The stack trace at the crash does lead me down into that area of the code. > > [1] cpp_vtable_call(nFunctionIndex = 3, nVtableOffset = 0, pCallStack > =0xe90acea8, nRegReturn = -1649035904490436800LL) in cpp2uno.cxx [2] > privateSnippetExecutorGeneral(0x9daf5d4, 0xe91d7294,xe90ad250, > 0xe90ad1ec,0x0, 0x0), at 0xf83516a2 > [3]dp_registry::backend::component::_unamed_AjaA7n_aOTEvD::BackendImpl > ::ComponentPackageImpl::processPackage_(this = 0xe91d7240, _ARG2 = > CLASS, doRegisterPackage = true, startup = false, abortChannel = > CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx > > Also, I was able to install the extension mentioned here with success. > > https://issues.apache.org/ooo/show_bug.cgi?id=121577 > it seems you have a general problem with your Solaris build. A dictionary extension is of course different to an add-on where you have real code and have to bridge between Java <-> UNO <-> C++ Can you start the wizards under the File menu? They are implemented in Java and should trigger a similar bridging scenario. But anyway it is quite hard to help you if you can't provide the necessary information. And unfortunately you are on Solaris where we have no official build in place for you. Juergen > > > -Original Message- > From: Ariel Constenla-Haile [mailto:arie...@apache.org] > Sent: Thursday, April 10, 2014 4:02 PM > To: dev@openoffice.apache.org > Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes > > This e-mail message contained a file attachment that was blocked per Lockheed > Martin Corporate Information Security Requirements. Certain file types are > being blocked from entering Lockheed Martin in order to minimize risk to > Corporate computing and information resources. > > If a business need exists and you must receive this file, alternate methods > have been approved for use by Corporate Information Security for receipt and > review of files/attachments. For more information and options for handling > blocked attachments, visit E-mail Attachment Security, at > > http://protection.global.lmco.com/protection/isafe/topics.e-attachment > s.cfm > > The current list of allowed attachment types is located at: > > http://protection.global.lmco.com/protection/awareness/e-msging/allowe > d_attachments.cfm > > If additional assistance is required, please contact the Lockheed Martin > Service Desk at 1-800-435-7063. > > == > On Thu, Apr 10, 2014 at 10:41:28PM +, Steele, Raymond wrote: >> Thanks, but I am totally lost when you mention "bridge". > > Literally, a bridge, for example a bridge from your compiler's C++ ABI > to UNO and back. See the stuff under > /trunk/main/bridges/source/cpp_uno/ > > Strange crashes not reproducible on other platforms like the ones you > describe here and in "RE: EXTERNAL: Re: DisposedException" may point to > something broken there. > > > Regards > -- > Ariel Constenla-Haile > La Plata, Argentina > > - > 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 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
Juergen, Then wizards seem to be working fine. What necessary information can I provide to you? Raymond -Original Message- From: Jürgen Schmidt [mailto:jogischm...@gmail.com] Sent: Friday, April 11, 2014 12:18 AM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 4/11/14 1:11 AM, Steele, Raymond wrote: > The stack trace at the crash does lead me down into that area of the code. > > [1] cpp_vtable_call(nFunctionIndex = 3, nVtableOffset = 0, pCallStack > =0xe90acea8, nRegReturn = -1649035904490436800LL) in cpp2uno.cxx [2] > privateSnippetExecutorGeneral(0x9daf5d4, 0xe91d7294,xe90ad250, > 0xe90ad1ec,0x0, 0x0), at 0xf83516a2 > [3]dp_registry::backend::component::_unamed_AjaA7n_aOTEvD::BackendImpl > ::ComponentPackageImpl::processPackage_(this = 0xe91d7240, _ARG2 = > CLASS, doRegisterPackage = true, startup = false, abortChannel = > CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx > > Also, I was able to install the extension mentioned here with success. > > https://issues.apache.org/ooo/show_bug.cgi?id=121577 > it seems you have a general problem with your Solaris build. A dictionary extension is of course different to an add-on where you have real code and have to bridge between Java <-> UNO <-> C++ Can you start the wizards under the File menu? They are implemented in Java and should trigger a similar bridging scenario. But anyway it is quite hard to help you if you can't provide the necessary information. And unfortunately you are on Solaris where we have no official build in place for you. Juergen > > > -Original Message- > From: Ariel Constenla-Haile [mailto:arie...@apache.org] > Sent: Thursday, April 10, 2014 4:02 PM > To: dev@openoffice.apache.org > Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes > > This e-mail message contained a file attachment that was blocked per Lockheed > Martin Corporate Information Security Requirements. Certain file types are > being blocked from entering Lockheed Martin in order to minimize risk to > Corporate computing and information resources. > > If a business need exists and you must receive this file, alternate methods > have been approved for use by Corporate Information Security for receipt and > review of files/attachments. For more information and options for handling > blocked attachments, visit E-mail Attachment Security, at > > http://protection.global.lmco.com/protection/isafe/topics.e-attachment > s.cfm > > The current list of allowed attachment types is located at: > > http://protection.global.lmco.com/protection/awareness/e-msging/allowe > d_attachments.cfm > > If additional assistance is required, please contact the Lockheed Martin > Service Desk at 1-800-435-7063. > > == > On Thu, Apr 10, 2014 at 10:41:28PM +, Steele, Raymond wrote: >> Thanks, but I am totally lost when you mention "bridge". > > Literally, a bridge, for example a bridge from your compiler's C++ ABI > to UNO and back. See the stuff under > /trunk/main/bridges/source/cpp_uno/ > > Strange crashes not reproducible on other platforms like the ones you > describe here and in "RE: EXTERNAL: Re: DisposedException" may point to > something broken there. > > > Regards > -- > Ariel Constenla-Haile > La Plata, Argentina > > - > 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 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
Carl, no message. Just a crash of the AOO suite. -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Thursday, April 10, 2014 5:51 PM To: a...@openoffice.apache.org; dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 04/10/2014 07:15 PM, Steele, Raymond wrote: > Carl, > > I have the new Netbeans plugin. I created a new Add-on project (just an empty > one that does nothing), compiled and generated the .OXT. The Extension > manager still rejects it and OpenOffice crashes. I was able to install the > extension mentioned here with success. > > https://issues.apache.org/ooo/show_bug.cgi?id=121577 > > -Original Message- > From: Carl Marcum [mailto:cmar...@apache.org] > Sent: Thursday, April 10, 2014 2:55 PM > To: dev@openoffice.apache.org > Cc: a...@openoffice.apache.org > Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes > > On 04/10/2014 03:31 PM, Steele, Raymond wrote: >> I am cross posting here since I am not getting much traction on the >> dev list and it appears it may be API related. I have an add-on that >> I developed using the Netbeans Openiffice module. This .oxt file >> works fine on AOO 3.3, but since I switched to AOO 4.0.1 and after a >> recompile, the Extension Manager will not take my add-on (see below >> please). However, the extension manager will take the module located >> http://extensions.openoffice.org/en/project/english-dictionaries-apac >> h >> e-openoffice >> >> Is there anything that the new AOO needs configured within the .oxt that was >> not needed in 3.3? Any help would be great! >> >> -Original Message- >> From: Steele, Raymond >> Sent: Wednesday, April 09, 2014 8:08 AM >> To: dev@openoffice.apache.org >> Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes >> >> Thanks. I am using Java. The extension I have works on my Solaris 10 >> OpenOffice 3.3 instance, but not on my Solaris 11 4.0.1 instance. I used the >> OpenOffice Netbeans module to create the Add-on. >> >> -Original Message- >> From: Jürgen Schmidt [mailto:jogischm...@gmail.com] >> Sent: Tuesday, April 08, 2014 11:16 PM >> To: dev@openoffice.apache.org >> Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes >> >> On 4/8/14 11:49 PM, Steele, Raymond wrote: >>> I installed the extension located at the following link with success, so >>> what is wrong with my extension >>> >>> http://extensions.openoffice.org/en/project/english-dictionaries-apa >>> c >>> h >>> e-openoffice >> >> it's difficult to say without having the code, you can easy make mistakes >> with extensions. >> >> I haven't followed the thread in detail but maybe you can describe in >> a few sentences what exactly you try >> >> - which programming language do you use >> - which kind of extension, an add-on, a calc add-in, ... >> - ... >> >> Juergen >> >> >>> >>> >>> -Original Message- >>> From: Steele, Raymond >>> Sent: Tuesday, April 08, 2014 10:31 AM >>> To: 'dev@openoffice.apache.org' >>> Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes >>> >>> Is there any one that is familiar with this code and able to lend a hand. I >>> do not understand what is going on here. I suspect that the crash is >>> cpp_vtable_call is due to a RuntimeException thrown in Reference.hxx >>> because pQueried is equal to (nil). Here is the stack trace leading up to >>> the RunTimeException during the registration of my .oxt file. >>> >>> =>[1] com::sun::star::uno::BaseReference::iquery_throw(pInterface = >>> 0x9e348ac, rType = CLASS), line 81 in "Reference.hxx" >>>[2] >>> dp_registry::backend::component::_unamed_AjaA7n_a0TEvD::BackendImpl::ComponentPackageImpl::processPackage_(this >>> = 0xea4f9a88, _ARG2 = CLASS, doRegisterPackge = true, startup = false, >>> abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx" >>>[3] dp_registry::backend::Package::processPackage_Impl(this = >>> 0xea4f9a88, doRegisterPackage = true, startup = false, xAbortChannel = >>> CLASS, xCmdEnv = CLASS), line 675 in "dp_backend.cxx" >>>[4] dp_registy::backend::Package::registerPackage(this = 0xe9b94c58, >>> startup = '\0', xAbortChannel = CLASS, xCmdEnv = CALSS), line 725 in >>> "dp_backend.cxx" >>> >>> I really need
RE: EXTERNAL: Re: Extension Manager Add Crashes
Carl, I have the new Netbeans plugin. I created a new Add-on project (just an empty one that does nothing), compiled and generated the .OXT. The Extension manager still rejects it and OpenOffice crashes. I was able to install the extension mentioned here with success. https://issues.apache.org/ooo/show_bug.cgi?id=121577 -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Thursday, April 10, 2014 2:55 PM To: dev@openoffice.apache.org Cc: a...@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 04/10/2014 03:31 PM, Steele, Raymond wrote: > I am cross posting here since I am not getting much traction on the > dev list and it appears it may be API related. I have an add-on that I > developed using the Netbeans Openiffice module. This .oxt file works > fine on AOO 3.3, but since I switched to AOO 4.0.1 and after a > recompile, the Extension Manager will not take my add-on (see below > please). However, the extension manager will take the module located > http://extensions.openoffice.org/en/project/english-dictionaries-apach > e-openoffice > > Is there anything that the new AOO needs configured within the .oxt that was > not needed in 3.3? Any help would be great! > > -----Original Message- > From: Steele, Raymond > Sent: Wednesday, April 09, 2014 8:08 AM > To: dev@openoffice.apache.org > Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes > > Thanks. I am using Java. The extension I have works on my Solaris 10 > OpenOffice 3.3 instance, but not on my Solaris 11 4.0.1 instance. I used the > OpenOffice Netbeans module to create the Add-on. > > -Original Message- > From: Jürgen Schmidt [mailto:jogischm...@gmail.com] > Sent: Tuesday, April 08, 2014 11:16 PM > To: dev@openoffice.apache.org > Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes > > On 4/8/14 11:49 PM, Steele, Raymond wrote: >> I installed the extension located at the following link with success, so >> what is wrong with my extension >> >> http://extensions.openoffice.org/en/project/english-dictionaries-apac >> h >> e-openoffice > > it's difficult to say without having the code, you can easy make mistakes > with extensions. > > I haven't followed the thread in detail but maybe you can describe in > a few sentences what exactly you try > > - which programming language do you use > - which kind of extension, an add-on, a calc add-in, ... > - ... > > Juergen > > >> >> >> -Original Message- >> From: Steele, Raymond >> Sent: Tuesday, April 08, 2014 10:31 AM >> To: 'dev@openoffice.apache.org' >> Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes >> >> Is there any one that is familiar with this code and able to lend a hand. I >> do not understand what is going on here. I suspect that the crash is >> cpp_vtable_call is due to a RuntimeException thrown in Reference.hxx because >> pQueried is equal to (nil). Here is the stack trace leading up to the >> RunTimeException during the registration of my .oxt file. >> >> =>[1] com::sun::star::uno::BaseReference::iquery_throw(pInterface = >> 0x9e348ac, rType = CLASS), line 81 in "Reference.hxx" >> [2] >> dp_registry::backend::component::_unamed_AjaA7n_a0TEvD::BackendImpl::ComponentPackageImpl::processPackage_(this >> = 0xea4f9a88, _ARG2 = CLASS, doRegisterPackge = true, startup = false, >> abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx" >> [3] dp_registry::backend::Package::processPackage_Impl(this = >> 0xea4f9a88, doRegisterPackage = true, startup = false, xAbortChannel = >> CLASS, xCmdEnv = CLASS), line 675 in "dp_backend.cxx" >> [4] dp_registy::backend::Package::registerPackage(this = 0xe9b94c58, >> startup = '\0', xAbortChannel = CLASS, xCmdEnv = CALSS), line 725 in >> "dp_backend.cxx" >> >> I really need to get over this hurdle. >> >> -Original Message- >> From: Steele, Raymond >> Sent: Friday, April 04, 2014 5:52 PM >> To: dev@openoffice.apache.org >> Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes >> >> I am still plugging away at this issue. This is what I have determined. >> addExtension is called in dp_extensionmanager.cxx. However, a >> RuntimeException is thrown somewhere and caught on line 819. Then on line >> 830, the code then tries to recover the "original status" then call >> activateExtension, which then leads up to the crash, which happens after an >> attempt to register and process the package in dp_component
RE: EXTERNAL: Re: Extension Manager Add Crashes
The stack trace at the crash does lead me down into that area of the code. [1] cpp_vtable_call(nFunctionIndex = 3, nVtableOffset = 0, pCallStack =0xe90acea8, nRegReturn = -1649035904490436800LL) in cpp2uno.cxx [2] privateSnippetExecutorGeneral(0x9daf5d4, 0xe91d7294,xe90ad250, 0xe90ad1ec,0x0, 0x0), at 0xf83516a2 [3]dp_registry::backend::component::_unamed_AjaA7n_aOTEvD::BackendImpl::ComponentPackageImpl::processPackage_(this = 0xe91d7240, _ARG2 = CLASS, doRegisterPackage = true, startup = false, abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx Also, I was able to install the extension mentioned here with success. https://issues.apache.org/ooo/show_bug.cgi?id=121577 -Original Message- From: Ariel Constenla-Haile [mailto:arie...@apache.org] Sent: Thursday, April 10, 2014 4:02 PM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes This e-mail message contained a file attachment that was blocked per Lockheed Martin Corporate Information Security Requirements. Certain file types are being blocked from entering Lockheed Martin in order to minimize risk to Corporate computing and information resources. If a business need exists and you must receive this file, alternate methods have been approved for use by Corporate Information Security for receipt and review of files/attachments. For more information and options for handling blocked attachments, visit E-mail Attachment Security, at http://protection.global.lmco.com/protection/isafe/topics.e-attachments.cfm The current list of allowed attachment types is located at: http://protection.global.lmco.com/protection/awareness/e-msging/allowed_attachments.cfm If additional assistance is required, please contact the Lockheed Martin Service Desk at 1-800-435-7063. == On Thu, Apr 10, 2014 at 10:41:28PM +0000, Steele, Raymond wrote: > Thanks, but I am totally lost when you mention "bridge". Literally, a bridge, for example a bridge from your compiler's C++ ABI to UNO and back. See the stuff under /trunk/main/bridges/source/cpp_uno/ Strange crashes not reproducible on other platforms like the ones you describe here and in "RE: EXTERNAL: Re: DisposedException" may point to something broken there. Regards -- Ariel Constenla-Haile La Plata, Argentina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
Thanks, but I am totally lost when you mention "bridge". -Original Message- From: Ariel Constenla-Haile [mailto:arie...@apache.org] Sent: Thursday, April 10, 2014 3:40 PM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes This e-mail message contained a file attachment that was blocked per Lockheed Martin Corporate Information Security Requirements. Certain file types are being blocked from entering Lockheed Martin in order to minimize risk to Corporate computing and information resources. If a business need exists and you must receive this file, alternate methods have been approved for use by Corporate Information Security for receipt and review of files/attachments. For more information and options for handling blocked attachments, visit E-mail Attachment Security, at http://protection.global.lmco.com/protection/isafe/topics.e-attachments.cfm The current list of allowed attachment types is located at: http://protection.global.lmco.com/protection/awareness/e-msging/allowed_attachments.cfm If additional assistance is required, please contact the Lockheed Martin Service Desk at 1-800-435-7063. == On Thu, Apr 10, 2014 at 10:01:22PM +0000, Steele, Raymond wrote: > Thanks Ariel. I compiled the code myself for Solaris 11 using Solaris Studio > 12.3 compilers. This might be the difference between OOo 3.3 and the AOO 4 you built yourself: OOo 3.3 was compiled with Sun Studio 12 / C++-5.9 according to https://wiki.openoffice.org/wiki/Compiler_versions_used_by_port_maintainers_and_release_engineers Studio 12.3 comes with C++ 5.12 according to http://docs.oracle.com/cd/E24457_01/html/E21991/bkabe.html#scrolltoc The compiler might have changed in a way that broke the bridge. Regards -- Ariel Constenla-Haile La Plata, Argentina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
Carl, I could scan and email you files if you could tell me which ones would be interesting to you. Thanks, Raymond -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Thursday, April 10, 2014 2:55 PM To: dev@openoffice.apache.org Cc: a...@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 04/10/2014 03:31 PM, Steele, Raymond wrote: > I am cross posting here since I am not getting much traction on the > dev list and it appears it may be API related. I have an add-on that I > developed using the Netbeans Openiffice module. This .oxt file works > fine on AOO 3.3, but since I switched to AOO 4.0.1 and after a > recompile, the Extension Manager will not take my add-on (see below > please). However, the extension manager will take the module located > http://extensions.openoffice.org/en/project/english-dictionaries-apach > e-openoffice > > Is there anything that the new AOO needs configured within the .oxt that was > not needed in 3.3? Any help would be great! > > -----Original Message- > From: Steele, Raymond > Sent: Wednesday, April 09, 2014 8:08 AM > To: dev@openoffice.apache.org > Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes > > Thanks. I am using Java. The extension I have works on my Solaris 10 > OpenOffice 3.3 instance, but not on my Solaris 11 4.0.1 instance. I used the > OpenOffice Netbeans module to create the Add-on. > > -Original Message- > From: Jürgen Schmidt [mailto:jogischm...@gmail.com] > Sent: Tuesday, April 08, 2014 11:16 PM > To: dev@openoffice.apache.org > Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes > > On 4/8/14 11:49 PM, Steele, Raymond wrote: >> I installed the extension located at the following link with success, so >> what is wrong with my extension >> >> http://extensions.openoffice.org/en/project/english-dictionaries-apac >> h >> e-openoffice > > it's difficult to say without having the code, you can easy make mistakes > with extensions. > > I haven't followed the thread in detail but maybe you can describe in > a few sentences what exactly you try > > - which programming language do you use > - which kind of extension, an add-on, a calc add-in, ... > - ... > > Juergen > > >> >> >> -Original Message- >> From: Steele, Raymond >> Sent: Tuesday, April 08, 2014 10:31 AM >> To: 'dev@openoffice.apache.org' >> Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes >> >> Is there any one that is familiar with this code and able to lend a hand. I >> do not understand what is going on here. I suspect that the crash is >> cpp_vtable_call is due to a RuntimeException thrown in Reference.hxx because >> pQueried is equal to (nil). Here is the stack trace leading up to the >> RunTimeException during the registration of my .oxt file. >> >> =>[1] com::sun::star::uno::BaseReference::iquery_throw(pInterface = >> 0x9e348ac, rType = CLASS), line 81 in "Reference.hxx" >> [2] >> dp_registry::backend::component::_unamed_AjaA7n_a0TEvD::BackendImpl::ComponentPackageImpl::processPackage_(this >> = 0xea4f9a88, _ARG2 = CLASS, doRegisterPackge = true, startup = false, >> abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx" >> [3] dp_registry::backend::Package::processPackage_Impl(this = >> 0xea4f9a88, doRegisterPackage = true, startup = false, xAbortChannel = >> CLASS, xCmdEnv = CLASS), line 675 in "dp_backend.cxx" >> [4] dp_registy::backend::Package::registerPackage(this = 0xe9b94c58, >> startup = '\0', xAbortChannel = CLASS, xCmdEnv = CALSS), line 725 in >> "dp_backend.cxx" >> >> I really need to get over this hurdle. >> >> -Original Message- >> From: Steele, Raymond >> Sent: Friday, April 04, 2014 5:52 PM >> To: dev@openoffice.apache.org >> Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes >> >> I am still plugging away at this issue. This is what I have determined. >> addExtension is called in dp_extensionmanager.cxx. However, a >> RuntimeException is thrown somewhere and caught on line 819. Then on line >> 830, the code then tries to recover the "original status" then call >> activateExtension, which then leads up to the crash, which happens after an >> attempt to register and process the package in dp_component.cxx. I am not >> sure if the initial RuntimeException is causing the problem, but something >> is not correct. Here is high level stack trace (typed out). >> >> [1]
RE: EXTERNAL: Re: Extension Manager Add Crashes
Thanks Ariel. I compiled the code myself for Solaris 11 using Solaris Studio 12.3 compilers. -Original Message- From: Ariel Constenla-Haile [mailto:arie...@apache.org] Sent: Thursday, April 10, 2014 2:58 PM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes This e-mail message contained a file attachment that was blocked per Lockheed Martin Corporate Information Security Requirements. Certain file types are being blocked from entering Lockheed Martin in order to minimize risk to Corporate computing and information resources. If a business need exists and you must receive this file, alternate methods have been approved for use by Corporate Information Security for receipt and review of files/attachments. For more information and options for handling blocked attachments, visit E-mail Attachment Security, at http://protection.global.lmco.com/protection/isafe/topics.e-attachments.cfm The current list of allowed attachment types is located at: http://protection.global.lmco.com/protection/awareness/e-msging/allowed_attachments.cfm If additional assistance is required, please contact the Lockheed Martin Service Desk at 1-800-435-7063. == On Thu, Apr 10, 2014 at 07:31:39PM +, Steele, Raymond wrote: > I am cross posting here since I am not getting much traction on the > dev list and it appears it may be API related. I have an add-on that I > developed using the Netbeans Openiffice module. This .oxt file works > fine on AOO 3.3, but since I switched to AOO 4.0.1 and after a > recompile, the Extension Manager will not take my add-on (see below > please). However, the extension manager will take the module located > http://extensions.openoffice.org/en/project/english-dictionaries-apach > e-openoffice > > Is there anything that the new AOO needs configured within the .oxt > that was not needed in 3.3? Any help would be great! You don't mention from where you got that AOO 4 for Solaris; nobody here builds on Solaris, so all that strange crashes you mention on your mails sound like a broken bridge on that platform (and that's where the bug you quote in one of your mails is pointing to, but in that case to a broken bridge after a GCC version update on Linux). That said, I know nothing about the bridge related code, so sorry I cannot help. Regards -- Ariel Constenla-Haile La Plata, Argentina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
Thanks Carl! Unfortunately, I will not be able to send you the .oxt file. Sorry. I am now looking over the additional information that you and Kay Schenk provided. -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Thursday, April 10, 2014 2:55 PM To: dev@openoffice.apache.org Cc: a...@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 04/10/2014 03:31 PM, Steele, Raymond wrote: > I am cross posting here since I am not getting much traction on the > dev list and it appears it may be API related. I have an add-on that I > developed using the Netbeans Openiffice module. This .oxt file works > fine on AOO 3.3, but since I switched to AOO 4.0.1 and after a > recompile, the Extension Manager will not take my add-on (see below > please). However, the extension manager will take the module located > http://extensions.openoffice.org/en/project/english-dictionaries-apach > e-openoffice > > Is there anything that the new AOO needs configured within the .oxt that was > not needed in 3.3? Any help would be great! > > -----Original Message- > From: Steele, Raymond > Sent: Wednesday, April 09, 2014 8:08 AM > To: dev@openoffice.apache.org > Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes > > Thanks. I am using Java. The extension I have works on my Solaris 10 > OpenOffice 3.3 instance, but not on my Solaris 11 4.0.1 instance. I used the > OpenOffice Netbeans module to create the Add-on. > > -Original Message- > From: Jürgen Schmidt [mailto:jogischm...@gmail.com] > Sent: Tuesday, April 08, 2014 11:16 PM > To: dev@openoffice.apache.org > Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes > > On 4/8/14 11:49 PM, Steele, Raymond wrote: >> I installed the extension located at the following link with success, so >> what is wrong with my extension >> >> http://extensions.openoffice.org/en/project/english-dictionaries-apac >> h >> e-openoffice > > it's difficult to say without having the code, you can easy make mistakes > with extensions. > > I haven't followed the thread in detail but maybe you can describe in > a few sentences what exactly you try > > - which programming language do you use > - which kind of extension, an add-on, a calc add-in, ... > - ... > > Juergen > > >> >> >> -Original Message- >> From: Steele, Raymond >> Sent: Tuesday, April 08, 2014 10:31 AM >> To: 'dev@openoffice.apache.org' >> Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes >> >> Is there any one that is familiar with this code and able to lend a hand. I >> do not understand what is going on here. I suspect that the crash is >> cpp_vtable_call is due to a RuntimeException thrown in Reference.hxx because >> pQueried is equal to (nil). Here is the stack trace leading up to the >> RunTimeException during the registration of my .oxt file. >> >> =>[1] com::sun::star::uno::BaseReference::iquery_throw(pInterface = >> 0x9e348ac, rType = CLASS), line 81 in "Reference.hxx" >> [2] >> dp_registry::backend::component::_unamed_AjaA7n_a0TEvD::BackendImpl::ComponentPackageImpl::processPackage_(this >> = 0xea4f9a88, _ARG2 = CLASS, doRegisterPackge = true, startup = false, >> abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx" >> [3] dp_registry::backend::Package::processPackage_Impl(this = >> 0xea4f9a88, doRegisterPackage = true, startup = false, xAbortChannel = >> CLASS, xCmdEnv = CLASS), line 675 in "dp_backend.cxx" >> [4] dp_registy::backend::Package::registerPackage(this = 0xe9b94c58, >> startup = '\0', xAbortChannel = CLASS, xCmdEnv = CALSS), line 725 in >> "dp_backend.cxx" >> >> I really need to get over this hurdle. >> >> -Original Message- >> From: Steele, Raymond >> Sent: Friday, April 04, 2014 5:52 PM >> To: dev@openoffice.apache.org >> Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes >> >> I am still plugging away at this issue. This is what I have determined. >> addExtension is called in dp_extensionmanager.cxx. However, a >> RuntimeException is thrown somewhere and caught on line 819. Then on line >> 830, the code then tries to recover the "original status" then call >> activateExtension, which then leads up to the crash, which happens after an >> attempt to register and process the package in dp_component.cxx. I am not >> sure if the initial RuntimeException is causing the problem, but something >> is not correct. Here is high level stack trace (t
RE: EXTERNAL: Re: Extension Manager Add Crashes
I am cross posting here since I am not getting much traction on the dev list and it appears it may be API related. I have an add-on that I developed using the Netbeans Openiffice module. This .oxt file works fine on AOO 3.3, but since I switched to AOO 4.0.1 and after a recompile, the Extension Manager will not take my add-on (see below please). However, the extension manager will take the module located http://extensions.openoffice.org/en/project/english-dictionaries-apache-openoffice Is there anything that the new AOO needs configured within the .oxt that was not needed in 3.3? Any help would be great! -Original Message- From: Steele, Raymond Sent: Wednesday, April 09, 2014 8:08 AM To: dev@openoffice.apache.org Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes Thanks. I am using Java. The extension I have works on my Solaris 10 OpenOffice 3.3 instance, but not on my Solaris 11 4.0.1 instance. I used the OpenOffice Netbeans module to create the Add-on. -Original Message- From: Jürgen Schmidt [mailto:jogischm...@gmail.com] Sent: Tuesday, April 08, 2014 11:16 PM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 4/8/14 11:49 PM, Steele, Raymond wrote: > I installed the extension located at the following link with success, so what > is wrong with my extension > > http://extensions.openoffice.org/en/project/english-dictionaries-apach > e-openoffice it's difficult to say without having the code, you can easy make mistakes with extensions. I haven't followed the thread in detail but maybe you can describe in a few sentences what exactly you try - which programming language do you use - which kind of extension, an add-on, a calc add-in, ... - ... Juergen > > > -Original Message- > From: Steele, Raymond > Sent: Tuesday, April 08, 2014 10:31 AM > To: 'dev@openoffice.apache.org' > Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes > > Is there any one that is familiar with this code and able to lend a hand. I > do not understand what is going on here. I suspect that the crash is > cpp_vtable_call is due to a RuntimeException thrown in Reference.hxx because > pQueried is equal to (nil). Here is the stack trace leading up to the > RunTimeException during the registration of my .oxt file. > > =>[1] com::sun::star::uno::BaseReference::iquery_throw(pInterface = > 0x9e348ac, rType = CLASS), line 81 in "Reference.hxx" > [2] > dp_registry::backend::component::_unamed_AjaA7n_a0TEvD::BackendImpl::ComponentPackageImpl::processPackage_(this > = 0xea4f9a88, _ARG2 = CLASS, doRegisterPackge = true, startup = false, > abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx" > [3] dp_registry::backend::Package::processPackage_Impl(this = > 0xea4f9a88, doRegisterPackage = true, startup = false, xAbortChannel = CLASS, > xCmdEnv = CLASS), line 675 in "dp_backend.cxx" > [4] dp_registy::backend::Package::registerPackage(this = 0xe9b94c58, > startup = '\0', xAbortChannel = CLASS, xCmdEnv = CALSS), line 725 in > "dp_backend.cxx" > > I really need to get over this hurdle. > > -Original Message- > From: Steele, Raymond > Sent: Friday, April 04, 2014 5:52 PM > To: dev@openoffice.apache.org > Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes > > I am still plugging away at this issue. This is what I have determined. > addExtension is called in dp_extensionmanager.cxx. However, a > RuntimeException is thrown somewhere and caught on line 819. Then on line > 830, the code then tries to recover the "original status" then call > activateExtension, which then leads up to the crash, which happens after an > attempt to register and process the package in dp_component.cxx. I am not > sure if the initial RuntimeException is causing the problem, but something is > not correct. Here is high level stack trace (typed out). > > [1] cpp_vtable_call(nFunctionIndex = 3, nVtableOffset = 0, pCallStack = > 0xe90acea8, nRegReturn = -1649035904490436800LL) in cpp2uno.cxx [2] > privateSnippetExecutorGeneral(0x9daf5d4, 0xe91d7294, 0xe90ad250, 0xe90ad1ec, > 0x0, 0x0), at 0xf83516a2 [3] > dp_registry::backend::component::_unamed_AjaA7n_aOTEvD::BackendImpl::ComponentPackageImpl::processPackage_(this- > 0xe91d7240, _ARG2 = CLASS, doRegisterPackage = true, startup = > false,abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx" > > > > -Original Message- > From: Carl Marcum [mailto:c...@codebuilders.net] > Sent: Friday, April 04, 2014 3:53 PM > To: dev@openoffice.apache.org > Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes > > On 04/04/2014 12:38 PM,
RE: EXTERNAL: Re: Extension Manager Add Crashes
Thanks. I am using Java. The extension I have works on my Solaris 10 OpenOffice 3.3 instance, but not on my Solaris 11 4.0.1 instance. I used the OpenOffice Netbeans module to create the Add-on. -Original Message- From: Jürgen Schmidt [mailto:jogischm...@gmail.com] Sent: Tuesday, April 08, 2014 11:16 PM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 4/8/14 11:49 PM, Steele, Raymond wrote: > I installed the extension located at the following link with success, so what > is wrong with my extension > > http://extensions.openoffice.org/en/project/english-dictionaries-apach > e-openoffice it's difficult to say without having the code, you can easy make mistakes with extensions. I haven't followed the thread in detail but maybe you can describe in a few sentences what exactly you try - which programming language do you use - which kind of extension, an add-on, a calc add-in, ... - ... Juergen > > > -Original Message- > From: Steele, Raymond > Sent: Tuesday, April 08, 2014 10:31 AM > To: 'dev@openoffice.apache.org' > Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes > > Is there any one that is familiar with this code and able to lend a hand. I > do not understand what is going on here. I suspect that the crash is > cpp_vtable_call is due to a RuntimeException thrown in Reference.hxx because > pQueried is equal to (nil). Here is the stack trace leading up to the > RunTimeException during the registration of my .oxt file. > > =>[1] com::sun::star::uno::BaseReference::iquery_throw(pInterface = > 0x9e348ac, rType = CLASS), line 81 in "Reference.hxx" > [2] > dp_registry::backend::component::_unamed_AjaA7n_a0TEvD::BackendImpl::ComponentPackageImpl::processPackage_(this > = 0xea4f9a88, _ARG2 = CLASS, doRegisterPackge = true, startup = false, > abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx" > [3] dp_registry::backend::Package::processPackage_Impl(this = > 0xea4f9a88, doRegisterPackage = true, startup = false, xAbortChannel = CLASS, > xCmdEnv = CLASS), line 675 in "dp_backend.cxx" > [4] dp_registy::backend::Package::registerPackage(this = 0xe9b94c58, > startup = '\0', xAbortChannel = CLASS, xCmdEnv = CALSS), line 725 in > "dp_backend.cxx" > > I really need to get over this hurdle. > > -Original Message- > From: Steele, Raymond > Sent: Friday, April 04, 2014 5:52 PM > To: dev@openoffice.apache.org > Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes > > I am still plugging away at this issue. This is what I have determined. > addExtension is called in dp_extensionmanager.cxx. However, a > RuntimeException is thrown somewhere and caught on line 819. Then on line > 830, the code then tries to recover the "original status" then call > activateExtension, which then leads up to the crash, which happens after an > attempt to register and process the package in dp_component.cxx. I am not > sure if the initial RuntimeException is causing the problem, but something is > not correct. Here is high level stack trace (typed out). > > [1] cpp_vtable_call(nFunctionIndex = 3, nVtableOffset = 0, pCallStack = > 0xe90acea8, nRegReturn = -1649035904490436800LL) in cpp2uno.cxx [2] > privateSnippetExecutorGeneral(0x9daf5d4, 0xe91d7294, 0xe90ad250, 0xe90ad1ec, > 0x0, 0x0), at 0xf83516a2 [3] > dp_registry::backend::component::_unamed_AjaA7n_aOTEvD::BackendImpl::ComponentPackageImpl::processPackage_(this- > 0xe91d7240, _ARG2 = CLASS, doRegisterPackage = true, startup = > false,abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx" > > > > -Original Message- > From: Carl Marcum [mailto:c...@codebuilders.net] > Sent: Friday, April 04, 2014 3:53 PM > To: dev@openoffice.apache.org > Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes > > On 04/04/2014 12:38 PM, Kay Schenk wrote: >> On Fri, Apr 4, 2014 at 3:49 AM, Carl Marcum wrote: >> >>> On 04/03/2014 07:29 PM, Steele, Raymond wrote: >>> >>>> I am not convinced the issue is with the extension. I created >>>> another simple extension using the Netbeans plugin and I receive >>>> the same crash. I don't know where to go from here. >>>> >>>> ... >>> >>> Raymond, >>> >>> What version of AOO and netbeans are you using. >>> >>> For AOO4+ and NB7+ you should try this one: >>> http://people.apache.org/~cmarcum/devtools/org- >>> openoffice-extensions-4.0.5.alpha.nbm >>> >>> I can't say how much testing
RE: EXTERNAL: Re: Extension Manager Add Crashes
I installed the extension located at the following link with success, so what is wrong with my extension http://extensions.openoffice.org/en/project/english-dictionaries-apache-openoffice -Original Message- From: Steele, Raymond Sent: Tuesday, April 08, 2014 10:31 AM To: 'dev@openoffice.apache.org' Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes Is there any one that is familiar with this code and able to lend a hand. I do not understand what is going on here. I suspect that the crash is cpp_vtable_call is due to a RuntimeException thrown in Reference.hxx because pQueried is equal to (nil). Here is the stack trace leading up to the RunTimeException during the registration of my .oxt file. =>[1] com::sun::star::uno::BaseReference::iquery_throw(pInterface = 0x9e348ac, rType = CLASS), line 81 in "Reference.hxx" [2] dp_registry::backend::component::_unamed_AjaA7n_a0TEvD::BackendImpl::ComponentPackageImpl::processPackage_(this = 0xea4f9a88, _ARG2 = CLASS, doRegisterPackge = true, startup = false, abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx" [3] dp_registry::backend::Package::processPackage_Impl(this = 0xea4f9a88, doRegisterPackage = true, startup = false, xAbortChannel = CLASS, xCmdEnv = CLASS), line 675 in "dp_backend.cxx" [4] dp_registy::backend::Package::registerPackage(this = 0xe9b94c58, startup = '\0', xAbortChannel = CLASS, xCmdEnv = CALSS), line 725 in "dp_backend.cxx" I really need to get over this hurdle. -Original Message- From: Steele, Raymond Sent: Friday, April 04, 2014 5:52 PM To: dev@openoffice.apache.org Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes I am still plugging away at this issue. This is what I have determined. addExtension is called in dp_extensionmanager.cxx. However, a RuntimeException is thrown somewhere and caught on line 819. Then on line 830, the code then tries to recover the "original status" then call activateExtension, which then leads up to the crash, which happens after an attempt to register and process the package in dp_component.cxx. I am not sure if the initial RuntimeException is causing the problem, but something is not correct. Here is high level stack trace (typed out). [1] cpp_vtable_call(nFunctionIndex = 3, nVtableOffset = 0, pCallStack = 0xe90acea8, nRegReturn = -1649035904490436800LL) in cpp2uno.cxx [2] privateSnippetExecutorGeneral(0x9daf5d4, 0xe91d7294, 0xe90ad250, 0xe90ad1ec, 0x0, 0x0), at 0xf83516a2 [3] dp_registry::backend::component::_unamed_AjaA7n_aOTEvD::BackendImpl::ComponentPackageImpl::processPackage_(this- 0xe91d7240, _ARG2 = CLASS, doRegisterPackage = true, startup = false,abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx" -Original Message- From: Carl Marcum [mailto:c...@codebuilders.net] Sent: Friday, April 04, 2014 3:53 PM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 04/04/2014 12:38 PM, Kay Schenk wrote: > On Fri, Apr 4, 2014 at 3:49 AM, Carl Marcum wrote: > >> On 04/03/2014 07:29 PM, Steele, Raymond wrote: >> >>> I am not convinced the issue is with the extension. I created >>> another simple extension using the Netbeans plugin and I receive the >>> same crash. I don't know where to go from here. >>> >>> ... >> >> Raymond, >> >> What version of AOO and netbeans are you using. >> >> For AOO4+ and NB7+ you should try this one: >> http://people.apache.org/~cmarcum/devtools/org- >> openoffice-extensions-4.0.5.alpha.nbm >> >> I can't say how much testing it's had, therefore the alpha designation. >> >> Best regards, >> Carl > > > Carl -- > > Is is OK to update the wiki page -- > > https://wiki.openoffice.org/wiki/OpenOffice_NetBeans_Integration#Downl > oad_and_Installation > > with this new version regardless of "alpha" status? This would give > more visibility and testing. > > > >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> > > Kay, I will leave that to the group. At the time I had only been able to test it using Netbeans 7.2, AOO 4.0.0 on Fedora 17 x86-64. I know of no testing on Windows or Mac. When I posted the update, I believe Juergen Schmidt was on vacation at the time but was going to look at it for some other changes being made so I waited until I heard back. The thread is here: http://markmail.org/message/5yv2nyob4rurmj2h The change that broke backward compatibility was for Addons.xcu here: https://issue
RE: EXTERNAL: Re: Extension Manager Add Crashes
Is there any one that is familiar with this code and able to lend a hand. I do not understand what is going on here. I suspect that the crash is cpp_vtable_call is due to a RuntimeException thrown in Reference.hxx because pQueried is equal to (nil). Here is the stack trace leading up to the RunTimeException during the registration of my .oxt file. =>[1] com::sun::star::uno::BaseReference::iquery_throw(pInterface = 0x9e348ac, rType = CLASS), line 81 in "Reference.hxx" [2] dp_registry::backend::component::_unamed_AjaA7n_a0TEvD::BackendImpl::ComponentPackageImpl::processPackage_(this = 0xea4f9a88, _ARG2 = CLASS, doRegisterPackge = true, startup = false, abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx" [3] dp_registry::backend::Package::processPackage_Impl(this = 0xea4f9a88, doRegisterPackage = true, startup = false, xAbortChannel = CLASS, xCmdEnv = CLASS), line 675 in "dp_backend.cxx" [4] dp_registy::backend::Package::registerPackage(this = 0xe9b94c58, startup = '\0', xAbortChannel = CLASS, xCmdEnv = CALSS), line 725 in "dp_backend.cxx" I really need to get over this hurdle. -Original Message- From: Steele, Raymond Sent: Friday, April 04, 2014 5:52 PM To: dev@openoffice.apache.org Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes I am still plugging away at this issue. This is what I have determined. addExtension is called in dp_extensionmanager.cxx. However, a RuntimeException is thrown somewhere and caught on line 819. Then on line 830, the code then tries to recover the "original status" then call activateExtension, which then leads up to the crash, which happens after an attempt to register and process the package in dp_component.cxx. I am not sure if the initial RuntimeException is causing the problem, but something is not correct. Here is high level stack trace (typed out). [1] cpp_vtable_call(nFunctionIndex = 3, nVtableOffset = 0, pCallStack = 0xe90acea8, nRegReturn = -1649035904490436800LL) in cpp2uno.cxx [2] privateSnippetExecutorGeneral(0x9daf5d4, 0xe91d7294, 0xe90ad250, 0xe90ad1ec, 0x0, 0x0), at 0xf83516a2 [3] dp_registry::backend::component::_unamed_AjaA7n_aOTEvD::BackendImpl::ComponentPackageImpl::processPackage_(this- 0xe91d7240, _ARG2 = CLASS, doRegisterPackage = true, startup = false,abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx" -Original Message- From: Carl Marcum [mailto:c...@codebuilders.net] Sent: Friday, April 04, 2014 3:53 PM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 04/04/2014 12:38 PM, Kay Schenk wrote: > On Fri, Apr 4, 2014 at 3:49 AM, Carl Marcum wrote: > >> On 04/03/2014 07:29 PM, Steele, Raymond wrote: >> >>> I am not convinced the issue is with the extension. I created >>> another simple extension using the Netbeans plugin and I receive the >>> same crash. I don't know where to go from here. >>> >>> ... >> >> Raymond, >> >> What version of AOO and netbeans are you using. >> >> For AOO4+ and NB7+ you should try this one: >> http://people.apache.org/~cmarcum/devtools/org- >> openoffice-extensions-4.0.5.alpha.nbm >> >> I can't say how much testing it's had, therefore the alpha designation. >> >> Best regards, >> Carl > > > Carl -- > > Is is OK to update the wiki page -- > > https://wiki.openoffice.org/wiki/OpenOffice_NetBeans_Integration#Downl > oad_and_Installation > > with this new version regardless of "alpha" status? This would give > more visibility and testing. > > > >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> > > Kay, I will leave that to the group. At the time I had only been able to test it using Netbeans 7.2, AOO 4.0.0 on Fedora 17 x86-64. I know of no testing on Windows or Mac. When I posted the update, I believe Juergen Schmidt was on vacation at the time but was going to look at it for some other changes being made so I waited until I heard back. The thread is here: http://markmail.org/message/5yv2nyob4rurmj2h The change that broke backward compatibility was for Addons.xcu here: https://issues.apache.org/ooo/show_bug.cgi?id=122055 3-Layer removal here: https://issues.apache.org/ooo/show_bug.cgi?id=123266 I would have some time to make changes if we find issues. Also NB 8 is out now so I don't know if that breaks anything also. Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
I am still plugging away at this issue. This is what I have determined. addExtension is called in dp_extensionmanager.cxx. However, a RuntimeException is thrown somewhere and caught on line 819. Then on line 830, the code then tries to recover the "original status" then call activateExtension, which then leads up to the crash, which happens after an attempt to register and process the package in dp_component.cxx. I am not sure if the initial RuntimeException is causing the problem, but something is not correct. Here is high level stack trace (typed out). [1] cpp_vtable_call(nFunctionIndex = 3, nVtableOffset = 0, pCallStack = 0xe90acea8, nRegReturn = -1649035904490436800LL) in cpp2uno.cxx [2] privateSnippetExecutorGeneral(0x9daf5d4, 0xe91d7294, 0xe90ad250, 0xe90ad1ec, 0x0, 0x0), at 0xf83516a2 [3] dp_registry::backend::component::_unamed_AjaA7n_aOTEvD::BackendImpl::ComponentPackageImpl::processPackage_(this- 0xe91d7240, _ARG2 = CLASS, doRegisterPackage = true, startup = false,abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx" -Original Message- From: Carl Marcum [mailto:c...@codebuilders.net] Sent: Friday, April 04, 2014 3:53 PM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 04/04/2014 12:38 PM, Kay Schenk wrote: > On Fri, Apr 4, 2014 at 3:49 AM, Carl Marcum wrote: > >> On 04/03/2014 07:29 PM, Steele, Raymond wrote: >> >>> I am not convinced the issue is with the extension. I created >>> another simple extension using the Netbeans plugin and I receive the >>> same crash. I don't know where to go from here. >>> >>> ... >> >> Raymond, >> >> What version of AOO and netbeans are you using. >> >> For AOO4+ and NB7+ you should try this one: >> http://people.apache.org/~cmarcum/devtools/org- >> openoffice-extensions-4.0.5.alpha.nbm >> >> I can't say how much testing it's had, therefore the alpha designation. >> >> Best regards, >> Carl > > > Carl -- > > Is is OK to update the wiki page -- > > https://wiki.openoffice.org/wiki/OpenOffice_NetBeans_Integration#Downl > oad_and_Installation > > with this new version regardless of "alpha" status? This would give > more visibility and testing. > > > >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> > > Kay, I will leave that to the group. At the time I had only been able to test it using Netbeans 7.2, AOO 4.0.0 on Fedora 17 x86-64. I know of no testing on Windows or Mac. When I posted the update, I believe Juergen Schmidt was on vacation at the time but was going to look at it for some other changes being made so I waited until I heard back. The thread is here: http://markmail.org/message/5yv2nyob4rurmj2h The change that broke backward compatibility was for Addons.xcu here: https://issues.apache.org/ooo/show_bug.cgi?id=122055 3-Layer removal here: https://issues.apache.org/ooo/show_bug.cgi?id=123266 I would have some time to make changes if we find issues. Also NB 8 is out now so I don't know if that breaks anything also. Thanks, Carl - 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: EXTERNAL: Re: Extension Manager Add Crashes
Thanks for letting me know Carl. I am still looking for a solution to why this is crashing. Any help would be great. -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Friday, April 04, 2014 4:11 PM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 04/04/2014 11:47 AM, Steele, Raymond wrote: > Thanks Carl. I will give it a try. Can you tell me what the changes are as > compared to the 3.0 version that I am using. > > -Original Message- > From: Carl Marcum [mailto:cmar...@apache.org] > Sent: Friday, April 04, 2014 3:49 AM > To: dev@openoffice.apache.org > Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes > > On 04/03/2014 07:29 PM, Steele, Raymond wrote: >> I am not convinced the issue is with the extension. I created another >> simple extension using the Netbeans plugin and I receive the same crash. I >> don't know where to go from here. >> > ... Raymond, AOO4 required a change to Addons.xcu that broke backward compatibility I documented here: https://issues.apache.org/ooo/show_bug.cgi?id=122055 The other change was for 3-Layer removal here: https://issues.apache.org/ooo/show_bug.cgi?id=123266 Best regards, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
Carl. Thanks for the information. I installed the module suggested and create a bare bones OpenOffice Add-on project in Netbeans. After I compiled and created the .oxt, I attempted to add it to OpenOffice extension manager, but received the same result. I am starting to become more confident that there is an issues in the compiled code. Possible in call.s and cpp2uno.cxx, but I cannot figure it out. Raymond -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Friday, April 04, 2014 3:49 AM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 04/03/2014 07:29 PM, Steele, Raymond wrote: > I am not convinced the issue is with the extension. I created another simple > extension using the Netbeans plugin and I receive the same crash. I don't > know where to go from here. > ... Raymond, What version of AOO and netbeans are you using. For AOO4+ and NB7+ you should try this one: http://people.apache.org/~cmarcum/devtools/org-openoffice-extensions-4.0.5.alpha.nbm I can't say how much testing it's had, therefore the alpha designation. Best regards, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
Thanks Carl. I will give it a try. Can you tell me what the changes are as compared to the 3.0 version that I am using. -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Friday, April 04, 2014 3:49 AM To: dev@openoffice.apache.org Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On 04/03/2014 07:29 PM, Steele, Raymond wrote: > I am not convinced the issue is with the extension. I created another simple > extension using the Netbeans plugin and I receive the same crash. I don't > know where to go from here. > ... Raymond, What version of AOO and netbeans are you using. For AOO4+ and NB7+ you should try this one: http://people.apache.org/~cmarcum/devtools/org-openoffice-extensions-4.0.5.alpha.nbm I can't say how much testing it's had, therefore the alpha designation. Best regards, Carl - 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: EXTERNAL: Re: Extension Manager Add Crashes
I am not convinced the issue is with the extension. I created another simple extension using the Netbeans plugin and I receive the same crash. I don't know where to go from here. -Original Message- From: Kay Schenk [mailto:kay.sch...@gmail.com] Sent: Thursday, April 03, 2014 9:35 AM To: OOo Apache Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On Thu, Apr 3, 2014 at 8:25 AM, Steele, Raymond wrote: > Is there anyone that is able to help me with this? > > -Original Message- > From: Steele, Raymond > Sent: Wednesday, April 02, 2014 3:34 PM > To: 'Stephan Bergmann' > Cc: dev@openoffice.apache.org; michael.me...@suse.com > Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes > > > I now understand what is described below (except the UNOIDL and .rbd > stuff) and see all of this in the code, but I am still lost for a > solution. Is there anything that I may be able to modify to get this > working? > > -Original Message- > From: Stephan Bergmann > [mailto:stephan.bergmann.second...@googlemail.com] > Sent: Tuesday, April 01, 2014 11:41 PM > To: Steele, Raymond > Cc: dev@openoffice.apache.org; michael.me...@suse.com > Subject: EXTERNAL: Re: Extension Manager Add Crashes > > On 04/02/2014 01:20 AM, Steele, Raymond wrote: > > Following up again with more information. At runtime, when the > > RuntimeException is thrown on line 249 > > > > nFunctionIndex = 3 > > > > pTypeDescr->nMapFunctionIndexToMemberIndex = 0 > > That means that the given pTypeDescr has not been initialized fully > (see the comment about the three levels of initialization for > typelib_InterfaceTypeDescription in typelib/typedescription.h), > presumably because there was some error finding the UNOIDL type data > (either compiled comprehensively into the cppumaker-generated headers, > or obtained from .rdb files). The initialization of > nMapFunctionIndexToMemberIndex would happen in > typelib_typedescription_initTables called from complete (both in > cppu/source/typelib/typelib.cxx). > > Stephan > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > Just out of curiosity, what is this extension? I don't think you mentioned this. -- - 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: Extension Manager Add Crashes
Thanks for responding. This is an extension that I build using the OpenOffice Netbeans module. https://wiki.openoffice.org/wiki/OpenOffice_NetBeans_Integration#Download_and_Installation -Original Message- From: Kay Schenk [mailto:kay.sch...@gmail.com] Sent: Thursday, April 03, 2014 9:35 AM To: OOo Apache Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes On Thu, Apr 3, 2014 at 8:25 AM, Steele, Raymond wrote: > Is there anyone that is able to help me with this? > > -Original Message- > From: Steele, Raymond > Sent: Wednesday, April 02, 2014 3:34 PM > To: 'Stephan Bergmann' > Cc: dev@openoffice.apache.org; michael.me...@suse.com > Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes > > > I now understand what is described below (except the UNOIDL and .rbd > stuff) and see all of this in the code, but I am still lost for a > solution. Is there anything that I may be able to modify to get this > working? > > -Original Message- > From: Stephan Bergmann > [mailto:stephan.bergmann.second...@googlemail.com] > Sent: Tuesday, April 01, 2014 11:41 PM > To: Steele, Raymond > Cc: dev@openoffice.apache.org; michael.me...@suse.com > Subject: EXTERNAL: Re: Extension Manager Add Crashes > > On 04/02/2014 01:20 AM, Steele, Raymond wrote: > > Following up again with more information. At runtime, when the > > RuntimeException is thrown on line 249 > > > > nFunctionIndex = 3 > > > > pTypeDescr->nMapFunctionIndexToMemberIndex = 0 > > That means that the given pTypeDescr has not been initialized fully > (see the comment about the three levels of initialization for > typelib_InterfaceTypeDescription in typelib/typedescription.h), > presumably because there was some error finding the UNOIDL type data > (either compiled comprehensively into the cppumaker-generated headers, > or obtained from .rdb files). The initialization of > nMapFunctionIndexToMemberIndex would happen in > typelib_typedescription_initTables called from complete (both in > cppu/source/typelib/typelib.cxx). > > Stephan > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > Just out of curiosity, what is this extension? I don't think you mentioned this. -- - 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: Extension Manager Add Crashes
Is there anyone that is able to help me with this? -Original Message- From: Steele, Raymond Sent: Wednesday, April 02, 2014 3:34 PM To: 'Stephan Bergmann' Cc: dev@openoffice.apache.org; michael.me...@suse.com Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes I now understand what is described below (except the UNOIDL and .rbd stuff) and see all of this in the code, but I am still lost for a solution. Is there anything that I may be able to modify to get this working? -Original Message- From: Stephan Bergmann [mailto:stephan.bergmann.second...@googlemail.com] Sent: Tuesday, April 01, 2014 11:41 PM To: Steele, Raymond Cc: dev@openoffice.apache.org; michael.me...@suse.com Subject: EXTERNAL: Re: Extension Manager Add Crashes On 04/02/2014 01:20 AM, Steele, Raymond wrote: > Following up again with more information. At runtime, when the > RuntimeException is thrown on line 249 > > nFunctionIndex = 3 > > pTypeDescr->nMapFunctionIndexToMemberIndex = 0 That means that the given pTypeDescr has not been initialized fully (see the comment about the three levels of initialization for typelib_InterfaceTypeDescription in typelib/typedescription.h), presumably because there was some error finding the UNOIDL type data (either compiled comprehensively into the cppumaker-generated headers, or obtained from .rdb files). The initialization of nMapFunctionIndexToMemberIndex would happen in typelib_typedescription_initTables called from complete (both in cppu/source/typelib/typelib.cxx). Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
I now understand what is described below (except the UNOIDL and .rbd stuff) and see all of this in the code, but I am still lost for a solution. Is there anything that I may be able to modify to get this working? -Original Message- From: Stephan Bergmann [mailto:stephan.bergmann.second...@googlemail.com] Sent: Tuesday, April 01, 2014 11:41 PM To: Steele, Raymond Cc: dev@openoffice.apache.org; michael.me...@suse.com Subject: EXTERNAL: Re: Extension Manager Add Crashes On 04/02/2014 01:20 AM, Steele, Raymond wrote: > Following up again with more information. At runtime, when the > RuntimeException is thrown on line 249 > > nFunctionIndex = 3 > > pTypeDescr->nMapFunctionIndexToMemberIndex = 0 That means that the given pTypeDescr has not been initialized fully (see the comment about the three levels of initialization for typelib_InterfaceTypeDescription in typelib/typedescription.h), presumably because there was some error finding the UNOIDL type data (either compiled comprehensively into the cppumaker-generated headers, or obtained from .rdb files). The initialization of nMapFunctionIndexToMemberIndex would happen in typelib_typedescription_initTables called from complete (both in cppu/source/typelib/typelib.cxx). Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: EXTERNAL: Re: Extension Manager Add Crashes
Thanks. I'll take a stab at it, although I am not too sure I understand. Raymond -Original Message- From: Stephan Bergmann [mailto:stephan.bergmann.second...@googlemail.com] Sent: Tuesday, April 01, 2014 11:41 PM To: Steele, Raymond Cc: dev@openoffice.apache.org; michael.me...@suse.com Subject: EXTERNAL: Re: Extension Manager Add Crashes On 04/02/2014 01:20 AM, Steele, Raymond wrote: > Following up again with more information. At runtime, when the > RuntimeException is thrown on line 249 > > nFunctionIndex = 3 > > pTypeDescr->nMapFunctionIndexToMemberIndex = 0 That means that the given pTypeDescr has not been initialized fully (see the comment about the three levels of initialization for typelib_InterfaceTypeDescription in typelib/typedescription.h), presumably because there was some error finding the UNOIDL type data (either compiled comprehensively into the cppumaker-generated headers, or obtained from .rdb files). The initialization of nMapFunctionIndexToMemberIndex would happen in typelib_typedescription_initTables called from complete (both in cppu/source/typelib/typelib.cxx). Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Extension Manager Add Crashes
Following up again with more information. At runtime, when the RuntimeException
is thrown on line 249
nFunctionIndex = 3
pTypeDescr->nMapFunctionIndexToMemberIndex = 0
Therefore,
if(nFunctionIndex >= pTypeDescr->nMapFunctionIndexToMemberIndex)
throw RuntimeException
Any help would be greatly appreciated. My vtable knowledge is limited.
Thanks!
From: Steele, Raymond
Sent: Tuesday, April 01, 2014 10:44 AM
To: dev@openoffice.apache.org
Cc: 'michael.me...@suse.com'; 'stephan.bergmann.second...@googlemail.com'
Subject: RE: Extension Manager Add Crashes
Still trying to figure this out, but I wanted to provide another update. The
code eventually gets to line 247 in cpp2uno.cxx, then throws the
RuntimException( rtl::OUString::createFromAscii("illegal vtable index!"),
(XInterface *)pThis ) on line 249.
From: Steele, Raymond
Sent: Tuesday, April 01, 2014 10:13 AM
To: dev@openoffice.apache.org<mailto:dev@openoffice.apache.org>
Cc: 'michael.me...@suse.com'; 'stephan.bergmann.second...@googlemail.com'
Subject: RE: Extension Manager Add Crashes
Just wanted to update that the actual crash seems to be after the
cpp_vtable_call in rtl::OUString::createFromAscii( inlined ), line 136 in
"Reference.hxx"
From: Steele, Raymond
Sent: Tuesday, April 01, 2014 9:45 AM
To: dev@openoffice.apache.org<mailto:dev@openoffice.apache.org>
Cc: 'michael.me...@suse.com'; 'stephan.bergmann.second...@googlemail.com'
Subject: Extension Manager Add Crashes
Using OpenOffice 4.0.1 on Solaris 11 x86. The code was compiled using
SolarisStudio 12.3 compiler.
When attempt to add an .oxt file using the Extension Manager, the application
crashes at
current threat: t@11
[1] cpp_vtable_call(nFunctionIndex = 3, nVtableOffset = 0, pCallStack =
0xe90acea8, nRegReturn = -1649035904490436800LL) in cpp2uno.cxx
[2] privateSnippetExecutorGeneral(0x9daf5d4, 0xe91d7294, 0xe90ad250,
0xe90ad1ec, 0x0, 0x0), at 0xf83516a2
[3]
dp_registry::backend::component::_unamed_AjaA7n_aOTEvD::BackendImpl::ComponentPackageImpl::processPackage_(this
- 0xe91d7240, _ARG2 = CLASS, doRegisterPackage = true, startup = false,
abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx"
I following issue seems to be related but I cannot decipher the meaning, or if
it applies to my situation. Hopefully, someone can get me going in the right
direction to address this issue.
https://issues.apache.org/ooo/show_bug.cgi?id=47459
Raymond
RE: Extension Manager Add Crashes
Still trying to figure this out, but I wanted to provide another update. The
code eventually gets to line 247 in cpp2uno.cxx, then throws the
RuntimException( rtl::OUString::createFromAscii("illegal vtable index!"),
(XInterface *)pThis ) on line 249.
From: Steele, Raymond
Sent: Tuesday, April 01, 2014 10:13 AM
To: dev@openoffice.apache.org
Cc: 'michael.me...@suse.com'; 'stephan.bergmann.second...@googlemail.com'
Subject: RE: Extension Manager Add Crashes
Just wanted to update that the actual crash seems to be after the
cpp_vtable_call in rtl::OUString::createFromAscii( inlined ), line 136 in
"Reference.hxx"
From: Steele, Raymond
Sent: Tuesday, April 01, 2014 9:45 AM
To: dev@openoffice.apache.org<mailto:dev@openoffice.apache.org>
Cc: 'michael.me...@suse.com'; 'stephan.bergmann.second...@googlemail.com'
Subject: Extension Manager Add Crashes
Using OpenOffice 4.0.1 on Solaris 11 x86. The code was compiled using
SolarisStudio 12.3 compiler.
When attempt to add an .oxt file using the Extension Manager, the application
crashes at
current threat: t@11
[1] cpp_vtable_call(nFunctionIndex = 3, nVtableOffset = 0, pCallStack =
0xe90acea8, nRegReturn = -1649035904490436800LL) in cpp2uno.cxx
[2] privateSnippetExecutorGeneral(0x9daf5d4, 0xe91d7294, 0xe90ad250,
0xe90ad1ec, 0x0, 0x0), at 0xf83516a2
[3]
dp_registry::backend::component::_unamed_AjaA7n_aOTEvD::BackendImpl::ComponentPackageImpl::processPackage_(this
- 0xe91d7240, _ARG2 = CLASS, doRegisterPackage = true, startup = false,
abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx"
I following issue seems to be related but I cannot decipher the meaning, or if
it applies to my situation. Hopefully, someone can get me going in the right
direction to address this issue.
https://issues.apache.org/ooo/show_bug.cgi?id=47459
Raymond
RE: Extension Manager Add Crashes
Just wanted to update that the actual crash seems to be after the cpp_vtable_call in rtl::OUString::createFromAscii( inlined ), line 136 in "Reference.hxx" From: Steele, Raymond Sent: Tuesday, April 01, 2014 9:45 AM To: dev@openoffice.apache.org Cc: 'michael.me...@suse.com'; 'stephan.bergmann.second...@googlemail.com' Subject: Extension Manager Add Crashes Using OpenOffice 4.0.1 on Solaris 11 x86. The code was compiled using SolarisStudio 12.3 compiler. When attempt to add an .oxt file using the Extension Manager, the application crashes at current threat: t@11 [1] cpp_vtable_call(nFunctionIndex = 3, nVtableOffset = 0, pCallStack = 0xe90acea8, nRegReturn = -1649035904490436800LL) in cpp2uno.cxx [2] privateSnippetExecutorGeneral(0x9daf5d4, 0xe91d7294, 0xe90ad250, 0xe90ad1ec, 0x0, 0x0), at 0xf83516a2 [3] dp_registry::backend::component::_unamed_AjaA7n_aOTEvD::BackendImpl::ComponentPackageImpl::processPackage_(this - 0xe91d7240, _ARG2 = CLASS, doRegisterPackage = true, startup = false, abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx" I following issue seems to be related but I cannot decipher the meaning, or if it applies to my situation. Hopefully, someone can get me going in the right direction to address this issue. https://issues.apache.org/ooo/show_bug.cgi?id=47459 Raymond
Extension Manager Add Crashes
Using OpenOffice 4.0.1 on Solaris 11 x86. The code was compiled using SolarisStudio 12.3 compiler. When attempt to add an .oxt file using the Extension Manager, the application crashes at current threat: t@11 [1] cpp_vtable_call(nFunctionIndex = 3, nVtableOffset = 0, pCallStack = 0xe90acea8, nRegReturn = -1649035904490436800LL) in cpp2uno.cxx [2] privateSnippetExecutorGeneral(0x9daf5d4, 0xe91d7294, 0xe90ad250, 0xe90ad1ec, 0x0, 0x0), at 0xf83516a2 [3] dp_registry::backend::component::_unamed_AjaA7n_aOTEvD::BackendImpl::ComponentPackageImpl::processPackage_(this - 0xe91d7240, _ARG2 = CLASS, doRegisterPackage = true, startup = false, abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in "dp_component.cxx" I following issue seems to be related but I cannot decipher the meaning, or if it applies to my situation. Hopefully, someone can get me going in the right direction to address this issue. https://issues.apache.org/ooo/show_bug.cgi?id=47459 Raymond
RE: EXTERNAL: Re: Trace Output
Thanks for the response. I am recompiling now. At first build, I removed --enable-debug and --enable-symbols, but I was still receiving the debug trace output at run in the terminal window and the installation set was 8.3G. How big is the installation supposed to be? I think earlier versions were less than 600M. Now, I removed --disable-strip-solver, hopefully, this build is clean. Raymond -Original Message- From: Andre Fischer [mailto:awf@gmail.com] Sent: Wednesday, February 19, 2014 12:43 AM To: dev@openoffice.apache.org Subject: EXTERNAL: Re: Trace Output On 18.02.2014 16:56, Steele, Raymond wrote: > I configured the OpenOffice build without debug and disabled symbols, but I > am still getting 'trace' output in the terminal when I run ./soffice. How do > I disable this? > > Raymond > > Can you give us an example? With that we can find the place in the source and understand why it is still printed. -Andre - 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: EXTERNAL: Re: dmake clean
Yes, we have made many local modifications. Gladly, we had the backup. Couldn't a check be placed in the make file to ensure $INPATH is set? -Original Message- From: Kay Schenk [mailto:kay.sch...@gmail.com] Sent: Tuesday, February 18, 2014 4:49 PM To: OOo Apache Subject: EXTERNAL: Re: dmake clean On Tue, Feb 18, 2014 at 3:01 PM, Steele, Raymond wrote: > I see in the Makefile: > > clean .PHONY > > -rm -rf */$(INPATH) > -rm -rf solver/*/$(INPATH) > > I am going to make an assumption that I performed the dmake clean and > $INPATH was not set, therefore rm -rf */ was performed > > From: Steele, Raymond > Sent: Tuesday, February 18, 2014 3:58 PM > To: dev@openoffice.apache.org > Subject: dmake clean > > I am not sure why, but I just did a dmake clean in ../main and once if > finished all the module directories including source was deleted. > Thankfully, I had a backup. Can anyone explain this? > > Raymond > > Hello Raymond -- Yes, an incredibly annoying thing and one I have experienced as well. If you "source" your env script and THEN do "dmake clean", only the bits generated toward the native build will disappear. The clean script does a MUCH bigger remove if you don't do that first. The first time this happened to me, I freaked a bit, but as I hadn't made any local mods, an svn update got everything back. It's good that you had a backup since I'm assuming you made local mods that you wanted to keep. The build doc needs a bit of updating to help others avoid this pitfall. Happy coding! -- - 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: dmake clean
I see in the Makefile: clean .PHONY -rm -rf */$(INPATH) -rm -rf solver/*/$(INPATH) I am going to make an assumption that I performed the dmake clean and $INPATH was not set, therefore rm -rf */ was performed From: Steele, Raymond Sent: Tuesday, February 18, 2014 3:58 PM To: dev@openoffice.apache.org Subject: dmake clean I am not sure why, but I just did a dmake clean in ../main and once if finished all the module directories including source was deleted. Thankfully, I had a backup. Can anyone explain this? Raymond
dmake clean
I am not sure why, but I just did a dmake clean in ../main and once if finished all the module directories including source was deleted. Thankfully, I had a backup. Can anyone explain this? Raymond
Trace Output
I configured the OpenOffice build without debug and disabled symbols, but I am still getting 'trace' output in the terminal when I run ./soffice. How do I disable this? Raymond
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Thanks. An enlightenment would be great, but I am afraid that may not happen. :) From: Andre Fischer [mailto:awf@gmail.com] Sent: Monday, February 17, 2014 3:27 AM To: Steele, Raymond; Andre Fischer; a...@openoffice.apache.org; Herbert Duerr (h...@apache.org); dev@openoffice.apache.org Cc: Meffe, David K Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault On 14.02.2014 22:37, Steele, Raymond wrote: Andre, I think we are going to keep that section commented out for now. We are not sure what to do. Do you think commenting out that section will have a big impact at runtime? Not big. It is probably OK to move on and come back later when you have some sort of enlightenment. -Andre We are working on the Save now (described below). From: Andre Fischer [mailto:awf@gmail.com] Sent: Friday, February 07, 2014 2:18 AM To: Steele, Raymond; Andre Fischer; a...@openoffice.apache.org<mailto:a...@openoffice.apache.org>; Herbert Duerr (h...@apache.org<mailto:h...@apache.org>); dev@openoffice.apache.org<mailto:dev@openoffice.apache.org> Cc: Meffe, David K Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault On 07.02.2014 00:04, Steele, Raymond wrote: Andre, When we commented out the section below, we were able to get the application to work correctly I would expect subtle errors in the sidebar, like panels not updating after context changes or when switching between application windows. (although it did not let us save a spreadsheet to disk for some reason. Each time we hit okay to save after supplying a unique name, the filechooser closes, but instantly reappears again. It did let us save it as another format, such as .dif). Strange, this change should not modify the saving of the document. That is probably an unrelated problem. However, the application crashes when we replace the lines with: Reference xThis (this, SAL_NO_ACQUIRE); WeakReference xWeakController (xThis); maSidebarControllerContainer.insert( SidebarControllerContainer::value_type( rxFrame, xWeakController)); I've attached the stack trace of that crash. It crashes right after the SidebarController destructor on line 177 (which is empty). Stepping from the destructor brings us into boost's checked_delete.hpp and eventually crashes at line 34 "delete x". See attached stack trace. m_RefCount was 3 for us as well. Also strange. All this does not fit together. If the ref count is larger than 0 then the SidebarController should not be deleted. And if it where deleted, then not from Reference<...>::iquery. And boost::scoped_ptr should have no problem deleting the control (I have not enough information to say which one it is). All controls are created in the initializer of the constructor and should be fully created and initialized by the time the crash is triggered. All this looks like the actual problem happens earlier, maybe some memory overwrite. Maybe you can use valgrind (or some other memory checker) to see if there is a memory problem? Thanks for taking the time to look into this, we are grateful. Would you happen to be located in the U.S.? No problem. I am a little worried that you have discovered a problem that lurks on all platforms and Solaris is the only one where it leads to an actual crash. And, no, I am not located in the US. I am in Germany. -Andre From: Andre Fischer [mailto:awf@gmail.com] Sent: Thursday, February 06, 2014 2:03 AM To: Steele, Raymond; a...@openoffice.apache.org<mailto:a...@openoffice.apache.org>; Herbert Duerr (h...@apache.org<mailto:h...@apache.org>); dev@openoffice.apache.org<mailto:dev@openoffice.apache.org> Cc: Meffe, David K; awf@gmail.com<mailto:awf@gmail.com> Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault On 05.02.2014 20:02, Steele, Raymond wrote: Andre, We are not seeing any exception before the actual crash. Maybe I am not looking in the right place, but we've been using dbx intercept command to track any. Any other suggestions? Raymond, there a few thing you can do to find out if this is a local problem (broken in the constructor) or something more fundamental that is possibly caused by an error that happened much earlier. - Comment out the last few lines: /* WeakReference xWeakController (this); maSidebarControllerContainer.insert( SidebarControllerContainer::value_type( rxFrame, xWeakController)); */ That should tell us whether the crash is caused just by storing the weak reference. The sidebar should still work in general but some updates may be lost. - Replace the last few lines by this: Reference xThis (this, SAL_NO_ACQUIRE); WeakReference xWeakController (xThis); maSidebarControllerContainer.insert( SidebarControllerContai
OO 4.01 Compiled for Solaris 11 x86 Save As Stuck in a Loop
We are attempting to use the newly build OpenOffice 4.0.1 for Solaris 11 x86,
but the 'Save As' to disk of any document type (i.e. .ods) continuous to
prompt for a file name. Each time we hit okay to save the document after
supplying a unique name, the FilePicker closes, but instantly reappears again.
I have narrowed it down to the following code located in
sfx2/source/doc/guisaveas.cxx lines 1497-1520
The program gets stuck in the while loop below. The variable 'bExit' is never
set to sal_True, so the loop continuous. I provide a name to the FilePicker
interface, click Save and the loop continuous, redisplaying the dialog. To
resolve the issue, I added bExit = sal_True after line 1513 so that the loop
discontinuous. I am not sure if this will have effects in other situations,
maybe someone can provide some feedback, but for now. I am able to save.
sal_Bool bExit = sal_False;
1497 while ( !bExit )
1498 {
1499 bUseFilterOptions = aModelData.OutputFileDialog( nStoreMode,
aFilterProps, bSetStandardName, aSuggestedName, bPreselectPassword,
aSuggestedDir, nDialog, sStandardDir, aBlackList );
1500
1501 // in case the dialog is opend a second time the folder should be
the same as before, not what was handed over by parameters
1502 aSuggestedDir = ::rtl::OUString();
1503 if ( nStoreMode == SAVEAS_REQUESTED )
1504 {
1505 // in case of saving check filter for possible alien warning
1506 ::rtl::OUString aSelFilterName =
aModelData.GetMediaDescr().getUnpackedValueOrDefault(
1507 aFilterNameString,
1508 ::rtl::OUString() );
1509 sal_Int8 nStatusFilterSave = aModelData.CheckFilter( aSelFilterName
);
1510 if ( nStatusFilterSave == STATUS_SAVEAS_STANDARDNAME ) These are
equal during runtime
1511 {
1512 // switch to best filter
1513 bSetStandardName = sal_True; bSetStandardName is set to sal_True
here, but bExit is not, so the loop continuous. Setting bExit following this
line allows the program to save.
++bExit = salTrue;
1514 }
1515 else if ( nStatusFilterSave == STATUS_SAVE )
1516 {
1517 // user confirmed alien filter or "good" filter is used
1518 bExit = sal_True;
1519 }
1520 }
1521 else
1522 bExit = sal_True;
1523 }
Raymond Steele
U-2 Mission Planning
Software Engineer Sr
Lockheed Martin - IS&GS Defense
1300 S. Litchfield Rd.
Goodyear, AZ 85338
Email: raymond.ste...@lmco.com
Business phone: 623-925-6402
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Andre, I think we are going to keep that section commented out for now. We are not sure what to do. Do you think commenting out that section will have a big impact at runtime? We are working on the Save now (described below). From: Andre Fischer [mailto:awf@gmail.com] Sent: Friday, February 07, 2014 2:18 AM To: Steele, Raymond; Andre Fischer; a...@openoffice.apache.org; Herbert Duerr (h...@apache.org); dev@openoffice.apache.org Cc: Meffe, David K Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault On 07.02.2014 00:04, Steele, Raymond wrote: Andre, When we commented out the section below, we were able to get the application to work correctly I would expect subtle errors in the sidebar, like panels not updating after context changes or when switching between application windows. (although it did not let us save a spreadsheet to disk for some reason. Each time we hit okay to save after supplying a unique name, the filechooser closes, but instantly reappears again. It did let us save it as another format, such as .dif). Strange, this change should not modify the saving of the document. That is probably an unrelated problem. However, the application crashes when we replace the lines with: Reference xThis (this, SAL_NO_ACQUIRE); WeakReference xWeakController (xThis); maSidebarControllerContainer.insert( SidebarControllerContainer::value_type( rxFrame, xWeakController)); I've attached the stack trace of that crash. It crashes right after the SidebarController destructor on line 177 (which is empty). Stepping from the destructor brings us into boost's checked_delete.hpp and eventually crashes at line 34 "delete x". See attached stack trace. m_RefCount was 3 for us as well. Also strange. All this does not fit together. If the ref count is larger than 0 then the SidebarController should not be deleted. And if it where deleted, then not from Reference<...>::iquery. And boost::scoped_ptr should have no problem deleting the control (I have not enough information to say which one it is). All controls are created in the initializer of the constructor and should be fully created and initialized by the time the crash is triggered. All this looks like the actual problem happens earlier, maybe some memory overwrite. Maybe you can use valgrind (or some other memory checker) to see if there is a memory problem? Thanks for taking the time to look into this, we are grateful. Would you happen to be located in the U.S.? No problem. I am a little worried that you have discovered a problem that lurks on all platforms and Solaris is the only one where it leads to an actual crash. And, no, I am not located in the US. I am in Germany. -Andre From: Andre Fischer [mailto:awf@gmail.com] Sent: Thursday, February 06, 2014 2:03 AM To: Steele, Raymond; a...@openoffice.apache.org<mailto:a...@openoffice.apache.org>; Herbert Duerr (h...@apache.org<mailto:h...@apache.org>); dev@openoffice.apache.org<mailto:dev@openoffice.apache.org> Cc: Meffe, David K; awf@gmail.com<mailto:awf@gmail.com> Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault On 05.02.2014 20:02, Steele, Raymond wrote: Andre, We are not seeing any exception before the actual crash. Maybe I am not looking in the right place, but we've been using dbx intercept command to track any. Any other suggestions? Raymond, there a few thing you can do to find out if this is a local problem (broken in the constructor) or something more fundamental that is possibly caused by an error that happened much earlier. - Comment out the last few lines: /* WeakReference xWeakController (this); maSidebarControllerContainer.insert( SidebarControllerContainer::value_type( rxFrame, xWeakController)); */ That should tell us whether the crash is caused just by storing the weak reference. The sidebar should still work in general but some updates may be lost. - Replace the last few lines by this: Reference xThis (this, SAL_NO_ACQUIRE); WeakReference xWeakController (xThis); maSidebarControllerContainer.insert( SidebarControllerContainer::value_type( rxFrame, xWeakController)); That removes one (of two) acquire calls (I don't know yet why there is a second acquire, after all the purpose of the weak reference is just /not/ to increase the reference count). - Check the value of the reference count of 'SidebarController* this' (in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of the SidebarController constructor is executed. In my case it is 3. -Andre Also, I've attached the stack trace of the first and second notifyContextChangeEvent. They are different. That is OK. They should be different. But the stack trace of the sec
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Andre, When we commented out the section below, we were able to get the application to work correctly (although it did not let us save a spreadsheet to disk for some reason. Each time we hit okay to save after supplying a unique name, the filechooser closes, but instantly reappears again. It did let us save it as another format, such as .dif). However, the application crashes when we replace the lines with: Reference xThis (this, SAL_NO_ACQUIRE); WeakReference xWeakController (xThis); maSidebarControllerContainer.insert( SidebarControllerContainer::value_type( rxFrame, xWeakController)); I've attached the stack trace of that crash. It crashes right after the SidebarController destructor on line 177 (which is empty). Stepping from the destructor brings us into boost's checked_delete.hpp and eventually crashes at line 34 "delete x". See attached stack trace. m_RefCount was 3 for us as well. Thanks for taking the time to look into this, we are grateful. Would you happen to be located in the U.S.? From: Andre Fischer [mailto:awf@gmail.com] Sent: Thursday, February 06, 2014 2:03 AM To: Steele, Raymond; a...@openoffice.apache.org; Herbert Duerr (h...@apache.org); dev@openoffice.apache.org Cc: Meffe, David K; awf@gmail.com Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault On 05.02.2014 20:02, Steele, Raymond wrote: Andre, We are not seeing any exception before the actual crash. Maybe I am not looking in the right place, but we've been using dbx intercept command to track any. Any other suggestions? Raymond, there a few thing you can do to find out if this is a local problem (broken in the constructor) or something more fundamental that is possibly caused by an error that happened much earlier. - Comment out the last few lines: /* WeakReference xWeakController (this); maSidebarControllerContainer.insert( SidebarControllerContainer::value_type( rxFrame, xWeakController)); */ That should tell us whether the crash is caused just by storing the weak reference. The sidebar should still work in general but some updates may be lost. - Replace the last few lines by this: Reference xThis (this, SAL_NO_ACQUIRE); WeakReference xWeakController (xThis); maSidebarControllerContainer.insert( SidebarControllerContainer::value_type( rxFrame, xWeakController)); That removes one (of two) acquire calls (I don't know yet why there is a second acquire, after all the purpose of the weak reference is just /not/ to increase the reference count). - Check the value of the reference count of 'SidebarController* this' (in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of the SidebarController constructor is executed. In my case it is 3. -Andre Also, I've attached the stack trace of the first and second notifyContextChangeEvent. They are different. That is OK. They should be different. But the stack trace of the second call looks broken. The top two frames (notifyContextChangeEvent being called from Reference constructor) indicate that something is very wrong, like the vtable overwritten or not fully created. One explanation (although I cannot say how probable that is) could be that the Solaris compiler has not fully created/initialized the vtable in the constructor. Raymond From: Steele, Raymond Sent: Wednesday, February 05, 2014 9:48 AM To: 'a...@openoffice.apache.org<mailto:a...@openoffice.apache.org>'; Herbert Duerr (h...@apache.org<mailto:h...@apache.org>); dev@openoffice.apache.org<mailto:dev@openoffice.apache.org> Cc: Meffe, David K; 'awf@gmail.com<mailto:awf@gmail.com>' Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault Hi Andre, Thanks for the response. We are looking at that now. In the constructor of SidebarController at line 168 "WeakReference...", on your system, does the code step to Reference.h: Line 359 - XInterface operator, as it does during our run? It appears that at runtime Reference.hxx: Line 136 - _pInterface->acquire() that occurs after "WeakReference.." does not execute as it does after addContextChangeEventListener a few lines above WeakReference. Do you see a similar behavior? Can you provide the first 5-10 steps your code takes after WeakReference (line 168)? Here are the requested frames >cppuhelper3MSC.dll!cppu::OWeakObject::acquire() Line 204C++ cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire() Line 236 + 0x9 bytesC++ sfx.dll!cppu::WeakComponentImplHelper4::acquire() Line 70 + 0xc bytesC++ sfx.dll!com::sun::star::uno::Reference::Reference(sfx2::sidebar::SidebarController * pInterface) Line 136 + 0x12 bytesC++ sfx.dll!sfx2::sideba
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Andre, We are not seeing any exception before the actual crash. Maybe I am not looking in the right place, but we've been using dbx intercept command to track any. Any other suggestions? Also, I've attached the stack trace of the first and second notifyContextChangeEvent. They are different. Raymond From: Steele, Raymond Sent: Wednesday, February 05, 2014 9:48 AM To: 'a...@openoffice.apache.org'; Herbert Duerr (h...@apache.org); dev@openoffice.apache.org Cc: Meffe, David K; 'awf@gmail.com' Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault Hi Andre, Thanks for the response. We are looking at that now. In the constructor of SidebarController at line 168 "WeakReference...", on your system, does the code step to Reference.h: Line 359 - XInterface operator, as it does during our run? It appears that at runtime Reference.hxx: Line 136 - _pInterface->acquire() that occurs after "WeakReference.." does not execute as it does after addContextChangeEventListener a few lines above WeakReference. Do you see a similar behavior? Can you provide the first 5-10 steps your code takes after WeakReference (line 168)? Thanks! Raymond From: Steele, Raymond Sent: Tuesday, February 04, 2014 3:59 PM To: a...@openoffice.apache.org<mailto:a...@openoffice.apache.org>; Herbert Duerr (h...@apache.org<mailto:h...@apache.org>); dev@openoffice.apache.org<mailto:dev@openoffice.apache.org> Cc: Meffe, David K Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault Herbert, Raymond and I have been using the dbx debugger feature of Solaris Studio 12.3 with an equivalent throw/catch feature (intercept/whocatches) and have found that the cases where we tried to intercept exceptions, they were unhandled. This includes inside the SidebarController where we have tracked the problem origination. We have stepped through the code multiple times and while we have found that the problem originates in the SidebarController, we cannot explain how it happens. Using the debug tool we see that the SidebarController constructor doesn't complete because the segmentation fault occurs when the notifyContextChangeEvent is called a second time. The first time it is called it is located in the addContextChangeEventListener where it appears to work as expected, even the acquire function appears to call the ContextChangeEventMultiplexer without any errors. The following lines are what we see as we step-by-step through the execution of the SidebarController.cxx constructor when we select the Spreadsheet or the Text Document. The first time the notifyContextChangeEvent is called: SidebarController: Line 147 - addContextChangeEventListener is called Reference.h: Line 359 - XInterface operator -> is called Reference.h: Line 217 - castFromXInterface is called Reference.hxx: Line 134 - castToXInterface is called Reference.h: Line 232 - function castToXInterface Reference.hxx: Line 135 - if(_pInterface) Reference.hxx: Line 136 - _pInterface->acquire(); compbase4.hxx: Line 70- WeakComponentHelperBase::acquire prototype implbase.hxx: Line 236 - WeakObject::acquire definition - ContextChangeEventMultiplexer receives and processes event. - In ContextChangeEventMultiplexer addContextChangeEventListener adds and calls the notifyContextChangeEvent - SidebarController::notifyContextChangeEvent: Line 257 is called. The rEvent associated with the notifyContextChangeEvent is a valid address - The rEvent STRUCT contains the application name and context name references Context.cxx: Line 51 - msContext(rsContext) ustring.hxx: Line103 - pData = str.pData - Processing continues as normal from this point till line 168 of SidebarController.cxx The second time the notifyContextChangeEvent is called: SidebarController: Line 168 - the xWeakController(this) is called Reference.hxx: Line 134 - castToXInterface is called Reference.h: Line 232 - function castToXInterface Reference.hxx: Line 135 - if(_pInterface) Reference.hxx: Line 136 - _pInterface->acquire(); (Why does this not behave like the first call above? Should there be a call to WeakComponentHelperBase::acuire? The next step appears to skip all these procedures.) SidebarController::notifyContextChangeEvent: Line 257 is called, the rEvent is pointing to a reference that cannot be accessed. - The dbx dump has an rEvent = STRUCT - The dbx print of the rEvent says that it is referenced through a nil pointer Context.cxx: Line 51 - msContext(rsContext) ustring.hxx: Line103 - pData = str.pData - Accessing the pData in the string has been corrupted and causes the following Segmentation Fault: - Signal SEGV(no mapping at the fault address) in rtl::OUString::OUString at line 10
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Hi Andre, Thanks for the response. We are looking at that now. In the constructor of SidebarController at line 168 "WeakReference...", on your system, does the code step to Reference.h: Line 359 - XInterface operator, as it does during our run? It appears that at runtime Reference.hxx: Line 136 - _pInterface->acquire() that occurs after "WeakReference.." does not execute as it does after addContextChangeEventListener a few lines above WeakReference. Do you see a similar behavior? Can you provide the first 5-10 steps your code takes after WeakReference (line 168)? Thanks! Raymond From: Steele, Raymond Sent: Tuesday, February 04, 2014 3:59 PM To: a...@openoffice.apache.org; Herbert Duerr (h...@apache.org); dev@openoffice.apache.org Cc: Meffe, David K Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault Herbert, Raymond and I have been using the dbx debugger feature of Solaris Studio 12.3 with an equivalent throw/catch feature (intercept/whocatches) and have found that the cases where we tried to intercept exceptions, they were unhandled. This includes inside the SidebarController where we have tracked the problem origination. We have stepped through the code multiple times and while we have found that the problem originates in the SidebarController, we cannot explain how it happens. Using the debug tool we see that the SidebarController constructor doesn't complete because the segmentation fault occurs when the notifyContextChangeEvent is called a second time. The first time it is called it is located in the addContextChangeEventListener where it appears to work as expected, even the acquire function appears to call the ContextChangeEventMultiplexer without any errors. The following lines are what we see as we step-by-step through the execution of the SidebarController.cxx constructor when we select the Spreadsheet or the Text Document. The first time the notifyContextChangeEvent is called: SidebarController: Line 147 - addContextChangeEventListener is called Reference.h: Line 359 - XInterface operator -> is called Reference.h: Line 217 - castFromXInterface is called Reference.hxx: Line 134 - castToXInterface is called Reference.h: Line 232 - function castToXInterface Reference.hxx: Line 135 - if(_pInterface) Reference.hxx: Line 136 - _pInterface->acquire(); compbase4.hxx: Line 70- WeakComponentHelperBase::acquire prototype implbase.hxx: Line 236 - WeakObject::acquire definition - ContextChangeEventMultiplexer receives and processes event. - In ContextChangeEventMultiplexer addContextChangeEventListener adds and calls the notifyContextChangeEvent - SidebarController::notifyContextChangeEvent: Line 257 is called. The rEvent associated with the notifyContextChangeEvent is a valid address - The rEvent STRUCT contains the application name and context name references Context.cxx: Line 51 - msContext(rsContext) ustring.hxx: Line103 - pData = str.pData - Processing continues as normal from this point till line 168 of SidebarController.cxx The second time the notifyContextChangeEvent is called: SidebarController: Line 168 - the xWeakController(this) is called Reference.hxx: Line 134 - castToXInterface is called Reference.h: Line 232 - function castToXInterface Reference.hxx: Line 135 - if(_pInterface) Reference.hxx: Line 136 - _pInterface->acquire(); (Why does this not behave like the first call above? Should there be a call to WeakComponentHelperBase::acuire? The next step appears to skip all these procedures.) SidebarController::notifyContextChangeEvent: Line 257 is called, the rEvent is pointing to a reference that cannot be accessed. - The dbx dump has an rEvent = STRUCT - The dbx print of the rEvent says that it is referenced through a nil pointer Context.cxx: Line 51 - msContext(rsContext) ustring.hxx: Line103 - pData = str.pData - Accessing the pData in the string has been corrupted and causes the following Segmentation Fault: - Signal SEGV(no mapping at the fault address) in rtl::OUString::OUString at line 103 in file ustring.hxx We are trying to do our due diligence on this problem and we have been investigating it as best we can, but we are lacking in knowledge that the community can provide, which is why we are seeking help. Also the errors don't seem to make sense, so we believe we are dealing with a bug. We hope we are not being an inconvenience, and we definitely appreciate the help. We are investigating alternatives, but would really like to get this to work. Our current applications use OpenOffice extensively. Since we had to move to Solaris 11, we are forced to get this working or find another solution, which we'd rather not pursue. Hopefully you or a member of the community can help us make some
RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Herbert, Raymond and I have been using the dbx debugger feature of Solaris Studio 12.3 with an equivalent throw/catch feature (intercept/whocatches) and have found that the cases where we tried to intercept exceptions, they were unhandled. This includes inside the SidebarController where we have tracked the problem origination. We have stepped through the code multiple times and while we have found that the problem originates in the SidebarController, we cannot explain how it happens. Using the debug tool we see that the SidebarController constructor doesn't complete because the segmentation fault occurs when the notifyContextChangeEvent is called a second time. The first time it is called it is located in the addContextChangeEventListener where it appears to work as expected, even the acquire function appears to call the ContextChangeEventMultiplexer without any errors. The following lines are what we see as we step-by-step through the execution of the SidebarController.cxx constructor when we select the Spreadsheet or the Text Document. The first time the notifyContextChangeEvent is called: SidebarController: Line 147 - addContextChangeEventListener is called Reference.h: Line 359 - XInterface operator -> is called Reference.h: Line 217 - castFromXInterface is called Reference.hxx: Line 134 - castToXInterface is called Reference.h: Line 232 - function castToXInterface Reference.hxx: Line 135 - if(_pInterface) Reference.hxx: Line 136 - _pInterface->acquire(); compbase4.hxx: Line 70- WeakComponentHelperBase::acquire prototype implbase.hxx: Line 236 - WeakObject::acquire definition - ContextChangeEventMultiplexer receives and processes event. - In ContextChangeEventMultiplexer addContextChangeEventListener adds and calls the notifyContextChangeEvent - SidebarController::notifyContextChangeEvent: Line 257 is called. The rEvent associated with the notifyContextChangeEvent is a valid address - The rEvent STRUCT contains the application name and context name references Context.cxx: Line 51 - msContext(rsContext) ustring.hxx: Line103 - pData = str.pData - Processing continues as normal from this point till line 168 of SidebarController.cxx The second time the notifyContextChangeEvent is called: SidebarController: Line 168 - the xWeakController(this) is called Reference.hxx: Line 134 - castToXInterface is called Reference.h: Line 232 - function castToXInterface Reference.hxx: Line 135 - if(_pInterface) Reference.hxx: Line 136 - _pInterface->acquire(); (Why does this not behave like the first call above? Should there be a call to WeakComponentHelperBase::acuire? The next step appears to skip all these procedures.) SidebarController::notifyContextChangeEvent: Line 257 is called, the rEvent is pointing to a reference that cannot be accessed. - The dbx dump has an rEvent = STRUCT - The dbx print of the rEvent says that it is referenced through a nil pointer Context.cxx: Line 51 - msContext(rsContext) ustring.hxx: Line103 - pData = str.pData - Accessing the pData in the string has been corrupted and causes the following Segmentation Fault: - Signal SEGV(no mapping at the fault address) in rtl::OUString::OUString at line 103 in file ustring.hxx We are trying to do our due diligence on this problem and we have been investigating it as best we can, but we are lacking in knowledge that the community can provide, which is why we are seeking help. Also the errors don't seem to make sense, so we believe we are dealing with a bug. We hope we are not being an inconvenience, and we definitely appreciate the help. We are investigating alternatives, but would really like to get this to work. Our current applications use OpenOffice extensively. Since we had to move to Solaris 11, we are forced to get this working or find another solution, which we'd rather not pursue. Hopefully you or a member of the community can help us make some headway. We'd appreciate it. Thanks. David Meffe -Original Message- From: Herbert Duerr [mailto:h...@apache.org] Sent: Saturday, February 01, 2014 5:46 AM To: a...@openoffice.apache.org Subject: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault Hi Raymond, most regulars are traveling (and are meeting this weekend at FOSDEM in Brussels). I already recommended the try to find whether any exceptions are thrown (and caught away) during the steps you already debugged. In gdb I'd use the command catch throw to find the throwing code. Maybe there is similar facility in Solaris Studio? Herbert On 31.01.2014 20:27, Steele, Raymond wrote: > Anyone out there? We really need to get this working, but are having a > difficult time. > > From: Steele, Raymond > Sent: Wednesday, January
RE: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Anyone out there? We really need to get this working, but are having a difficult time. From: Steele, Raymond Sent: Wednesday, January 29, 2014 5:11 PM To: dev@openoffice.apache.org; a...@openoffice.apache.org; Herbert Duerr (h...@apache.org) Cc: Meffe, David K Subject: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault We've recently compiled OpenOffice 4.01 on Solaris 11 x86 and are experiencing the following at runtime. I've included some of the stack trace below. Any help would be great. Thanks! 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 "WeakReference WeakController (this);" 6.This template definition for WeakController uses Reference::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 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. It appears as if inside the SidebarController Constructor at line 168 when xWeakController(this) is called that the problem first occurs. The xWeakController appears to be defined in Reference.hxx in /cppu/inc/com/sun/star/uno/ and this definition as an inline function that calls the _pInterface->acquire() at line 136. We assume that this acquire is where the problem occurs because the SidebarController::notifyContextChangeEvent (which is the next item on the stack) rEvent contains an value in the dbxtool (debug tool) immediately following in the stack. It eventually crashes downstream at line 103 of ustring.hxx in /sal/inc/rtl when the string is trying to be accessed as pData = str.pData; Stack Trace: (dbx) where current thread: t@1 =>[1] rtl::OUString::OUString(this = 0xfeff9dac, str = CLASS), line 103 in "ustring.hxx" [2] sfx2::sidebar::Context::Context(this = 0xfeff9dac, rsApplication = CLASS, rsContext = CLASS), line 51 in "Context.cxx" [3] sfx2::sidebar::SidebarController::notifyContextChangeEvent(this = 0xebc6d6b0, rEvent = STRUCT), line 257 in "SideBarController.cxx" [4] com::sun::star::uno::Reference::Reference(this = 0xfeff9f64, pInterface = 0xebc6d6b0), line 136 in "Reference.hxx" [5] sfx2::sidebar::SidebarController::SidebarController(this = 0xebc6d6b0, pParentWindow = 0x9659bf8, rxFrame = CLASS), line 168 in "SidebarController.cxx" I can provide more of the stack trace if needed. Thanks in Advance! Raymond
OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
We've recently compiled OpenOffice 4.01 on Solaris 11 x86 and are experiencing the following at runtime. I've included some of the stack trace below. Any help would be great. Thanks! 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 "WeakReference WeakController (this);" 6.This template definition for WeakController uses Reference::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 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. It appears as if inside the SidebarController Constructor at line 168 when xWeakController(this) is called that the problem first occurs. The xWeakController appears to be defined in Reference.hxx in /cppu/inc/com/sun/star/uno/ and this definition as an inline function that calls the _pInterface->acquire() at line 136. We assume that this acquire is where the problem occurs because the SidebarController::notifyContextChangeEvent (which is the next item on the stack) rEvent contains an value in the dbxtool (debug tool) immediately following in the stack. It eventually crashes downstream at line 103 of ustring.hxx in /sal/inc/rtl when the string is trying to be accessed as pData = str.pData; Stack Trace: (dbx) where current thread: t@1 =>[1] rtl::OUString::OUString(this = 0xfeff9dac, str = CLASS), line 103 in "ustring.hxx" [2] sfx2::sidebar::Context::Context(this = 0xfeff9dac, rsApplication = CLASS, rsContext = CLASS), line 51 in "Context.cxx" [3] sfx2::sidebar::SidebarController::notifyContextChangeEvent(this = 0xebc6d6b0, rEvent = STRUCT), line 257 in "SideBarController.cxx" [4] com::sun::star::uno::Reference::Reference(this = 0xfeff9f64, pInterface = 0xebc6d6b0), line 136 in "Reference.hxx" [5] sfx2::sidebar::SidebarController::SidebarController(this = 0xebc6d6b0, pParentWindow = 0x9659bf8, rxFrame = CLASS), line 168 in "SidebarController.cxx" I can provide more of the stack trace if needed. Thanks in Advance! Raymond
RE: EXTERNAL: Re: loadComponentFromURL - Solaris 11 OO 3.3
Andrew,
Thanks again for taking the time to look at this. I hope someone else can also
provide some input.
Thanks,
Raymond
-Original Message-
From: Andrew Douglas Pitonyak [mailto:and...@pitonyak.org]
Sent: Tuesday, January 21, 2014 8:16 PM
To: Steele, Raymond; a...@openoffice.apache.org
Subject: Re: EXTERNAL: Re: loadComponentFromURL - Solaris 11 OO 3.3
No worries regarding the confusion, language is generally imprecise :-)
Disclaimer: I have never used Java to manipulate OO.
That said, your explanation sounds plausible, and my mostly uninformed opinion
is that you are correct. Hopefully another more familiar person can provide a
workable solution.
On 01/21/2014 02:03 PM, Steele, Raymond wrote:
> Thanks for the reply and I apologize about the confusion. If I use
> OpenOffice as a regular user, the applications work just find (i.e. writer,
> database, etc.), but if I attempt to run any code that I've written in Java
> that uses the loadComponentFromURL method, the application crashes with the
> below stack trace. Also, compiling and running of FirstLoadComponent.java
> located in sdk/examples/DevelopersGuide/FirstSteps results in the same.If
> I install OpenOffice 3.3 on a Solaris 10, not Solaris 11 as in this case, the
> applications run fine. I presume there is a conflict with the libraries.
> Specifically, the libxml.so.2 libraries, which already exist in my /usr/lib
> (installed by other Solaris applications). It appears that OpenOffice
> requires the libxml.so.2 located within the /opt/openoffice.org directories
> instead of the one installed by the Solaris apps. If I change my
> LD_LIBRARY_PATH to include the one openoffice requires, I then get other
> library references out of sync.
>
> Raymond
> -Original Message-
> From: Andrew Douglas Pitonyak [mailto:and...@pitonyak.org]
> Sent: Tuesday, January 21, 2014 6:49 AM
> To: a...@openoffice.apache.org; Steele, Raymond
> Subject: EXTERNAL: Re: loadComponentFromURL - Solaris 11 OO 3.3
>
> Given all of the lists that you copied, I assumed that you were not
> subscribed so I copied you directly. Please respond to the list rather than
> me directly so that others will see your response...
>
> On 01/15/2014 07:00 PM, Steele, Raymond wrote:
>> Hello,
>>
>> I have OpenOffice 3.3 installed and running on my Solaris x86 system.
>> Things run under normal user experience, but if I run a custom
>> application it fails on
>>
>> loadComponentFromURL("private:factory/scalc", "_blank, 0, loadProps).
>>
>> This code works fine on a Solaris 10 system running OO 3.3. Here is some of
>> the stack trace that java produces.
> I am unclear on what you are saying since you say things like "this code
> works fine" and "here is a stack trace". Are you saying:
>
> (1) You have code that works on one computer but not on another
>
> (2) "this code always fails"
>
> If (1), then there is a problem with your installation or a bug in OOo.
> If (2), your code is probably wrong.
>
> What language did you use? Basic, Java, C++? My guess is Basic, but your
> claimed error seems wrong for that.
>
> If (1) then there is probably a problem in Java version, linked libraries, or
> similar.
>
> If (2), have you tried a simple version written in Basic? Can you show a few
> lines before and after the one line that causes the problem. This is not even
> an entire line of code (since loadComponentFromURL is a method on the desktop
> object). Would be nice to see how loadProps is declared and what it contains.
>
>
>
>> Register to memory mapping:
>>
>> EAX=0x090bbe40 is an unknown value
>> EBX=0xfe762000: _GLOBAL_OFFSET_TABLE_+0 in /libc.so.1 at 0xfe60
>>
>> Stack [oxddc51, 0xddd4f000], sp=0xddd4c520, free space=1005k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
>> code)
>> C [libc.so.1] t_delete+0x41
>> C [libc.so.1] realfree+0x5e
>> C [libc.so.1] _malloc_unlocked+0x1d2
>> C [libc.so.1] malloc+0x38
>> C [libxml2.so.2] xmlXPathNewParserContext+0x28
>> C [libxml2.so.2] xmlXPathEval+0x92
>> C [libunoxml.so+0x81131]
>>
>>
>> Any help would be greatly appreciated. Also, I had to type this stack trace
>> so I only provided what I thought was pertinent. Please let me know if you
>> need more.
>>
>> Thanks,
>> Raymond Steele
>>
>>
> --
> Andrew Pitonyak
> My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
> Info: http://www.pitonyak.org/oo.php
>
>
--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info: http://www.pitonyak.org/oo.php
-
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 .
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 "WeakReference
> WeakController (this);"
> 6.This template definition for WeakController uses
> Reference::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 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 "WeakReference WeakController (this);" 6. This template definition for WeakController uses Reference::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 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
loadComponentFromURL - Solaris 11 OO 3.3
Hello,
I have OpenOffice 3.3 installed and running on my Solaris x86 system. Things
run under normal user experience, but if I run a custom application it fails on
loadComponentFromURL("private:factory/scalc", "_blank, 0, loadProps).
This code works fine on a Solaris 10 system running OO 3.3. Here is some of
the stack trace that java produces.
Register to memory mapping:
EAX=0x090bbe40 is an unknown value
EBX=0xfe762000: _GLOBAL_OFFSET_TABLE_+0 in /libc.so.1 at 0xfe60
Stack [oxddc51, 0xddd4f000], sp=0xddd4c520, free space=1005k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libc.so.1] t_delete+0x41
C [libc.so.1] realfree+0x5e
C [libc.so.1] _malloc_unlocked+0x1d2
C [libc.so.1] malloc+0x38
C [libxml2.so.2] xmlXPathNewParserContext+0x28
C [libxml2.so.2] xmlXPathEval+0x92
C [libunoxml.so+0x81131]
Any help would be greatly appreciated. Also, I had to type this stack trace so
I only provided what I thought was pertinent. Please let me know if you need
more.
Thanks,
Raymond Steele
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_ref >>::auto_ptr_ref::_TypeU>(std::auto_ptr, const std::auto_ptr_ref *) needed in std::auto_ptr_ref > ::operator std::auto_ptr_ref> >>() " 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 ParagraphData&ParagraphData::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 . 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 > 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 . 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 reviewe
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_ref >>::auto_ptr_ref::_TypeU>(std::auto_ptr, const std::auto_ptr_ref *) needed in std::auto_ptr_ref > ::operator std::auto_ptr_ref> >>() " 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 ParagraphData&ParagraphData::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 . 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 > 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 . 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 s
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_ref >>::auto_ptr_ref::_TypeU>(std::auto_ptr, const std::auto_ptr_ref *) needed in std::auto_ptr_ref > ::operator std::auto_ptr_ref> >>() " 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 ParagraphData&ParagraphData::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 . 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 > 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 . 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&
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 ParagraphData&ParagraphData::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 . 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 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 . 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 > "ParagraphData&ParagraphData::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 chec
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 "ParagraphData&ParagraphData::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
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
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
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
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 . 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 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 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 . 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 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 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, 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 . 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 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 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 . 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 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 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 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 located in systemstl/tr1 did. Our > Makefile flags are set to include the stdcxx4 instead of the > systemstl/tr1 . To get around this we modified > namedvaluecollection.cxx: > > #if defined(__SUNPRO_CC) > #include "../systemstl/tr1/functional" > #esle >#include > #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 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 located in systemstl/tr1 did. Our > Makefile flags are set to include the stdcxx4 instead of the > systemstl/tr1 . To get around this we modified > namedvaluecollection.cxx: > > #if defined(__SUNPRO_CC) > #include "../systemstl/tr1/functional" > #esle >#include > #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
For select1st, we noticed that the header delivered with stdcxx4 did not define select1st, but the aoo delivered located in systemstl/tr1 did. Our Makefile flags are set to include the stdcxx4 instead of the systemstl/tr1 . To get around this we modified namedvaluecollection.cxx: #if defined(__SUNPRO_CC) #include "../systemstl/tr1/functional" #esle #include #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::map::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=revision&revision=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::map::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=revision&revision=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
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::map::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=revision&revision=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 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::map::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::get boost::tuples::TT>(constboost::tuples::tuple 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_tuple(configmgr::Partial::Node*, > constboost::tuples::tuple 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_tuple(configmgr::Partial::Node*, > constboost::tuples::tuple 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_map boost::hash,_STL::equal_to, > _STL::allocator<_STL::pair 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
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::get boost::tuples::TT>(constboost::tuples::tuple 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_tuple(configmgr::Partial::Node*, > constboost::tuples::tuple 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_tuple(configmgr::Partial::Node*, > constboost::tuples::tuple 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_map boost::hash,_STL::equal_to, > _STL::allocator<_STL::pair 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
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::get(constboost::tuples::tuple) needed inboost::unordered::detail::construct_from_tuple(configmgr::Partial::Node*, constboost::tuples::tuple&). "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where: While instantiating"boost::unordered::detail::construct_from_tuple(configmgr::Partial::Node*, constboost::tuples::tuple&)". "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where: Instantiated from boost::unordered::unordered_map,_STL::equal_to, _STL::allocator<_STL::pair>>::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
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::get(constboost::tuples::tuple)
needed
inboost::unordered::detail::construct_from_tuple(configmgr::Partial::Node*,
constboost::tuples::tuple&).
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where:
While
instantiating"boost::unordered::detail::construct_from_tuple(configmgr::Partial::Node*,
constboost::tuples::tuple&)".
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where:
Instantiated from
boost::unordered::unordered_map,_STL::equal_to,
_STL::allocator<_STL::pair>>::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::pair const
insertion(
-rData.m_addresses.insert(pObj) );
-DEBUGBASE_ENSURE( insertion.second, "### insertion failed!?" );
-static_cast(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::pair const
insertion(
-rData.m_addresses.insert(pObj) );
-DEBUGBASE_ENSURE( insertion.second, "### insertion failed!?" );
-static_cast(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::pair const
insertion(
-rData.m_addresses.insert(pObj) );
-DEBUGBASE_ENSURE( insertion.second, "### insertion failed!?" );
-static_cast(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, 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
