Leaderboard

I get the point. Dynamically referenced will not be visible by the builder as dependency. If I may forgiven for being so stubborn, as a workaround one could still put just one conditional disable structure with the different statically linked CLNs within a false if frame in just one mandatory, but called once, ancillary, and leave all the rest with mupLibPath.

you make it sound more impossible than it reasonably is in this case. libmuparser is at least not unknown to ubuntu, I apparently brought it on 14 and 16 as dependency of meshlib or of some FEM package. Now Porter's toolbox is apparently using a patched version of it to add some syntactical feature, but the toolbox would also work with the off the box version of it. Even with an earlier version, if the ABI didn't change. If, I concede. But LV-muParser could say: requires x.x.x<libmuparser<y.y.y If a locally patched version of the library is so important, to avoid conflicts just give it an insanely improbable name - like libmuparser-with-added-esclamation.so Dump the responsibility to the author of the original library: ./configure; make; make install. If it can be built for the target distro (or if someone bothered to distribute it), ok; if it can't, just don't claim it is supported. I haven't thoroughly looked into, and I'm just a script-kiddy at it anyway, but FWIW nm -C libmuparserX64.so.2.2.4 | grep @ tells me only of GLIBC_2.0, GLIBC_2.3.4, GCC_3.0, CXXABI_1.3, GLIBCXX_3.4 - standard stuff, hopefully not dramatically changing across distros. Anyway - I agree that the effort is best invested in developing the toolbox. I never suggested that the toolbox should provide also compiled .so, and see the reasons why. I was perhaps carried along by the academic discussion, which in my view was in general about the best LV strategy to support different shared libraries for different platforms.

The issue is not much to do with LabVIEW and very much depends on the distro and versions already present. Your next issue may be that Linux will load another DLL with the same name if it is present in the general locations and everything will crash. The DLL should also be compiled with "-soname" so that ld and ld_config are aware of what it should do with it-dlls need to be installed, as such The easiest way is to just put it in the appropriate lib/lib64, for that distro run ld_config. Then use a symlink to point to it and hope it works. LabVIEW sees through symlinks so as long as you name the symlink the same as the library, in the CLN path, it will work on all platforms - you can just have the DLL itself in the app directory on Windows so it's business as usual. It's then demonstrably the users distro/configuration that is the problem if things don't work. If it doesn't work then you have conflicts with other, already loaded version and since the LabVIEW CLN function cannot be set to " RTLD_DEEPBIND "; you are stuck This is what -soname is supposed to alleviate but I've had mixed success. If this is the case, you can point the symlink to the version already loaded (if you can figure it out) which will work as long as the binary interface (ABI) is the same - they don't think twice about breaking it between versions, though (yes I'm looking at you Python!).You will end up spending most of your time answering Linux support with a myriad of configurations as everyone has all sorts of favourite crud installed. My advice is to get it all production ready and installation proof on windows and think about Linux for version 2. Linux devs can still try the symlink method if they are aching to use it, but you can avoid all the Linux rabbit holes while you concentrate on the library itself.

I also prefer the statically linked dll because I can imagine that no one will remember to include the correct DLL or even know where to find the DLL when they build their exe. However, since this library is under development, I think that it is wise to stick with the in-lined mupLibPath vi for now. When we get closer to V1.0 perhaps it will be worth putting in the extra effort to setup a conditional disable structure around each CLN.

For the record I obstinately still tried this, following smithd. Because of "current VI's path" this cannot be inlined, at most given subroutine priority. The result with the previous benchmarks is ~600ns overhead (on ~12us, 5%) on 32bit and ~200ns (on 10.4us, 2%) on 64 bit. Results obviously degrade for less than subroutine priority. mupLibPath.vi