CVS head + MacOS X

[renchap]

there is the results of my compilation of the last cvs head with tiger, last version of xcode (with x86 support) :
- the -W uninitialized option is still present in the development build style, so it causes one warning per file... and in the doc you can read that it is a deployment option only, so we can safely remove it
- there is still one only target for xerces and tinyxml build. it is easy to change this, simply add a new target called CEGUIWithTiNyXML, remove the CEGUI_WITH_XERCES constant and add -DCEGUI_WITH_XERCES to gcc arguments in the xerces target. you must also remove tinyxml files from this target
- no target for the lua bindings
- cant compile it with xerces :

Code: Select all

ld: warning prebinding disabled because of undefined symbols
ld: Undefined symbols:
__ZN11xercesc_2_610XMLRefInfo9serializeERNS_16XSerializeEngineE
__ZN11xercesc_2_613DTDEntityDecl9serializeERNS_16XSerializeEngineE
__ZN11xercesc_2_613XMLAttDefList9serializeERNS_16XSerializeEngineE
__ZN11xercesc_2_613XMLEntityDeclD2Ev
__ZN11xercesc_2_617SAXParseExceptionC1ERKS0_
__ZN11xercesc_2_617SAXParseExceptionD1Ev
__ZN11xercesc_2_67XMemorydlEPv
__ZNK11xercesc_2_610XMLRefInfo12getProtoTypeEv
__ZNK11xercesc_2_610XMLRefInfo14isSerializableEv
__ZNK11xercesc_2_613DTDEntityDecl12getProtoTypeEv
__ZNK11xercesc_2_613DTDEntityDecl14isSerializableEv
__ZNK11xercesc_2_613XMLAttDefList12getProtoTypeEv
__ZNK11xercesc_2_613XMLAttDefList14isSerializableEv
__ZTIN11xercesc_2_613XMLEntityDeclE
__ZTIN11xercesc_2_617SAXParseExceptionE
__ZN11xercesc_2_615XMLTransService20makeNewTranscoderForENS_13XMLRecognizer9EncodingsERNS0_5CodesEjPNS_13MemoryManagerE
__ZN11xercesc_2_616XMLPlatformUtils10InitializeEPKcS2_PNS_12PanicHandlerEPNS_13MemoryManagerE
__ZN11xercesc_2_616XMLPlatformUtils14fgTransServiceE
__ZN11xercesc_2_616XMLPlatformUtils15fgMemoryManagerE
__ZN11xercesc_2_616XMLPlatformUtils9TerminateEv
__ZN11xercesc_2_617MemBufInputSourceC1EPKhjPKcbPNS_13MemoryManagerE
__ZN11xercesc_2_617MemBufInputSourceD1Ev
__ZN11xercesc_2_617SAX2XMLReaderImplC1EPNS_13MemoryManagerEPNS_14XMLGrammarPoolE
__ZN11xercesc_2_66XMLUni14fgXercesSchemaE
__ZN11xercesc_2_66XMLUni20fgSAX2CoreNameSpacesE
__ZN11xercesc_2_66XMLUni20fgSAX2CoreValidationE
__ZN11xercesc_2_66XMLUni22fgXercescDefaultLocaleE
__ZN11xercesc_2_66XMLUni30fgXercesValidationErrorAsFatalE
__ZN11xercesc_2_66XMLUni31fgXercesUseCachedGrammarInParseE
__ZN11xercesc_2_66XMLUni47fgXercesSchemaExternalNoNameSpaceSchemaLocationE
__ZN11xercesc_2_67XMemorydlEPvPNS_13MemoryManagerE
__ZN11xercesc_2_67XMemorynwEmPNS_13MemoryManagerE
__ZN11xercesc_2_69XMLString7releaseEPPc
__ZN11xercesc_2_69XMLString7releaseEPPt
__ZN11xercesc_2_69XMLString9transcodeEPKc
__ZN11xercesc_2_69XMLString9transcodeEPKt
__ZTIN11xercesc_2_612XMLExceptionE


(with both fink installed version and the official source)

i havent the time to test this version now, but the compilation works

i cant use my computer during 6 or 7 days (exams) but i will try to make a new xcode project, with both tinyxml and xerces targets, and also the lua support (works, but need to clean the project)

and still my problem with texture loading : http://sourceforge.net/tracker/index.ph ... tid=605422

[CrazyEddie]

The issue with the integrated tga loader used with the OpenGL renderer will be an endian issue; this was a contribution, and I guess was not developed in an endian neutral way. DevIL is probably a better choice in most cases anyway (since it supports more file formats).

[CrazyEddie]

The thing with Xerces is that until recently it was a requirement; so I know for a fact that CEGUI can be successfully compiled on the Mac with Xerces support. What I do not know, is whether the problems you are reporting are issues caused by Tiger, or whether there is some other problem that exists; all I do know is that you're the only person to have reported this as an issue, maybe you're the only Mac user we currently have? ( )

I currently think that until this is confirmed as an issue by other users, I do not think it is wise to take any action. If we jumped everytime somebody reported a 'problem' and suggested a fix, then the projects and code would soon deteriorate into a useless mess - in most cases it turns out to be a problem at the users end. I'm not saying that this is the case here, though until it can be comfirmed as an issue, I'd not recommend any action be taken.