GeezerVison is showing github.com — Arrayfire Static Library · Issue #313 · arrayfire/arrayfire
Arrayfire Static Library #313DescriptionIt would be awesome to have arrayfire built as a static library in addition to a shared one.
It makes it a lot easier to build in ar files into projects than to use dynamic linkage.
This would also entail:
- static clFFT
- static clBLAS
- static arrayfire
Activityjramapuram commented on Jul 20, 2015 This would be very useful to have when incorporating arrayfire into other languages such as Rust. RoyiAvital commented on May 7, 2018 @umar456 ,
The current situation of shared libraries mean that if I write a simulation and I want it to run on someone else's computer he must install ArrayFire as well.
This is a deal breaker for many reasons.
You really should reevaluate this decision. umar456 commented on May 7, 2018 You can include the ArrayFire so/dlls with your application. They do not need to separately install the library. RoyiAvital commented on May 7, 2018 @umar456 ,
Yea. But it is always less convenient and bullet proof than static linking.
Anyhow, I will watch this issue.
Once you offer static linking in installers I will start using ArrayFire as it seems perfect for scientific computing. jramapuram commented on May 8, 2018 @umar456 : is the issue mainly the linking with GLIBC? Any chance of statically linking against MUSL? FloopCZ commented on May 8, 2018 @RoyiAvital @jramapuram I believe that even in the case of static ArrayFire linkage, libc can remain to be linked dynamically, the same stands for CUDA, OpenCL, etc, that cannot be easily statically linked anyway.
But as @umar456, you should be able to distribute the necessary ArrayFire libraries along with your application, just take a look at the output of ldd your_program to see the objects it is linked against.
[floop@pine /tmp ]$ ldd a.out
linux-vdso.so.1 (0x00007ffe20fa3000)
libaf.so.3 => /usr/lib/libaf.so.3 (0x00007fe9ef435000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fe9ef0ae000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fe9eed1a000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fe9eeb03000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fe9ee748000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fe9ee544000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fe9ee326000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fe9efb18000)
Then you need to distribute the objects with you application, and set up the linker properly to pick them up (e.g., by setting LD_LIBRARY_PATH). On Windows, I believe the objects are picked up automatically as long as they reside in the same directory as the executable (not 100% sure though). I actually prefer this option to a single huge statically linked executable. It is easier to update and easier to manage.
Furthermore, some distributions already ship ArrayFire in their repositories, so as long as you are on Linux, the installation procedure is simple. However, beware that e.g., Ubuntu has a very old version of ArrayFire (3.3), so there is quite a few unresolved issues.
The last option is to use the official installer, e.g., something like:
sh ArrayFire-v3.6.0_Linux_x86_64.sh --exclude-subdir --prefix=/usr/local
RoyiAvital commented on May 8, 2018 Guys,
I'm not using Linux.
That's the problem with the Linux concept, everything is allowed to be some kind of a hack and assumed to be done by experts.
I want to focus about the algorithm not how to support colleagues how to run it.
For instant, Eigen model is perfect for that.
Once you compile it, it works.
Same with Intel IPP / MKL, if you chose static linking, once you compile it, the program is totally portable.
I think this is the right model for auxiliary library. FloopCZ commented on May 8, 2018 @RoyiAvital The procedure with providing the objects (.dll files) along with your executable works for Windows as well and it is a usual practice. Windows programs ported from Linux are often shipped with their own dynamically linked qt, gtk or similar, but also pure Windows programs are split into many libraries loaded in runtime. Your colleagues don't have to do anything extra, they just get the folder you gave them and run the executable as for any other program.
The main difference between Windows-style "Program Files" and Linux-style "/usr/lib" is that on Windows, every program tends to have its own copy of the nonstandard libraries it uses, whereas on Linux, the recommended way is to have a single copy of all libraries that are shared between all the programs that use them. Both approaches have their pros and cons (both practical and legal).
The Eigen model you mention is a bit different. Eigen is a header-only library, so it does not even compile into a library. The benefit is that there is no library to distribute. The disadvantage is that your program usually takes longer to compile compared to the case where you have an already precompiled library you just link to. Therefore, header-only libraries have some limitations (but if you have a heavily templated code, you have no other option anyway, hopefully C++ modules will be adopted soon).
ArrayFire uses CUDA, OpenCL and similar and those are difficult and often impossible to build statically. That is the reason why I cannot see the real benefit of static linkage in this case. You have to distribute the objects of the underlying libraries anyway, so just drag&dropping one more library does not seem to be an issue.
But don't take me wrong, I don't want to discourage you, I want to help you. Of course, both static and shared libraries have their pros and cons, but both can be made portable. What I would consider to be interesting is a static library of ArrayFire CPU backend for minimalistic applications and mobile devices without GPU support. For any other use, dynamic library seems to be appropriate. (This is how TensorFlow does it). Reacted by syurkevi and Pradeep Garigipati umar456 commented on May 8, 2018 As @FloopCZ mentioned, the DLL model works on Windows just fine.
With that said, I can understand the appeal for static libraries. Currently, there are some practical limitations that prevent me from including them with the installers. The main issue is that the installer's size is already quite large. Including static libraries will almost double that size. There are ways to improve this situation and this is something that I want to work on for the next release.
I am not suggesting that we will not support static libs for the builds. I think that should be possible but will be more involved for the end user. They will need static versions for each of the dependencies but it should be possible for the CPU and CUDA backends. I think OpenCL requires you to link against libOpenCL and I am not sure if there is a way to statically link that library.
There seems to be a good bit of interest for this issue. I will try to make more progress on this soon. RoyiAvital commented on May 8, 2018 @FloopCZ ,
What you're talking about DLL is related to applications and programs.
Namely behind them there is a company, support, resources...
When someone want to share simple simulation with someone else this model doesn't work.
Again, from my point of view ArrayFire is like Intel MKL.
If they give Static Linking out of the box, I'd expect similar libraries to do so as well.
CUDA / OpenCL can be assumed to be installed as those available on most computers with dedicated GPU on Windows. So no problem here...
It doesn't make sense to have ArrayFire installed on target computer or start dealing with DLL's (Or any Dynamic Library). damian123 commented on Dec 27, 2018 This would be nice, in particular the MKL libraries can only be dynamically linked at the moment.
This would require a change in the FindMKL.cmake file.
FYI.: I am on Windows 10, Visual Studio 2017. umar456 commented on Mar 25, 2020 We have made a little bit of progress on this front with #2785 . I will attempt to do this again in the next minor release. haydnv commented on May 29, 2021 Is there any ETA for when this feature will be available? 9prady9 commented on May 31, 2021 @haydnv Unfortunately, we don't have an ETA for this yet. Kindly bare with us. We will share any updates we have here as soon as we have it.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|