Mixing Fortran and C (on arm64, ppc64, ppc64el, mips64el and s390x)

[peter green]

Does anyone here have any experience of mixing Fortran and C?
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.

[Edmund Grimley Evans]

Post by peter green
From the ppc64 build log (s390x was much the same).

Thank you for taking the trouble to look at the build logs; I just saw
that it was "Installed" and naively assumed it had worked!

Perhaps then the architectures for which "INTEGER" is "long" (or
whatever) really are exactly those architectures for which a pointer
is 64-bit. If that is the case, one could use

Post by peter green
#if defined(__alpha__) || defined(__sparc64__) || defined(__x86_64__) || defined(__ia64__) || defined(__LP64__)

as you suggest, or just

#if defined(__LP64__)

or:

#include <stdint.h>
#if UINTPTR_MAX == UINT64_MAX

I think that last approach is required to work by the standards, while
__LP64__ is a GCC extension, though I might be wrong.

[peter green]

Post by Edmund Grimley Evans

Post by peter green
From the ppc64 build log (s390x was much the same).

Thank you for taking the trouble to look at the build logs; I just saw
that it was "Installed" and naively assumed it had worked!
Perhaps then the architectures for which "INTEGER" is "long" (or
whatever) really are exactly those architectures for which a pointer
is 64-bit.

Umm, you seem to be reading things backwards.

#if defined(__alpha__) || defined(__sparc64__) || defined(__x86_64__) ||
defined(__ia64__)
typedef int integer;
typedef int logical;
#else
typedef long int integer;
typedef long int logical;
#endif

That code is defining "integer" and "logical" as "long" on most
architectures but as "int" on a list of 64-bit architectures. My
interpretation is that the code is trying to make "integer" and
"logical" 32-bit on all systems.

If you only care about Debian and other modern systems you could
probablly reduce the code to

typedef int integer;
typedef int logical;

Since int is 32-bit on all Debian architectures.

Post by Edmund Grimley Evans
#include<stdint.h>
#if UINTPTR_MAX == UINT64_MAX
I think that last approach is required to work by the standards, while
__LP64__ is a GCC extension, though I might be wrong.

If my understanding of the intent of the ifdef is correct and you
believe it's ok to rely on c99 stuff you may as well just do

#include <|inttypes.h|>
typedef int32_t integer;
typedef int32_t logical;