Firefox won't launch on OS X due to absolute paths in internal symlinks

RESOLVED INVALID

Status

()

Firefox
Build Config
RESOLVED INVALID
14 years ago
12 years ago

People

(Reporter: justdave, Unassigned)

Tracking

Trunk
PowerPC
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Trying to build Firefox from the tip of the Aviary branch as of this afternoon...

The Firefox.app/Contents/MacOS directory contains a huge number of symlinks
which contain absolute paths to items outside of the Firefox.app directory
(which means those items are not included in the portion of the app which is
hence distributed).  This means if I build it on one machine and then copy it to
another, I can't use it.

Comment 1

14 years ago
I have seen this, and I believe that it occurs with Thunderbird also.
It may be a new thing

Would it help if hard links were used?

When producing a Mac deliverable, it would appear that in general the 
Package Contents need to be copied not linked, to meet the Mac HCI
guidelines that deliverables should be drag installable

Comment 2

14 years ago
I can't believe this hasn't been reported before... since you can only do shared
builds for some time (if ever).

My fix has been...

rm -rf ~/Firefox.app
cp -RLf <Path to>/dist/Firefox.app/ ~/Firefox.app/

BTW this has been the case for Thunderbird since around the .4 days (I think)

Comment 3

14 years ago
I can believe it!

Most people who build their own probably run it from the dist directory
(perhaps in a debugger). If you don't, there is a reasonable chance that the 
build tree is on the same device as any place one copies it to, such
as the Applications folder.

I began to notice problems when I moved my build tree onto a removable
(Firewire) device.

The criteria ought not to be some infrequently excercised options to cp,
but to produce something that can be copied by dragging in the finder.
(Most OS X user know to do this with Applications and packages to ensure
that resource forks are copied).

I assume that the Firefox Gods have this in hand ahead of producing a 
deliverable (and if not, it is strange that the nightlies work at all).

There is (of course) nothing wrong with using symlinks in this way when 
constructing the final package.

Comment 4

14 years ago
fwiw, you're expected to make a disk image and distribute that. the black magic
resides in the dmg target.
if the dmg works, that'd be a suitable workaround...  what magic incantation do
I need to put in the mozconfig file to make it do that?

Comment 6

14 years ago
regression of bug193164 ?

Comment 7

14 years ago
Dave,

Jerry Talkington does the Mac Firefox builds... and here is his build script
http://smartasfuck.com/mozilla/mozmake

Comment 8

14 years ago
The 'cp -RL'-thingy is also necessary for the Mozilla suite

Comment 9

14 years ago
Also note that some of the symlinks (css and xul files) point not into the 
build tree but the source tree. If you mount your sources remotely while
compiling you will need to have that disk mounted whilst you run your
lizard (or use the -L copy links as files option) to create a local copy
of the full app, which will be fairly large for a debug compile.
Assignee: bryner → nobody
QA Contact: asa → build.config
Version: unspecified → Trunk

Comment 10

12 years ago
Everything is working as intended.  The built tree in dist not guaranteed to work once it leaves dist.  Either produce a dmg:

$ make -C objdir/browser/installer

or use rsync to resolve external symbolic links:

$ rsync -a --copy-unsafe-links objdir/dist/Firefox.app/ /path/to/target/Firefox.app/
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.