Apache OpenOffice (AOO) Bugzilla – Issue 10385
OOO_STABLE_1_PORTS/X11+Aqua: OS X locale detection dylib
Last modified: 2004-03-25 07:51:41 UTC
The Mac OS X/Darwin port has identified a need to store code that links against Mac OS X frameworks outside the module the code is needed in. Example: locale discovery. On Mac OS X, it is easiest to use OS X functions to do this, but we cannot link against OS X frameworks because Darwin doesn't have them. Therefore, this code must exist in a separate dylib and must be loaded at run-time after determining the system we are running on. The platform_extras module allows any platform to store pieces of code or other resources in this module that do not fit or cannot be put into other modules of the project.
Created attachment 4183 [details] cd to $SRC_ROOT, unzip and untar the archive
Created attachment 4184 [details] cd to $SRC_ROOT/sal, patch -p0 < /path/to/patchfile Changes locale functions for OS X to use platform_extras module
Please approve both: 1) platextras.tar.gz 2) sal.OOO_STABLE_1_PORTS.010103.patch Dan
Hi Dan, I just unpacked your platform_extras into my OOO_STABLE_1 tree and ran build in it under LinuxPPC and got the following error message: [kbhend@localhost ooo102]$ tcsh [kbhend@localhost ooo102]$ source LinuxPPCEnv.Set [kbhend@localhost ooo102]$ cd platform_extras [kbhend@localhost platform_extras]$ build build -- version: 1.65 /src2/ooo102/platform_extras/macxp_x11osx/osxlocale mkout -- version: 1.3 Nothing to build for GUIBASE unx /src2/ooo102/platform_extras/util ------------------------------ Making: ../unxlngppc.pro/misc/platextra.dpc dmake subdmake=true depend=t ALLDPC ------------------------------ No Dependencies dmake: Error -- `../unxlngppc.pro/slb/osxlocale.lib' not found, and can't be made ---* TG_SLO.MK *--- ERROR: Error 65280 occurred while making /src2/ooo102/platform_extras/util [kbhend@localhost platform_extras]$ So I do not think something here is being properly protected. I will look closer. Kevin
Hi Dan, The problem is in platform_extras/util/ There is no ifdef to protect those targets. You might want to model things on bridges/ or lingucomponent/ which do not use a util/ subdirectory to buid all libraries and instead merge that right into the appropriate target directory. Hope this helps, Kevin
Kevin, Correct. I also need to add a dependency for idlc on platform_extras for Mac OS X at least. We need this to be built fairly early during the process as tools like idlc, xml2cmp, cppumaker, etc, use the locale discovery during their run. I will clean up and resubmit. Dan
Hi Dan, For safety sake, why don't you have it be built before sal (if possible make it a sal dependency) that way it it should be done very very early in the process before all of the other tools which might be needed for the build (probably not possible given it uses osl_module right). The key is to make it as early on as possible. However, the dependency thing is the real issue here! What if other platforms need platform_extras to be later than idlc or or have some other dependency that conflicts? What if some alter addition has a conflicting module dependency? Perhaps it would really be better to make put all of these changes right in sal (or the most closely related target) and not use a platform_extras for multiple platforms since conflicting dependencies will happen eventually? I think I understand better what Sander and Martin were talking about dependency wize given the limited flexibility in assigning module dependencies. Hmmm... I am just no sure what is best here. Couldn't all of this just become an extra subdirectory of sal that is built after sal/osl/unx/ (as set by the prj/build.lst dependencies)? Kevin
The following two patches are the result of breaking down the platform_extras proposal to a per-module basis to resolve any potential conflicts. The first two patches from January should _NOT_ be used. Dan
Created attachment 4823 [details] cd to sal/, patch -p0 < /path/to/patchfile Implements dynamic loading functions for locale
Created attachment 4824 [details] cd to sal, uncompress. Implements OS X locale detection in separate dylib
Created attachment 4832 [details] Patch to tools project. Apply by executing the following commands: cd $SRC_ROOT/tools ; patch -p0 < /path/to/patch/file
*** Issue 11688 has been marked as a duplicate of this issue. ***
for lowlevel platform specific implementations I would prefer sal/systools. for win32/win95 the same game was already played some time ago. we have now not the possiblity to specify platform dependent module dependencies, so every makefile has to take care of excluding other platforms. also I see no problem to add a platform specific directory in a module when needed. As a last choice I'd introduce an extra module for this, but if it make sense I will not object.
Martin, I will move the Mac specific stuff into systools. I'm not using systools/util at this time for any linkage stuff, the linkage currently happens in the Mac specific directory itself since there may need to be 1 library for each mac specific directory (ie one for Aqua, one for OS X/X11, one for pure Darwin). Patches to be posted soon. dan
Created attachment 5222 [details] cd to sal, patch -p0 < /path/to/patchfile Loads the locale dylib on demand, and adds build support for the macxp specific systools directory
Created attachment 5223 [details] cd to sal/systools, and untar and ungzip the archive Adds macxp specific files for creating dylib that does locale detection on OS X
The two 032403 patches implement the dylib-based locale detection on OS X using the systools directory. Please approve both patches for commit to PORTS. dan
salmacxp_extras.PORTS.032403.tar.gz sal.extras.PORTS.032403.patch tools.patch Committed to OOO_STABLE_1_PORTS. Dan
Created attachment 5261 [details] cd to scp, patch -p0 < /path/to/patchfile Allows the sal locale dylib to be delivered with the full product
scp.salextra.OOO_STABLE_1_PORTS.032603.patch committed to PORTS also. Allows the locale detection dylib created by the other patches to actually be zipped up and delivered to the final product directory. MERGE: scp.salextra.OOO_STABLE_1_PORTS.032603.patch salmacxp_extras.PORTS.032403.tar.gz sal.extras.PORTS.032403.patch tools.patch Dan
For whatever reason, the locale detection patches broke the builds. The problem is that since the static template data member libraries link against libsal, but libsal isn't built at the time that the locale detection stuff is, things go haywire. So we have to add a new variable NOCREATESTATICLIB, that specifies for a particular target that we wish NOT to run the static data scripts on it. Dan
Created attachment 5295 [details] cd to sal, patch -p0 < /path/to/patchfile Adds the NOCREATESTATICLIB stuff for osx locale detection, and rearranges the build order for locale dylib too
Created attachment 5296 [details] cd to solenv, patch -p0 < /path/to/patchfile Adds solenv build support for NOCREATESTATICLIB on OS X to not run static template data member library scripts on a dylib
Approval requested for the following patches: sal.nocreatestatic.032703.patch solenv.nocreatestatic.032703.patch Dan
Hi Dan, Did you remember to protect the new makefile.mk added to the sal build.lst for unix platforms that are not MacOSX? If so, then both look okay so approved. Hope this helps, Kevin
The makefile is build only for OS=MACOSX. Committed to PORTS: sal.nocreatestatic.032703.patch solenv.nocreatestatic.032703.patch Dan
Fixed in 103 GM and 1.1.
This is fixed, can we close it?
close issue.