Hi Eric, all,
some status information on cws macosx20xfixes01 (target PP2).
The cws has been resynced to m146. I executed the following
automatic tests on this cws:
Top10 test: passed
Framework/first.bas: passed
Framework/first/topten.bas: 1 warning
Writer/update/w_updt.bas: passed
Writer/update/ma_updt.bas: passed
Writer/update/ww_updt.bas: passed
Calc/update/c_updt.bas: 1 warning
Chart/update/ch_updt.bas: passed
Graphics/update/d_updt.bas: 2 errors, 5 warnings
Graphics/update/gallery.bas: 1 error, 2 warnings
Graphics/update/gallery2.bas: passed
Graphics/update/i_updt.bas: 2 errors, 2 warnings
Math/update/m_updt.bas: passed
I need to evaluate these results with Joerg Sievers next week.
eric.bachard wrote:
2) *macosx20xfixes01* cws
#i54440# Some files are not attached when using "Send as Email" function
: <http://www.openoffice.org/issues/show_bug.cgi?id=54440>
Status: Verified
#i54948# send active document as attachment does not work
<http://www.openoffice.org/issues/show_bug.cgi?id=54948> :
Status: Verified
#i55863# Synchronize loading of dynamic link libraries :
<http://www.openoffice.org/issues/show_bug.cgi?id=55863>
In the course of fixing this issue I have remove all Mac specific
funtions for loading and handling of dynamic libraries (e.g. NSAddImage)
in sal/osl/unx/module.c in favor of the standard Unix API (dlopen and Co.).
This serves multiple pruposes:
o Fewer platform specific code in sal. Meanwhile Apple suggest to use
the Unix standard API for dynamic library loading and handling (e.g. to
ease porting of Unix applications to Mac OS X).
o On Mac OS X 10.4 (aka Tiger) Apple even promises performance
advantages by using dlopen and Co.
o The native Mac OS X API for instance NSAddImage is not thread safe
while the dlopen implementation is so by using the standard Unix API
there is no need anymore to protect osl_loadModule by a mutex.
However there are some problems connected to this change.
Testtool crashes when the current working directory is different than
the OOo program directory or no LD_LIBRARY_PATH or DYLD_LIBRARY_PATH is
set to the OOo progam directory. This happens because libraries loaded
with relative path will not be found.
In contrast to Solaris and Linux for instance exacutables or dynamic
libraries on Mac OS X do not contain something like an rpath. While the
dynamic linker on Solaris and Linux evaluates the rpath during dynamic
library loading it does not on Mac OS X. On Linux/Solaris the rpath is
set to $ORIGIN which means that in case dynamic libraries will be loaded
with realtive paths the value of the rpath of the calling executable or
dynamic library will be included in the search path (in case of OOo it
will almost for sure be the OOo program directory).
(I hope someone understands this somewhat complicated sounding
explanation :-) )
As OOo will usualy be started via the 'soffice' script which sets the
DYLD_LIBRARY_PATH (on Mac OS X) the problem should not happen. It is
likely that similar problems occur when soffice.bin will be started
directly.
I have currently no final idea on how to solve this problem just some
proposals:
- Fix all places which are loading dynamic libraries with relative path
- Require to start OOo/testtool always with LD_LIBRARY_PATH - which is
probably a bad idea
- Switch back to "old" Mac OS X specific implementation of
osl_loadModule which used NSAddImage and was manually searching for
dynamic libraries beside the executable (soffice.bin or testtool.bin)
Opinions and further ideas welcome.
#i56093# use of external epm is broken on Mac OSX :
<http://www.openoffice.org/issues/show_bug.cgi?id=56093>
Status: Verified
#i56734# osl_executeProcess doesn't handle fork returning '-1'
<http://www.openoffice.org/issues/show_bug.cgi?id=56734> :
Status: Resolved
#i55073# fix crash for digital signature :
<http://www.openoffice.org/issues/show_bug.cgi?id=55073>
Still need to be added to this cws
#i57253# Move user's config directory from ~/.openoffice.org2 to
~/Library/Application Support/OpenOffice.org 2.0
<http://www.openoffice.org/issues/show_bug.cgi?id=57253>
Still need to be added to this cws.
Kind regards,
Tino
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
