Re: Mixing Fortran and C (on arm64, ppc64, ppc64el, mips64el and s390x)
- To: Edmund Grimley Evans <edmund.grimley.evans@gmail.com>, edmund.grimley.evans@gmail.com
- Cc: ARM <debian-arm@lists.debian.org>, 774618@bugs.debian.org, 800040@bugs.debian.org, debian-powerpc@lists.debian.org, debian-s390@lists.debian.org, debian-mips@lists.debian.org
- Subject: Re: Mixing Fortran and C (on arm64, ppc64, ppc64el, mips64el and s390x)
- From: peter green <plugwash@p10link.net>
- Date: Sun, 27 Sep 2015 04:56:31 +0100
- Message-id: <[🔎] 560768EE.20406@p10link.net>
- In-reply-to: <[🔎] 20150925205703.GD3923@rano.org>
- References: <[🔎] 20150925205703.GD3923@rano.org>
On 25/09/15 21:57, Edmund Grimley Evans wrote:
Does anyone here have any experience of mixing Fortran and C?
A couple of (possibly) related bug reports:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774618
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800040
Right.
I don't use fortran but I took a look at the bug reports anyway.
#if defined(__alpha__) || defined(__sparc64__) || defined(__x86_64__) || defined(__ia64__)
I think you could just add the failing 64-bit architectures to that
list: defined(__aarch64__) for arm64; see
https://wiki.debian.org/ArchitectureSpecificsMemo for the others.
That just seems like papering over the problem.
(Note that this is, presumably, not supposed to be a list of all
"64-bit architectures". The package seems to be working on s390x and
ppc64, although they are "64-bit architectures" and not in the list
I belive your conclusion is wrong.
From the ppc64 build log (s390x was much the same).
┌──────────────────────────────────────────────────────────────────────────────┐
│ Run tests for ruby2.1 from debian/ruby-tests.rb │
└──────────────────────────────────────────────────────────────────────────────┘
RUBYLIB=/«PKGBUILDDIR»/debian/ruby-lapack/usr/lib/powerpc64-linux-gnu/ruby/vendor_ruby/2.1.0:/«PKGBUILDDIR»/debian/ruby-lapack/usr/lib/ruby/vendor_ruby:. ruby2.1 debian/ruby-tests.rb
Loaded suite tests
Started ** On entry to CGESDD parameter number 5 had an illegal value
/usr/bin/ruby2.2 /usr/bin/gem2deb-test-runner
On the other hand from the alpha build log I see (armel and i386 were
much the same).
┌──────────────────────────────────────────────────────────────────────────────┐
│ Run tests for ruby2.1 from debian/ruby-tests.rb │
└──────────────────────────────────────────────────────────────────────────────┘
RUBYLIB=/«PKGBUILDDIR»/debian/ruby-lapack/usr/lib/alpha-linux-gnu/ruby/vendor_ruby/2.1.0:/«PKGBUILDDIR»/debian/ruby-lapack/usr/lib/ruby/vendor_ruby:. ruby2.1 debian/ruby-tests.rb
Loaded suite tests
Started
...............................................................................
.....................................
Finished in 0.232545348 seconds.
------
116 tests, 448 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed
------
498.83 tests/s, 1926.51 assertions/s
/usr/bin/ruby2.2 /usr/bin/gem2deb-test-runner
So I would conclude that the code is broken on all 64-bit architectures
not explicitly enumerated in the ifdef but the breakage manifests itself
differently on big endian and little endian architectures and for
whatever reason the manifestation seen on big endian architectures
doesn't cause a build failure.
Personally I would suggest changing the ifdef to
#if defined(__alpha__) || defined(__sparc64__) || defined(__x86_64__) || defined(__ia64__) || defined(__LP64__)
(you could remove the specific CPUs that are already there but I left
them in just in case anyone is building with an old compiler)
I would then suggest running test builds on at least one architecture
from each category (e.g. at least one out of arm64/mips64el/ppc64el and
at least one out of s390x/ppc64) and seeing if the situation improves.
Reply to: