Hi Tino, all
Thank you very much for your long and usefull answer !
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
*To all* : Forwarding my initial message, I propose to continue on
[EMAIL PROTECTED] mailing-list, created for everything about
Mac OS X. Included devel.
BTW : don't forget to suscribe ;-) => see mailing list on
<http://porting.openoffice.org>
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Tino Rachui a écrit :
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
[...cut...]
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.
I must admit I never proceed like that, but for important cws, it's
impressive !
Maybe we should describe the QA process on the wiki ?
#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.).
I remember, and we observed some strange crashes.
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).
yes
o On Mac OS X 10.4 (aka Tiger) Apple even promises performance
advantages by using dlopen and Co.
yes too
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.
Yes, and I didn't know more.
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.
Thank's for the explanation. I remember testtool crashes just at the end
on Linux PPC. Maybe some relation with this issue ?
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.
I'll search documentation about that. Could this be caused by bad flags
in unxmacxp.mk ? (I meant to LINKFLAGS* )
e.g. , in unxlngppc4.mk I know well, there is a LINKFLAGRUNPATH*
variable, defined using :
LINKFLAGRUNPATH*= -Wl,-rpath,\''$$ORIGIN'\'
Maybe search in this direction ?
(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.
ok
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
not sure :-)
- 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.
First, testtool is not intended for final user : we can do whatever we
want, and start like soffice does.
On Mac OS X (only), testtool could be a shell script containing
everything for a good initialisation, launching testtool.bin
Second: this is just an idea like that, late in the night, and I'm
prehpas wrong...
#i55073# fix crash for digital signature :
<http://www.openoffice.org/issues/show_bug.cgi?id=55073>
Still need to be added to this cws
Yes, I have to commit before
#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.
Oliver already provided the patch, but I have commited nothing. I'll do
it asap
Kind regards,
eric
--
<[EMAIL PROTECTED]>
Francophone OpenOffice.org Commmunity developer (Linux PPC / Mac OS X /
X11)
See : <http://fr.openoffice.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
