Standardize ILP64 SONAME and symbols suffix

[nalimilan]

Since #459, it is possible to add a suffix to all symbols during the build, so that the ILP64 version of OpenBLAS does not conflict with the LP64 one. This is necessary to avoid interferences between libraries that might be loaded in a given process.

But there's no standardization of the suffixes and of the SONAME. Julia chose 64_ and libopenblas.so (JuliaLang/julia#8734), while Fedora retained no suffix and libopenblas64.so. Other distributions do not ship a ILP64 version AFAIK, but other apps like NumPy have discussed the same issue (numpy/numpy#5906).

Thus, I suggest to define a convention for the SONAME and the suffix before other projects adopt a different one. It could be as simple as writing it in the build instructions; or a bit more automated, like enabling these SONAME and suffix as soon as INTERFACE=64 is set. The first option would already be great.

I would be inclined to retain libopenblas64.so as the SONAME, and 64_ as the suffix. This implies changes to both Julia and Fedora, but it sounds like the most robust solution, and treats both projects equally.

CC: @tkelman @stevengj @susilehtola

[stevengj]

I would be inclined to use lib<PREFIX>openblas<SUFFIX>.so, e.g. libopenblas64_.so for a 64_ suffix. This can be automated and generalizes to any prefix/suffix, and also avoids putting the Julia project in the situation where we have to wait for a Fedora update for conflicts to go away.

[nalimilan]

@stevengj Interesting idea. I would be OK with that, as with almost any convention.

I don't think Julia would need to wait for a Fedora update in any case. Since the library to use is passed manually to make via an environment variable, I will be able to use the ILP64 Fedora library with my Julia package whenever it adds the suffixes, and whatever the name it retains.

[stevengj]

@nalimilan, one reason for the rename is that when we load some external libraries that also link to libopenblas.so, they are apparently using the Julia version instead (and crashing because of the ABI difference). To avoid this, Julia's soname needs to be different from the OS one, which means we would need to wait for a Fedora update to avoid conflicts with libopenblas64.so.

In any case, I think my proposal is probably cleaner in the long run anyway, since it supports different prefixes and suffixes.

[tkelman]

We could automate this recommendation by putting the SYMBOLSUFFIX at the end of the library name in the makefiles

[stevengj]

@tkelman, that is implemented by #656.

[xianyi]

@stevengj , Thank you for the patch.

@nalimilan , @tkelman , I am going to close this issue. If you have any questions, please reopen it.

[nalimilan]

@xianyi In #656, @stevengj mentioned that another PR should tackle the issue of defining a convention when INTERFACE64=1.

[xianyi]

@nalimilan , I can set a suffix when INTERFACE64=1 . However, I am not sure whether the user wants the different interface.

[nalimilan]

@xianyi Do you mean you're not sure that the user wants INTERFACE64=1, or that the user wants symbols with suffixes added? We're only talking about the latter.

[xianyi]

@nalimilan , the latter. For example, Intel MKL uses same dgemm_ function name for LP64 and ILP64. The user need to link the different library at compiling time.

[nalimilan]

Yes, it's unfortunate that no convention exists. The only solution I can see is for distributions to offer both APIs...

Anyway, it would already be cool if we can agree on a convention to use when adding a suffix. The issue of whether to add it or not is another story.

[nalimilan]

Looks like the suffix to "standardize" on is more clearly 64_ now, as we have three different uses of it: SunPerf BLAS, Julia, and Fedora/EPEL.

[stevengj]

(Note that the 64_ suffix actually goes after the trailing "Fortran" underscore. So, from the perspective of the Fortran symbol, I would say that the suffix is "really" _64. e.g. in C we call dgemm_64_, and in Fortran you call dgemm_64.)