Bug 584875
Summary: | RFE: MPI compatibility in fftw? | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | David Jansen <jansen> | ||||||||
Component: | fftw | Assignee: | Rex Dieter <rdieter> | ||||||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | low | ||||||||||
Version: | el5 | CC: | cse.cem+redhatbugz, dave.love, mkrupcale, orion, rdieter, susi.lehtola | ||||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||||
Target Release: | --- | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2017-04-06 10:32:06 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
David Jansen
2010-04-22 15:54:45 UTC
Even though there is a configure option, there is no MPI support in the 3.2 series. It is be part of the 3.3 series, which is in beta phase. When fftw 3.3 is released, we will have to work in the MPI support (at least against Open MPI and MPICH2, which are currently in Fedora). ok, so let's mark this notabug for now, and we'll enable the feature when it actually does something. :) This could be done now. If someone wants to do this and doesn't yet have git access to fftw, I'm happy to approve co-maintainers. I don't have experience building MPI programs / libraries. I'm picturing: 1. We'd add build dependencies on MPI stuff (???) 2. Flip on the --enable-mpi switch 3. fftw produces a few additional libraries 4. We tag those libraries into a new -mpi subpackage (In reply to Conrad Meyer from comment #4) > If someone wants to do this and doesn't yet have git access to fftw, I'm > happy to approve co-maintainers. I don't have experience building MPI > programs / libraries. I'm picturing: > > 1. We'd add build dependencies on MPI stuff (???) > 2. Flip on the --enable-mpi switch > 3. fftw produces a few additional libraries > 4. We tag those libraries into a new -mpi subpackage Not as simple as that, see https://fedoraproject.org/wiki/Packaging:MPI (In reply to Susi Lehtola from comment #5) > Not as simple as that, see Then I really don't want to do it :-). But again, I'm happy to hand out git permissions to anyone who does. Created attachment 1136160 [details]
FFTW spec file patch for MPI
Created attachment 1136161 [details]
FFTW patch for MPI pkg-config
This is my first attempt at a RPM build. I have been working on this issue for the past couple of days and have some progress to report. I've attached a patch for the fftw.spec file and a patch to fix the pkg-config file for the MPI builds (I suggested this to the upstream at https://github.com/FFTW/fftw3/issues/57). I've performed some builds which have succeeded and can be found at: https://copr.fedorainfracloud.org/coprs/mkrupcale/fftw-mpi/build/167900/ (I commented out the make checks for these to speed up the build process and because the MPI checks were failing due to an error "Fatal error in PMPI_Init_thread: Other MPI error, error stack: channel initialization failed" with a "gethostbyname failed". I'm new to using Copr as well and am not sure how to fix that. My local RPM builds were able to pass the MPI checks, though.) There are some rpmlint errors such as *unknown-key (MD5 *zero-length ChangeLog in several of the Copr RPMs. I believe the empty ChangeLog errors were in the original package as well, and the unknown-key errors do not appear in my local builds. I'm also somewhat unsure about whether the non-MPI libraries (i.e. libfftw3{f,,l}_{,threads,omp}.{a,so*}) produced with --enable-mpi are the same as the non-MPI libraries produced without --enable-mpi. Looking at the automake files and source files, it looks like the code and linking for these libraries should be no different with or without --enable-mpi. The non-MPI header files are indeed the same. Comparing the library symbols for the two build modes, it looks like these libraries have the same symbols but different addresses (interrogated with 'readelf -Ws') and different hashes, however. So for now I have assumed that the non-MPI libraries are the same (correct me if this is wrong) and only the MPI headers fftw3*-mpi* and libraries libfftw3{f,,l}_mpi.{a,so*} are different, which are the files to be included in the fftw-{mpich,openmpi}-{libs*,static,devel} subpackages, with corresponding explicit Requires for the fftw-{libs*,devel}. This also required some removal of the allegedly identical non-MPI build files for the MPI builds and is thus probably not the most efficient way to build everything. Please let me know if I have made any mistakes or if you have any other comments. Happy pi day! (In reply to Matthew Krupcale from comment #7) > Created attachment 1136160 [details] > FFTW spec file patch for MPI Looks about right. (In reply to Matthew Krupcale from comment #7) > Created attachment 1136160 [details] > FFTW spec file patch for MPI No need to run ldconfig in the mpi packages as the libs are not installed in /usr/lib{,64}. Otherwise looks good. Created attachment 1140177 [details]
FFTW spec file patch for MPI
-Remove ldconfig %post/%postun in MPI packages.
-Include reference in ChangeLog to this bug.
Fedora EPEL 5 changed to end-of-life (EOL) status on 2017-03-31. Fedora EPEL 5 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora or Fedora EPEL, please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |