Closed
Bug 157036
Opened 19 years ago
Closed 18 years ago
[mach-o] building Mach-O on UFS drive fails
Categories
(SeaMonkey :: Build Config, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: riscky, Assigned: bryner)
References
Details
Attachments
(1 file, 5 obsolete files)
938 bytes,
patch
|
bryner
:
review+
sfraser_bugs
:
superreview+
sspitzer
:
approval1.4+
|
Details | Diff | Splinter Review |
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[5]: *** [../../../dist/bin/libwidget.rsrc] Error 1 make[5]: Leaving directory `/Volumes/relativity/mozilla/widget/src/mac' make[4]: *** [libs] Error 2 make[4]: Leaving directory `/Volumes/relativity/mozilla/widget/src' make[3]: *** [libs] Error 2 make[3]: Leaving directory `/Volumes/relativity/mozilla/widget' make[2]: *** [tier_9] Error 2 make[2]: Leaving directory `/Volumes/relativity/mozilla' make[1]: *** [default] Error 2 make[1]: Leaving directory `/Volumes/relativity/mozilla' make: *** [build] Error 2 make: Leaving directory `/Volumes/relativity/mozilla'
Comment 1•19 years ago
|
||
At a glance, it looks like asdecode doesn't like UFS. Over to bryner.
Assignee: seawood → bryner
Comment 2•19 years ago
|
||
Is this not a duplicate of bug 86538? http://bugzilla.mozilla.org/show_bug.cgi?id=86538
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
Assignee | ||
Comment 4•19 years ago
|
||
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
Comment 5•19 years ago
|
||
beard is on sabbatical for a couple of more weeks (at least) so I hope you're not waiting on him to change asdecode :-)
Comment 6•18 years ago
|
||
*** Bug 182743 has been marked as a duplicate of this bug. ***
Comment 7•18 years ago
|
||
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.
Comment 8•18 years ago
|
||
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
Comment 9•18 years ago
|
||
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:
Comment 10•18 years ago
|
||
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
Updated•18 years ago
|
Attachment #121856 -
Attachment is obsolete: true
Updated•18 years ago
|
Attachment #121857 -
Flags: superreview?(beard)
Attachment #121857 -
Flags: review?(bryner)
Assignee | ||
Comment 11•18 years ago
|
||
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.
Assignee | ||
Comment 12•18 years ago
|
||
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-
Updated•18 years ago
|
Attachment #121857 -
Flags: superreview?(beard)
Comment 14•18 years ago
|
||
Updated•18 years ago
|
Attachment #121857 -
Attachment is obsolete: true
Comment 15•18 years ago
|
||
Attachment #122458 -
Attachment is obsolete: true
Updated•18 years ago
|
Attachment #122460 -
Flags: review?(bryner)
Assignee | ||
Comment 16•18 years ago
|
||
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?
Attachment #122460 -
Flags: review?(bryner)
Attachment #122460 -
Flags: review+
Attachment #122460 -
Flags: approval1.4?
Comment 17•18 years ago
|
||
I've no objections to checking it in. Does this need a superreview too though?
Comment 18•18 years ago
|
||
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 19•18 years ago
|
||
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+
Comment 20•18 years ago
|
||
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 varga@netscape.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.
Comment 21•18 years ago
|
||
Attachment #122460 -
Attachment is obsolete: true
Updated•18 years ago
|
Attachment #122937 -
Flags: superreview?(sfraser)
Attachment #122937 -
Flags: review?(bryner)
Comment 22•18 years ago
|
||
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 23•18 years ago
|
||
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.
Attachment #122937 -
Flags: superreview?(sfraser)
Attachment #122937 -
Flags: superreview+
Attachment #122937 -
Flags: approval1.4?
Comment 24•18 years ago
|
||
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+
Assignee | ||
Updated•18 years ago
|
Attachment #122937 -
Flags: review?(bryner) → review+
Assignee | ||
Comment 25•18 years ago
|
||
checked in.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•