[dev] openOffice-3.3.0 ?
Hello, I am Simona PASCA, sorry to bother you, I have some questions if you could help me. I need to install openOffice-3.3.0 on Sparc-solaris2.8 machine; I have downloaded some source of openOffice-3.3.0 tool from http://download.openoffice.org/other.html site , but in my installation I need to change the way to the installation path. I saw that the defaultdir for openoffice is /opt , but I really need to change this location to another one. Could you please help me with this information's and tell me which is the method to change the installation path to openOffice-3.3.0 tool , on a sparc-solaris2.8 machine ? Thank you, Best regards, Simona PASCA -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: does anybody still use tcsh to build OOo?
On 08.04.2011 14:22, Christian Lohmaier wrote: On Thu, Apr 7, 2011 at 9:47 AM, Mathias Bauernospamfor...@gmx.de wrote: Hi, AFAIK tcsh doesn't work anymore anyway - using tcsh as the shell used *by* the build: yes. But the environment files are for the user's shell, and there it would still work. Months ago I worked on that but then got in serious merge conflicts as somebody else did some refactoring in configure.in. So I just abandoned that work. AFAIR the fix was quite annoying work as the generation of the scripts is scattered over the code. configure has nothing to do with it, as it is generated by set_soenv[.in] Yes and no. The support for with-use-shell is in configure and that's where I started. OTOH it's possible that it was set_soenv.in where large changes kept me from continuing. I don't remember exactly. Nevertheless, configure doesn't support --with-use-shell anymore since quite some time. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: How to find out whether the installed OOo is 32- or 64-bit
Hi, Hi there, for an installation routine it is necessary to determine whether the installed version of OOo is 32- or 64-bit, as this determines which libraries and configuration should be installed. Is there a way to find that out (currently on Linux, but once MacOSX and/or Windows gain 64-bit versions then the request would be for all platforms)? If so, what would be the correct means? For Windows you can use ProcessExplorer (a task manager alternative). See http://technet.microsoft.com/en-us/sysinternals/bb896653 When you have selected a process open the 'Properties' entry in the context menu and go to the 'Image' tab. There it is listed. I don't know about the other platforms. Google will probably know though. ^_- Thomas -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: How to find out whether the installed OOo is 32- or 64-bit
On 04/09/11 11:27, Rony G. Flatscher wrote: for an installation routine it is necessary to determine whether the installed version of OOo is 32- or 64-bit, as this determines which libraries and configuration should be installed. Is there a way to find that out (currently on Linux, but once MacOSX and/or Windows gain 64-bit versions then the request would be for all platforms)? If so, what would be the correct means? Using the file command on .../program/soffice.bin (Linux) or .../program/soffice (Mac OS X) should mention either 32 or 64 somewhere in its output (which is not specified, so this is with a little luck---also note that at least Mac OS X could also have universal binaries where file would mention both 32 and 64). -Stephan -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: openOffice-3.3.0 ?
On 11/04/2011 08:16, Simona Pasca wrote: I need to install openOffice-3.3.0 on Sparc-solaris2.8 machine; please note that since OOo 3.0 only Solaris 10 or newer are supported. on older Solaris versions you should expect problems. please either use OOo 2.4, or upgrade to Solaris 10. -- The metric system is the tool of the devil! My car gets forty rods to the hogshead and that's the way I likes it! -- Abe Simpson -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: openOffice-3.3.0 ?
And if I try to install OOo 2.4 on Sparc-solaris2.8 machine , which is the way to change the way to the installation path , not to use the default one ? Thank you. - On 11/04/2011 12:14, Michael Stahl wrote: On 11/04/2011 08:16, Simona Pasca wrote: I need to install openOffice-3.3.0 on Sparc-solaris2.8 machine; please note that since OOo 3.0 only Solaris 10 or newer are supported. on older Solaris versions you should expect problems. please either use OOo 2.4, or upgrade to Solaris 10. -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: How to find out whether the installed OOo is 32- or 64-bit
Dear Stephan and Thomas, thank you for your pointers! On 11.04.2011 09:54, Stephan Bergmann wrote: On 04/09/11 11:27, Rony G. Flatscher wrote: for an installation routine it is necessary to determine whether the installed version of OOo is 32- or 64-bit, as this determines which libraries and configuration should be installed. Is there a way to find that out (currently on Linux, but once MacOSX and/or Windows gain 64-bit versions then the request would be for all platforms)? If so, what would be the correct means? Using the file command on .../program/soffice.bin (Linux) or .../program/soffice (Mac OS X) should mention either 32 or 64 somewhere in its output (which is not specified, so this is with a little luck---also note that at least Mac OS X could also have universal binaries where file would mention both 32 and 64). What I would be after would be to get this information at installation time without any user-interaction (most won't know what would be asked) in a platform independent manner. Something equivalent to a hyptohetic uninfo bitness returning either 32, 64 or 32 64 (if a universal binary). Regards ---rony P.S.: file is usually not installed on Windows, nor the sysinternal utilities like ProcessExplorer. -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: How to find out whether the installed OOo is 32- or 64-bit
On 04/11/11 12:24, rony wrote: What I would be after would be to get this information at installation time without any user-interaction (most won't know what would be asked) in a platform independent manner. Something equivalent to a hyptohetic uninfo bitness returning either 32, 64 or 32 64 (if a universal binary). I don't think there is something better than inspecting the binaries with platform specific tools right now. Internally, of course, OOo knows what platform (x86 Linux, x64 Linux, x86 Mac OS X, etc.) it is---this is at least needed when filtering out extension material that is not appropriate for the given platform. (Also, the standard ways to interact with an OOo installation is either via UNO, which abstracts over those platform details, or through extensions, which already support platform differences.) -Stephan -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Problems building DEV300_m105
I am having some problems building DEV300_m105 on Cygwin. Here is my configure: configure=--with-lang=is --with-vendor=OpenOffice.is --with-build-version=Build by OpenOffice.is --disable-activex --disable-directx --disable-atl --disable-build-mozilla --disable-nss-module --without-junit --with-cl-home=/cygdrive/C/Program Files/Microsoft Visual Studio 9.0/VC --with-ant-home=/cygdrive/c/winapps/java/ant --with-frame-home=/cygdrive/C/Program Files/Microsoft SDKs/Windows/v6.1 --with-psdk-home=/cygdrive/C/Program Files/Microsoft SDKs/Windows/v6.1 --with-midl-path=/cygdrive/C/Program Files/Microsoft SDKs/Windows/v6.1/Bin --with-asm-home=/cygdrive/C/Program Files/Microsoft Visual Studio 9.0/VC/Bin --with-jdk-home=/cygdrive/C/Winapps/java/jdk16 --with-csc-path=/cygdrive/C/WINDOWS/Microsoft.NET/Framework/v3.5 And here is the problem building glib: Kristj¦n@kristjan /cygdrive/c/Backup/OpenOffice/ooo/glib $ dmake mkdir: cannot create directory `./wntmsci12.pro/misc/build/glib-2.28.1/': File e xists Microsoft (R) Program Maintenance Utility Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. /usr/bin/cp glib/glibconfig.h.win32 glib/glibconfig.h The system cannot find the path specified. NMAKE : fatal error U1077: '' : return code '0x1' Stop. dmake: Error code 2, while making './ wntmsci12.pro/misc/build/so_built_so_glib' I don't get what the error is because the file glib/glibconfig.h.win32 does exist. -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Problems building DEV300_m105
Hi Kristjan, In message [dev] Problems building DEV300_m105, Kristj疣_Bjarni_Gu〓undsson wrote... I don't get what the error is because the file glib/glibconfig.h.win32 does exist. The build target is wrongly specified as glibconfig.h, not glib/glibconfig.h and the build command is in posix abs path that cannot be used with nmake. Please take a look at the issue. http://openoffice.org/bugzilla/show_bug.cgi?id=117792 Regards, Takashi Ono (t...@openoffice.org) -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: How to find out whether the installed OOo is 32- or 64-bit
On 11.04.2011 13:16, Stephan Bergmann wrote: On 04/11/11 12:24, rony wrote: What I would be after would be to get this information at installation time without any user-interaction (most won't know what would be asked) in a platform independent manner. Something equivalent to a hyptohetic uninfo bitness returning either 32, 64 or 32 64 (if a universal binary). I don't think there is something better than inspecting the binaries with platform specific tools right now. Internally, of course, OOo knows what platform (x86 Linux, x64 Linux, x86 Mac OS X, etc.) it is---this is at least needed when filtering out extension material that is not appropriate for the given platform. (Also, the standard ways to interact with an OOo installation is either via UNO, which abstracts over those platform details, or through extensions, which already support platform differences.) It seems that this is some sort of a chicken and egg problem. E.g. on MacOSX: if one uses Java to query the configuration via UNO, it may be the case that 64-bit Java is used instead of a 32-bit Java when getting in touch with OOo/UNO, which may be a 32-bit (and sometimes in the future) a 64-bit implementation or both (universal binary). If using the wrong bitness combination, i.e. 64-bit Java with 32-bit OOo/UNO (or 32-bit Java with 64-bit OOo/UNO), then an error would occur? (E.g., how about trying it out and if an error comes along one can infer that the wrong bitness was used; but then, if wrong bitnesses are playing a role, is it possible that a crash occurs, which could not be intercepted? ) If no crash is to be expected, what configuration service/path should I use to figure out the architecture/memory model? (Didn't find anything in the schema Setup.xcs nor in Setup-brand.cxu.) Or with other words, is there an XML-file that carries this information, and if so what is its name and element (this would be even easier to analyze without the need to directyl interact with UNO). ---rony -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Problems building DEV300_m105
Hi, possibly the patch attached to issue 117792 can help with that. It replaces the use of cp with copy. http://openoffice.org/bugzilla/show_bug.cgi?id=117792 Kind regards, pl On 11.04.11 14:27, Kristján Bjarni Guðmundsson wrote: I am having some problems building DEV300_m105 on Cygwin. Here is my configure: configure=--with-lang=is --with-vendor=OpenOffice.is --with-build-version=Build by OpenOffice.is --disable-activex --disable-directx --disable-atl --disable-build-mozilla --disable-nss-module --without-junit --with-cl-home=/cygdrive/C/Program Files/Microsoft Visual Studio 9.0/VC --with-ant-home=/cygdrive/c/winapps/java/ant --with-frame-home=/cygdrive/C/Program Files/Microsoft SDKs/Windows/v6.1 --with-psdk-home=/cygdrive/C/Program Files/Microsoft SDKs/Windows/v6.1 --with-midl-path=/cygdrive/C/Program Files/Microsoft SDKs/Windows/v6.1/Bin --with-asm-home=/cygdrive/C/Program Files/Microsoft Visual Studio 9.0/VC/Bin --with-jdk-home=/cygdrive/C/Winapps/java/jdk16 --with-csc-path=/cygdrive/C/WINDOWS/Microsoft.NET/Framework/v3.5 And here is the problem building glib: Kristj¦n@kristjan /cygdrive/c/Backup/OpenOffice/ooo/glib $ dmake mkdir: cannot create directory `./wntmsci12.pro/misc/build/glib-2.28.1/ http://wntmsci12.pro/misc/build/glib-2.28.1/': File e xists Microsoft (R) Program Maintenance Utility Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. /usr/bin/cp glib/glibconfig.h.win32 glib/glibconfig.h The system cannot find the path specified. NMAKE : fatal error U1077: '' : return code '0x1' Stop. dmake: Error code 2, while making './wntmsci12.pro/misc/build/so_built_so_glib http://wntmsci12.pro/misc/build/so_built_so_glib' I don't get what the error is because the file glib/glibconfig.h.win32 does exist. -- http://www.oracle.com/ Philipp Lohmann | Software engineer OracleOpen Office Development ORACLE Deutschland B.V. Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven http://www.oracle.com/commitment Oracle is committed to developing practices and products that help protect the environment -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: How to find out whether the installed OOo is 32- or 64-bit
On 04/11/11 14:42, rony wrote: On 11.04.2011 13:16, Stephan Bergmann wrote: On 04/11/11 12:24, rony wrote: What I would be after would be to get this information at installation time without any user-interaction (most won't know what would be asked) in a platform independent manner. Something equivalent to a hyptohetic uninfo bitness returning either 32, 64 or 32 64 (if a universal binary). I don't think there is something better than inspecting the binaries with platform specific tools right now. Internally, of course, OOo knows what platform (x86 Linux, x64 Linux, x86 Mac OS X, etc.) it is---this is at least needed when filtering out extension material that is not appropriate for the given platform. (Also, the standard ways to interact with an OOo installation is either via UNO, which abstracts over those platform details, or through extensions, which already support platform differences.) It seems that this is some sort of a chicken and egg problem. E.g. on MacOSX: if one uses Java to query the configuration via UNO, it may be the case that 64-bit Java is used instead of a 32-bit Java when getting in touch with OOo/UNO, which may be a 32-bit (and sometimes in the future) a 64-bit implementation or both (universal binary). Right, when you want to use the OOo's URE to set up a UNO connection to OOo, you easily run into this chicken/egg problem. If no crash is to be expected, what configuration service/path should I use to figure out the architecture/memory model? (Didn't find anything in the schema Setup.xcs nor in Setup-brand.cxu.) Or with other words, is there an XML-file that carries this information, and if so what is its name and element (this would be even easier to analyze without the need to directyl interact with UNO). Jochen (now on CC) should know how OOo's extension manager determines the current platform. -Stephan -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: build.pl debug=1 for sw and svx
On 08.04.2011 11:19, Michael Stahl wrote: On 07/04/2011 10:05, Mathias Bauer wrote: On 06.04.2011 19:47, Michael Stahl wrote: On 06/04/2011 18:45, tora - Takamichi Akiyama wrote: Hello Christian, On 2011/04/06 20:55, Christian Lippka wrote: While Niklas and Daniel are absolutely right, make clean may not always be what you want. For example, if you just want to rebuild svx with debug and do a make -sr clean, your next make in sw module would rebuild a lot of stuff, since all dependency to svx would fire. actually, for a module like svx it shouldn't rebuild any cxx files in dependent modules (which takes up most of the time), because gbuild will preserve the timestamp of the original file when delivering. of course if headers are *generated*, then dependent cxx files will be rebuilt. hmm... on second thought, if you actually use the top-level makefile, then probably the cxx files will be rebuilt in this case... :( If in this case means: if there are generated headers, this is true. no, i mean for ordinary headers that are just copied. (that generated headers cause rebuild is really obvious...) for headers that are just copied, GNU make will consider the target in the outdir outdated, because, well, it doesn't exist, and will copy the header to the outdir. Ah, I see. I just overlooked that you talked about build after make clean. Sorry. of course the right question here is, why the hell are we copying all those headers? it seems pointless to me: they could just as well be included from the source directory instead of from the solver. I agree. OTOH this would be a huge change. The current way we include our headers from outside the current module assumes that they reside in a common root folder. If we took them from their location in the source directory, we either had to move all currently delivered header files into a common source directory or we had to change all include statements (e.g. from #include sfx2/objsh.hxx to #include sfx2/inc/sfx2/objsh.hxx. The third option to add all modules to the INCLUDE path is a no-go for performance reasons. There is a fourth, somewhat pragmatic option: add a second clean target that does't remove headers that are only copied but not generated. For those who now start to think that the rebuild caused by a make clean is a bug in the new build system: that's not true. The bug is that we copy header files in the build instead of using them where they are. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
