lapack: adapt to removal of Job and Comp types in lapack package #38
Conversation
Without this change 'go generate' fails on my machine with: binding: failed to parse ["lapacke.h"]: /usr/include/bits/byteswap.h:37:10: called object is not a function or function pointer (have '<undefined>') (and 1 more errors)
|
I could use the dedicated types instead of byte but I would have to check whether we can map to a type based exclusively on job parameter name or whether some additional logic is necessary. In the latter case I think it is easier to just use the byte type. |
|
It is not possible to decide the type based only on the parameter name and besides we would need Job and Comp types for functions that we haven't ported yet. Given that |
|
Yes, that's my feeling. It feels right that there's almost no support. |
|
I'm sorry, I missed this being opened. This seems like a good idea to me. |
vladimir-ch
force-pushed
the
lapack/job-comp-byte
branch
from
13e3ba4
to
6675b1a
Compare
vladimir-ch
force-pushed
the
lapack/job-comp-byte
branch
from
80e774f
to
b8926a6
Compare
|
I've updated the PR to include also changes for gonum/gonum#595 |
| @@ -335,6 +335,7 @@ func Declarations(paths ...string) ([]Declaration, error) { | |||
| #define __inline | |||
| #define __restrict | |||
| unsigned __builtin_bswap32 (unsigned x); | |||
| unsigned __builtin_bswap16 (unsigned x); | |||
There was a problem hiding this comment.
Out of curiosity, why did this become necessary?
There was a problem hiding this comment.
Without this code generation fails on my Arch machine. Motivated by your question I searched a bit and it comes from a change in glibc 2.28 that uses this built-in function if GCC 4.8 or later is available.
This PR adapts to the changes in gonum/gonum#572 by using
bytetype instead oflapack.Compandlapack.Job. This removes the dependence of this package on thelapackpackage and I think we should do the same for the blas constants. I will send a PR for this later.Please take a look.