Closed Bug 157036 Opened 18 years ago Closed 17 years ago
[mach-o] building Mach-O on UFS drive fails
The summary says it all. Trying to pull and build mach-o fails on a UFS drive. Using gcc-937.2, based on gcc version 2.95.2 19991024 10.1.5 chmod +x libwidget_mac.dylib ../../../config/nsinstall -R -m 755 libwidget_mac.dylib ../../../dist/lib/components : ../../../dist/lib/components/libwidget_mac.dylib ../../../config/nsinstall -R -m 755 libwidget_mac.dylib ../../../dist/bin/components : ../../../dist/bin/components/libwidget_mac.dylib nsIChangeManager.idl ../../../dist/bin/xpidl -m typelib -w -I ../../../dist/idl -I. -o _xpidlgen/nsIChangeManager nsIChangeManager.idl nsIMacTextInputEventSink.idl ../../../dist/bin/xpidl -m typelib -w -I ../../../dist/idl -I. -o _xpidlgen/nsIMacTextInputEventSink nsIMacTextInputEventSink.idl nsIMenuCommandDispatcher.idl ../../../dist/bin/xpidl -m typelib -w -I ../../../dist/idl -I. -o _xpidlgen/nsIMenuCommandDispatcher nsIMenuCommandDispatcher.idl nsPIWidgetMac.idl ../../../dist/bin/xpidl -m typelib -w -I ../../../dist/idl -I. -o _xpidlgen/nsPIWidgetMac nsPIWidgetMac.idl nsPIEventSinkStandalone.idl ../../../dist/bin/xpidl -m typelib -w -I ../../../dist/idl -I. -o _xpidlgen/nsPIEventSinkStandalone nsPIEventSinkStandalone.idl nsIDragHelperService.idl ../../../dist/bin/xpidl -m typelib -w -I ../../../dist/idl -I. -o _xpidlgen/nsIDragHelperService nsIDragHelperService.idl ../../../dist/bin/xpt_link _xpidlgen/widget_mac.xpt _xpidlgen/nsIChangeManager.xpt _xpidlgen/nsIMacTextInputEventSink.xpt _xpidlgen/nsIMenuCommandDispatcher.xpt _xpidlgen/nsPIWidgetMac.xpt _xpidlgen/nsPIEventSinkStandalone.xpt _xpidlgen/nsIDragHelperService.xpt ../../../config/nsinstall -R -m 644 _xpidlgen/widget_mac.xpt ../../../dist/bin/components ../../../dist/bin/asdecode ./nsMacWidget.rsrc ../../../dist/bin/libwidget.rsrc.tmp make: *** [../../../dist/bin/libwidget.rsrc] Error 1 make: Leaving directory `/Volumes/relativity/mozilla/widget/src/mac' make: *** [libs] Error 2 make: Leaving directory `/Volumes/relativity/mozilla/widget/src' make: *** [libs] Error 2 make: Leaving directory `/Volumes/relativity/mozilla/widget' make: *** [tier_9] Error 2 make: Leaving directory `/Volumes/relativity/mozilla' make: *** [default] Error 2 make: Leaving directory `/Volumes/relativity/mozilla' make: *** [build] Error 2 make: Leaving directory `/Volumes/relativity/mozilla'
At a glance, it looks like asdecode doesn't like UFS. Over to bryner.
Assignee: seawood → bryner
Will, no bug 86538 is about runing Mozilla from a UFS drive. I am trying to build mozilla from a USF drive. Also bug 86538 is for the CFM builds not mach-o. This bug is more related to bug 133190 and bug 108300 (they are the only USF and Macintosh building bugs I could find, thats the only way they are related.)
Summary: building Mach-O on UFS drive fails → [mach-o] building Mach-O on UFS drive fails
beard wrote asdecode, cc'ing him. UFS probably doesn't like resource forks at all. Perhaps we should modify asdecode so that we can specify a filename for the resource fork. That would eliminate the extra copy step as well.
Status: UNCONFIRMED → NEW
Ever confirmed: true
beard is on sabbatical for a couple of more weeks (at least) so I hope you're not waiting on him to change asdecode :-)
*** Bug 182743 has been marked as a duplicate of this bug. ***
This is a DeRez'd for of libwidget.r that I had around in my tree. I don't still have the makefile changes, but they just used Rez -useDF instead of asdecoding & copying.
Yeah. The simplest thing to do would be: /Developer/Tools/DeRez MacWidget.rsrc > MacWidget.r Then remove MacWidget.rsrc from CVS and add MacWidget.r. Alter the Makefile to do this: /Developer/Tools/Rez MacWidget.r -useDF -o libWidget.rsrc Naturally one would have to add the appropriate directory names to the filenames above. I'll see if I can get to this.
Status: NEW → ASSIGNED
This patch removes the need for Apple Single when building 'widget' and the Null Plugin. There's currently a third use in the tree at: /plugin/oji/MRJCarbon/plugin/Resources/Makefile, line 3 but I think that's dead code. Here's the approach: For nsMacWidget.rsrc:
This patch removes the need for Apple Single when building widget/mac and widget/cocoa and the Null Plugin. There's currently a fourth use in the tree at: /plugin/oji/MRJCarbon/plugin/Resources/Makefile, line 3 but I think that's dead code. Here's the approach: For widget/src/mac/nsMacWidget.rsrc: (i) simply checkin the data fork version of this resource file instead (ii) In Makefile.in just 'cp' it to the correct location in /dist/. Works in my tree. For NullPlugin.rsrc (i) DeRez the file into NullPlugin.r (ii) Replace the reference to _NullPlugin.rsrc in the ProjectBuilder project with a reference to NullPlugin.r (iii) Remove all reference to these files from Makefile.in (nothing for Make to do anymore) (iv) Remove NullPlugin.rsrc from CVS Works in my tree. For widget/src/cocoa/nsMacWidget.rsrc (i) This file is unused and should be removed from CVS. The Makefile.in in widget/src/cocoa just refers to ../mac/nsMacWidget.rsrc. (ii) Patch alters Makefile.in to remove asdecode stuff as for widget/src/mac
Attachment #113216 - Attachment is obsolete: true
Yeah, we should do this. I didn't do that before because I wanted the .rsrc file to be shared between the CFM and Mach-O builds. Now that we've abandoned the CFM build, I don't see any reason not to use the approach here.
Comment on attachment 121857 [details] [diff] [review] Remove need for Apple Single from 2 places in the tree However, I like the approach in comment 8 better than the patch in attachment 121857 [details] [diff] [review]. We should prefer text files over binary for CVS; it makes things easier for merging changes and seeing revision history.
Attachment #121857 - Flags: review?(bryner) → review-
Comment on attachment 122460 [details] [diff] [review] Run cvs diff in the correct directory this time! Looks good. Can we get this in for 1.4 final?
I've no objections to checking it in. Does this need a superreview too though?
Comment on attachment 122460 [details] [diff] [review] Run cvs diff in the correct directory this time! a=sspitzer for 1.4 final
Attachment #122460 - Flags: approval1.4? → approval1.4+
Comment on attachment 122460 [details] [diff] [review] Run cvs diff in the correct directory this time! I'd have a slight preference for the cocoa Makefile.in to follow the pattern we use for other widget/src/mac files, which would be to make a symlink of the .r in the export target. sr=sfraser with or without this change.
Attachment #122460 - Flags: superreview+
Simon: I tried to do this as a symlink, but it doesn't work. Presumably the routine that opens the resource fork doesn't follow symlinks. Bryner: Thanks for checking this in and fixing the problem with Rez -i. Unfortunately you've introduced 2 problems: 1) You didn't checkin nsMacWidget.r in the widget/src/COCOA directory, but the Makefile.in in that directory expects to find it. 2) In bug 189719 email@example.com had added 2 new cursors, resource #150 and #151 to nsMacWidget.rsrc, but you lost them from the .r you checked in. I guess that just goes to prove you were right when you said it's better to have '.r' text based files in the tree than binary ones :) I'll make a new .r and attach it presently. Let me know how to get it checked in.
Of course, I was wrong about item (1). For my benefit, I assume the line: MAC_CPP_CSRCS := $(addprefix $(srcdir)/../mac/,$(MAC_LCPPSRCS)) from widget/src/cocoa/Makefile.in allows it to find sources in ../mac ?
Comment on attachment 122937 [details] [diff] [review] Adds in the cursors that the previous patch accidentally removed The Makefile in widget/src/cocoa has a list of cpp files in $(MAC_LCPPSRCS) in src/mac, that are made relative in $(MAC_CPP_CSRCS), then symlinked in the export phase. Bryner did this for nsMacWidget.r by adding $(srcdir)/../mac/$(RES_SRC) to the export phase.
Comment on attachment 122937 [details] [diff] [review] Adds in the cursors that the previous patch accidentally removed a=sspitzer
Attachment #122937 - Flags: approval1.4? → approval1.4+
Attachment #122937 - Flags: review?(bryner) → review+
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.