Re: XDarwin.app is installed with symlinks inside MainMenu.nib bundles, app won't launch.
On Tue, 22 May 2007, SciFi wrote: On Tue, 22 May 2007 08:50:00 -0600, Marc Aurele La France wrote: Now, is there anything else that you think needs fixing here? I can only remember another patch I put on locally here, as I want to set this in the custom build/config/cf/host.def: cut-here --- xc/config/cf/darwin.cf_orig 2007-04-25 09:42:47 -0500 +++ xc/config/cf/darwin.cf 2007-04-25 10:18:58 -0500 @@ -315,7 +315,9 @@ #define BuildLibPathVar DYLD_LIBRARY_PATH +#ifndef DefaultUserPath #define DefaultUserPath /bin:/sbin:/usr/bin:/usr/sbin:$(BINDIR) +#endif #define DefaultSystemPath DefaultUserPath /* include rules to build shared libraries */ <<< In my host.def I specify: #define DefaultUserPath $(PATH):$(BINDIR) to pick up the normal user environment (it's really long). Of course this mod will affect all platforms. But let me try to explain why I do this. This is to be sure we run the new(er) code in /usr/local/bin and other places rather than the vendor's old cruft in /usr/bin during _all_ phases. There are other tricks e.g. to set [DY]LD_ for similar reasons. Specifically for darwin/osx, we mainly do this in the user's ~/.MacOSX/environment.plist as well as root's, so the boot-system, early GUI-related apps, Finder, and all spawned apps including XDarwin.app will get the same long paths and hopefully run with newer bins & libs etc. even during early single-user mode (yes I have modified /etc/rc* scripts as well). I know $(PATH) in host.def will be resolved at build time, but at least this will pick up the same long string, without our having to manually modify any /etc/X11 stuff or in users' hidden $HOME parmfiles. I hope at least. ;) (Since I can't afford $ADC$ account to test Leopard officially, this is the next-best effort to get up on latest code and to override what Apple provides at all levels, hoping to spot any problems before they include it into Leopard. I'm mainly interested in free / open apps, not caring much for any new proprietary gizmos that they are of course adding to Leopard, per se. I'll try to take any problem to the project itself, not to Apple, as I'm doing here. My philosophy is that the project ought to build & function properly straight out of the tarball and without any pkg-mgr "help" even officially from the vendor. ;) ) Such a long-winded justification for a simple change ;-) Committed. As a final _final_ test, regardless -- When the public cvs server gets that latest XDarwin.app symlink patch pushed to it, let's do a complete new checkout and build it. Are we getting close to an official 4.7 release? :) We're looking at a June code freeze, release in July. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: XDarwin.app is installed with symlinks inside MainMenu.nib bundles, app won't launch.
On Tue, 22 May 2007 08:50:00 -0600, Marc Aurele La France wrote: > Now, is there anything else that you think needs fixing here? I can only remember another patch I put on locally here, as I want to set this in the custom build/config/cf/host.def: cut-here --- xc/config/cf/darwin.cf_orig 2007-04-25 09:42:47 -0500 +++ xc/config/cf/darwin.cf 2007-04-25 10:18:58 -0500 @@ -315,7 +315,9 @@ #define BuildLibPathVar DYLD_LIBRARY_PATH +#ifndef DefaultUserPath #define DefaultUserPath /bin:/sbin:/usr/bin:/usr/sbin:$(BINDIR) +#endif #define DefaultSystemPath DefaultUserPath /* include rules to build shared libraries */ <<
Re: XDarwin.app is installed with symlinks inside MainMenu.nib bundles, app won't launch.
On Mon, 21 May 2007, SciFi wrote: On Sun, 20 May 2007 17:12:54 -0600, Marc Aurele La France wrote: On Sun, 20 May 2007, SciFi wrote: On Fri, 18 May 2007 12:44:22 -0600, Marc Aurele La France wrote: On Thu, 17 May 2007, SciFi wrote: I'm totally out of ideas on this... I'm not. At least, not yet. Please try the attached patch. Patch went on okay. Still have symlinks in the installed .app bundle. :( I tee'd the stdout + stderr output to files for both make [all, not World] and make install to prove your new lines to the Imakefiles _did_ get executed, as well the xcodeprojs did get rerun etc. If you need this evidence, we probably should convert this into a bugzilla report for proper tracking & attachments etc. `make all` won't do it. `make Everything` minimum. Then `make install`. Bingo -- that did it. Fresh .app installed and running without needing any hand-fixin', using it right now AAMOF. :) OK. I've committed the change. Thanks for trying it out. I could've sworn make-all did run your patched instructions. But I see why make-Everything was needed to be sure this was done at an earlier stage. I'm not used to Imakefiles, I feel they cause way too much unnecessary reprocessing. Maybe I could've just cd'd to the hw/darwin section and remake things there to save some time. Oh well, at least it seems this bug is licked now. ;) `make all` doesn't regenerate Makefiles. Thus the `make install` with those Makefiles would not include the symlink workaround. Thanks heaps. You're quite welcome. Now, is there anything else that you think needs fixing here? Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
(no subject)
Hi, We are students of Lund University doing our Bachelor thesis for the Systems Design-programme. We are conducting research on why and how FOSS projects fork. The aim of the research is to better understand the special issues regarding FOSS-projects with regards to the forces leading up to a fork. We hope that any knowledge gained from this can be incorporated in the future education of System analysts. Our focus is the motivation of the developers involved. We are now looking for developers from the XFree86 and X.Org projects who would like to share their experience and thoughts with us to base our research on. If you are interested in helping us please reply in private to [EMAIL PROTECTED] or [EMAIL PROTECTED] If you desire to be anonymous we will take action to ensure this. Obviously it will be hard to mask what projects has been involved in the study as we have contacted you in public allready. However, the interviews will be anonymized by the best of our abillities while still retaining credibillity for the data. Before finalizing the thesis all participators will recieve an altered copy of their transcript (the one which will be published) to approve it. We appreciate the sensitivity of the matter, however it will be hard to conduct scientific research without some means to validate the conclusions. If the interviewee does not find the altered transcript acceptable we will discard the transcript, or the sensitive parts thereof, and not use it in our research. Regards, John Nilsson Johan Sånesson
