[Fink-devel] Re: strange key behavior after compiling zsh on tiger (fwd)
It appears the cvs version of zsh gets around the poll() problem, should we decide we might want to include a working version of zsh for 10.4 in fink at some point in the near future -- Forwarded message -- Date: Tue, 23 Aug 2005 21:38:53 -0400 From: Mike Hernandez <[EMAIL PROTECTED]> To: Jordan Breeding <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: strange key behavior after compiling zsh on tiger On 8/23/05, Jordan Breeding <[EMAIL PROTECTED]> wrote: > You might try zsh out of CVS. CVS has a fix for not using poll() > when you are running Tiger, and instead running select(). Poll() has > issues in Tiger. I compiled and ran zsh from CVS after the fix went > in and it seemed to work well. > > Jordan > That did the trick! Thanks Jordan! Mike --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] XCode Legacy Tools on ADC
On 8/23/05, David R. Morrison <[EMAIL PROTECTED]> wrote: > > > On Aug 23, 2005, at 5:46 PM, Dave Vasilevsky wrote: > > > On Aug 23, 2005, at 6:21 PM, Daniel Johnson wrote: > > An XCode Legacy Tools package is now available on ADC which provides, among > other things, gcc 2.95.2 and gcc 3.1 for Tiger (and Panther). If a Tiger > user installs this, fink will want to install it's gcc3.1 package since it's > version number is higher than the virtual gcc3.1 package. This is likely not > the desired behavior. :) > > Fink's gcc3.1 package installs into the fink prefix (usually /sw), so it's > not as if there's a critical problem with Fink's GCC overwriting Apple's GCC > 3.1. It just means a bit of extra compile time and installation space, when > they end up installed in parallel. > > I wouldn't object to synchronizing the version numbers of the GCC 3.1 > virtual package and the real package. Currently the virtual one is at > version '3.1' and the real one uses the build number '1175', it should be > possible to have them both use '1:3.1-1175' for example. Perhaps there is a > pressing reason why they need to be different? > > > One problem, however, is keeping these versions in synch. If there's a minor > change to the real package, and the revision needs to be bumped, should the > revision of the virtual package be bumped too? And how will the virtual > package engine know when its revision needs a bump? > > Another potential problem arises if there's a particular package somewhere > that needs specifically the Apple or Fink version of GCC 3.1 (assuming there > turns out to be any bug or other difference in one of them). > > > Any ideas how to get around these issues? If it's not reasonably easy to do > so, it might be best to just live with the imperfect but working solution we > have now, and simply deal with the extra time and space needed to install > Fink's gcc3.1 in parallel. > > Dave > Thanks to Daniel for the heads-up about this issue. > > The fink gcc3.1 is a crude hack (made by me) which lets some gcc 3.1 > packages compile but not all. I plan to test the new Apple package, but I > assume it will do a better job. Once the testing has been done, we can > decide how best to proceed. > > -- Dave > As a lowest-order test, I checked the gcc2 and gcc3 executables from the Legacy package and compared them to those from XCode 1.5--they're identical (size, anyway). --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] XCode Legacy Tools on ADC
On Aug 23, 2005, at 5:46 PM, Dave Vasilevsky wrote:On Aug 23, 2005, at 6:21 PM, Daniel Johnson wrote: An XCode Legacy Tools package is now available on ADC which provides, among other things, gcc 2.95.2 and gcc 3.1 for Tiger (and Panther). If a Tiger user installs this, fink will want to install it's gcc3.1 package since it's version number is higher than the virtual gcc3.1 package. This is likely not the desired behavior. :) Fink's gcc3.1 package installs into the fink prefix (usually /sw), so it's not as if there's a critical problem with Fink's GCC overwriting Apple's GCC 3.1. It just means a bit of extra compile time and installation space, when they end up installed in parallel.I wouldn't object to synchronizing the version numbers of the GCC 3.1 virtual package and the real package. Currently the virtual one is at version '3.1' and the real one uses the build number '1175', it should be possible to have them both use '1:3.1-1175' for example. Perhaps there is a pressing reason why they need to be different?One problem, however, is keeping these versions in synch. If there's a minor change to the real package, and the revision needs to be bumped, should the revision of the virtual package be bumped too? And how will the virtual package engine know when its revision needs a bump?Another potential problem arises if there's a particular package somewhere that needs specifically the Apple or Fink version of GCC 3.1 (assuming there turns out to be any bug or other difference in one of them).Any ideas how to get around these issues? If it's not reasonably easy to do so, it might be best to just live with the imperfect but working solution we have now, and simply deal with the extra time and space needed to install Fink's gcc3.1 in parallel.DaveThanks to Daniel for the heads-up about this issue.The fink gcc3.1 is a crude hack (made by me) which lets some gcc 3.1 packages compile but not all. I plan to test the new Apple package, but I assume it will do a better job. Once the testing has been done, we can decide how best to proceed. -- Dave
Re: [Fink-devel] XCode Legacy Tools on ADC
On Aug 23, 2005, at 6:21 PM, Daniel Johnson wrote: An XCode Legacy Tools package is now available on ADC which provides, among other things, gcc 2.95.2 and gcc 3.1 for Tiger (and Panther). If a Tiger user installs this, fink will want to install it's gcc3.1 package since it's version number is higher than the virtual gcc3.1 package. This is likely not the desired behavior. :) Fink's gcc3.1 package installs into the fink prefix (usually /sw), so it's not as if there's a critical problem with Fink's GCC overwriting Apple's GCC 3.1. It just means a bit of extra compile time and installation space, when they end up installed in parallel. I wouldn't object to synchronizing the version numbers of the GCC 3.1 virtual package and the real package. Currently the virtual one is at version '3.1' and the real one uses the build number '1175', it should be possible to have them both use '1:3.1-1175' for example. Perhaps there is a pressing reason why they need to be different? One problem, however, is keeping these versions in synch. If there's a minor change to the real package, and the revision needs to be bumped, should the revision of the virtual package be bumped too? And how will the virtual package engine know when its revision needs a bump? Another potential problem arises if there's a particular package somewhere that needs specifically the Apple or Fink version of GCC 3.1 (assuming there turns out to be any bug or other difference in one of them). Any ideas how to get around these issues? If it's not reasonably easy to do so, it might be best to just live with the imperfect but working solution we have now, and simply deal with the extra time and space needed to install Fink's gcc3.1 in parallel. Dave PGP.sig Description: This is a digitally signed message part
[Fink-devel] XCode Legacy Tools on ADC
An XCode Legacy Tools package is now available on ADC which provides, among other things, gcc 2.95.2 and gcc 3.1 for Tiger (and Panther). If a Tiger user installs this, fink will want to install it's gcc3.1 package since it's version number is higher than the virtual gcc3.1 package. This is likely not the desired behavior. :) I haven't actually installed this package, but I remember what happened when I had a leftover Panther gcc3.1 on my system after upgrading to 10.4. -- Daniel Johnson [EMAIL PROTECTED] PGP public key: http://homepage.mac.com/danielj7/publickey.txt PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] ssl packages in main/
Chris Dolan wrote: 1) Does this mean that we can set Depends: openssl097-dev | system-openssl-dev and start putting SSL-dependent .info files in main/finkinfo? No, the install_name is different (/usr/lib vs. /sw/lib), they're not interchangeable. 2) If I build an SSL-dependent package against system-openssl-dev and later install openssl097-shlibs the package will remain linked against the system openssl, right? Could that be a problem? Yes, it will remain linked against it, no, it shouldn't be a problem, both libraries are twolevel. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] ssl packages in main/
On Aug 21, 2005, at 4:43 PM, Benjamin Reed wrote: I've made a "system-openssl-dev" package that will allow packagers to force the use of the system OpenSSL rather than the fink- provided one. I'm going to be using it for KDE and a few other things to get rid of the hell that is the ssl/non-ssl split, and the accompanying license craziness. Since apple's openssl is provided with the OS, it should be OK to distribute binaries linked this way. Ben, Two questions: 1) Does this mean that we can set Depends: openssl097-dev | system-openssl-dev and start putting SSL-dependent .info files in main/finkinfo? 2) If I build an SSL-dependent package against system-openssl-dev and later install openssl097-shlibs the package will remain linked against the system openssl, right? Could that be a problem? Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
