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

 
 

bug #50510: 64-bit build issue

Submitter:  John W. Eaton <jwe>
Submitted:  Fri 10 Mar 2017 06:01:12 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Ready For Test Assigned to:  None
Originator Name:  jwe Open/Closed:  * Closed
Release:  * dev Operating System:  * Mac OS
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group administrator
Wed 12 Apr 2017 08:31:17 PM UTC, comment #6: 

I checked in the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/209e749363a2

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>
Group 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>
Group Member
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>
Group 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>
Group 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>
Group 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:


# -D'LONGBLAS=long' or -DLONGBLAS='long long' defines the integers used by
#               LAPACK and the BLAS (defaults to 'int')


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>
Group Member
Fri 10 Mar 2017 06:01:12 PM UTC, 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>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-04-13 jwe Open/ClosedOpen Closed
    2017-04-12 jwe StatusNeed Info Ready For Test
    2017-03-10 siko1056 StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code