On Sun, 22 Apr 2007 10:29:12 -0600, Marc Aurele La France wrote: > On Tue, 17 Apr 2007, Marc Aurele La France wrote: >> On Sun, 15 Apr 2007, Yves de Champlain wrote: >>> Le 07-04-15 à 14:55, Marc Aurele La France a écrit : >>>> On Wed, 11 Apr 2007, SciFi wrote: >>>>> 6. XDarwin.app is installed with symlinks inside MainMenu.nib >>>>> bundles, app won't launch. > >>>>> Discussion: > >>>>> The make-install process is creating/copying symlinks for the >>>>> innards of the MainMenu.nib bundles instead of copying the actual >>>>> files. This is for each language inside the installed XDarwin.app >>>>> bundle itself. > >>>>> As installed, we'll see errors in console.log concerning the >>>>> language couldn't be loaded, and the app will fail to launch. > >>>>> This is what we _should_ see in the installed app-bundle after >>>>> repaired by hand: >>>>> $ cd /Applications/XDarwin.app/Contents/Resources/English.lproj/ >>>>> MainMenu.nib >>>>> $ ls -alL >>>>> total 28 >>>>> drwxr-xr-x 5 scifi wheel 170 2007-04-04 11:05 . dr-xr-xr-x 7 root >>>>> wheel 238 2007-04-11 02:26 .. -rw-r--r-- 1 scifi wheel 2369 >>>>> 2003-10-16 18:50 classes.nib -rw-r--r-- 1 scifi wheel 20640 >>>>> 2003-10-16 18:50 objects.nib > >>>>> The xf86 installer is creating those two .nib files as symlinks to >>>>> somewhere in the build/ tree, which further are symlinks elsewhere. >>>>> OSX don't like it that way. ;) > >>>>> Each/every MainMenu.nib in all *.lproj (language) subdirs are >>>>> affected this way. > >>>>> I don't know how to fix this in Makefiles etc. I ended up using >>>>> Finder to drag-copy these from the real xc/ tree (not the build/ >>>>> tree) directly into the installed /Application/XDarwin.app bundle >>>>> itself. > >>>> I don't see anywhere in `make install` that would create symlinks for >>>> these. So, I suspect this is artifact is due to a combination of the >>>> way XCode normally operates and your use of shadow trees for builds >>>> (a practice I highly recommend BTW). There might be a way to coerce >>>> XCode into following symlinks either through a command line flag, the >>>> project file, so some other mechanism. Please investigate. > >>> There already is a bug opened that XDarwin won't build in shadow tree. > >>> http://bugs.xfree86.org/show_bug.cgi?id=1182 > >>> As mentionned there, once the right files are copied to replace >>> symlinks, everything go on smoothly. > >>> I think the "right files" (TM) were >>> xc/programs/Xserver/hw/darwin/bundle > >> OK. Thanks for the info. The attached patch should fix this. > > The change I attached has now been committed. Thanks for reporting the > problem. > > Marc. Hi, Took a while to get back here to report. I built the current cvs as of the date of this msg (gee why can't cvs just give us a simple "revision number" as svn can...). The XDarwin.app that got installed into /Applications *again* has the symlinks inside the MainMenu nibs for all languages. Just to be sure, I moved the previous build out of the way for a clean copy to be put there. I did this build to apply the test patches from bug #1683; I've updated that record with good results. A "cvs up" will show 'M' as expected for those files that were modified from those patches of course. I don't think those patches had anything to do with this problem with XDarwin.app. The nibs built under e.g. build2/programs/Xserver/hw/darwin/bundle/English.lproj/ have symlinks. Shouldn't use them for bundling into the final .app. The nibs built under e.g. build2/programs/Xserver/hw/darwin/quartz/build/Development/XDarwin.app/Contents/Resources/English.lproj/ are OKAY. The latter are the .lproj trees I used to "fix" the XDarwin.app installed into /Applications manually via Finder drag&drop directly into the .app bundle. Wish I could help diagnose this more, this is perplexing. I'll try testing anything if someone comes up with something. Thanks. _______________________________________________ Devel mailing list Devel@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/devel
