Closed Bug 53679 Opened 24 years ago Closed 23 years ago

[CW6] xpidl.mcp does not build in CodeWarrior 6 or 7

Categories

(Core :: XPCOM, defect, P3)

PowerPC
All
defect

Tracking

()

RESOLVED DUPLICATE of bug 98349
mozilla1.0

People

(Reporter: lordpixel, Assigned: beard)

References

Details

Attachments

(2 files)

*DISCLAIMER* I know you guys aren't moving to CodeWarrior 6 until after RTM, but it's all I have and I want to start hacking, so if you can spare any cycles to fix problems now I'm sure myself and others would apprechiate it. I've set up a Mac build environment that uses CW6 but I'm hitting problems almost immediately while trying to build xpidl.mcp. Here's what I'm seeing: Error : illegal implicit conversion from 'const char *' to 'void *' gmessages.c line 463 write (fd, log_domain, strlen (log_domain)); Error : illegal implicit conversion from 'const char *' to 'void *' gmessages.c line 472 write (fd, message, strlen(message)); Error : illegal implicit conversion from 'const char *' to 'void *' gmessages.c line 483 write (fd, log_domain, strlen (log_domain)); Error : illegal implicit conversion from 'const char *' to 'void *' gmessages.c line 492 write (fd, message, strlen(message)); Error : illegal implicit conversion from 'const char *' to 'void *' gmessages.c line 509 write (fd, log_domain, strlen (log_domain)); Error : illegal implicit conversion from 'const char *' to 'void *' gmessages.c line 518 write (fd, message, strlen(message)); Error : illegal implicit conversion from 'const char *' to 'void *' gmessages.c line 534 write (fd, log_domain, strlen (log_domain)); Error : illegal implicit conversion from 'const char *' to 'void *' gmessages.c line 541 write (fd, message, strlen(message)); Error : illegal implicit conversion from 'const char *' to 'void *' gmessages.c line 551 write (fd, log_domain, strlen (log_domain)); Error : illegal implicit conversion from 'const char *' to 'void *' gmessages.c line 558 write (fd, message, strlen(message)); Error : illegal implicit conversion from 'const char *' to 'void *' gmessages.c line 568 write (fd, log_domain, strlen (log_domain)); Error : illegal implicit conversion from 'const char *' to 'void *' gmessages.c line 575 write (fd, message, strlen(message)); Error : illegal implicit conversion from 'const char *' to 'void *' gmessages.c line 588 write (fd, log_domain, strlen (log_domain)); Error : illegal implicit conversion from 'const char *' to 'void *' gmessages.c line 615 write (fd, message, strlen(message)); Warning : function has no prototype gmessages.c line 751 { Warning : implicit 'int' is no longer supported in C++ mac_memory.cpp line 45 const bool kTemporaryAllocation = false; Error : 'const' or '&' variable needs initializer mac_memory.cpp line 45 const bool kTemporaryAllocation = false; Error : undefined identifier 'kTemporaryAllocation' mac_memory.cpp line 50 if (CWAllocateMemory(gPluginContext, size, kTemporaryAllocation, &ptr) == cwNoErr) Error : undefined identifier 'kTemporaryAllocation' mac_memory.cpp line 58 CWFreeMemory(gPluginContext, ptr, kTemporaryAllocation); Error : undefined identifier 'kTemporaryAllocation' mac_memory.cpp line 64 if (CWAllocateMemory(gPluginContext, size, kTemporaryAllocation, &ptr) == cwNoErr) Error : undefined identifier 'kTemporaryAllocation' mac_memory.cpp line 72 CWFreeMemory(gPluginContext, ptr, kTemporaryAllocation); Error : illegal implicit conversion from 'char **' to 'void **' mac_console.c line 99 if (CWLockMemHandle(gPluginContext, mac_console_handle, false, &ptr) == noErr) { Could not find or load the file “PluginLib4” for target “compiler” for project “xpidl.mcp”. Any thoughts?
Hm. Well, to our credit, it looks like all of the errors occur in glib, which we get from the GNOME folks. It's checked into our tree to accomodate the changes we needed to make to it to support the mac. Evidently more are needed. Everything here looks easy to fix. Every 'illegal implicit conversion' can probably be fixed with an explicit cast. The function with the missing prototype could get one, and the implicit int variable (yuck!) can be declared. Probably the best way to proceed is for you to make these changes in your tree. If you can get a compile, make a diff file (I think the mac CVS tool supports it) and attach it to this bug. As we're currently in a big stability push, it's pretty hard to check things in now, but I'd be happy to apply the patch when things calm down a little. It'll be good to get this out of the way now rather than when we do move to CW6.
Status: NEW → ASSIGNED
Its pretty trivial to get this to compile, just add explicit casts. Don't know if that's an *appropriate* solution though...
Explicit casts are probably the way to go in this case - we don't maintain the code in question, and it's only in the tree to support the tweaks we needed to make to it to support the mac. (Should get those back to the authors someday, but we haven't yet. I'm to blame.)
As far as the mac_memory.cpp problems go, it looks to me like you don't have bool support turned on. I noticed that some other projects of mine wouldn't compile, and that bool support got lost when converting from Pro5 to Pro6 format.
Reassigning this Mac bug from mccabe to beard -
Assignee: mike+mozilla → beard
Status: ASSIGNED → NEW
OS: All
Attached patch Patch to fix CW6 compile errors (deleted) — Splinter Review
OK, added bug 75075 dependancy, because even when this builds it doesn't work on Mac OS X, likely because the linker needs some carbonisation. On getting this project to build: 1/ Apply the patch attached to this bug 2/ bool support doesn't seem to matter so much, try turning it on if you get errors 3/ Need to delete InterfaceLib from the project and replace it with CarbonLib. Which release of Universal Headers is Netscape targettting 4/ on PluginLib4... Need to remove PluginLib4 from the project and replace it with PluginLib4.shlb. With CodeWarrior 6 two copies of the SDK are installed, one in the top level codewarrior folder, another in "Mac OS Support", where it has been disabled by adding brackets around its name. There's a note in the top level one which warns against including/enabling the SDK libraries (in Mac OS Support, I believe) because they're built into the 4.1 IDE. I think all we want to do is link against the shlb file in the top level copy of the SDK and leave the one in Mac OS Support disabled. This means you need to add Metrowerks CodeWarrior6:CodeWarrior SDK:Libraries and :Headers to the Access Paths for the project. End result of all that is 17 link errors for the linker target: Link Error : undefined 'CWDonePluginRequest' (code) Referenced from 'xpt_linker' in mac_xpt_linker.cpp Link Error : undefined 'CWSetTargetInfo' (code) Referenced from 'GetTargetInfo(CWPluginPrivateContext*)' in mac_xpt_linker.cpp Link Error : undefined 'CWCreateNewTextDocument' (code) Referenced from 'Disassemble(CWPluginPrivateContext*)' in mac_xpt_linker.cpp Link Error : undefined 'CWGetMainFileNumber' (code) Referenced from 'Disassemble(CWPluginPrivateContext*)' in mac_xpt_linker.cpp Link Error : undefined 'CWAllocateMemory' (code) Referenced from 'operator new[](unsigned long)' in mac_memory.cpp Link Error : undefined 'CWResizeMemHandle' (code) Referenced from 'Disassemble(CWPluginPrivateContext*)' in mac_xpt_linker.cpp Referenced from 'WriteCharsToConsole' in mac_console.c Link Error : undefined 'CWGetMemHandleSize' (code) Referenced from 'WriteCharsToConsole' in mac_console.c Link Error : undefined 'CWFreeMemHandle' (code) Referenced from 'RemoveConsole' in mac_console.c Link Error : undefined 'CWAllocMemHandle' (code) Referenced from 'InstallConsole' in mac_console.c Link Error : undefined 'CWFreeMemory' (code) Referenced from 'operator delete[](void*)' in mac_memory.cpp Link Error : undefined 'CWGetStoredObjectFileSpec' (code) Referenced from 'Disassemble(CWPluginPrivateContext*)' in mac_xpt_linker.cpp Referenced from 'LinkTypeLib(CWPluginPrivateContext*,XPIDLSettings&)' in mac_xpt_linker.cpp Referenced from 'LinkHeaders(CWPluginPrivateContext*,XPIDLSettings&)' in mac_xpt_linker.cpp Link Error : undefined 'CWGetOutputFileDirectory' (code) Referenced from 'GetTargetInfo(CWPluginPrivateContext*)' in mac_xpt_linker.cpp Referenced from 'Disassemble(CWPluginPrivateContext*)' in mac_xpt_linker.cpp Referenced from 'LinkTypeLib(CWPluginPrivateContext*,XPIDLSettings&)' in mac_xpt_linker.cpp Referenced from 'LinkHeaders(CWPluginPrivateContext*,XPIDLSettings&)' in mac_xpt_linker.cpp Link Error : undefined 'CWGetProjectFileCount' (code) Referenced from 'LinkTypeLib(CWPluginPrivateContext*,XPIDLSettings&)' in mac_xpt_linker.cpp Referenced from 'LinkHeaders(CWPluginPrivateContext*,XPIDLSettings&)' in mac_xpt_linker.cpp Link Error : undefined 'CWUnlockMemHandle' (code) Referenced from 'WriteCharsToConsole' in mac_console.c Referenced from 'GetSettings(CWPluginPrivateContext*,XPIDLSettings&)' in mac_xpt_linker.cpp Link Error : undefined 'CWLockMemHandle' (code) Referenced from 'WriteCharsToConsole' in mac_console.c Referenced from 'GetSettings(CWPluginPrivateContext*,XPIDLSettings&)' in mac_xpt_linker.cpp Link Error : undefined 'CWGetNamedPreferences' (code) Referenced from 'GetSettings(CWPluginPrivateContext*,XPIDLSettings&)' in mac_xpt_linker.cpp Link Error : undefined 'CWGetPluginRequest' (code) Referenced from 'xpt_linker' in mac_xpt_linker.cpp
Blocks: 75075
grrr. I nuked the data folder and those link errors disappeared. Do Metrowerks have a bakcground thread whose sole purpose is to go around corrupting project data folders? So plugin compiles with the changes I suggested, but it don't work on Mac OS X.
An additional comment, this uses some of Jim Luther's More Files stuff, and I just diffed the latest release 1.5.2 against the Mozilla copy. Unsurprisingly the Mozilla one is heavily modified. It looks like there's duplication of Carbonization effort and all sorts of fun. Dunno if that's whats causing this problem (I'd guess not) but worrisome in any case...
Ah ha! Got part of it. Linking against MathLib which seems to be obsolete. Removing this makes the linker show up in the IDE. Unfortunately opening a project which uses the linker is now impossible. "Operating System error 2. Can not open project" [OK] Hmmm, great...
Bingo. Got it need to remove DragLib from the Carbon build too, otherwise the Linker settings panel for the xpidl compiler won't load. Now seems to be trucking along on Mac OS X with CodeWarrior 6. Output .h files look good. Just in case anyone didn't know (I sure wish I'd found out earlier) There's a plugin debug preference in the IDE which will give you *reams* of output about why things don't load.
Blocks: 53682
Target Milestone: --- → mozilla1.0
Also seeing similar (the same?) problem with CW7: Error : illegal implicit conversion from 'char **' to 'void **' mac_console.c line 114 if (CWLockMemHandle(gPluginContext, mac_console_handle, false, &ptr) == noErr) {
Summary: [CW6] xpidl.mcp does not build in CodeWarrior 6 → [CW6] xpidl.mcp does not build in CodeWarrior 6 or 7
Attached patch patch for compile error in CW7 (deleted) — Splinter Review
Much simpler patch for CW7. Most of the library issues apply too, but then that's more because I'm building Carbon than anything else...
If you see this: Link Error : undefined 'write' (code) Referenced from 'g_log_default_handler' in gmessages.c Its because you're building Carbon and you need to use the Carbon version of MSL. Add (code warrior7):Mac OS Support:Libraries:Runtime:Libs:MSL_All_Carbon.Lib to your project. You can also remove: MSL_C_PPC.Lib MSL_Runtime_PPC.Lib and maybe the MPW ones too.
You need to add the SDK Headers folder to at least compiler/linker and xpidl, plus you should remove MSL C.PPC MPW(NL).Lib from the project
Blocks: 98349
This doesn't really block bug 98349. Under that bug, the xpidl tools are up and working under Pro 7. This bug should be closed.
No longer blocks: 98349
*** This bug has been marked as a duplicate of 98349 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Component: xpidl → XPCOM
QA Contact: mike+mozilla → xpcom
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: