My question is: If I have an executable that requires some libs, then do I have to install these libs to all the nodes of the grid, or is there a way to install the libs on one node and then share to all the others?
Thank you in advance.
If all your nodes run the same system (same architecture, version etc.), you should be able to store the libs on a shared drive. Note that reading the libs frequently from a shared location might impact speed of the executables.
Related
I have a vendor who supplies the SoC, associated BSP and some key middle-ware to us. Vendor uses gcc-4.9 to build all the delivered software.
The software delivered has two categories
Source packages: we get all sources and build ourselves.
Libraries and Binaries: we reuse what vendor delivers pre-built.
We plan to move to gcc-6.2, but vendor has no plans to move anytime soon.
So the questions arise:
For the pre-built binaries/libraries will there be ABI compatibility issues if we use gcc-6.2 and vendor delivers pre-builts with gcc-4.9. All the pre-built libs are shared objects.
Shall we expect compile time issues for the vendor's source packages (some packages have c as well as assembly), when we rebuild using gcc-6.2?
Target architecture is ARM.
We are putting together a Linux distribution.
I read about abicheck, I am considering to run abicheck for all the vendor delivered pre-builts (built with 4.9) and objects I build with 6.2.
Any pointers if this is the correct approach?
Other suggestions are equally welcome.
Does anyone know if at least D runtime and Phobos for D 2 will be pre-built as DLLs or at least ready to be compiled in such a way?
Currently, as I understand, it will require to mark all relevant functions and/or classes as export. Couldn't find anything similar in current sources of DMD.
Thanks.
Currently, Phobos is available as pre-built LIB file, which is statically linked to your executable during compilation.
This has some advantages to DLL:
Deployment - you can be always sure that your executable have appropriate runtime/gc/phobos available - the one which is tested with your application. There is new version of Phobos and D runtime every month, using DLLs in this case could cause versioning problems.
Disadvantages
Executable size is slightly larger (100s of kb)
Every "unit" exe / dll has its own garbage collector.
Why are you researching options of using DLL for Phobos? What insufficiencies do you seen in using LIB ?
I have installed GCC and GTK+. Its working fine, but i need to statically link GTK+ libraries with my application (it's a small application) so that there exist only one '.exe'.
mingw-cross-env has fixes to build gtk and all related libs statically
It is supported with a few minor issues (like having trouble finding configuration files), but you will have to compile GTK+ yourself! (the default binaries do not include static libraries)
See this mailing-list thread for more information on this issue.
The correct answer would be two words: not supported. Really, if you want to distribute your application, being it 2 or 100000 lines, just bind a copy of GTK+ with it.
I have a program (specifically my entry for the SO DevDays Countdown app challenge) which relies on several dynamic libraries, namely libSDL, libSDL_ttf, and others. I have these libraries installed under /opt/local/lib via MacPorts, and many people won't have these installed (and some might have them installed, but not at that location).
How do I distribute my program so that people without these libraries installed can run it out-of-the-box? Obviously I'll have to distribute the various .dylib files, but doing this is insufficient. The dynamic loader still looks for the libraries installed at the locations I have them installed at. Is there a way to tell the dynamic loader to look in the current directory of the executable, like what Windows does with DLLs? People shouldn't have to modify any environment variables (e.g. DYLD_LIBRARY_PATH), since again I want this to work out-of-the-box.
The basic approach to this is to ship them in the .app bundle. You'll then modify the location the linker looks for shared libraries to include this.
The steps are:
Create a new copy files build phase to your target that copies those files into the Frameworks directory of the .app bundle.
Edit the build configuration setting "Runpath Search Paths" to include #executable_path/../Frameworks
If you build your executable with these changes and then look, you should find that the dylibs exist in the Foo.app/Contents/Framework directory and running otool -L Foo.app/Contents/MacOS/Foo should yield and entry prefixed by #rpath for those dylibs.
From this Cocoabuilder post:
In general, #loader_path is preferred over #executable_path, as it
allows embedded frameworks to work in both an executable and a bundle,
plugin, or sub-framework. The only downside is that #loader_path
requires 10.4 or newer. If you're on 10.5 or newer, #rpath is even
better than #loader_path.
As you mentioned you're not using Xcode, so it's a bit difficult. Here are options in my order of preference:
Switch to Xcode. Use frameworks. The SDL libraries are available as frameworks already, and I've seen more than a couple commercial games with a libsdl.framework inside the app bundle.
Use frameworks, but keep your Makefiles. Download the framework versions of your SDL libraries (or build them yourself), and link with them with the -framework linker flag. Distribute the frameworks with your app or don't, and tell your users to put them in either ~/Library/Frameworks or in /Library/Frameworks. I wouldn't bother with an installer for this.
Statically link against SDL. In the Makefile, you'll have to list the path of the static libraries rather than use the -l flag, e.g., you run "ld blah blah /opt/local/lib/libsdl.a". There is no way that I know to tell -l to prefer static over shared libraries, and believe me, I've looked.
Statically link the libraries.
I am working on a project which is built using autoconf, automake and libtool. The project is distributed in both binary and source form.
On Linux, by default the build script links to all libraries dynamically. This makes sense since Linux users can rely on their distribution’s package manager to handle dependencies.
On Windows, by default the build script links to all libraries statically using libtool’s -all-static option. This makes sense since none of the dependencies are provided with Windows, and it’s helpful to be able to distribute a single binary containing all dependencies rather than mucking about distributing tons of DLLs.
On OSX, some of the dependencies are provided by the OS, and some are not. Therefore it would be helpful to link to the OS-provided libraries dynamically and to the other libraries statically. Unfortunately libtool’s all-or-nothing -all-static option is not helpful here.
Is there a good way to get libtool to link to some libraries statically, but not all?
Note: I realise I could carefully compile the dependencies so that only static builds are available. However, I’d rather the build system for my project were robust in the common case of static and dynamic builds of dependencies being available.
Note: Of course, I am not concerned with really low level dependencies like the C/C++ runtime libraries, which are always linked dynamically on all three of the above platforms.
After some research I have answered my own question.
If you have static and dynamic builds of a library installed, and you link to that library using the -l parameter, libtool links by preference to the dynamic build. It links to a static build if there is no dynamic build available, or if you pass the -static or -all-static options.
libtool can be forced to link to the static library by giving the full path to that library in place of the -l option.