Apache OpenOffice (AOO) Bugzilla – Issue 37919
registry break for Mac OS X port of SRC680
Last modified: 2010-09-28 10:53:59 UTC
SRC680_m63 Mac OS X port / build done under Mac OS X 10.3.4 / XCode 1.5 Powerbook G4 This issue is a way to organize my progress while building SRC680 for MAc OS X. Everyone doing the same work is invited to collaborate :-) While I'm reading the doc to build my own CWS, this is a little workaround, and with it, 1) registry is now buildable :-) I think this patch will be proposed for a _to_be_created_ CWS, because it's really needed for Mac OSX port 2) ...coming soon :-) To be continued... (searching howto solve malloc.h and stdlib problems with configure) ;-)
Created attachment 19710 [details] registry build break on SRC680 for MacOSX port
ericb: please paste full error report with the full message from build, so it could be found.
Hi, Excuse me, I'll take care next time. The following log comes from Eric Hoch, but it was exactly the same I had. Historicaly : XCode1.2 -> no registry crash XCode1.5 first version (08/2004) -> crash and registry patch necessary update of gcc-33 (bundled in XCode1.5) -> no registry patch, even if it necessayr (IMHO) I think when we can answer to the question : is this patch necessary or not, we can close this issue. The missing log : ============= Building project registry ============= /Volumes/Daten/OpenOffice/ooo113/registry/source ------------- /Volumes/Daten/OpenOffice/ooo113/registry/util ------------------------------ Making: ../unxmacxp.pro/lib/libreg.dylib.3.1.0 gcc -c -dynamic -o ../unxmacxp.pro/slo/reg_version.o -DUNX -DBUILD_OS_APPLEOSX -DBUILD_OS_MAJOR=10 -DBUILD_OS_MINOR=3 -DBUILD_OS_REV=5 -I../unxmacxp.pro/inc /Volumes/Daten/OpenOffice/ooo113/solenv/src/version.c gcc -Wl,-multiply_defined,suppress -dynamiclib -single_module -install_name @executable_path/libreg.dylib.3 -L../unxmacxp.pro/lib -L/Volumes/Daten/OpenOffice/ooo113/solver/645/unxmacxp.pro/lib -L/usr/lib -L/usr/X11R6/lib -o ../unxmacxp.pro/lib/libreg.dylib.3.1.0 -dylib_file @executable_path/libsal.dylib:/Volumes/Daten/OpenOffice/ooo113/solver/645/unxmacxp.pro/lib/libsal.dylib -dylib_file @executable_path/libstlport_gcc.dylib:/Volumes/Daten/OpenOffice/ooo113/solver/645/unxmacxp.pro/lib/libstlport_gcc.dylib -dylib_file @executable_path/libsalhelpergcc3.dylib:/Volumes/Daten/OpenOffice/ooo113/solver/645/unxmacxp.pro/lib/libsalhelpergcc3.dylib -dylib_file @executable_path/libsal.dylib.3:/Volumes/Daten/OpenOffice/ooo113/solver/645/unxmacxp.pro/lib/libsal.dylib.3 -dylib_file @executable_path/libstore.dylib:/Volumes/Daten/OpenOffice/ooo113/solver/645/unxmacxp.pro/lib/libstore.dylib -lsal -lsalhelpergcc3 -lstore -lpthread -lm -lstlport_gcc -lstdc++ -filelist ../unxmacxp.pro/misc/libreg.dylib.3.1.list ld:/usr/bin/libtool: internal link edit command failed Undefined symbols: _STL::_Swap_lock_struct<0>::_S_swap_lock dmake: Error code 1, while making '../unxmacxp.pro/lib/libreg.dylib.3.1.0' ---* TG_SLO.MK *--- ERROR: Error 65280 occurred while making /Volumes/Daten/OpenOffice/ooo113/registry/util dmake: Error code 1, while making 'build_all' ---* TG_SLO.MK *--- """""""""""""""""""""""""""end """"""""""""""""""""""""""""""""""""""""""" Regards, ericb
Created attachment 20427 [details] state of art of cws patches for Mac OSX port 11 december 2004
New "non definitive" set of patch for Mac OS X build (SRC680_m64). * this is the state of art the 11 december 2004. * I have to verify some of them for see if they're usable directly against m64 sources. I need 2 or 3 days to finish. Many thanks to Kevin, Kato, Maho, Li, Pavel, Eric, Jim ...and I probably forgot someone, sorry. Yet missing : Python .dylib and epm packaging The Mac OSX build continue :-)
mozilla packages for Mac OS X are updated. The URL is : <http://eric.bachard.free.fr/mac/patches/SRC680/m64/patches/moz/zipped/> Note : they are available for m64+ (so m65, m66...) Regards, eric bachard
Hi all, As an archive attachment, some patches working on SRC680_m64 (and 65). I have applied them against a fresh cvs up module everytime. Some are from Kevin Hendricks, some are mine. Sometimes, I prefer Kevin's solution, sometimes mine ;-) So, when I was in front of a doubt, I have not include it, and they'lll come later (soon, of course). Important : *All these patches will be include in HEAD under macosx01 cws (thank's Pavel)* The content describes (if I'm not wrong) the exact tree where patch have to be applied with patch flag "-p0" I'm nearly sure they solve a lot of problems on Mac OS X port, but not all, because some like python dylib delivery and some others are yet missing. To be continued :-) Pavel : you'll find Kevin's and I patches. please let me know if something's going wrong.
Created attachment 20577 [details] verified patches for Mac OS X port to be applied on SRC680_m64+
Can anyone confirm this break? My build works OK without this patch.
No more necessary : last XCode 1.5 solves a lot of problems, and build is fine without this -> issue set as WONTFIX -- eric bachard
I'm sorry Eric, but with XCode 1.5, I can reproduce the problem. Reopening the issue. Removing the lines #define inline #undef inline as suggested in the patch solved the break for me.
Confirming ;-)
I would vote for removing the #ifdef MACOSX // Get the store.hxx inlines non-inline, solves crashes in cppumaker #define inline #endif lines and the #ifdef MACOSX // Get the store.hxx inlines non-inline, solves crashes in cppumaker #undef inline #endif lines in any case, even if some people can build with them, because they look like a ugly hack to me. Are they still needed in any way to fix cppuhelper? Instead of "does someone need these lines to be removed?", the question should be "does someone need these lines to remain?".
ericb->ebischoff Just to be sure, which XCode version have you ? First XCode 1.5 had this problem, not the update (last XCode 1.5 available )
I have XCode 1.5. I know that this problem does not appear anymore with later versions of XCode. However, the problem is in OpenOffice.org, not in XCode 1.5. XCode 1.5 only reveals it. Those #defines are an ugly hack. Unless they are still necessary to someone else, they should disappear. They can only create problems.
@eric: is this patch still valid ?
@eric: ping !
Oops... sorry... ;-). Pong! What is your question, exactly? Quoting myself: Instead of "does someone need these lines to be removed?", the question should be "does someone need these lines to remain?" and I can't answer this question. My vote goes for removing these conditional defines, and see if it breaks something for someone.
reassign to macport
It seems the patch has long since been applied or a similar change been done; at least the offending #define inline is no longer there. closing as fixed
closing