Bug#459025: [Pkg-scicomp-devel] Bug#459025: parmetis_3.1-8+b1(unstable/amd64/xenophanes): FTBFS: Doesn't search for mpi.h in right include path
Ondrej Certik [EMAIL PROTECTED] writes: On Jan 4, 2008 10:15 AM, Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote: I tried rebuilding parmetis against the new mpich packages, so that the whole heap of packages can migrate to testing. This failed: | Automatic build of parmetis_3.1-8+b1 on xenophanes by sbuild/amd64 98-farm | Build started at 20080104-0031 | ** [...] | make[2]: Entering directory `/build/buildd/parmetis-3.1/METISLib' | gcc -I. -I.. -I/build/buildd/parmetis-3.1/ -O3 -c coarsen.c | In file included from ./metis.h:27, | from coarsen.c:13: | ../parmetis.h:17:17: error: mpi.h: No such file or directory | In file included from ./metis.h:27, | from coarsen.c:13: | ../parmetis.h:59: error: expected declaration specifiers or '...' before 'MPI_Comm' [...] A complete build log can be found at http://experimental.debian.net/build.php?arch=amd64pkg=parmetisver=3.1-8+b1 I guess you will need to update the build scripts to look into /usr/lib/openmpi/include. The problem is, that openmpi package moved the *.h files out of /usr/include to /usr/lib and created a link from /usr/include/openmpi. However, that link doesn't always work. And if the link doesn't work, it's a FHS violation - *.h files should be in /usr/include/... not in /usr/lib. Ehm, parmetis is *only* looking into the standard include path + some local dirs. There is no mpi.h in /usr/include, even if the symlink exists. Either you need to add /usr/include/openmpi to the include path or try to include openmpi/mpi.h (which sounds b0rken) (ie add -I/usr/include/openmpi and everything should be fine). Marc -- Fachbegriffe der Informatik - Einfach erklärt 158: Geisterfahrer Gegenrichtungsfahrbahnbenutzer (Burkhardt Schröder) pgpTSqM2lWy7f.pgp Description: PGP signature
Bug#459025: [Pkg-scicomp-devel] Bug#459025: parmetis_3.1-8+b1(unstable/amd64/xenophanes): FTBFS: Doesn't search for mpi.h in right include path
On Jan 4, 2008 11:52 AM, Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote: Ondrej Certik [EMAIL PROTECTED] writes: On Jan 4, 2008 10:15 AM, Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote: I tried rebuilding parmetis against the new mpich packages, so that the whole heap of packages can migrate to testing. This failed: | Automatic build of parmetis_3.1-8+b1 on xenophanes by sbuild/amd64 98-farm | Build started at 20080104-0031 | ** [...] | make[2]: Entering directory `/build/buildd/parmetis-3.1/METISLib' | gcc -I. -I.. -I/build/buildd/parmetis-3.1/ -O3 -c coarsen.c | In file included from ./metis.h:27, | from coarsen.c:13: | ../parmetis.h:17:17: error: mpi.h: No such file or directory | In file included from ./metis.h:27, | from coarsen.c:13: | ../parmetis.h:59: error: expected declaration specifiers or '...' before 'MPI_Comm' [...] A complete build log can be found at http://experimental.debian.net/build.php?arch=amd64pkg=parmetisver=3.1-8+b1 I guess you will need to update the build scripts to look into /usr/lib/openmpi/include. The problem is, that openmpi package moved the *.h files out of /usr/include to /usr/lib and created a link from /usr/include/openmpi. However, that link doesn't always work. And if the link doesn't work, it's a FHS violation - *.h files should be in /usr/include/... not in /usr/lib. Ehm, parmetis is *only* looking into the standard include path + some local dirs. There is no mpi.h in /usr/include, even if the symlink There are two problems here: 1) parmetis is only looking into /usr/include, which used to work, it doesn't now and thus parmetis should be fixed to look into the place where mpi.h is supposed to be 2) the quesiton is, where to look. One place where mpi.h is is this: /usr/lib/openmpi/include/mpi.h, however, that is not FHS compliant, as I understand it. *.h file should be in /usr/include/somewhere. The mpi.h should be either in /usr/include/mpi.h, or /usr/include/openmpi/mpi.h. Neither of which works now, so I just reported a bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=459070 exists. Either you need to add /usr/include/openmpi to the include path or try to include openmpi/mpi.h (which sounds b0rken) (ie add -I/usr/include/openmpi and everything should be fine). As I said above, I don't think this will work. For now, Christophe fixed this by adding: -I/usr/lib/openmpi/include, so the package should work now, but clearly, one should look into /usr/include/openmpi for *.h files. At least that's what I thought. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459025: [Pkg-scicomp-devel] Bug#459025: parmetis_3.1-8+b1(unstable/amd64/xenophanes): FTBFS: Doesn't search for mpi.h in right include path
On Jan 4, 2008 10:15 AM, Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote: Package: parmetis Version: 3.1-8+b1 Severity: serious Heya, I tried rebuilding parmetis against the new mpich packages, so that the whole heap of packages can migrate to testing. This failed: | Automatic build of parmetis_3.1-8+b1 on xenophanes by sbuild/amd64 98-farm | Build started at 20080104-0031 | ** [...] | make[2]: Entering directory `/build/buildd/parmetis-3.1/METISLib' | gcc -I. -I.. -I/build/buildd/parmetis-3.1/ -O3 -c coarsen.c | In file included from ./metis.h:27, | from coarsen.c:13: | ../parmetis.h:17:17: error: mpi.h: No such file or directory | In file included from ./metis.h:27, | from coarsen.c:13: | ../parmetis.h:59: error: expected declaration specifiers or '...' before 'MPI_Comm' [...] A complete build log can be found at http://experimental.debian.net/build.php?arch=amd64pkg=parmetisver=3.1-8+b1 I guess you will need to update the build scripts to look into /usr/lib/openmpi/include. Thanks a lot! The problem is, that openmpi package moved the *.h files out of /usr/include to /usr/lib and created a link from /usr/include/openmpi. However, that link doesn't always work. And if the link doesn't work, it's a FHS violation - *.h files should be in /usr/include/... not in /usr/lib. I reported this against the openmpi package here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457088 But I was not accepted friendly. Unfortunately, I just checked on my computer, and /usr/include/openmpi doesn't work, so I will have to report it again. Part of the problem is probably in the broken update-alternatives package (that sometimes fails to update the link), but nevertheless it's the openmpi package, that doens't work. So I think I should report it against the openmpi package, right? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
