Closed Bug 75653 Opened 23 years ago Closed 22 years ago

Build changes for Fizzilla-Mach


(SeaMonkey :: Build Config, defect, P2)



(Not tracked)



(Reporter: mikepinkerton, Assigned: beard)



(Keywords: meta)


(24 obsolete files)

placeholder bug for build changes for the mach-o build of fizzilla.
I think we need to test these changes on Mac classic builds, and Unix.
i'm building this on mac and linux now. for what it's worth, the patch as 
attached applied cleanly with no trouble using macCVSPro. goooooo mac!
blast! the further we get on this, the more we run into problems with |CR| 
defined globally in nsCRT.h. working around it in one place causes problems in 

maybe we should just try to use the unix file stuff in the short term, until we 
can get the other obstacles out of the way.

i'll attach pav's original osx patch to the bug (the one i've been pulling bits 
out of as needed) and maybe we can see if we can get it up and running more 
Depends on: 76060
Depends on: 75853
just submitted another patch, titled #2, where i have all of xpcom building with 
the mac file i/o. note that this requires a change to MachineExceptions.h in the 
carbon framework.

i've checked in a bunch of changes as i went, anything that was mostly harmless 
is now in the tree. go off the latest patch.
for those interested, i've been checking in changes as i go. the current patch is 
still valid, but all changes since are in the tree. i'm past gfx, but not yet to 
with the patch and the current tip, i can get up to where widget tries to link, 
but fails because of a couple things. shouldn't be hard to get past, but i'm 
Attached patch updated patch (obsolete) — Splinter Review
In the above patch, I updated some of the files:

nsprpub/ added "-traditional-cpp" to CFLAGS because this is needed 
by the LDAP build

xpcom/build/ $(topsrcdir) does not work for an objdir build; changed 
to look in $(DEPTH)

NOTES:  "make clean" fails when it tries to run the command "rm -rf" (with no 
arguments).  This is due to GARBAGE_DIRS having no value (see 
ALL_TRASH_DIRS).  If you add a dummy name to that list, 'make clean' works:

+	.insane_directory_name	\

However, this is just a hack.  Any suggestions on how to fix this?
Attached patch jav's further changes (obsolete) — Splinter Review
see bug 75895 for a discussion and patch for the make clean problem.
With the changes in the latest patch, the build goes all the way through.  Most 
of the changes are self-explanatory.

- NO_LD_ARCHIVE_FLAGS is set for our build because we don't define 
MKSHLIB_FORCE_ALL.  However, in some Makefiles, I needed to undefine 
NO_LD_ARCHIVE_FLAGS because some of the libs were getting include twice (once in 
the dylib and once explicitly in the Makefile).  The proper way around this is to 
actually define MKSHLIB_FORCE_ALL to "-Wl,-all_load".  However, this conflicts 
when passing in "-dynamiclib" (which implicitly passes '-noall_load' to libtool).  
I will try to investigate this further.

