Hi Ondrej! Am Donnerstag, den 20.12.2007, 08:00 +0100 schrieb Ondrej Certik: > thanks very much for your reply. As you explained in your previous email, > I think the misunderstanding is, that you and Dirk think, that > /usr/include/mpi.h > is symlinked to /usr/lib/openmpi/whatever, right?
No. We never stated that mpi.h is symlinked in /usr/include. I said in my previous mail that mpi.h can be found in the /usr/include/mpi directory which is a symlink to /usr/lib/openmpi/include/. This is like all MPI packages do it. To the best of my knowledge, this is totally fine. All X11 include files are for example in /usr/include/X11 and not symlinked into /usr/include. Neither do we, because the amount of header files you need to compile against a MPI package varies between the packages. That's we all provide them in /usr/include/mpi as alternative. > If it was true, everything would be fine and imho that would be > according to the policy. Unfortunately, I think it is not true: > > $ ll /usr/include/mpi.h > ls: /usr/include/mpi.h: No such file or directory > > That's just my computer, it can be misconfigured. But it's the same > problem on buildbots: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456869 As I stated already, this is supposed to happen, as there is no /usr/include/mpi.h. There's just an /usr/include/mpi/mpi.h. To make things even worse, mpich does not even have a mpi.h. But you're not building against that anyway. > As you can see there: > > > /usr/lib/petsc/include/petsc.h:138:17: error: mpi.h: No such file or > > directory > > if the mpi.h was in /usr/include, as you say, it would be found. Yes. But if you provide -I/usr/include/mpi to your compiler, it would be found as well, and you don't have to modify your package at all if some thinks it's a better idea to compile it against i.e. LAM. > Imho, the right thing to do is to open this bug, leave it open, and > then try to fix it. Maybe it's a problem with update-alternatives > again, as it used to be in the past. Could be. But, the end result is, that > libopenmpi-dev is not following FHS (for one reason or another) and > that is a bug (in my opinion). So let's open this bug and maybe > another one in update-alternatives, blocking this one? This time, it's not a problem of update-alternatives. We can of course reopen the bug. (Or you can do it, if you feel it's the right thing, I won't blame you.) I do not know what your solution to this is. I can see two: 1. We move stuff to symlink in /usr/include, so /usr/include/mpi.h can be found there. That means we do have to do a lot of cross-checking with the other packages and clutter /usr/include without a good reason. As said above, you usually need more than mpi.h to link successfully. This will take a while and we need to get the other MPI maintainers to adopt the change. 2. You pass -I/usr/include/mpi or check if your ./configure accepts something like --with-mpi-include. Some packages using MPI do because they are aware that there is more than just one MPI implementation in the wild. That is the way most packages went for years. > I think there is some misunderstanding, I am sure you have thought > about libopenmpi-dev being compliant to FHS and that's why > you think it's not a bug, but I have my computer misconfigured (and > buildbots too). So where is your intended place for mpi.h? > /usr/inlude/mpi.h? Or /usr/include/openmpi/mpi.h? (Neither exist on my > system). As explained above, neither of them. It's /usr/include/mpi/mpi.h. > Let's make this clear, and then try to fix this bug. Agreed. I'd like to hear your view on what solutions you like best, or maybe you have a better solution than the ones I proposed. But to fix it, we need to agree on how to that. (Or in our case, agree that it's actually broken.) > I would be glad, if you could Dirk reopen it. As said, everyone can do this. If you still think it has to be reopened after reading this email, you should do so! > Thanks a lot, You're welcome. Best regards, Manuel
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
