both BLAS and LAPACK are compiled in FORTRAN and sustain -lgfortran dependency..
There are actually multiple implementations providing the exact same API (and ABI), from Goto to OpenBLAS to Intel MKL and AMD OCL.
Not all of them are written in Fortran, nor do all of them even have Fortran bindings.
We barely could rely that sort of redirection tests to some Pythonish "os.module"...
Bullshit, because existing Python code that does not rely on non-builtin modules runs absolutely fine on all architectures. That is proof that it can be done. It is the contributed Python modules that rely on specific native libraries that makes things difficult.
Moreover, the fact that you can use native Qt 5 libraries using the same Python code using PyQt5, PySide2, or GIR bindings –– the first two using SIP and the latter using GObject introspection files to generate the Python bindings –– with something like a fifty-line module shim (that selects the interface to be used at runtime, depending on what is available, optionally controlled by an environment variable) –– shows that it is also practically possible; it is just a matter of the Python modules being uniform and available on all OSes also, without their own dependency hells.
You could ask "Why, then, do so many Python projects suffer from dependency hell?". This is what my post above dug into. Because the base library doesn't modularise OS features properly, many developers don't bother to do it either. (I am drawing a somewhat tenuous relationship here, but I believe it is true: it just isn't something Python developers want to consider at all.) Hell, most external Python modules don't even bother to state their library versions and dependencies!
That is a problem that an interpreted programming language could and should solve better.
If you want to provide an "universal Linux binary" using any interpreted language like Python, it is easiest to do so via a dynamically linked interpreter that uses a fixed directory for all its libraries, that directory being populated by symlinks to either system libraries or the versions provided along with the binary itself, whichever is newer or preferred by the user. You could even have a run-time configurator utility to manage those. (However, that has security implications re. system-wide vs. per-user installations, and the interpreter/binaries being able to modify themselves, making this approach one of those which basically requires a dedicated user and group for such an application. Very doable, but it is a complex subject that requires quite a lot of experience to do right, which explains why it is so often done wrong.)
I often write POSIX C exactly because of this. The subset and superset of C implemented is closer to what I need, so that the code I write does not need autotools to be compilable and runnable across basically all POSIXy systems (Linux, Android, MacOS, BSDs, Unixes with a POSIXy C library). What does annoy me, however, is that as long as I use the standard C library in Linux, I cannot get at the really nifty features provided by the Linux kernel for my Linux-only code, like per-task credentials (user and group). (The C library in Linux uses a realtime signal across all threads in the process to synchronize those in userspace.)
(I have written simple shell scripts to emulate basic
./configure functionality to modify an included Makefile fragment setting the directory paths and such. It is not necessary to run it, but if someone wants to modify how the binary is compiled and installed, they can do so either via that script or by modifying the configuration Makefile snippet. All explained in the traditional
INSTALL text file.)
As someone having used Linux from Scratch extensively a decade or two ago, I'm very familiar with
using autotools. However, I do not like to write code that requires autotools to be compiled myself. For similar reasons, I don't like CMake much either. In other words, I am happy that autoconf and automake and CMake exist as they can often fix these issues without worries; that on my systems running GNU-derived build tools they almost always Just Work. However, I am decidedly not happy that autoconf and automake are needed in the first place.
Home
Help
Search
Login
Register
Poll