- We shouldn't explicitly set the path of a src file when passing it to CPPSRCS, 
such as in widget/src/mac/  Rather, set the VPATH to include that 
directory, and then just add the file to CPPSRCS. With the previous way, in an 
objdir, the object file was building in the source tree and could then not be 
found when linking.
Now, I can build all the way, but the browser does not come up.  It fails with 
several assertions about receiving a unix path when expecting a native path.  
Should we be compiling with the unix file support, instead?
i think we want the mac file stuff, so we can do things like handle aliases and 
find the correct locations for files using the mac way.
Attached patch additional patches for xpcom/io (obsolete) — Splinter Review
These are some additional changes in xpcom/io.  The only new change in 
nsFileSpec.h is a condition in the Error function.  In nsDirectoryServiceDefs.h I 
enable some of the UNIX defs under MACOSX - I think a netwerk file wanted one of 
them.  In nsDirectoryService::GetCurrentProcessDirectory, GetProcessInfo is 
returning -50, so I am trying to add a fallback to use getcwd() but I'm not doing 
something right. It doesnt compile: no matching function for call to 
`nsDerivedSafe<nsILocalFileMac>::InitWithPath (char[1024])'
Keywords: meta
Attached patch updated diff (obsolete) — Splinter Review
Newer patch with some more changes.  At the moment, I get to the point where autoregistering fails:

Type Manifest File: X:Users:pedemont:build:mozilla:obj:xpfe:bootstrap:Components
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering FAILED

I've attached the diff above.

There are some rather big issues debugging this thing with gdb.  The first one I have encountered is that GetProcessInformation fails when debugging.  You can see the hacks I put in to try to deal with this. Unfortunately, 'PR_getenv' also fails;  so I had to revert to hard coding the directory.  I don't know why these things fail when debugging only.  Is this a problem with gdb?
If I try to debug at the point I am at now, I get an assertion failure in one of the pthreads files.  I have no idea why this happens when running from gdb, but not when running by itself.
i pulled a clean trunk today and applied the 8/2 patch (fixed one small 
conflict in the patch, but unrelated to my problems) and i get the following 
error right off the bat (first thing it tries to build)

cc  nsinstall.o  -o nsinstall
/usr/bin/ld: Undefined symbols:

anyone else see this?
wtc says that nspr builds fine for him on beard's osx box. i wonder what 
could be different. cc'ing him just in case.
wtc says he knows what the problem is in nspr and is looking into it. i'll 
file a new bug.
Depends on: 93355
ok, it appears there needs to be some changes to the build instructions. i guess 
we have to run autoconf now or nspr won't build for some reason. i'll experiment 
and make the appropriate changes to the instructions. it's all voodoo to me ;)

i'm also now seeing a problem where we're looking for lib/mac/MoreFiles/Makefile 
and it doesn't exist. Why was this rule added when we don't have a makefile?
ok, appears we never checked in the for lib/mac/MoreFiles. I'll get 
to that asap so the patch works. ;)
Attached file lib/mac/MoreFiles/ (obsolete) —
I have a for the lib/mac/MoreFiles directory.  Attached above.
lib/mac/MoreFiles/ has been checked in.
Depends on: 93479
I'm dying building nsAppShell.cpp trying to find .deps/nsAppShell.pp. I _think_
I've correctly applied the path, although I can't be certain. At least I get
this far! Any chance of getting the changes on a branch instead of in a patch?
I've hit the problem with .deps/nsAppShell.pp a couple times.  Seems like I just 
manually create the .deps directory then the make will work.  I never looked into 
how its supposed to work.
Ok, making the .deps folder gets me past that. Now I do trying to build
nsMenuItemX.cpp with an error about sizeof being applied to an incomplete type,
nsIWidget, Order dependencies in the .h files?
Attached patch Updated diff (obsolete) — Splinter Review
Things that need to be fixed:

1) OS_ARCH=Rhapsody. As Rhapsody was a different beast than Darwin, I think all
references to Rhapsody should be removed and/or replaced with Darwin.  We don't
support building on Rhapsody so we shouldn't reference it.

2) XP_UNIX.  Although Darwin is a BSD unix underneath, I think there are enough
differences in  to warrant using XP_MACOSX (or XP_DARWIN) instead of (XP_UNIX &&
!MACOSX).  It makes the ifdefs cleaner and it will prevent unforseen OSX bustage
when people make unix-specific XP_UNIX changes. 

3) local headers.  If a header is not public (ie it's only used in a specific
directory or module), then it shouldn't be put in the EXPORTS list (example
being xpcom/io/ & ns{,I}LocalFileMac.h.  Instead use LOCAL_INCLUDES
to add the necessary directory to the include path.
to get around the failure in nsMenuItemX.h, just #include <nsIWidget.h> at 
the top. we'll add this to the next patch.
Actually, pinkerton just checked the changes in to nsMenuItemX.h. There is 
further bustage to fix in the region code, perhaps we need some more Makefile foo 
for that.
There is a chance that at some point, someone has the time to try again a GTK or
Xlib build on Darwin. I think it would be good to use XP_MACOSX for code that
requires Apple-only GUI stuff and reserve XP_DARWIN for things that are at the
Darwin level (don't require Apple's closed-source libs).
I agree about the Darwin thing, but shouldn't this just be another flavor of
XP_UNIX? The more Darwin specific stuff we can avoid, and instead address via
autoconf HAS_XXX style directives, the better.

Also, shouldn't X or Carbon/Quartz/Aqua just be different windowing toolkits?
Sure would be nice if we could just say ./configure --with-quartz or --with-x
and build from the same unix-y source base with different windowing toolkits.
I'm sure it's more involved in that, but getting away from the current MacOS
code and new MACOS_X directives and focusing on XP_UNIX with a new windowing
toolkit _sounds_ cool at least. The file/path stuff seems a good example of
where the current approach breaks down.
about 1/2 of the latest patch (from 8/3) doesn't apply with today's trunk. 
does someone want to post a patch that's current with the tip?
patch applies cleanly on the trunk, use mac cvs pro to apply. Also, I am in 
the process of hacking this to work and noticed one issue besides the 
creation of the .deps dir:

cp mozilla/gfx/src/mac/nsRegionMac.o mozilla/widget/src/mac/

Needs to be run when you get the error about the missing 
nsRegionMac.o. We need to do something to mozilla/widget/src/mac/ so that it searches mozilla/widget/src/mac for the file, how do 
we do this?
The problem of reaching gfx/src/mac/nsRegionMac.cpp from withing widget/src/mac is taken care of by having a VPATH that looks like this: "VPATH		= @srcdir@ @top_srcdir@/gfx/src/mac".  This tells gnu make to look for files in the current srcdir (widget/src/mac) and also at gfx/src/mac.  I have not had any problems with this; it always finds the files from gfx/src/mac.  I am building with an objdir, so the only issue I could see is if you are building within the source tree, and for some reason the VPATH argument is not working properly with a source tree build.  Is this what you see?
Also, I have not had any problems with the ".deps" dir.  For those that are seeing this problem, could you explain how you are building mozilla?  Thanks.
Everyone: I spent some time last night pounding this thing (and pinkerton) 
and discovered the following:

First, pull a fresh tree
Apply beard's patch (the last one on the bug) using mac cvs pro NOT 
PATCH, unless you like rm -rf mozilla and doing the checkout again. It's 
the good old cvs.m.o is broken issues...
Next, do an autoconf and ./configure, if you value your life run configure 
with --disable-xprint, otherwise the build stalls at xprint (I learned this one 
the hard way) --enable-xterm-updates will help debugging of the build by 
updating the title bar of the mac os x term. with the current directory that it 
is working on.

Now, do a make and watch it fail somewhere in widget. To fix this one, 

mkdir widget/src/mac/.deps

As a total hack, we should at the very least make the Makefile do this and 
make things work...

Run make again, notice that it fails. Run:

cp mozilla/gfx/src/mac/nsRegionMac.o mozilla/widget/src/mac/

to make things right again. What is happening here is that mozilla/widget/
src/mac/Makefile wants to call nsRegionMac.o, but can't find it because it 
is in mozilla/gfx/src/mac, even though the VPATH is set to mozilla/gfx/src/
mac. Perhaps agccn (Apple Gnu C Compiler Knockoff) doesn't accept 

Anyway, after you run my hack, run make again and all should be well 

/usr/bin/ld: Undefined symbols:
make[2]: *** [xpicleanup] Error 1

That's in mozilla/xpinstall/cleanup. Pinkerton thinks that we need to pull in 
stuff from the carbon framework there. That is also beyond my skill level. 
That seems to be our next task, beard, pinkerton, anyone?
- why are some people not seeing the .deps problem?
- why do we pull in nsMacRegion.o into widget? it's already in gfx, right?
- how can MCVSPro apply the patch when unix patch can't if the problem is on the 
cvs server side?
i just talked to smfr and he doesn't think the server has anything to do with the 
patch not applying cleanly, so what's up here?
I am not sure about the .deps issue, what is causing this in the first place
(something with autoconf, bryner, cls?) As to the patch issue, beard says that
m.o cvs is old and messed, and that it outputs diffs that patch thinks that
mozilla/gfx/src/mac/Makefile (random example) means mozilla/example, beard says
that mac cvs pro understands what to do and it works there. Or perhaps beard's
cvs client is old (or is it mac cvs pro :)? As to the Makefile issue, I'll try
to build with that file out of the Makefile tomorrow and see how things go,
also, does this mean that os x doesn't like VPATH?

Yes, cvs.m.o is running an older version of cvs that creates patches that don't
work properly when the file to be patched is in the current directory as well as
a subdirectory. Known problem (bug 72505).  Generate patches from mozilla/.. to
get around the problem.  

The .deps issue is a classic VPATH/srcdir problem.  Because .deps already exists
in $(srcdir)/gfx/src/mac, it won't be created in $(DEPTH)/widget/src/mac.  This
is only a problem when building in the src tree.  You will need to work around
it by setting MDDEPDIR to something other than .deps. See
modules/zlib/standalone/ for a working example.
I created the following branch to allow us to land all mach-o related build 


A soon as possible, I will check in all changes from my local tree, and we can 
start working together on getting this build working. One immediate fix to get in 
is a working version of:

Hmm the patch seems to apply with:
$ patch -p0 -posix < ../patch.diff  

The version of patch I use is:
$ patch -v 
Patch version 2.0, patch level 12u8

Note, this is the patch command specified in
All patches are now checked into the branch. I am now unable to get past
problems compiling mozilla/directory/c-sdk/ldap.
Attached patch update to MACHO_20010807_BRANCH (obsolete) — Splinter Review
Using the above diff, I finish building. Here are my changes:
1) Added the tag to such that you can now pull the tree by doing "make -f pull_all"
2) I have XFree86 installed on my machine (for ddd), and was finding the XFree86 dirs
     and enabling XPRINT.  Added "no_x=yes" to avoid this.
3) I had a break in widget/src/mac building an objdir build, until I added the VPATH statement

Also, we still have to run autoconf on the three configure.ins.  Normally, when is changed,
the configure file is regenerated by mozilla's autoconf.  Is this not happening with the branch?  Or
is MacOSX autoconf different from the 'regular' autoconf?
Javier, I looked at your patch, but I think my patch is simpler, and should pull 
ALL of the modules on our branch. Please let me know if it works for you. I 
tagged ALL of the files in the tree.
That should work.  All I had done was take the from another branch and
changed the tags.  I'll try tonight, when I am at my mac.
I have checked in the changes to into the branch.
Try configure with --without-ldap. That should get you by the ldap error for 
the short term.

After pulling a branch and building --without-ldap, I can get things to run 
(with beard's latest work that wen't in tonight in xpcom), but I hit the 
following assert during registration:

*** Registering nsSoftwareUpdate components (all right -- a generic 
nsNativeComponentLoader: autoregistering succeeded
'(!((rv) & 0x80000000))', file nsScriptSecurityManager.cpp, line 2275
###!!! Break: at file nsScriptSecurityManager.cpp, line 2275
WARNING: can't initialize JS engine security protocol glue!, file 
nsScriptSecurityManager.cpp, line 1959
nNCL: registering deferred (0)
'(!((rv) & 0x80000000))', file nsAppStartupNotifier.cpp, line 55
###!!! Break: at file nsAppStartupNotifier.cpp, line 55
###!!! ASSERTION: QueryInterface needed: 'query_result.get() == 
mRawPtr', file ../../../dist/include/nsCOMPtr.h, line 500
###!!! Break: at file ../../../dist/include/nsCOMPtr.h, line 500
'(!((rv) & 0x80000000))', file nsChromeRegistry.cpp, line 299
###!!! Break: at file nsChromeRegistry.cpp, line 299

What do we need to do for this?
Is this ever going to be assigned a priority and target?
I have managed to get things built (--without-ldap), but hit the following on 
launch (this is in gdb):

(gdb) run
Starting program: /Users/zach/mozilla/dist/bin/./viewer 
[Switching to thread 1 (process 26582 thread 0x1a03)]
Reading symbols for shared libraries ........................................................ 
Type Manifest File: /Users/zach/mozilla/dist/bin/Components/xpti.dat
nsNativeComponentLoader: autoregistering begins.
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries ... done
nsNativeComponentLoader: autoregistering succeeded
Reading symbols for shared libraries . done
nNCL: registering deferred (0)
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
0xbffff360 in ?? ()

Output from bt: 

(gdb) bt
#0  0xbffff360 in ?? ()
#1  0x010afbac in nsSupportsArray::AppendElement (this=0x11ce718, 
aElement=0x80004005) at nsSupportsArray.h:64
#2  0x010a622c in nsObserverList::AddObserver (this=0x7a42d0, 
anObserver=0x7a3f04) at nsObserverList.cpp:211
#3  0x010a7a7c in nsObserverService::AddObserver (this=0x7931e0, 
anObserver=0x7a3f04, aTopic=0xbffff528) at nsObserverService.cpp:158
#4  0x03828d04 in nsCookieService::Init (this=0x7a3f00) at 
#5  0x03825d10 in nsCookieServiceConstructor (aOuter=0x0, aIID=
@0x45098, aResult=0xbffff79c) at nsModuleFactory.cpp:41
#6  0x01106184 in nsGenericFactory::CreateInstance (this=0x7a3ea0, 
aOuter=0x0, aIID=@0x45098, aResult=0xbffff79c) at 
#7  0x011013a4 in nsComponentManagerImpl::CreateInstance (this=
0x423fe0, aClass=@0x407d0, aDelegate=0x0, aIID=@0x45098, aResult=
0xbffff79c) at nsComponentManager.cpp:1231
#8  0x011116e4 in nsComponentManager::CreateInstance (aClass=
@0x407d0, aDelegate=0x0, aIID=@0x45098, aResult=0xbffff79c) at 
#9  0x01112f74 in nsServiceManagerImpl::GetService (this=0x423a20, 
aClass=@0x407d0, aIID=@0x45098, result=0xbffff898, 
shutdownListener=0x0) at nsServiceManager.cpp:344
#10 0x011139b4 in nsServiceManager::GetService (aClass=@0x407d0, 
aIID=@0x45098, result=0xbffff898, shutdownListener=0x0) at 
#11 0x01112034 in nsGetServiceByCID::operator() (this=0xbffff944, aIID=
@0x45098, aInstancePtr=0xbffff898) at nsServiceManager.cpp:44
#12 0x0003be28 in nsCOMPtr<nsICookieService>::assign_from_helper 
#13 0x0003bfc4 in nsCOMPtr<nsICookieService>::nsCOMPtr ()
#14 0x0001a9f4 in nsViewerApp::SetupRegistry (this=0x7930e0) at 
#15 0x0001aba8 in nsViewerApp::Initialize (this=0x7930e0, argc=1, argv=
0xbffffaac) at nsViewerApp.cpp:289
#16 0x00002f44 in main (argc=1, argv=0xbffffaac) at nsMacMain.cpp:458
#17 0x00001ff4 in _start ()
#18 0x00001e34 in start ()
#19 0x00000001 in ?? ()

Any idea what to do with this one?
zach:  first of all, you shouldn't need to run "--without-ldap".  It builds fine
for me, as long as I run autoconf in mozilla, mozilla/nsprpub, and
mozilla/directory/c-sdk/ldap.  Afterwards, I build fine.
As for EXC_BAD_ACCESS, I only get this when running mozilla in gdb twice in a
row.  Quitting gdb and restarting takes care of this.  Don't know what the root
cause is.

Also, in general, I am still concerned about going down the UNIX file I/O path.
 Is this just a temporary thing to get things working, or do we intend to hack
up the unix files with MACOSX specific code in order to build?  I have looked at
the Mac file I/O files, and there are two major areas that we would need to
take: XPCOM and NSPR.  The NSPR files are the trickiest, though:  we use
pthreads, which defines its own I/O functions.  I don't know how hard it would
be to use both pthreads and Mac I/O.  Any comments on this?
We are taking the branch down UNIX file I/O for convenience. Today, in the
macdev meeting, we discussed creating a hybrid implementation of nsILocalFile
that would be based on the nsLocalFile for UNIX, but would also implement the
nsILocalFileMac  interface.
Priority: -- → P3
Target Milestone: --- → mozilla1.0
this is a meta-bug, so i'd prefer to leave it untargeted. it also stays at the 
top of my list that way. we all know we're working hard on this, so it doesn't 
have to have a milestone attached.
Priority: P3 → P2
Target Milestone: mozilla1.0 → ---
ok, with ldap, and without getting the stack twice, here is the real error:

********** Got plugins path: /Users/zach/mozilla/dist/bin/./plugins
kCGSErrorNoneAvailable : CGSOrderFrontConditionally: Process not 

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x18700a30 in nsWindow::SetCursor (this=0x7fdef0, aCursor=
eCursor_spinning) at nsWindow.cpp:681
681                             ::SetCursor(*(::GetCursor(cursor)));

Output from a bt:

(gdb) bt
#0  0x18700a30 in nsWindow::SetCursor (this=0x7fdef0, aCursor=
eCursor_spinning) at nsWindow.cpp:681
#1  0x03afd094 in nsDocShell::OnStateChange (this=0x7fe200, 
aProgress=0x7fe4e4, aRequest=0x1ae6f570, aStateFlags=458753, 
aStatus=0) at nsDocShell.cpp:3639
#2  0x1740c97c in nsDocLoaderImpl::FireOnStateChange (this=
0x7fe4d0, aProgress=0x7fe4e4, aRequest=0x1ae6f570, aStateFlags=
458753, aStatus=0) at nsDocLoader.cpp:1094
#3  0x1740b510 in nsDocLoaderImpl::doStartDocumentLoad (this=
0x7fe4d0) at nsDocLoader.cpp:661
#4  0x1740add0 in nsDocLoaderImpl::OnStartRequest (this=0x7fe4d0, 
request=0x1ae6f570, aCtxt=0x0) at nsDocLoader.cpp:477
#5  0x12d400e0 in nsLoadGroup::AddRequest (this=0x7fe560, request=
0x1ae6f570, ctxt=0x0) at nsLoadGroup.cpp:450
#6  0x12daa080 in nsFileChannel::AsyncOpen (this=0x1ae6f570, 
listener=0x1ae703e8, ctxt=0x0) at nsFileChannel.cpp:286
#7  0x12db8aa8 in nsResChannel::AsyncOpen (this=0x1ae703e0, 
listener=0x1ae70440, ctxt=0x0) at nsResChannel.cpp:405
#8  0x174059c8 in nsDocumentOpenInfo::Open (this=0x1ae70440, 
aChannel=0x1ae703e0, aCommand=0, aWindowContext=0x7fe200) at 
#9  0x17407414 in nsURILoader::OpenURIVia (this=0x7fe3f0, channel=
0x1ae703e0, aCommand=0, aWindowContext=0x7fe200, aLocalIP=0) at 
#10 0x1740717c in nsURILoader::OpenURI (this=0x7fe3f0, channel=
0x1ae703e0, aCommand=0, aWindowContext=0x7fe200) at 
#11 0x03b02614 in nsDocShell::DoChannelLoad (this=0x7fe200, 
aChannel=0x1ae703e0, aLoadCmd=0, aURILoader=0x7fe3f0) at 
#12 0x03b01d3c in nsDocShell::DoURILoad (this=0x7fe200, aURI=
0x1ae70380, aReferrerURI=0x0, aOwner=0x0, aLoadCmd=0, aPostData=
0x0, aHeadersData=0x0) at nsDocShell.cpp:4592
#13 0x03b00ea8 in nsDocShell::InternalLoad (this=0x7fe200, aURI=
0x1ae70380, aReferrer=0x0, aOwner=0x0, aInheritOwner=1, 
aStopActiveDoc=0, aWindowTarget=0xbffff1e8, aPostData=0x0, 
aHeadersData=0x0, aLoadType=1, aSHEntry=0x0) at 
#14 0x03aecc6c in nsDocShell::LoadURI (this=0x7fe200, aURI=
0x1ae70380, aLoadInfo=0x0, aLoadFlags=0) at nsDocShell.cpp:602
#15 0x03af60b4 in nsDocShell::LoadURI (this=0x7fe200, aURI=
0x7a86b0, aLoadFlags=0) at nsDocShell.cpp:2251
#16 0x17d13ac8 in nsWebBrowser::LoadURI (this=0x7fdb70, aURI=
0x7a86b0, aLoadFlags=0) at nsWebBrowser.cpp:563
#17 0x0000c5ec in nsBrowserWindow::GoTo (this=0x7de2a0, aURL=
0x7a86b0) at nsBrowserWindow.cpp:1090
#18 0x0001c37c in nsViewerApp::OpenWindow (this=0x830550) at 
#19 0x000021b8 in nsNativeViewerApp::Run (this=0x830550) at 
#20 0x00002f84 in main (argc=1, argv=0xbffff9d8) at nsMacMain.cpp:459
#21 0x00001ff4 in _start ()
#22 0x00001e34 in start ()
#23 0x00000000 in ?? ()

zach, your problem is a missing resource. from beard's email:

Also, when you're doing building, be sure to put a copy of


(pulled using MacCVS or decoded from AppleSingle)

into ~/Library/libwidget.rsrc. Eventually we should just probably 
make this the actual Mozilla.rsrc we put into
I dunno if you all have been working on the branch today, but I just built it,
and was able to get the viewer running.

It isn't able to load the menus, and the big mozilla doesn't get too far, but
the viewer came up and gives me a rendered page.  (the back/forward buttons
don't work, the URL area doesn't accept input, and there are no scrollbars).

Here's the output from loading the viewer:

[localhost:mozilla/dist/bin] stevek% ./ 
./ ./viewer
arg[0] = ./viewer
Type Manifest File:
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
Going to create the event queue
nsPluginHostImpl ctor
********** Got plugins path:
###!!! ASSERTION: menu failed to load: 'menu', file nsMacMain.cpp, line 249
###!!! Break: at file nsMacMain.cpp, line 249
###!!! ASSERTION: menu failed to load: 'menu', file nsMacMain.cpp, line 249
###!!! Break: at file nsMacMain.cpp, line 249
###!!! ASSERTION: menu failed to load: 'menu', file nsMacMain.cpp, line 249
###!!! Break: at file nsMacMain.cpp, line 249
###!!! ASSERTION: menu failed to load: 'menu', file nsMacMain.cpp, line 249
###!!! Break: at file nsMacMain.cpp, line 249
###!!! ASSERTION: menu failed to load: 'menu', file nsMacMain.cpp, line 249
###!!! Break: at file nsMacMain.cpp, line 249
###!!! ASSERTION: menu failed to load: 'menu', file nsMacMain.cpp, line 249
###!!! Break: at file nsMacMain.cpp, line 249
###!!! ASSERTION: menu failed to load: 'menu', file nsMacMain.cpp, line 249
###!!! Break: at file nsMacMain.cpp, line 249
Start reading in bookmarks.html
Opening file bookmarks.html failed
Finished reading in bookmarks.html  (132334 microseconds)
###!!! ASSERTION: failed to create xul atoms namespace manager: '0', file
nsXULAtoms.cpp, line 55
###!!! Break: at file nsXULAtoms.cpp, line 55
Disabling Quirk StyleSheet
Enabling Quirk StyleSheet
Note: verifyreflow is disabled
Note: styleverifytree is disabled
###!!! ASSERTION: QueryInterface needed: 'query_result.get() == mRawPtr', file
../../../../dist/include/nsCOMPtr.h, line 500
###!!! Break: at file ../../../../dist/include/nsCOMPtr.h, line 500
###!!! ASSERTION: QueryInterface needed: 'query_result.get() == mRawPtr', file
../../../../dist/include/nsCOMPtr.h, line 500
###!!! Break: at file ../../../../dist/include/nsCOMPtr.h, line 500
Note: frameverifytree is disabled
Starting mozilla gives many many failed assertions, etc., and then finally a
dialog named "Alert" that says "Error creating browser instance", which doesn't
accept focus.

Anyways, I imagine you have found the same results already, so this report is
probably extraneous, but figured I'd post for the "woo-hoo" value anyways.

So, "woo-hoo".
Yes, viewer and in fact mozilla-bin are running. I have and bundled applications on my local build. I have checked in the
skeleton for creating the folder here:


I will check in similar files for I will provide build targets to
create these directories (application bundles). With a file called "Viewer.rsrc"
included in, I am able to use the menus.
*** Bug 58799 has been marked as a duplicate of this bug. ***
Just a note, you should probably switch from using -traditional-cpp to
-no-cpp-precomp for compatibility with GCC 3.1 when that finally rolls around.
Better safe than sorry :)
Reassigning to beard as the plan is to carpool these changes in sometime soon
Assignee: pinkerton → beard
Target Milestone: --- → mozilla0.9.5
Blocks: 102998
Why don't we have an entry on the branch landings page for this?
Landing will happen in 0.9.6 timeframe.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Can the tip patches be posted somewhere?
Attached patch Latest patches to trunk. (obsolete) — Splinter Review
To build with these latest patches, you'll also need to pull the following files
from the MACHO_20010807_BRANCH:


I will mark the rest of the patches obsolete.
Attachment #30544 - Attachment is obsolete: true
Attachment #30705 - Attachment is obsolete: true
To create the packaged folder, you'll also need to pull:


from the branch.
Attachment #30911 - Attachment is obsolete: true
Attachment #30925 - Attachment is obsolete: true
Attachment #31933 - Attachment is obsolete: true
i noticed smfr's latest changes to nsSound broke the latest patch. :(
Attachment #31938 - Attachment is obsolete: true
Attachment #32528 - Attachment is obsolete: true
Attachment #44379 - Attachment is obsolete: true
Attachment #44505 - Attachment is obsolete: true
Attachment #44649 - Attachment is obsolete: true
Attachment #45231 - Attachment is obsolete: true
Attachment #45279 - Attachment is obsolete: true
I have my usual requests based upon the assumptions that Rhapsody & Darwin are
distinct systems and we no longer "support" Rhapsody:

1) Remove the hardcoding of OS_ARCH & OS_TARGET to Rhapsody

2) Replace all OS_ARCH & OS_TARGET checks for Rhapsody to Darwin

3) Change -DMACOSX to -DXP_MACOSX for consistency.

4) Is there really any reason to have a -DDARWIN (or -DRHAPSODY)?  If not, then
remove the defines and replace any references with -DXP_MACOSX.

5) The |if defined(XP_UNIX) && !defined(MACOSX)| checks seem to be unneeded as
darwin doesn't define XP_UNIX in Mozilla.  It does in nspr.

6) Likewise for the |if defined(XP_MAC) && !defined(MACOSX))| checks.

Can you break at least the nspr & ldap portions of the patch into separate
chunks so that their owners can review those smaller bits?

pink: i have a new patch with changes to account for smfr's mods to nsSound.cpp
... will attach it as soon as my build completes.
darin: how is that patch coming?
Attachment #53607 - Attachment is obsolete: true
This fails for me unless I use --without-x to configure
zach: yup.. you'll need that if you have the X libraries installed.
Actually, I thought I hit stop in time to cancel that post, I figured out. I forgot 
to run autoconf in all the right places first :(

Sorry about that
Simon's new printing code busts us. Patch coming up.
Attachment #53897 - Attachment is obsolete: true
With the latest patch, do I need to check out makefiles from the branch or is
mozilla/xpfe/bootstrap/macbuild/Contents the only file needed fromt the branch?
OK. I used only these makefiles
(Checked out after applying the patch.)

Previously I had checked out more makefiles from the branch and applied the
patch only after checking out from the branch.

Now FizzillaMach compiles and runs. I'm using it right now.

Thanks for making the Mach build work!
How does one apply the patch? I tried with -p0 and --psoix, but it refused 
to create new files, when I tried without --posix, it wouldn't work at all. 
When I used maccvspro, it created new files with mac linebreaks, 
causing all sorts of problems, can someone just check this in on a 
branch or something?

% cd /path/to/mozilla
% cd ..
% patch -p0 --posix < /path/to/patch

this works for me.
with a freshly pulled tree, the patch _does not_ apply. the new files confuse
patch and it keeps asking what files to patch since they don't exist.

skipping them and pulling from the branch doesn't work because they're out of
sync and need constant fixing.

can someone post a patch that applies to a clean, freshly pulled tree?
when patch complains that the file does not exist, all you have to do is create
the file (make sure it is completely empty) and then give patch the path to the
file you just created.  do this for each file that does not exist and you should
be good to go.

we should probably try to get these's checked in ASAP since they
aren't apart of any other build.
pinkerton:  I was able to apply the latest patch to a fresh tree by doing the
  % cd mozilla
  % patch -p1 < diff
This even created the's.
In the patch, why do you remove "VPATH = @srcdir@" from
widget/src/mac/  This is necessary to build an OBJDIR build.
We removed it because it was messing up our build. We will work on restoring it
as soon as this is checked into the tree. I don't use an OBJDIR in my build.
wow, you're right. that just worked. why does the --posix mess it up? well,
building now, we'll see how far i get...thanks!
The patch doesn't apply on a fresh checkout ; patch -p1 < diff tells me :

Reversed (or previously applied) patch detected!  Assume -R? [n]
for MANY files.

As a result, some files aren't corrected. The compile fails either (with one
checkout, different tries with the patch, etc.) at
c++ [...] -o libxpcom.dylib  nsXPComInit.o  pldhash.o plvector.o nsArena.o
nsAtomTable.o nsAtomService.o nsAVLTree.o nsByteBuffer.o nsCRT.o
nsConjoiningEnumerator.o nsDeque.o
nsEmptyEnumerator.o nsEnumeratorUtils.o nsFixedSizeAllocator.o nsHashtable.o
nsHashtableEnumerator.o nsObserver.o nsObserverList.o nsObserverService.o
nsProperties.o nsPersistentProperties.o nsQuickSort.o nsSizeOfHandler.o
nsStaticNameTable.o nsStatistics.o nsSupportsArray.o nsSupportsArrayEnumerator.o
nsSupportsPrimitives.o nsUnicharBuffer.o nsVoidArray.o nsVoidBTree.o
nsTextFormatter.o nsAppFileLocationProvider.o nsBinaryStream.o
nsByteArrayInputStream.o nsDirectoryService.o nsEscape.o nsFastLoadFile.o
nsFastLoadService.o nsFileSpec.o nsFileSpecImpl.o nsFileSpecStreaming.o
nsFileStream.o nsIFileStream.o nsIStringStream.o nsInputStreamTee.o
nsLinebreakConverter.o nsLocalFileCommon.o nsPipe2.o nsScriptableInputStream.o
nsSegmentedBuffer.o nsSpecialSystemDirectory.o nsStorageStream.o
nsUnicharInputStream.o nsLocalFileUnix.o nsComponentManager.o nsGenericFactory.o
nsNativeComponentLoader.o nsRegistry.o nsRepository.o nsServiceManager.o
nsCategoryManager.o xcDll.o plevent.o nsAutoLock.o nsEventQueue.o
nsEventQueueService.o nsThread.o nsProcessCommon.o nsProxyEvent.o
nsProxyEventClass.o nsProxyEventObject.o nsProxyObjectManager.o
nsLogging.o nsAllocator.o nsMemoryImpl.o nsErrorService.o nsDebug.o
nsIInterfaceRequestor.o nsTraceRefcnt.o nsCOMPtr.o nsID.o nsCWeakReference.o
nsWeakReference.o nsConsoleService.o nsConsoleMessage.o nsExceptionService.o
xptcall.o xptiFile.o xptiInterfaceInfo.o xptiInterfaceInfoManager.o
xptiManifest.o xptiMisc.o xptiTypelibGuts.o xptiWorkingSet.o xptiZipItem.o
xptiZipLoader.o xpt_arena.o xpt_struct.o xpt_xdr.o xptcinvoke_ppc_rhapsody.o
xptcstubs_ppc_rhapsody.o xptcinvoke_asm_ppc_rhapsody.o
xptcstubs_asm_ppc_rhapsody.o reg.o VerReg.o vr_stubs.o nr_bufio.o
nsAFlatString.o nsAString.o nsDependentConcatenation.o nsDependentString.o
nsDependentSubstring.o nsFragmentedString.o nsPrintfCString.o
nsPrivateSharableString.o nsPromiseFlatString.o nsReadableUtils.o
nsSharableString.o nsSharedBufferList.o nsSlidingString.o nsXPIDLString.o
nsStr.o nsString.o nsString2.o -framework Carbon 
../../dist/lib/libmacmorefiles_s.a ../../dist/lib/libmacmorefiles_s.a
-L../../dist/bin -L/Users/thomas/Documents/Darwin-Unix/fizmach/mozilla/dist/lib
-lplds4 -lplc4 -lnspr4 -lpthread  -lm
/usr/bin/ld: Undefined symbols:
make[2]: *** [libxpcom.dylib] Erreur 1
make[1]: *** [install] Erreur 2
make: *** [install] Erreur 2

either (with a fresh checkout) at :

nsSpecialSystemDirectory.cpp: In function `void
GetCurrentProcessDirectory(nsFileSpec &)':
nsSpecialSystemDirectory.cpp:425: `SystemDirectories' undeclared (first use this
nsSpecialSystemDirectory.cpp:425: (Each undeclared identifier is reported only once
nsSpecialSystemDirectory.cpp:425: for each function it appears in.)
nsSpecialSystemDirectory.cpp:425: parse error before `)'
finally got it all built and put together. man, is it ugly ;)

