Closed Bug 75653 Opened 24 years ago Closed 23 years ago

Build changes for Fizzilla-Mach

Categories

(SeaMonkey :: Build Config, defect, P2)

PowerPC
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla0.9.6

People

(Reporter: mikepinkerton, Assigned: beard)

References

Details

(Keywords: meta)

Attachments

(24 obsolete files)

placeholder bug for build changes for the mach-o build of fizzilla.
Status: NEW → ASSIGNED
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 another. 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 quickly.
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 widget.
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 tired.
Attached patch updated patch (obsolete) — Splinter Review
In the above patch, I updated some of the files: nsprpub/configure.in: added "-traditional-cpp" to CFLAGS because this is needed by the LDAP build xpcom/build/Makefile.in: $(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 rules.mk:218 ALL_TRASH_DIRS). If you add a dummy name to that list, 'make clean' works: ALL_TRASH_DIRS = \ + .insane_directory_name \ $(GARBAGE_DIRS) However, this is just a hack. Any suggestions on how to fix this?
Attached patch jav's further changes (obsolete) — Splinter Review
Javier, 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. NOTES: - 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/Makefile.in. 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. ISSUES: ------- 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: _lchown 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 makefile.in for lib/mac/MoreFiles. I'll get to that asap so the patch works. ;)
Attached file lib/mac/MoreFiles/Makefile.in (obsolete) —
I have a Makefile.in for the lib/mac/MoreFiles directory. Attached above.
lib/mac/MoreFiles/Makefile.in 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/Makefile.in & 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/ nsRegionMac.o Needs to be run when you get the error about the missing nsRegionMac.o. We need to do something to mozilla/widget/src/mac/ Makefile.in 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, run: 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/ nsRegionMac.o 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 VPATH? Anyway, after you run my hack, run make again and all should be well until: /usr/bin/ld: Undefined symbols: _GetFullPath _FSpGetFullPath _FSpLocationFromFullPath 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?
questions: - 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? Zach
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/Makefile.in for a working example.
I created the following branch to allow us to land all mach-o related build changes: MACHO_20010807_BRANCH 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: xptcinvoke_asm_ppc_rhapsody.s
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 http://www.mozilla.org/ports/fizzilla/Mach.html
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 client.mk such that you can now pull the tree by doing "make -f client.mk pull_all" 2) I have XFree86 installed on my machine (for ddd), and configure.in 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 configure.in 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 client.mk from another branch and changed the tags. I'll try tonight, when I am at my mac.
I have checked in the changes to client.mk into the branch.
Try configure with --without-ldap. That should get you by the ldap error for the short term. Zach
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 module!) nsNativeComponentLoader: autoregistering succeeded ###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: '(!((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) ###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: '(!((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 ###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: '(!((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 ........................................................ done 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 nsCookieService.cpp:69 #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 nsGenericFactory.cpp:59 #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 nsRepository.cpp:81 #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 nsServiceManager.cpp:559 #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 nsViewerApp.cpp:264 #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 ?? () (gdb) 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 found 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))); (gdb) 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 nsURILoader.cpp:182 #9 0x17407414 in nsURILoader::OpenURIVia (this=0x7fe3f0, channel= 0x1ae703e0, aCommand=0, aWindowContext=0x7fe200, aLocalIP=0) at nsURILoader.cpp:521 #10 0x1740717c in nsURILoader::OpenURI (this=0x7fe3f0, channel= 0x1ae703e0, aCommand=0, aWindowContext=0x7fe200) at nsURILoader.cpp:482 #11 0x03b02614 in nsDocShell::DoChannelLoad (this=0x7fe200, aChannel=0x1ae703e0, aLoadCmd=0, aURILoader=0x7fe3f0) at nsDocShell.cpp:4805 #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 nsDocShell.cpp:4409 #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 nsViewerApp.cpp:703 #19 0x000021b8 in nsNativeViewerApp::Run (this=0x830550) at nsMacMain.cpp:159 #20 0x00002f84 in main (argc=1, argv=0xbffff9d8) at nsMacMain.cpp:459 #21 0x00001ff4 in _start () #22 0x00001e34 in start () #23 0x00000000 in ?? () (gdb)
zach, your problem is a missing resource. from beard's email: Also, when you're doing building, be sure to put a copy of mozilla/widget/src/mac/nsMacWidget.rsrc (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 Mozilla.app/Contents/Resources.
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% ./mozilla-viewer.sh ./run-mozilla.sh ./viewer MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=.:./plugins LIBRARY_PATH=.:./components SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./viewer MOZ_TOOLKIT= moz_debug=0 moz_debugger= arg[0] = ./viewer Type Manifest File: /Users/stevek/src/mozilla-macho/mozilla/dist/bin/components/xpti.dat nsNativeComponentLoader: autoregistering begins. nsNativeComponentLoader: autoregistering succeeded nNCL: registering deferred (0) Going to create the event queue WEBSHELL+ = 1 nsPluginHostImpl ctor ********** Got plugins path: /Users/stevek/src/mozilla-macho/mozilla/dist/bin/./plugins ###!!! 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 Mozilla.app and Viewer.app bundled applications on my local build. I have checked in the skeleton for creating the Mozilla.app/Contents folder here: mozilla/xpfe/bootstrap/macbuild/Contents I will check in similar files for Viewer.app. I will provide build targets to create these directories (application bundles). With a file called "Viewer.rsrc" included in Viewer.app/Contents/Resources, 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
Status: ASSIGNED → NEW
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: content/xbl/builtin/mac/Makefile.in lib/mac/MoreFiles/Makefile.in xpfe/browser/resources/content/mac/Makefile.in xpfe/browser/resources/locale/en-US/mac/Makefile.in xpfe/communicator/resources/content/mac/Makefile.in xpfe/global/resources/content/mac/Makefile.in xpfe/global/resources/locale/en-US/mac/Makefile.in I will mark the rest of the patches obsolete.
Attachment #30544 - Attachment is obsolete: true
Attachment #30705 - Attachment is obsolete: true
To create the Mozilla.app packaged folder, you'll also need to pull: mozilla/xpfe/bootstrap/macbuild/Contents 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 mozilla/xpfe/global/resources/content/mac/Makefile.in mozilla/xpfe/communicator/resources/content/mac/Makefile.in mozilla/xpfe/browser/resources/content/mac/Makefile.in mozilla/content/xbl/builtin/mac/Makefile.in (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?
zach: % 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 Makefile.in'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 following: % cd mozilla % patch -p1 < diff This even created the Makefile.in's.
In the patch, why do you remove "VPATH = @srcdir@" from widget/src/mac/Makefile.in? 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: _main 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 function) 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 ;) notes: - 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` setenv OBJROOT $SRCROOT/obj setenv DSTROOT $SRCROOT/dst make RC_OS=macos RC_ARCHS=ppc BOOTSTRAP= TARGETS=ppc SRCROOT=$SRCROOT OBJROOT=$OBJROOT DSTROOT=$DSTROOT 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 Makefile.in 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 Makefile.in's today: mozilla/content/xbl/builtin/mac/Makefile.in mozilla/xpfe/browser/resources/content/mac/Makefile.in mozilla/xpfe/communicator/resources/content/mac/Makefile.in mozilla/xpfe/global/resources/content/mac/Makefile.in
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))) { +#else + ProcessSerialNumber psn = {kNoProcess, kCurrentProcess}; +#endif 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"); +#else + char *moz5 = "X:Users:pedemont:build:mozilla:obj:dist:bin"; +#endif (etc.) 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 nsFileSpec.cpp? -#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/Makefile.in, 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 +static NS_IMETHODIMP +nsImageManagerImplConstructor(nsISupports* aOuter, REFNSIID aIID, void** aResult) +{ + NS_ENSURE_NO_AGGREGATION(aOuter); + NS_ENSURE_ARG_POINTER(aResult); + *aResult = nsnull; + nsCOMPtr<nsIImageManager> result; + nsresult rv = NS_NewImageManager(getter_AddRefs(result)); + NS_ENSURE_SUCCESS(rv, rv); + return result->QueryInterface(aIID, aResult); +} +#endif Ibid: +#if 0 + { "nsImageManagerImpl", + NS_IMAGEMANAGER_CID, + "@mozilla.org/gfx/imagemanager;1", + nsImageManagerImplConstructor }, +#endif 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: mozilla/config/Makefile.in mozilla/config/config.mk mozilla/content/xbl/builtin/Makefile.in mozilla/widget/src/mac/Makefile.in mozilla/xpfe/browser/resources/content/Makefile.in mozilla/xpfe/communicator/resources/content/Makefile.in mozilla/xpfe/global/resources/content/Makefile.in mozilla/widget/timer/src/mac/Makefile.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 configure.in reorg
Attachment #55061 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Next patch cleans up: mozilla/xpcom/io/nsFileSpec.cpp mozilla/webshell/tests/viewer/nsMacMain.cpp 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: mozilla/config/autoconf.mk.in mozilla/widget/src/Makefile.in
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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
i agree... BTW you can find the tinderbox at: http://tinderbox.mozilla.org/showbuilds.cgi?tree=MozillaTest 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.

Attachment

General

Created:
Updated:
Size: