Closed
Bug 75653
Opened 24 years ago
Closed 23 years ago
Build changes for Fizzilla-Mach
Categories
(SeaMonkey :: Build Config, defect, P2)
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.
Reporter | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
I think we need to test these changes on Mac classic builds, and Unix.
Reporter | ||
Comment 3•24 years ago
|
||
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!
Reporter | ||
Comment 4•24 years ago
|
||
Reporter | ||
Comment 5•24 years ago
|
||
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.
Reporter | ||
Comment 6•24 years ago
|
||
Reporter | ||
Comment 7•24 years ago
|
||
Reporter | ||
Comment 8•24 years ago
|
||
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.
Reporter | ||
Comment 9•24 years ago
|
||
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.
Reporter | ||
Comment 10•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
Comment 12•24 years ago
|
||
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?
Comment 13•24 years ago
|
||
Comment 14•24 years ago
|
||
Javier,
see bug 75895 for a discussion and patch for the make clean problem.
Comment 15•24 years ago
|
||
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.
Comment 16•24 years ago
|
||
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?
Reporter | ||
Comment 17•24 years ago
|
||
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.
Comment 18•24 years ago
|
||
Comment 19•24 years ago
|
||
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])'
Comment 20•23 years ago
|
||
Comment 21•23 years ago
|
||
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.
Reporter | ||
Comment 22•23 years ago
|
||
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?
Reporter | ||
Comment 23•23 years ago
|
||
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.
Reporter | ||
Comment 24•23 years ago
|
||
wtc says he knows what the problem is in nspr and is looking into it. i'll
file a new bug.
Reporter | ||
Comment 25•23 years ago
|
||
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?
Reporter | ||
Comment 26•23 years ago
|
||
ok, appears we never checked in the makefile.in for lib/mac/MoreFiles. I'll get
to that asap so the patch works. ;)
Comment 27•23 years ago
|
||
Comment 28•23 years ago
|
||
I have a Makefile.in for the lib/mac/MoreFiles directory. Attached above.
Reporter | ||
Comment 29•23 years ago
|
||
lib/mac/MoreFiles/Makefile.in has been checked in.
Comment 30•23 years ago
|
||
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?
Comment 31•23 years ago
|
||
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.
Comment 32•23 years ago
|
||
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?
Assignee | ||
Comment 33•23 years ago
|
||
Comment 34•23 years ago
|
||
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.
Reporter | ||
Comment 35•23 years ago
|
||
to get around the failure in nsMenuItemX.h, just #include <nsIWidget.h> at
the top. we'll add this to the next patch.
Assignee | ||
Comment 36•23 years ago
|
||
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.
Comment 37•23 years ago
|
||
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).
Comment 38•23 years ago
|
||
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.
Reporter | ||
Comment 39•23 years ago
|
||
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?
Comment 40•23 years ago
|
||
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?
Comment 41•23 years ago
|
||
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.
Comment 42•23 years ago
|
||
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?
Reporter | ||
Comment 43•23 years ago
|
||
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?
Reporter | ||
Comment 44•23 years ago
|
||
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?
Comment 45•23 years ago
|
||
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
Comment 46•23 years ago
|
||
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.
Assignee | ||
Comment 47•23 years ago
|
||
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
Comment 48•23 years ago
|
||
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
Assignee | ||
Comment 49•23 years ago
|
||
All patches are now checked into the branch. I am now unable to get past
problems compiling mozilla/directory/c-sdk/ldap.
Comment 50•23 years ago
|
||
Comment 51•23 years ago
|
||
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?
Assignee | ||
Comment 52•23 years ago
|
||
Assignee | ||
Comment 53•23 years ago
|
||
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.
Comment 54•23 years ago
|
||
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.
Assignee | ||
Comment 55•23 years ago
|
||
I have checked in the changes to client.mk into the branch.
Comment 56•23 years ago
|
||
Try configure with --without-ldap. That should get you by the ldap error for
the short term.
Zach
Comment 57•23 years ago
|
||
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?
Comment 58•23 years ago
|
||
Is this ever going to be assigned a priority and target?
Comment 59•23 years ago
|
||
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?
Comment 60•23 years ago
|
||
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?
Assignee | ||
Comment 61•23 years ago
|
||
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
Reporter | ||
Comment 62•23 years ago
|
||
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 → ---
Comment 63•23 years ago
|
||
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)
Reporter | ||
Comment 64•23 years ago
|
||
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.
Comment 65•23 years ago
|
||
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".
Assignee | ||
Comment 66•23 years ago
|
||
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.
Comment 67•23 years ago
|
||
*** Bug 58799 has been marked as a duplicate of this bug. ***
Comment 68•23 years ago
|
||
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 :)
Comment 69•23 years ago
|
||
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
Comment 70•23 years ago
|
||
Why don't we have an entry on the branch landings page for this?
Assignee | ||
Comment 71•23 years ago
|
||
Landing will happen in 0.9.6 timeframe.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Comment 72•23 years ago
|
||
Can the tip patches be posted somewhere?
Assignee | ||
Comment 73•23 years ago
|
||
Assignee | ||
Comment 74•23 years ago
|
||
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.
Assignee | ||
Updated•23 years ago
|
Attachment #30544 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #30705 -
Attachment is obsolete: true
Assignee | ||
Comment 75•23 years ago
|
||
To create the Mozilla.app packaged folder, you'll also need to pull:
mozilla/xpfe/bootstrap/macbuild/Contents
from the branch.
Assignee | ||
Updated•23 years ago
|
Attachment #30911 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #30925 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #31933 -
Attachment is obsolete: true
Reporter | ||
Comment 76•23 years ago
|
||
i noticed smfr's latest changes to nsSound broke the latest patch. :(
Assignee | ||
Updated•23 years ago
|
Attachment #31938 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #32528 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #44379 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #44505 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #44649 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #45231 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #45279 -
Attachment is obsolete: true
Comment 77•23 years ago
|
||
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?
Comment 78•23 years ago
|
||
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.
Comment 79•23 years ago
|
||
darin: how is that patch coming?
Assignee | ||
Comment 80•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Attachment #53607 -
Attachment is obsolete: true
Comment 81•23 years ago
|
||
This fails for me unless I use --without-x to configure
Comment 82•23 years ago
|
||
zach: yup.. you'll need that if you have the X libraries installed.
Comment 83•23 years ago
|
||
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
Assignee | ||
Comment 84•23 years ago
|
||
Simon's new printing code busts us. Patch coming up.
Assignee | ||
Comment 85•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Attachment #53897 -
Attachment is obsolete: true
Comment 86•23 years ago
|
||
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?
Comment 87•23 years ago
|
||
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!
Comment 88•23 years ago
|
||
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?
Comment 89•23 years ago
|
||
zach:
% cd /path/to/mozilla
% cd ..
% patch -p0 --posix < /path/to/patch
this works for me.
Reporter | ||
Comment 90•23 years ago
|
||
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?
Comment 91•23 years ago
|
||
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.
Comment 92•23 years ago
|
||
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.
Comment 93•23 years ago
|
||
In the patch, why do you remove "VPATH = @srcdir@" from
widget/src/mac/Makefile.in? This is necessary to build an OBJDIR build.
Assignee | ||
Comment 94•23 years ago
|
||
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.
Reporter | ||
Comment 95•23 years ago
|
||
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!
Comment 96•23 years ago
|
||
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 `)'
Reporter | ||
Comment 97•23 years ago
|
||
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! ;)
Comment 98•23 years ago
|
||
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?
Assignee | ||
Comment 99•23 years ago
|
||
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.
Comment 100•23 years ago
|
||
*** Bug 76134 has been marked as a duplicate of this bug. ***
Comment 101•23 years ago
|
||
*** Bug 76060 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 102•23 years ago
|
||
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.
Reporter | ||
Comment 103•23 years ago
|
||
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?
Assignee | ||
Comment 104•23 years ago
|
||
I noticed the rainbox text problem in the print dialog. I'll fix this today.
Assignee | ||
Comment 105•23 years ago
|
||
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.
Reporter | ||
Comment 106•23 years ago
|
||
xptcall changes landed on trunk. will remove from patch.
Reporter | ||
Comment 107•23 years ago
|
||
Reporter | ||
Updated•23 years ago
|
Attachment #53914 -
Attachment is obsolete: true
Comment 108•23 years ago
|
||
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?
Comment 109•23 years ago
|
||
Comment 110•23 years ago
|
||
Comment 111•23 years ago
|
||
Updated•23 years ago
|
Attachment #54219 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #54624 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #54628 -
Attachment is obsolete: true
Comment 112•23 years ago
|
||
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
Comment 113•23 years ago
|
||
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.
Comment 114•23 years ago
|
||
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.
Comment 115•23 years ago
|
||
Updated•23 years ago
|
Attachment #54727 -
Attachment is obsolete: true
Reporter | ||
Comment 116•23 years ago
|
||
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.
Reporter | ||
Comment 117•23 years ago
|
||
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 118•23 years ago
|
||
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
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Comment 119•23 years ago
|
||
Assignee | ||
Comment 120•23 years ago
|
||
Assignee | ||
Comment 121•23 years ago
|
||
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.
Assignee | ||
Comment 122•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Attachment #55284 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #55332 -
Attachment is obsolete: true
Comment 123•23 years ago
|
||
Huzzah! Ship it!
Assignee | ||
Comment 124•23 years ago
|
||
Patch coming up that should get macho running again. This adds patches for:
mozilla/config/autoconf.mk.in
mozilla/widget/src/Makefile.in
Assignee | ||
Comment 125•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Attachment #55337 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #55370 -
Attachment is obsolete: true
Comment 126•23 years ago
|
||
The rest of the macho changes have landed on the trunk. No further patches (at
this time) are needed. Have a nice weekend.
Reporter | ||
Comment 127•23 years ago
|
||
thanks to everyone who helped out with this landing! we couldn't have done it
without you.
Assignee | ||
Comment 128•23 years ago
|
||
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
Comment 129•23 years ago
|
||
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.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•