[Pkg-openmpi-maintainers] [Fwd: Re: debian/patches/99autoconf]

[Manuel Prinz]

I did some investigation on that. To cut a long story short, I'm pretty
sure that the 10opal* patch is obsolete and can be safely removed from
trunk, along with the 99* patch. More details follow, if you're
interested. Otherwise, you can stop reading here.


Am Mittwoch, den 27.06.2007, 10:44 -0500 schrieb Dirk Eddelbuettel:
> I really appreciate your digging through this!

Thanks! It's part of maintaining, after all. ;)

> [ As an aside, has anybody figured out what to do with the test/ directory? I
> could not find a 'make check' or 'make test' entry.  If we had unit tests
> from upstream, then comparing the config changes would be simpler :-/ ]

On my system, the tests seem to be created as part of the regular build
process. Invoking "make check" in the root directory runs them. (The
results get lost in way too much output, nevertheless.)

> Sorry, let me try again:   If there is a 10opal* patch, why do we need to
> patch a second time via autoconf?

I think the reasoning was to seperate the "source" patch from the
"binary" patch, meaning to keep the changes in the autogenerated files
seperate from the "real" patch, so one doesn't need to worry about
those. We do actually, so this is kind of not working.

> Would be nice to confirm.  The one (semi-strong) argument in favour is that I
> have learned, at some cost :), to just trust Steve Langasek. If he was
> involved in the patch at some point, there must be a reason. But from the
> changelog I can't quite decipher what he did -- some FTBFS issue?

Seems to be the result of some Etch RC bug squashing or something. I am
not sure.

> Also, they stem from the 1.1* series that Florian started with and may well
> have gotten obsolete now.  

As mentioned earlier, I'm quite sure they are.

I compiled the unmodified upstream version and checked it with scanelf
and readelf for the GNU-stack note. I didn't find any. I created a list
of all assember files and those file containing the string "GNU-stack".
Those list didn't match because some files are platform-specific and not
build.

Anyway, configure checks if the GNU-stack node is needed. The Perl
script in ./opal/asm modifies the assembler files, adding a GNU-stack
note if it's required. The assembler files all seem to ship without one,
so it's added during the build.

To me, it looks like upstream thought about this issue and I'm quite
sure that configure will handle the situation on other architectures
correctly; I can't test that anyway. So compiling with --noexecstack is
useless because upstreams version doesn't create files that expect an
executable stack, making the 10opal* patch obsolete. And since 99*
contains only changes due to the 10opal* patch, it's obsolete too.

I'll have to delete those patches and recompile to check if it still
works but don't see a reason why it wouldn't.

Best regards
Manuel