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

 
 

bug #50510: 64-bit build issue

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

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

Wed Mar 22 18:29:47 2017, 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 Mar 15 20:53:23 2017, 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 Mar 10 23:19:03 2017, 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 Mar 10 22:36:38 2017, 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 Mar 10 22:22:40 2017, 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 Mar 10 18:01:12 2017, original submission:

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

http://buildbot.octave.org:8010/builders/clang-osx

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):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by siko1056 (Posted a comment)
  • -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):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri Mar 10 22:22:40 2017siko1056StatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup1