bugGNU Octave - Bugs: bug #50510, 64-bit build issue


bug #50510: 64-bit build issue

Submitted by:  John W. Eaton <jwe>
Submitted on:  Fri 10 Mar 2017 06:01:12 PM UTC  
Category: Configuration and Build SystemSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Build Failure
Status: Ready For TestAssigned to: None
Originator Name: jweOpen/Closed: Closed
Release: devOperating System: Mac OS

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Thu 13 Apr 2017 02:00:41 PM UTC, comment #7:

Closing report since it seems to have fixed the build problem on OS X systems.

John W. Eaton <jwe>
Project Administrator
Wed 12 Apr 2017 08:31:17 PM UTC, comment #6:

I checked in the following changeset:


It might be possible to do this more efficiently with a configure check, but I'm not up for that challenge at the moment.

John W. Eaton <jwe>
Project Administrator
Wed 22 Mar 2017 06:29:47 PM UTC, comment #5:

Ideally, the SuiteSparse_long type would be defined to be the same as int64_t, and we wouldn't have to worry about this at all. But it sounds like macOS libc defines int64_t to be "long long int", which seems unnecessary, but fine; while SuiteSparse_long is just "long int".

I guess if we can't trust that SuiteSparse_long will always be the same as int64_t on a given system, then we might need to introduce copying (inefficient) or punning (maybe risky) to convert between what Octave uses for 64-bit integers and what SuiteSparse needs.

Or we add a configure rule to test that SuiteSparse_long is the same as int64_t, and refuse to build against it if that is not the case.

Mike Miller <mtmiller>
Project Administrator
Wed 15 Mar 2017 08:53:23 PM UTC, comment #4:

This issue isn't about compiling everything for 64-bit integers. It's about pointers to long int not being compatible to pointers to long long int, even when they are both signed integers that are 64-bits wide.

John W. Eaton <jwe>
Project Administrator
Fri 10 Mar 2017 11:19:03 PM UTC, comment #3:

AFAIK, the situation on Linux isn't that easy too. If one really wants everything to work with 64 bit indices (OpenBLAS, Suitesparse, ARPACK, QRUPDATE, and Octave) one needs to compile everything by his own too. On Debian and OpenSuse all the dependent binary packages are configured using "int" as index type, just to match the default FORTRAN integer size.

Mike https://bitbucket.org/mtmiller/octave-64-bit-index-builder and I https://github.com/siko1056/GNU-Octave-enable-64 created build instructions to actually address this issue. So maybe macOS needs some MXE-Octave as well?

Kai Torben Ohlhus <siko1056>
Project Member
Fri 10 Mar 2017 10:36:38 PM UTC, comment #2:

suitesparse provides interfaces for both 32- and 64-bit integers. With whatever package system we are using on OS X, it is configured to use "long int" for 64-bit integers. That is not identical to int64_t, which is a typedef for "long long int" on that system.

We don't get to choose what typedef is used for suitesparse if we are using someone else's packaged version of it.

Yes, other systems could have similar issues. We build everything ourselves on Windows and we use typedefs that match.

We could see the same for Linux systems if "long int" and "long long int" were mixed. They are the same size. But we appear to be lucky there and everyone seems to use "long int" and that's the same as what is used for "int64_t".

John W. Eaton <jwe>
Project Administrator
Fri 10 Mar 2017 10:22:40 PM UTC, comment #1:

You say "suitesparse is configured to use 'long int'", so you don't have an influence on the configuration?

Otherwise you can configure SuiteSparse using -DLONGBLAS='long long'. See SuiteSparse_config/SuiteSparse_config.mk:

I assume for Windows there is the same issue. On Linux usually sizeof(long) is 64 Bit, on my rarely used Windows systems 32 Bit only. But I don't use Octave there.

Kai Torben Ohlhus <siko1056>
Project Member
Fri 10 Mar 2017 06:01:12 PM UTC, original submission:

This build is failing due to a 64-bit integer issue:


The failure happens because Octave is using int64_t (== "long long int" on OS X systems) for octave_idx_type but suitesparse is configured to use "long int" for 64-bit integers.

This shouldn't matter, right? They are both 8-byte integers. But no, passing a pointer to long long int to a function that expects a pointer to long int is an error.

In all fairness, this is not a clang or OS X problem. It would happen anywhere. We just haven't noticed it until now because the typedefs on other systems have happened to be consistent. But in a world where there are independently compiled libraries, it seems there is little hope that everyone will make the same choice. So, what to do?

I chose Mac OS as the OS category since that's where I noticed the failure, but it could happen anywhere.

John W. Eaton <jwe>
Project Administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by jwe (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 13 Apr 2017 02:00:41 PM UTCjweOpen/ClosedOpen=>Closed
    Wed 12 Apr 2017 08:31:17 PM UTCjweStatusNeed Info=>Ready For Test
    Fri 10 Mar 2017 10:22:40 PM UTCsiko1056StatusNone=>Need Info

    Back to the top

    Powered by Savane 3.1-cleanup1