support simultaneous linking of 32- and 64-bit ABIs

[stevengj]

It would be good to have a way to link both the 32- and 64-bit (INTERFACE64=1) versions of OpenBLAS in the same executable. (Note: I am referring to the size of the integer arguments, not the pointer sizes.) To do this, one would need a different name for the latter functions, e.g. cblas_dgemm64 and dgemm64.

We ran into this in Julia, which links the 64-bit OpenBLAS interface, because then it is problematic to link to third-party libraries which want a 32-bit BLAS; see JuliaLang/julia#4923

---

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

[wernsaar]

Hi,

we cannot simply rewrite the whole build process.
But we could provide a shell-script, that builds the libraries for int32 and int64, where
all symbols in the int64 build are prefixed with a string, for example int64_

What do you think about that?

Best regards

Werner

[stevengj]

@wernsaar, we can just use objcopy after the build completes; no modification to the build process is required, just an extra 2-3 lines in the Makefile. I don't see why we need to bother building the int32 version on a 64-bit machine, though.

(Third-party code should be able to link to the int32 version, but I don't think we need to build it ourselves.)

[wernsaar]

On 08.06.2014 21:44, Steven G. Johnson wrote:

@wernsaar, we can just use objcopy after the build completes; no modification to the build process is required, just an extra 2-3 lines in the Makefile. I don't see why we would bother building the int32 version on a 64-bit machine, though.

---

Reply to this email directly or view it on GitHub:
#319 (comment)
Hi,

please give me some extra lines as example.
The I will try and test it.

Werner

[stevengj]

@wernsaar, see this comment

[nalimilan]

I don't see why we need to bother building the int32 version on a 64-bit machine, though.

As I noted at JuliaLang/julia#4923 (comment), it could be interesting (on Linux/BSD) to bundle both LP64 and ILP64 in a single library, using symbol versioning so that programs that have no clue use the former, and those who are aware of ILP64 use it. That would prevent conflicts when mixing libraries that use both, without requiring to patch all calls in a library.

[stevengj]

It seems like this is closed by #459 by @tkelman? That should allow you to link both versions into the same executable; whether they are built into a single library seems unimportant to me.