Build changes for Fizzilla-Mach

RESOLVED FIXED in mozilla0.9.6

Status

P2
normal
RESOLVED FIXED
18 years ago
14 years ago

People

(Reporter: mikepinkerton, Assigned: beard)

Tracking

({meta})

Trunk
mozilla0.9.6
PowerPC
Mac OS X
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(24 obsolete attachments)

(Reporter)

Description

18 years ago
placeholder bug for build changes for the mach-o build of fizzilla.
(Reporter)

Updated

18 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 1

18 years ago
Created attachment 30544 [details] [diff] [review]
[patch] first attempt, xpcom does not yet link with mac fileIO

Comment 2

18 years ago
I think we need to test these changes on Mac classic builds, and Unix.
(Reporter)

Comment 3

18 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

18 years ago
Created attachment 30705 [details] [diff] [review]
[patch] pav's original diff from last summer
(Reporter)

Comment 5

18 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)

Updated

18 years ago
Depends on: 76060
(Reporter)

Updated

18 years ago
Depends on: 75853
(Reporter)

Comment 6

18 years ago
Created attachment 30911 [details]
the makefile.in from lib/mac/MoreFiles/
(Reporter)

Comment 7

18 years ago
Created attachment 30925 [details] [diff] [review]
#2 [patch] through xpcom with mac file i/o
(Reporter)

Comment 8

18 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

18 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

18 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

18 years ago
Created attachment 31933 [details] [diff] [review]
updated patch

Comment 12

18 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

18 years ago
Created attachment 31938 [details] [diff] [review]
jav's further changes

Comment 14

18 years ago
Javier,
see bug 75895 for a discussion and patch for the make clean problem.

Comment 15

18 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

18 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

18 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

18 years ago
Created attachment 32528 [details] [diff] [review]
additional patches for xpcom/io

Comment 19

18 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])'

Updated

18 years ago
Keywords: meta

Comment 20

18 years ago
Created attachment 44379 [details] [diff] [review]
updated diff

Comment 21

18 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

18 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

18 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

18 years ago
wtc says he knows what the problem is in nspr and is looking into it. i'll 
file a new bug.
(Reporter)

Updated

18 years ago
Depends on: 93355
(Reporter)

Comment 25

18 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

18 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

18 years ago
Created attachment 44505 [details]
lib/mac/MoreFiles/Makefile.in

Comment 28

18 years ago
I have a Makefile.in for the lib/mac/MoreFiles directory.  Attached above.
(Reporter)

Comment 29

18 years ago
lib/mac/MoreFiles/Makefile.in has been checked in.
(Reporter)

Updated

18 years ago
Depends on: 93479

Comment 30

18 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

18 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

18 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

18 years ago
Created attachment 44649 [details] [diff] [review]
Updated diff

Comment 34

18 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

18 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

18 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.
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

18 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

18 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

18 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

18 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

18 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

18 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

18 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

18 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

18 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

18 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

18 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

18 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

18 years ago
Created attachment 45231 [details] [diff] [review]
update to MACHO_20010807_BRANCH

Comment 51

18 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

18 years ago
Created attachment 45279 [details] [diff] [review]
Patch to client.mk.patch to pull everything on the MACHO_20010807_BRANCH.
(Assignee)

Comment 53

18 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

18 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

18 years ago
I have checked in the changes to client.mk into the branch.

Comment 56

18 years ago
Try configure with --without-ldap. That should get you by the ldap error for 
the short term.

Zach

Comment 57

18 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

18 years ago
Is this ever going to be assigned a priority and target?

Comment 59

18 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

18 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

18 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

18 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

18 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

18 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

18 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

18 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

18 years ago
*** Bug 58799 has been marked as a duplicate of this bug. ***

Comment 68

18 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

17 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

Updated

17 years ago
Blocks: 102998

Comment 70

17 years ago
Why don't we have an entry on the branch landings page for this?
(Assignee)

Comment 71

17 years ago
Landing will happen in 0.9.6 timeframe.
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Comment 72

17 years ago
Can the tip patches be posted somewhere?
(Assignee)

Comment 73

