[Fink-devel] Maybe we should just get rid of the packages that don't work with the new gcc4
Hi Jack: The ccp4 package currently works and compiles the way that users expect it to on OS X, on linux, and 10 other platforms. If we make large changes, chances are users simply won't want to use this any more. Also, I just don't have time right now to re-invent the whole compilation scheme. Every build takes hours. I've already invested countless hours in this, along with ccp4, to make it work on OS X, and as of today it works great, I can get results and publish them in the best journals. CCP4 have a paid staff to address compilation issues that arise, courtesy of the British taxpayers. They also now distribute OS X binaries. It just doesn't make sense for us to invest more time in this. It would probably make far more sense for me just to remove ccp4 and all of the other packages that don't compile with your new gfortran from fink, or else keep the current gcc4 package and call it something like gcc4-old. Bill On Nov 15, 2006, at 9:02 AM, [EMAIL PROTECTED] wrote: Bill, No problem. If you have ever followed the debian packaging process, they spend a huge amount of time detecting and eliminating unexpected library dependencies. Of course they have a major advantage since they use build machines for something like 11 architectures. So at any given time each of those build machines has some random set of packages installed that might tickle latent build issues. It will be interesting to find out if you sense any speed up from the use of -O3. Their use of -O0 and -O1 for whole directories was pretty severe overkill for the problem. What I would do is find each program that fails at -O3 and try -O1 for all of its files and then subsets of -O1 and -O3 until I pinned down the offending file. At that point we can try to puzzle out a testcase. I did notice that the ccp4 package is pretty fat even with shared libs. I need to review the total build log and see if there is any other places where we can convert the build over to shared libs. It can make a huge difference. You should have seen Mklinux when we did the first release before they had shared lib support. Bloated binaries everywhere. Jack - Original Message - From: William Scott [EMAIL PROTECTED] Date: Wednesday, November 15, 2006 11:45 am Subject: Re: full multilib packaging To: [EMAIL PROTECTED] Hi Jack: I haven't had time to do anything more than compile ccp4 with the old and new gfortran. (Sorry, my wife is gone for 2 weeks and I have 3 little kids that are relentless in their demands). The phaser issue should be easy enough to correct, since it works in isolation of everything else. Phaser is really more of a fellow traveller with ccp4 than an integrated part. There is actually a reason to keep it the way it is. I have a separate cctbx package that builds similar libraries, etc. that uses the system compilers, system python, and so on. So I do not install these libraries from the ccp4 build, so it is probably easiest just to leave things as they are in that case. Refmac is the ccp4 refinement program. The newer version works with -03. I have a separate package that supercedes what is in ccp4, so it probably isn't worth investing time in an obsolete version of refmac. Most of the other programs aren't time-intensive, except for the molecular replacement programs (molrep, amore) and density modification (dm, solomon), so those are the most reasonable priorities. I haven't yet had a chance to try your additional patch, and wont have before this evening. Sorry! Bill - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Maybe we should just get rid of the packages that don't work with the new gcc4
Hi Jack: If you can get it to work better, please by all means do so. I'm sorry that I am limited both in time and innate ability, but it might be more efficient for you to work with the ccp4 folks on this. They need to have it work with gfortran on a variety of platforms. So far it seems to compile out of the box on linux with gfortran (gcc 4.1 and 4.2). Meanwhile, if you put the new gcc4 into fink, I have to do something as a stop-gap or I am going to have ca. 100 people screaming at me. Bill [EMAIL PROTECTED] wrote: Bill, Give me sometime and I'll try to work through the build process over the next couple of weeks. I believe the current build process is suppressing a bunch of compilation errors even under the current gcc4. For example, the IDATE call doesn't compile as used in ccp4 so not everything is really getting built. Granted they have paid staff, however that doesn't insure that the proper fixes are found and applied for MacOS X which is pretty strict about linkages. Also I wouldn't go off blaming the new gcc 4.2 for braaking a very fragile build system on ccp4. Jack - Original Message - From: William Scott [EMAIL PROTECTED] Date: Thursday, November 16, 2006 9:54 am Subject: Maybe we should just get rid of the packages that don't work with the new gcc4 To: [EMAIL PROTECTED] Cc: fink-devel@lists.sourceforge.net Hi Jack: The ccp4 package currently works and compiles the way that users expect it to on OS X, on linux, and 10 other platforms. If we make large changes, chances are users simply won't want to use this any more. Also, I just don't have time right now to re-invent the whole compilation scheme. Every build takes hours. I've already invested countless hours in this, along with ccp4, to make it work on OS X, and as of today it works great, I can get results and publish them in the best journals. CCP4 have a paid staff to address compilation issues that arise, courtesy of the British taxpayers. They also now distribute OS X binaries. It just doesn't make sense for us to invest more time in this. It would probably make far more sense for me just to remove ccp4 and all of the other packages that don't compile with your new gfortran from fink, or else keep the current gcc4 package and call it something like gcc4-old. Bill - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Maybe we should just get rid of the packages that don't work with the new gcc4
Bill, Give me sometime and I'll try to work through the build process over the next couple of weeks. I believe the current build process is suppressing a bunch of compilation errors even under the current gcc4. For example, the IDATE call doesn't compile as used in ccp4 so not everything is really getting built. Granted they have paid staff, however that doesn't insure that the proper fixes are found and applied for MacOS X which is pretty strict about linkages. Also I wouldn't go off blaming the new gcc 4.2 for braaking a very fragile build system on ccp4. Jack - Original Message - From: William Scott [EMAIL PROTECTED] Date: Thursday, November 16, 2006 9:54 am Subject: Maybe we should just get rid of the packages that don't work with the new gcc4 To: [EMAIL PROTECTED] Cc: fink-devel@lists.sourceforge.net Hi Jack: The ccp4 package currently works and compiles the way that users expect it to on OS X, on linux, and 10 other platforms. If we make large changes, chances are users simply won't want to use this any more. Also, I just don't have time right now to re-invent the whole compilation scheme. Every build takes hours. I've already invested countless hours in this, along with ccp4, to make it work on OS X, and as of today it works great, I can get results and publish them in the best journals. CCP4 have a paid staff to address compilation issues that arise, courtesy of the British taxpayers. They also now distribute OS X binaries. It just doesn't make sense for us to invest more time in this. It would probably make far more sense for me just to remove ccp4 and all of the other packages that don't compile with your new gfortran from fink, or else keep the current gcc4 package and call it something like gcc4-old. Bill - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] upgrade path for xml-sax-pm586_0.14-3
Using fink's 10.4-unstable tree on a dual G5 when upgrading xml-sax-pm586 I get the following error: Preparing to replace xml-sax-pm586 0.14-2 (using .../xml-sax-pm586_0.14-3_darwin-powerpc.deb) ...mv: cannot move `/sw/etc/perl/XML/SAX' to a subdirectory of itself, `/sw/etc/perl5/5.8.6/XML/SAX'/sw/bin/dpkg: error processing /sw/fink/dists/unstable/main/binary-darwin-powerpc/libs/perlmods/xml-sax-pm586_0.14-3_darwin-powerpc.deb (--install): subprocess pre-installation script returned error exit status 1 ... which was resolved by issuing: sudo apt-get remove xml-sax-pm586 sudo apt-get install icon-naming-utils xml-sax-expat-pm586 xml-simple-pm586 xml-sax-pm586 (fink-devel is listed as the maintainer) Best, Robert - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
