157036 - [mach-o] building Mach-O on UFS drive fails

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[riscky]

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

[hacker formerly known as [e-mail]]

At a glance, it looks like asdecode doesn't like UFS.  Over to bryner.

Comment 2

[Will Jenkins]

Is this not a duplicate of bug 86538?
http://bugzilla.mozilla.org/show_bug.cgi?id=86538

Comment 3

[riscky]

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

Comment 4

[Brian Ryner (not reading)]

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.

Comment 5

[Steve Dagley]

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

[hacker formerly known as [e-mail]]

*** Bug 182743 has been marked as a duplicate of this bug. ***

Comment 7

[Conrad Carlen (not reading bugmail)]

Attachment: .r version of libwidget.rsrc

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

[Andrew Thompson]

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.

Comment 9

[Andrew Thompson]

Attachment: Remove need for Apple Single from 2 places in the tree

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

[Andrew Thompson]

Attachment: Remove need for Apple Single from 2 places in the tree

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

Comment 11

[Brian Ryner (not reading)]

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 12

[Brian Ryner (not reading)]

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.

Comment 13

[Simon Fraser [no longer active]]

NullPlugin.r is covered by bug 179863.

Comment 14

[Andrew Thompson]

Attachment: Patch uses .r file as requested. Removed NullPlugin stuff as is handled by another bug

Comment 15

[Andrew Thompson]

Attachment: Run cvs diff in the correct directory this time!

Comment 16

[Brian Ryner (not reading)]

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?

Comment 17

[Andrew Thompson]

I've no objections to checking it in.

Does this need a superreview too though?

Comment 18

[(not reading, please use [e-mail] instead)]

Comment on attachment 122460 [details] [diff] [review]
Run cvs diff in the correct directory this time!

a=sspitzer for 1.4 final

Comment 19

[Simon Fraser [no longer active]]

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.

Comment 20

[Andrew Thompson]

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 [e-mail] 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

[Andrew Thompson]

Attachment: Adds in the cursors that the previous patch accidentally removed

Comment 22

[Andrew Thompson]

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

[Simon Fraser [no longer active]]

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 24

[(not reading, please use [e-mail] instead)]

Comment on attachment 122937 [details] [diff] [review]
Adds in the cursors that the previous patch accidentally removed

a=sspitzer

Comment 25

[Brian Ryner (not reading)]

checked in.