- xpmenus don't dismiss
- gtk classic skin
- cmd-q launches composer
- no quit item in file (must be missing platform overlay)

...but scrollwheel works! ;)
Thomas Deniau:  If you get "Reversed (or previously applied) patch detected",
that usually means that you have already applied the patch.  None of these
changes seem to have been checked into the trunk yet, so make sure it is
actaully a clean build.

Pinkerton:  Am I right in assuming that the post-10.1 compiler is still needed
to get the build working?  Is there any news on this situation?
I've been told that we should be able to pull Apple's latest gcc from the 
Darwin repository, and build just fine with that. This is unconfirmed. 
Here're the commands required to pull and build gcc (assuming you have 
an appropriate CVSROOT and you've already logged in):

cvs co gcc
cd gcc
rm -rf obj dst
setenv SRCROOT `pwd`

Once it's built, you replace bits in /usr/libexec/gcc with bits you'll find in the 
dst directory.
*** Bug 76134 has been marked as a duplicate of this bug. ***
No longer depends on: 76060
*** Bug 76060 has been marked as a duplicate of this bug. ***
one more thing, the mach-o build suffers from the 'rainbow text' bug. it looks
like we didn't fix the xptcall byte-alignment bugs when we fixed it for the CFM
build. whatever changes we made need to be applied here as well.
ok, i carried over the patches from bug 98290 and it seems to work better, no
more rainbows. Should i try to land this whole file on the trunk (easy, since
it's not being built) or wait so the patch doesn't get messed up?
I noticed the rainbox text problem in the print dialog. I'll fix this today.
I think it would be a good plan to land ALL of the changes that aren't 
currently being built by a tinderbox. That would include most of the patches that are in Mac-specific directories. Of course, these 
are the least likely to change, but it will reduce the patch we need to carry 
around. After you do that, just delete those from the patch in the bug, and 
reattach the revised patch.
xptcall changes landed on trunk. will remove from patch.
Attachment #53914 - Attachment is obsolete: true
Speaking of a Fizzilla-Mach tbox - there's a B&W G3 sitting in my cube that has 
beed donated for this task.  Patrick, can you or Darin grab that machine and work 
with JJ & mcafee to get it set up?  
Attachment #54219 - Attachment is obsolete: true
Attachment #54624 - Attachment is obsolete: true
Attachment #54628 - Attachment is obsolete: true
checked in the following's today:

These changes in xpcom/io/nsDirectoryService.cpp look a bit weird. 
Could you double check them? (Also, indenting got goofed here and 
elsewhere in this file -- use spaces, not tabs!)

+#if 0
     ProcessSerialNumber psn;
     if (!(err = GetCurrentProcess(&psn)))
+       ProcessSerialNumber psn = {kNoProcess, kCurrentProcess};

This whole tract of code (starting with what's below) also looks suspect. 
Same file.

+#if defined(DEBUG) && defined(MACOSX)
+               else
+               {
+               // In the absence of a good way to get the executable directory let
+               // us try this for unix:
+               //      - if MOZILLA_FIVE_HOME is defined, that is it
+#if 0
+                   char *moz5 = PR_GetEnv("MOZILLA_FIVE_HOME");
+                   char *moz5 = "X:Users:pedemont:build:mozilla:obj:dist:bin";

Looks like similar hackery in xpcom/io/nsSpecialSystemDirectory? (Both 
of the previous two comments apply there, as well.)

Urgh, did you really want to just comment this code out in 

-#elif defined(RHAPSODY)
-#include "nsFileSpecMac.cpp" // Macintosh-specific implementations
-#include "nsFileSpecUnix.cpp" // Unix-specific implementations
+//#elif defined(MACOSX)
+//#include "nsFileSpecMac.cpp" // Macintosh-specific implementations

In gfx/src/mac/, looks like there's a dropping left. Kill it?

+#                $(DIST)/lib/libimg_s.a \

In nsGfxFactoryMac.cpp, do you want to leave this in there?

+#if 0
+nsImageManagerImplConstructor(nsISupports* aOuter, REFNSIID aIID, 
void** aResult)
+  *aResult = nsnull;
+  nsCOMPtr<nsIImageManager> result;
+  nsresult rv = NS_NewImageManager(getter_AddRefs(result));
+  return result->QueryInterface(aIID, aResult);


+#if 0
+  { "nsImageManagerImpl",
+    ";1",
+    nsImageManagerImplConstructor },

Ugh, you're killing me with the indentation in webshell/tests/viewer/
nsMacMain.cpp! ;-)

        for (int i = menu_First; i <= menu_Last; i++)
-               InsertMenu(GetMenu(i), 0);
+    MenuHandle menu = GetMenu(i);
+    NS_ASSERTION(menu, "menu failed to load");
+    if (menu) InsertMenu(menu, 0);

Fix above, or otherwise convince yourself that it's okay, and sr=waterson.
The following makefiles were checked in:


I spun off 2 bugs for the nspr (bug 106617) & ldap (bug 106627) changes.  I
removed the rhapsody references from the tree and replaced them with XP_MACOSX &
DARWIN where appropriate.   I also made the -DMACOSX -> -DXP_MACOSX change.

Attachment #54727 - Attachment is obsolete: true
just to be clear, in addition to the patch in this bug, you must apply the
patches in cls' two spin-off bugs. you'll know you didn't because you die
building LDAP.
i've updated the build instructions to not talk about the branch and to
reference the compiler on turly's iDisk. Let me know if there are any problems.
Comment on attachment 55061 [details] [diff] [review]
Remove rhapsody references & switched to using -DXP_MACOSX

Missing a couple of bits & won't apply cleanly after the reorg
Attachment #55061 - Attachment is obsolete: true
Next patch cleans up:


This should take care of all the issues waterson raised.
Attachment #55284 - Attachment is obsolete: true
Attachment #55332 - Attachment is obsolete: true
Huzzah! Ship it!
Patch coming up that should get macho running again. This adds patches for:

Attachment #55337 - Attachment is obsolete: true
Attachment #55370 - Attachment is obsolete: true
The rest of the macho changes have landed on the trunk.  No further patches (at
this time) are needed.  Have a nice weekend.

thanks to everyone who helped out with this landing! we couldn't have done it
without you.
Since we now have a tinderbox for mach-o, and these changes have 
landed, I move we close this bug.
Closed: 22 years ago
Resolution: --- → FIXED
i agree... BTW you can find the tinderbox at:

hopefully it'll soon make its way onto the ports page.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.