Apache OpenOffice (AOO) Bugzilla – Issue 5900
OOO_STABLE_1/X11+Aqua: product needs patch to build
Last modified: 2004-05-19 16:53:45 UTC
This patch to product allows it to build successfully for OS X. This translates .so extensions in the product lists to UNXSUFFIX to allow for the .dylib extension on OS X. Additionally, it contains a hack to allow stlport4 to build successfully through the module through copying it to the location where stlport 4.5 would dump its files. *** THIS PATCH SHOULD BE CHECKED FOR XPLATFORM COMPATIBILITY BEFORE COMMITTING IT ***
Created attachment 1994 [details] cd $SRCROOT/product; patch -p0 < product.OOO_STABLE_1.061602.patch
Created attachment 2038 [details] cd to SRC_ROOT/product, patch -p0 < /path/to/patch Requires a CLEAN module from CVS (I used 6/17/02), replaces previous patch
Created attachment 2052 [details] apply after the 062102 patch to remove extraneous dots in filenames.
Created attachment 2059 [details] superceds all previous patches, requires fresh copy of product (cvs date 06-17-02 verified).
the most recent patch adds in appropriate periods and removes quotations from within the CONCAT# macros that wouldn't be properly applied and result in mislocated files when building instsetoo
Ed, obviously I'm missing something, but I can't find the definition of UNXSUFFIX. Where does it come from? Heiner
See patch for issue 6078 for scp module. This defines UNXSUFFIX.
Hi Dan, the scp part of the patch is approved (HR + IS). But copying libstlport_gcc.dylib shouldn't be done from module product but from stlport/pprj/d.lst module. This part of the patch should be omitted. Heiner
When I was poking around, I couldn't get the stlport makefiles to copy stlport4 dylibs into appropriate locations as things kept complaining about paths on me. Doing it in product was quick and dirty. The problem I was having was in how the different modules were defined in that makefile. The dependencies never seemed to work out in such a way to actually result in the copy getting executed in that stlport makefile.
Hi Ed, Copying from the stlport makefile.mk might in fact be difficult. But why not just use the stlport/prj/d.lst deliver mechanism? I do not really object the patch because it's MacOSX specific. But it does not feel right. Heiner
However, how exactly does one copy from STLPORT_4 directory that might be anywhere on the hard drive to the _DEST, but in the d.lst file? What would we use instead of __SRC? For example, I built wtih --stlport4- home=/Developer/OpenOffice/STLport4.0 What would be used to represent this path in the d.lst file? Dan
Hi Dan, I see. Well the build is supposed to use the stlport project for acquiring the stlport, at least for "regular" ports - one of which MacOS X will hopefully be in future. If configure overrides the stlport than IMHO configure should make certain that it will be found somewhere. Heiner
Most of the linklines in the makefiles I believe still have STLPORT4_HOME style checks on them and include different paths as necessary, at least, that's how I recall it being done in the past. Perhaps I should just ask the list. According to Kevin, gcc2 adn stlport4 were used for the LinuxPPC build so it'd be interesting to see if they ran into this dependency problem in the makefiles as well.
Created attachment 2836 [details] Remove STLPort-4.0 hack from 062402 patch. This patch supercedes all previous patches.
The product.OOO_STABLE_1.091302.patch removes the copying of libstlport_gcc.dylib. This patch builds fine with a clean build since libstlport_gcc.dylib is delivered to solver earlier in the build.
Created attachment 2886 [details] Correct NO_STLPORT4 check. This supercedes all previous patches
The attached patch product.OOO_STABLE_1.091602.patch corrects the NO_STLPORT4 check in product/util/makefile.mk. The previous patch was applying the rules in the reverse of the NO_STLPORT4 check.
Added approval_pending keyword to get patrick's cleaner version approved instead of my hack job :)
Approved Kevin
091602 patch committed to _PORTS. dAn
Changed to merge_pending. Merge: 1) product.OOO_STABLE_1.091602.patch 2) Also see scp patch (6078) as that is a dependency of this one. Dan
patch is obsolete, issue has been fixed. closing
.