Re: mpich C++ transition status
Following up on the issues from my previous note that still exist. Sorry
that I hadn't given this attention sooner; I've been a bit buried
preparing for vacation.
Steve Langasek <vorlon@debian.org> writes:
> On Tue, Oct 04, 2005 at 11:58:11PM -0700, Russ Allbery wrote:
>> rmpi is in dep-wait on arm waiting for libf2c2 (which is building), and
>> in dep-wait on hppa waiting for r-base. r-base failed on hppa with an
>> odd error:
>> running code in 'utils-Ex.R' ...make[1]: *** [check] Terminated
>> make[2]: *** [test-all-basics] Terminated
>> make[3]: *** [test-Examples] Terminated
>> semop(2): encountered an error: Invalid argument
>> make: *** [check-stamp] Terminated
>> make[4]: *** [test-Examples-Base] Error 1
>> Build killed with signal 15 after 150 minutes of inactivity
>> Not really sure what to do with that problem; it smells a little like a
>> buildd issue rather than a problem with the package?
> If the package previously built without trouble on hppa, it tends to
> suggest the package has gotten itself into an infinite loop of some
> kind, or else that a new version is substantially slower than previous
> versions for some unknown reason. It will almost certainly require
> coordination between the maintainer and the buildd admin to figure out.
I've filed a bug against r-base for this. I'm going to file it at
severity: important since I don't want the bug itself to block migration
if hppa gets built properly, but if that's not correct and it should be
upgraded, please feel free to either do so or ask me to do so.
>> scalapack failed on powerpc with:
>> /usr/bin/ld: /usr/lib/gcc/powerpc-linux-gnu/4.0.2/../../../../lib/libf2c.a(lread.o)(.got2+0xbc): unresolvable R_PPC_ADDR32 relocation against symbol `f__units'
>> /usr/bin/ld: final link failed: Nonrepresentable section on output
>> Does this ring a bell with anyone? That looks like a gcc issue, not a
>> problem with the package. It's also in dep-wait on arm waiting for
>> libf2c2.
> My first guess was that scalapack was trying to link a shared library
> against non-PIC code, but that doesn't seem to be the case. It may be a
> problem with gcc, but it may be a once-removed problem with an *old*
> version of gcc that requires rebuilding libf2c to fix it. Dunno,
> someone will need to poke at this (maybe debian-powerpc?).
I've now seen this problem elsewhere, and it's a problem with binutils on
powerpc. krb5 appears to also be affected. See Bug#329686 for more
details. Rebuilding the affected library from source should fix the
problem.
I'm not sure the right approach to take here. A new libf2c2 build on
powerpc with the current binutils will fix the problem; should I file a
bug against libf2c2 asking for a new sourceful upload to unstable, or is
this the place for a porter binary NMU? I never entirely understood how
those are supposed to work and when they are appropriate.
> The removal will be semi-automatic once plplot has built on m68k, but
> that won't happen until octave2.1 is also available on m68k. But
> octave2.1 build-depends on gfortran, which is not available on m68k --
> and not because the package hasn't built, because the package source is
> gcc-defaults. That looks like someone should file a bug against
> octave2.1, asking it to build-depend again on fort77 on m68k as previous
> versions did.
Bug filed.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Reply to: