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

Status: RESOLVED INVALID

(Firefox Build System :: General, defect)

Description

[Dave Miller [:justdave]]

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

[Ben Fowler]

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

[riscky]

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

[Ben Fowler]

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

[timeless]

fwiw, you're expected to make a disk image and distribute that. the black magic
resides in the dmg target.

Comment 5

[Dave Miller [:justdave]]

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

[Hiro]

regression of bug193164 ?

Comment 7

[riscky]

Dave,

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

Comment 8

[Bjarne D Mathiesen]

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

Comment 9

[Ben Fowler]

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.

Comment 10

[Mark Mentovai]

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/