Modules requiring conversion:

bridges
extensions
setup2
sysui
vcl

Created attachment 3703 [details]
cd to SRCROOT/extensions, patch -p0 < /path/to/patchfile

Created attachment 3704 [details]
cd to SRC_ROOT/sysui, patch -p0 < /path/to/patchfile

Created attachment 3705 [details]
cd to SRC_ROOT/vcl, patch -p0 < /path/to/patchfile

Kevin & Ed,

Can you approve:
1)  extensions 112202
2)  sysui 112202 (____check xplat____)
3)  vcl 112202

Thanks,
Dan

Hi Dan, 
 
I looked at these and I don't see any problems: 
 
1. why not simply patch things so that everyone uses the osl sal lib 
functions instead of dlXXXX?  That would make the code the most 
portable? 
 
2.  Is there any difference between dlclose and oslunloadmodule we 
need to worry about here? 
 
I approve the changes but this is something that we really should 
think about fixing for everyone isn't it? 
 
Thanks, 
 
Kevin 
 

At least in the Mac version of dlcompat the dlclose() function calls "_fini()" and the dlopen() function calls "_init()".  I'm still not sure how I am going to handle this in this code, either to patch sal to do it and add the necessary symbol lookups and calls where osl_loadModule() isn't used, or to just add the necessary lookup/call everywhere that I have killed dlcompat for OS X.

In the end a separate call that does something like dlopen() and another for dlsym and dlclose() might have to be done for OS X if this proves an issue, just to keep the mess down and the code cleaner.

Dan

Created attachment 3753 [details]
cd SRC_ROOT/setup2, patch -p0 < /path/to/patchfile

setup2 patch stops building loader (which depends on dlopen() api) for
OS X entirely.  We don't use it anyway.

dAn

Patches committed to _PORTS.

Dan

Hi, 
 
According to Daniel's response (from the udk project) we can not 
simply replace the dlopen with the osl module load in the gcc3 
bridge code since it is used to get the current process handle to 
search for symbols for properly throwing exceptions. 
 
Specifically  
 
RTTI::RTTI() SAL_THROW( () ) 
    : m_hApp( dlopen( 0, RTLD_LAZY ) ) 
{ 
} 
 
invoking dlopen(0,RTLD_LAZY) seems to return the handle for the 
current process (library?). 
 
Here is what the Solaris man page says about this specific use: 
 
     If the value of pathname is 0, dlopen() provides a handle on 
     a  global  symbol object. This object provides access to the 
     symbols from an ordered set of  objects  consisting  of  the 
     original  program image file, together with any dependencies 
     loaded at program startup, and any objects that were  loaded 
     using  dlopen()  together  with the RTLD_GLOBAL flag. As the 
     latter set of objects can change during  process  execution, 
     the set identified by handle can also change dynamically. 
 
So we either need to keep dlcompat or extend the MacOSX version of 
oslloadModule to handle the special case of passing in a 0 for the 
name of the library. 
 
Hope this helps, 
 
Kevin 
 

Kevin,

I believe we can implement this using NSImage API or the dyld calls on
OS X.  I will investigate more.

Dan

Created attachment 4908 [details]
cd SRC_ROOT/setup2, patch -p0 < /path/to/patchfile.  REPLACES 112202 PATCH.  Removes dlopen()/dlsym() calls from the setup loader

setup2.nodlcompat 022603 patch REPLACES the previous 112202 patch.  The 022603 patch converts dlopen()/dlsym()/dlclose()/dlerr() calls mow/source/loader to NS Image calls for Mac OS X.

Please approve setup2.nodlcompat.OOO_STABLE_1_PORTS.022603.patch for commit to PORTS.

Dan

setup2.nodlcompat.OOO_STABLE_1_PORTS.022603.patch approved

See also Issue 12433 for the setup patches.

http://www.openoffice.org/issues/show_bug.cgi?id=12433

Dan

Created attachment 6077 [details]
cd vcl; patch -p0 < vcl.OOO_STABLE_1_PORTS.050703.patch

Added in new patch to vcl library to remove libdl dependency when linking libvcl for 
X11.  Linking is successful;  libdl should no longer be necessary for vcl after the 
xrender changes to use osl_* routines on OS X.

Hi, 
 
Completely MacOSX specific so approved. 
 
Kevin 
 

Kevin already approved. What is the status?

Since Panther/OS X 10.3 has dlopen() functionality included, closing this issue.

closing