I would like to write a program using Scala Native but it has to run on a linux host (centos 6.5) with a very old glibc. So I would like to deploy that program as a statically linked executable, e.g. as golang does.
How do I build a statically linked executable with scala-native? Is it possible? If yes, how do I do it? If no, why not?
The sbt option nativeLinkingOptions takes a Seq[String] of extra arguments which are passed verbatim to clang during linking.
Adding the following to the project build settings works for me in a quick test:
nativeLinkingOptions += "-static"
I'm not an expert on this topic, but from what I understand that's not something that can be done for all kinds of applications, it might be even impossible to do based on what are your dependency libraries;
For example you cannot statically link against glibc (it's not designed to be statically linkable and has dynamic features like nss that prevents it from being linked statically).
You can try another libc implementation like musl which is statically linkable, however you need to compile a lot of things from scratch and in the end, your output binary might have some weird behaviors, for example name resolution might not work and you need to use direct IP addresses, unless you use a resolver library too.
That's a rabbit hole you probably don't want to go to!
But, if you are also an experienced C/C++ developer, you can tweak with linker parameters as mentioned in the other answer; however you might need to link manually, as currently available sbt options does not allow you to change order of existing linking parameters, which is unfortunately important when linking statically!
Related
I have a Perl application which is used in two contexts: It can be used as a diagnostic tool which displays information about a system, or as a testing tool which sends Modbus commands to that system. The problem I have is that allowing the user to send commands to the system in a diagnostic context is a potential safety risk, so I want to create two executables: A testing version that includes the Modbus module and a diagnostic one that does not.
My current solution is to include the Modbus module like this:
BEGIN { eval { require Modbus; }; Modbus->import; }
This only includes the Modbus module if I use the option -M Modbus while building the .exe with PAR Packager. The issue with this approach is that it fails unless this is the only place where Modbus is imported. So if another developer who isn't aware of this risk comes along, it only takes one require statement to bypass this fix.
Is there a way for me to prevent a specific module from being included in the executable unless I explicitly want it to be (either with the -M option or some other method)? I've been trying to figure something out with Devel::Hide, but haven't had much luck. All the solutions I've found so far fail the "other developer who doesn't know about this" test.
I'm using Strawberry Perl 5.20.3.3, but I can upgrade if necessary.
When I've done this sort of thing, I've created a small module that is included if it is present and not included if it is not:
eval { require MaybeItsThere }
In my Makefile (or whatever build system you want), I have targets for development and production builds. One of the subtasks for the dev build creates that MaybeItsThere file. It can also set whatever it needs for PERL5LIB and so on such that only the dev build can load it.
However, as you say, the enterprising developer can quickly find out what they need to do to get the features they want.
Having read through your comments, it seems that you're not going to be able to enforce correct usage. (You gave examples how the module has already been misused by people sidestepping your build process.) I would suggest an alternative approach.
Document the problem at that place where someone would find a workaround.
In other words, if some other developers is going to look at the code or at the build to see the name of the missing module, let them see a warning about the dangers right there. Put a comment block explaining why the Modbus module should only be used when diagnostics are disabled or filtered. Make the build's failure put a warning right there at the same place as the name of the missing module; use a die "Modbus should not be used when user interaction is enabled."; or something similar to convey the message in the same place where the other developer would be looking for the solution.
Ultimately, you can't force someone to use your build tools, but you can try to educate them while they're trying to work around you, instead of documenting the problem somewhere else that they might not see.
Considering that I am developing an end-user software program (as an uberjar) I am wondering what my options are to make it possible for the user to download a plugin and load that during runtime.
The plugin(s) should come compiled and without source code, so sth. like load is not an option.
What existing libraries (or ways of Java...?) exist to build this on?
EDIT: If you are not sure I would also be satisfied with a way that costs a reboot/-start of the main-program. However, what is important is that the source-code won't be included in any JAR file (neither main application nor plugin-jars, see :omit-source of Leiningen documentation).
To add a jar during runtime, use pomegranate which lets you add a .jar file to the classpath. Plugins of your software should be regular Clojure libs that follow certain conventions that you need to establish:
Make them provide (e. g. in an edn) a symbol to an object implementing a constructor/destructor mechanism such as the Lifecycle protocol in Stuart Sierras component library. In runtime, require and resolve that symbol, start the resulting object and hand it over to rest your programs plugin coordination facilities.
Provide a public API in your program that allows the plugins to interact with it in ways that you coordinate asynchronously e. g. with clojure.core.async (don't let one plugin block the entire program).
Make sure that the plugins have a coordinated way to expose their functionality to each other only if they desire so to enable a high degree of modularity among your plugins. Make sure that your plugin loader is capable of detecting dependencies among plugins and is capable of loading and unloading them in the right order.
I've not tried it myself, but you should in theory be able to get OSGi to work with Clojure.
There's a Clojure / OSGi integration library here:
https://github.com/aav/clojure.osgi
If I were to attempt to role my own solution, I would try using tools.namespace to load and unload plugins. I'm not entirely sure it will work, but it's certainly in the right direction. I think one key piece is that the plugin jars will have to be "installed" in a location that's already on the classpath.
Again, this is only the start of one possible solution. I haven't tried doing this.
There is a relatively-new lightweight JVM called Avian that can produce executables for iOS targets.
There isn't too much documentation on the website (and not much can be found searching with Google). I was wondering if anybody was aware of a step-by-step tutorial on how to get a basic Scala program running on iOS, using Avian.
Another alternative JVM to iOS compiler is RoboVM. Although it is at an early stage, it looks quite promising, with examples on how to compile Scala for iOS.
EDIT This was an old answer, valid at that time, but, as #JamesMoore points out, RoboVM is no more. What looks very promising now, and may well be the way to run Scala code in iOS in the near future is Scala Native
Compiled Scala sources are completely standard class files. You should be able to follow the instructions (look for “Embedding”) on the website without large changes, just treat scala-library.jar as a dependency of your code.
I managed to bootstrap the complete compiler and the standard library running on Avian a few days ago.
Some parts might still be a bit rough around the edges, e. g. there is one mandatory fix which will be part of the next release of Scala (2.10.1) but is not in 2.10.0. If you want to play with it right now, you need to use a nightly build until 2.10.1 is released.
If you encounter any additional issues, please report them!
I may not need it anymore, now that Oracle is making JavaFX open-source on iOS and Android!
EDIT: Oracle updated the article to announce that they will not release a JVM, so it looks like JavaFX+Avian may be the way to go.
Running Java byte code on iOS (not-rooted) is not only running that or those JVM. As far as I understand iOS memory management doesn't allow executable memory pages to be writable in user mode. That basically prohibits any JIT compilation.
So even if it's possible to run some compiled (either from Java or Scala) classes on specific Java VM I would carefully check how this VM supports Ahead-Of-Time compilation in order to be runnable on iOS.
As I have seen Avian AOT works well on a desktop. For iOS you will have to check it yourself, although the project looks promising in AOT area.
Can go run dynamically in order to be used for a plugin based application ?
In eclipse, we can create some plugins that Eclipse can run dynamically.
Would the same thing be possible in Go ?
I'll argue that those are two separate problems :
having dynamic load
having plugins
The first one is simply no : A Go program is statically linked, which means you can't add code to a running program. And which also means you must compile the program to let it integrate plugins.
Fortunately, you can define a program accepting plugins in Go as in most languages, and Go, with interfaces and fast compilation doesn't make that task hard.
Here are two possible approaches :
Solution 1 : Plugin integrated in the main program
Similarly to Eclipse plugins, we can integrate the "plugins" in the main program memory, by simply recompiling the program. In this sense we can for example say that database drivers are plugins.
This may not feel as simple as in Java, as you must have a recompilation and you must in some point of your code import the "plugin" (see how it's done for database drivers) but, given the standardization of Go regarding directories and imports, it seems easy to handle that with a simple makefile importing the plugin and recompiling the application.
Given the ease and speed of compilation in Go, and the standardization of package structure, this seems to me to be a very viable solution.
Solution 2 : Separate process
It's especially easy in Go to communicate and to handle asynchronous calls. Which means you could define a solution based on many process communicating by named pipes (or any networking solution). Note that there is a rpc package in Go. This would probably be efficient enough for most programs and the main program would be able to start and stop the plugin processes. This could very well feel similar to what you have in Eclipse with the added benefits of memory space protection.
A last note from somebody who wrote several Eclipse plugins : you don't want that mess; keep it simple.
Go 1.8 supports plugins (to be released soon Feb 2017.)
https://tip.golang.org/pkg/plugin/
As dystroy already said, it's not possible to load packages at runtime.
In the future (or today with limitations) it may be possible to have this feature with projects like go-eval, which is "the beginning of an interpreter for Go".
A few packages I found to do this:
https://golang.org/pkg/net/rpc/
https://github.com/hashicorp/go-plugin
https://github.com/natefinch/pie
I have a library compiled into a .a file, linked against my application. (iphone, developing with Xcode)
Everything seems to be fine, linking seems to succeed, but when I run the program it crashes. The point of crash is at a memcmp() call in the statically linked library. The debugger shows all kind of stuff called with "dyld" in their names, so it seems that for whatever reason it can not resolve memcmp, starts looking for dynamic libraries, then fails.
AFAIK memcmp is in libc, so should not be a problem. (tried also passing -lc to the linker, and it did not help, just as I expected)
So how it is supposed to work? Why can't a statically linked library use anything from libc? How should I compile it?
Thank you
libc is apparently dynamically linked on your platform. A matching version cannot be found at runtime to satisfy the dependency generated at link time.
I can't explain how this would happen other than filesystem corruption or calling chroot before the dynamic linking happens (which would seem unlikely).
Perhaps someone will find it useful if I share what the problem was:
The library was not compiled for the same OS version as the main program, so it was expecting a different libc than what it found when running.