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

VERIFIED WONTFIX

Status

SeaMonkey
Build Config
P3
normal
VERIFIED WONTFIX
18 years ago
13 years ago

People

(Reporter: Andrew Thompson, Assigned: Andrew Thompson)

Tracking

({meta})

Trunk
mozilla1.2alpha
PowerPC
All
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Assignee)

Description

18 years ago
*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.
(Assignee)

Updated

18 years ago
Keywords: meta

Comment 1

18 years ago
Spam mac folks

Comment 2

18 years ago
Passing over to jj.
Assignee: cls → jj
(Assignee)

Comment 3

18 years ago
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 ?
(Assignee)

Comment 4

18 years ago
File is sfraser's BTW ... I'll dig around a bit further...
(Assignee)

Comment 5

18 years ago
Created attachment 15497 [details] [diff] [review]
Solve malloc ambiguity in nsNewPtrMalloc.patch

Comment 6

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

Comment 7

18 years ago
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.
(Assignee)

Comment 8

18 years ago
Created attachment 15586 [details] [diff] [review]
Improved patch, as suggested
(Assignee)

Comment 9

18 years ago
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

17 years ago
Is this issue and the submitted patch still valid? Please update summary and 
status as needed.
OS: All
(Assignee)

Comment 11

17 years ago
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.
(Assignee)

Updated

17 years ago
Depends on: 53679
(Assignee)

Updated

17 years ago
Depends on: 75136
(Assignee)

Updated

17 years ago
Depends on: 75137
(Assignee)

Updated

17 years ago
Depends on: 40013
(Assignee)

Comment 12

17 years ago
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.
(Assignee)

Updated

17 years ago
Depends on: 75333
(Assignee)

Comment 13

17 years ago
See bug 75333 for details of latest roadblock

Updated

17 years ago
Target Milestone: --- → mozilla1.2
(Assignee)

Updated

17 years ago
Depends on: 76051
(Assignee)

Updated

17 years ago
Depends on: 76095
(Assignee)

Comment 14

17 years ago
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?
carbon? i thought you weren't building carbon. anyway, we require version 1.2 at 
minimum.
(Assignee)

Comment 16

17 years ago
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

17 years ago
This should not be mine. Reassigning to lordpixel@mac.com since he's been doing
all the work.
Assignee: jj → lordpixel

Comment 18

17 years ago
Closing as WONTFIX - see comments in 76051
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX

Comment 19

16 years ago
verified wontfix.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.