[Pkg-openmpi-maintainers] Bug#457088: Bug#457088: Bug#457088: Bug#457088: mpi.h is missing

[Manuel Prinz]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.alioth.debian.org/pipermail/pkg-openmpi-maintainers/attachments/20071220/b89169a6/attachment-0001.pgp