17 years ago
Created attachment 53607 [details] [diff] [review]
Latest patches to trunk.
(Assignee)

Comment 74

17 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

17 years ago
Attachment #30544 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #30705 - Attachment is obsolete: true
(Assignee)

Comment 75

17 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

17 years ago
Attachment #30911 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #30925 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #31933 - Attachment is obsolete: true
(Reporter)

Comment 76

17 years ago
i noticed smfr's latest changes to nsSound broke the latest patch. :(
(Assignee)

Updated

17 years ago
Attachment #31938 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #32528 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #44379 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #44505 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #44649 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #45231 - Attachment is obsolete: true
(Assignee)

Updated

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







Comment 78

17 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

17 years ago
darin: how is that patch coming?
(Assignee)

Comment 80

17 years ago
Created attachment 53897 [details] [diff] [review]
Latest patch from darin, to fix nsSound.cpp bustage.
(Assignee)

Updated

17 years ago
Attachment #53607 - Attachment is obsolete: true

Comment 81

17 years ago
This fails for me unless I use --without-x to configure

Comment 82

17 years ago
zach: yup.. you'll need that if you have the X libraries installed.

Comment 83

17 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

17 years ago
Simon's new printing code busts us. Patch coming up.
(Assignee)

Comment 85

17 years ago
Created attachment 53914 [details] [diff] [review]
Latest patch, fixes printing bustage in gfx/src/mac.
(Assignee)

Updated

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

Comment 88

17 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

17 years ago
zach:

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

this works for me.
(Reporter)

Comment 90

17 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

17 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

17 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

17 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

17 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

17 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

17 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

17 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! ;)
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

17 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.
*** 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. ***
(Reporter)

Comment 102

17 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

17 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

17 years ago
I noticed the rainbox text problem in the print dialog. I'll fix this today.
(Assignee)

Comment 105

17 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

17 years ago
xptcall changes landed on trunk. will remove from patch.
(Reporter)

Comment 107

17 years ago
Created attachment 54219 [details] [diff] [review]
remove xptcall from patch (on trunk now)
(Reporter)

Updated

17 years ago
Attachment #53914 - Attachment is obsolete: true

Comment 108

17 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

17 years ago
Created attachment 54624 [details] [diff] [review]
diffs against the trunk: fix some merge conflicst and add nsTSMStrategy.cpp to build

Comment 110

17 years ago
Created attachment 54628 [details] [diff] [review]
fix VPATH in widget/src/mac so objdir builds work

Comment 111

17 years ago
Created attachment 54727 [details] [diff] [review]
fix rules for copying files from GFX so OBJDIR builds work

Updated

17 years ago
Attachment #54219 - Attachment is obsolete: true

Updated

17 years ago
Attachment #54624 - Attachment is obsolete: true

Updated

17 years ago
Attachment #54628 - Attachment is obsolete: true

Comment 112

17 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

17 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.
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.

Created attachment 55061 [details] [diff] [review]
Remove rhapsody references & switched to using -DXP_MACOSX
Attachment #54727 - Attachment is obsolete: true
(Reporter)

Comment 116

17 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

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

17 years ago
Status: NEW → ASSIGNED
Created attachment 55284 [details] [diff] [review]
Updated patch against configure.in reorg
(Assignee)

Comment 120

17 years ago
Created attachment 55332 [details] [diff] [review]
Removes #if 0 and extraneous debugging code, per waterson's comments.
(Assignee)

Comment 121

17 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

17 years ago
Created attachment 55337 [details] [diff] [review]
Fixes last of problems identified by waterson.
(Assignee)

Updated

17 years ago
Attachment #55284 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #55332 - Attachment is obsolete: true

Comment 123

17 years ago
Huzzah! Ship it!
(Assignee)

Comment 124

17 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

17 years ago
Created attachment 55370 [details] [diff] [review]
Properly configures the toolkit, so widget/src/mac & gfx/src/mac get built.
(Assignee)

Updated

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

(Reporter)

Comment 127

17 years ago
thanks to everyone who helped out with this landing! we couldn't have done it
without you.
(Assignee)

Comment 128

17 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
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 129

17 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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.