use platform dependent c_char instead of hardcoded i8

[mike-kfed]

this should fix issue #351

I am willing to adapt to your preferences, but this works for me (tm)

[seddonm1]

I have tested this on both x86_64 and aarch64 and it works. Would be great to see it merged.

[Dirreke]

And also this @termoshtt .Thanks very much!

[leecbaker]

@mike-kfed Thanks for putting this together!

Is there a reason to use libc::c_char instead of std::ffi::c_char or std::os::raw::c_char?

I think either of those may be equivalent, and avoids adding the dependency on libc.

[mike-kfed]

@leecbaker honestly I just followed the advice found in an open issue and "just wanted to make it work" (tm) ;)

I'll remove the dependency on libc, you are correct the other Rust std lib c_char definitions should be fine too.

[daniestevez]

I'm using this in armv7-unknown-linux-gnueabihf and it works too.

[FylmTM]

Encountered this issue today when our CI was switched to AWS C7g instances, that are using ARM Graviton3 processors.

It seems that this PR fixes the issue. Would it possible to merge it, so that it can become available in upstream? 👀 Thankie!

[daniestevez]

Pinging again on this PR. What would be required to get this or something similar merged?

[ivan-aksamentov]

My version is using core::ffi: https://github.com/rust-ndarray/ndarray-linalg/pull/384

But that's not the whole story. The root cause is addressed in: https://github.com/blas-lapack-rs/lapack-sys/pull/15

These libs feel pretty abandoned. The issues are piling up, PRs are not being reviewed.

I spend lots of time figuring some of the things out and created a new org with fixed forks at https://github.com/numrs. Feel free to grab them. I don't expect this will ever be upsteamed due to reasons above. If you need cross-compilation, then build a static version of openblas yourself and enable system and openblas-system features in all packages. Because opeblas* packages are also broken, but feeding it the prebuilt "system" version is a decent workaround.

[mike-kfed]

@ivan-aksamentov I can make my PR use core too if you like, then there's only one PR in open for the same problem

[ivan-aksamentov]

@mike-kfed Sure, I'll close mine then. I prepared mine independently, without knowing that yours already exist (should have searched better). But it's been a while since yours is hanging. It's likely that neither will be merged anyways :)

[mike-kfed]

@ivan-aksamentov thanks for pointing out that core can be used, makes it more platform independent. I just adapted my code.

for the merging issue, our chances are higher when there's just one PR ;)

[Dirreke]

Hi @bluss, if you have time, could you please review and merge this PR before publishing the new release? It fixes the compile failure issue for ARM.

[bluss]

Just a head's up that I do not have crate publish rights for lax, only ndarray-linalg at this time. Not sure if that can be easily adjusted, let's see.