Description of problem: The static libraries where dropped between fftw-devel-3.1-1.fc4.x86_64.rpm and fftw-devel-3.1-2.fc4.x86_64.rpm. This prevents building static executables that use FFTW 3.1 that can be checkpointed on Condor clusters. Version-Release number of selected component (if applicable): fftw-devel-3.1-2.fc4.x86_64.rpm How reproducible: 100% Steps to Reproduce: 1. rpm -qlp fftw-devel-3.1-2.fc4.x86_64.rpm 2. Note missing /usr/lib64/lib*.a files 3. Actual results: Expected results: Additional info:
I'm willing to reconsider my decision to remove static libs--I removed them because it's the prevailing opinion of Fedora Extras developers that they should be removed. However, could you provide some more detail on exactly why static libraries are necessary for this and why dynamic libraries won't work?
Condor is a job scheduler for large collections of computers that aggregates them into a large computation pool (http://www.cs.wisc.edu/condor). For Condor to checkpoint long running jobs so they can be resumed again at a later time and/or on a different computer it must follow the following rules listed for Standard Universe jobs, http://www.cs.wisc.edu/condor/manual/v6.7/2_4Road_map_Running.html#sec:standard-universe One of these restrictions for Linux is that the executable be statically linked. Thanks.
After starting an extensive discussion on the fedora-extras mailing list, I have decided for the time being to put the static libs back the way they were, particularly since they were for a current Fedora Core release. Some have proposed the creation of -static packages for static libs. This approach has some merits, but at this time there appears to be only one such package in Fedora Core or Extras. I may consider doing that later, but I would like a more established standard before doing so.