53682 - [CW6] Issues building with CodeWarrior 6 (and solutions)

Status: VERIFIED WONTFIX

(SeaMonkey :: Build Config, defect, P3)

Description

[Andrew Thompson]

*DISCLAIMER* I know you guys aren't moving to CW6 until after RTM, and I think 
that's the only sensible plan. 

This bug collects things that I've figured out so far that you need to to to 
getany buildage in CW6. I realise this information isn't useful right away, but 
it should hopefully form a pointer for later.

1/ See bug 53679 about getting the xpidl.mcp code to compile.

2/ the location of PluginLib4 has changed. This is used in xpil.mcp.

The installer now no longer puts the CodeWarrior SDK in the Mac OS Support 
folder, instead it puts it in the top level of your CoeWarrior folder and it 
seems you need to include the PluginLib4 libarary from there insead.

3/ In NGLayoutBuildList.pm, change this line:

    	if ( ! -e $codewarrior_msl . "Lib:PPC:MSL C.PPC MPW(NL).Lib") {
to this:
    	if ( ! -e $codewarrior_msl . "Lib:PPC:MSL C.PPC MPW.Lib") {

4/ In Mac OS Support:Libraries:Runtime

the Common Source folder has been disabled by calling it (Common Source)

You can obviously work around this by changing the name back, but it begs the 
question whether this is the right thing to do - why has it been disabled?

That's it for now. I'm currently failing in NSStLib. I'll post more as I learn 
more.

Comment 1

[Simon Fraser [no longer active]]

Spam mac folks

Comment 2

[cls]

Passing over to jj.

Comment 3

[Andrew Thompson]

OK, got some time, got another one for you:

Now failing in MemAllocator.mcp with this charming message:

Error   : ambiguous access to overloaded function 
'malloc(unsigned long)'
'std::malloc(unsigned long)'
nsNewPtrMalloc.cp line 84   void    *newBlock = ::malloc(space);


Looks like too many mallocs in scope to me. Any ideas ?

Comment 4

[Andrew Thompson]

File is sfraser's BTW ... I'll dig around a bit further...

Comment 5

[Andrew Thompson]

Attachment: Solve malloc ambiguity in nsNewPtrMalloc.patch

Comment 6

[Scott Collins]

...though I'd (a) make the prototype |inline| also, and (b) put the definition of
|mozMalloc| before its first use.

Comment 7

[Simon Fraser [no longer active]]

Before you mess with MacMemoryAllocator, there are larger fish to fry in getting 
NSStdLib and NSRuntime to build. beard has fixes for those (but he's away for a 
week). There are lots of namespace issues there.

Comment 8

[Andrew Thompson]

Attachment: Improved patch, as suggested

Comment 9

[Andrew Thompson]

OK, I re-disabled the Common Sources folder I mentioned above, because I have no 
idea whether it should be in the build or not, but if its disabled in CW6 I don't 
want it there until someone tells me different.

This makes the build fail in nsRuntime.mcp with this error:

Error   : the file 'CPlusLib.h' cannot be opened
CPlusLibPPC.cp line 9   #include <CPlusLib.h>

which is unsurprising, given this header is in Common Sources.

I'll probably just wait for Beard to get back, unless someone volunteers the 
right solution.

Thanks for all the help so far.

Comment 10

[J.J. Enser]

Is this issue and the submitted patch still valid? Please update summary and 
status as needed.

Comment 11

[Andrew Thompson]

We still can't build with CodeWarrior 6 to the best of my knowledge.

Simon Fraser can probably tell you better whether this patch is still needed.

Comment 12

[Andrew Thompson]

OK, here's the April 2001 Story on how to do this

0/ If you want to do this on Mac OS X, set up for a Carbon build as described on 
the CFM Fizzilla page (Mozilla.org->Ports->Fizzilla->FizzillaCFM)

1/ See bug 53679 for how to get xpidl.mcp to compile

2/ In NGLayoutBuildList.pm, change this line:

        if ( ! -e $codewarrior_msl . "Lib:PPC:MSL C.PPC MPW(NL).Lib") {
to this:
        if ( ! -e $codewarrior_msl . "Lib:PPC:MSL C.PPC MPW.Lib") {


4/ In Mac OS Support:Libraries:Runtime

the Common Source folder has been disabled by calling it (Common Source)
re-enable it by removing the brackets

5/ If 40013 hasn't been checked in yet, then download the projects attached to 
that bug. If they're out of date you'll have to open each and change the settings 
in your NSStdLib.mcp and NSRuntime.mcp for the Stubs and StubsCarbon targets such 
that these are set up like the ones attached to those patches. 

You need to change Target Settings, PPC Target, PPC Linker and PPC PEF to match, 
maybe more, but I don't think so.

This'll get you through the stubs phase of NSStdLib

6/ Build. The memallocator patch attached to this bug is no longer needed, at 
least if you're building Carbon. If not, you might still need this patch.

Currently I fail in NSStdLib during linking.... more details to follow.

Comment 13

[Andrew Thompson]

See bug 75333 for details of latest roadblock

Comment 14

[Andrew Thompson]

Well, it now builds. Follow all the depends bugs.

Viewer runs, profile manager runs, but Moz never brings up a window

Pink, which version of carbon do you link against?

Comment 15

[Mike Pinkerton (not reading bugmail)]

carbon? i thought you weren't building carbon. anyway, we require version 1.2 at 
minimum.

Comment 16

[Andrew Thompson]

Yeah, I'm building it Carbon. Didn't seem to be much point in using a Carbon
application to build a classic app, but then again, why not I suppose...

I was curious as I'm using the 1.2.5 GM release of the Carbon SDK, which I
believe corresponds to Mac OS 9.1 and Mac OS X 10.0.0. I noticed the FizzillaCFM
page doesn't mention exactly which release is used internally at Netscape.

If you could check and update the page I'm sure it would help people eliminate
variables in their builds.

Comment 17

[J.J. Enser]

This should not be mine. Reassigning to [e-mail] since he's been doing
all the work.

Comment 18

[Steve Dagley]

Closing as WONTFIX - see comments in 76051

Comment 19

[Jon Granrose]

verified wontfix.