On the kerl page it mentions that HiPe is not used for Linux because of otp_build (but I am assuming by implication it is okay for Mac OS). Why is that?
(Note that kerl uses the otp_build script internally, and ./otp_build configure disables HiPE on linux)
Related
How to install the jenkins on a solaris server? i found articles that this cannot be done as jenkins has discontinued support for solaris.
Even though official IPS repositories for Solaris are discontinued, you can still run Jenkins in Solaris via the jenkins webapp (jenkins.war). To quote from Jenkins installation doc:
Solaris, OmniOS, SmartOS, and other siblings
Generally it should
suffice to install Java 8 and download the jenkins.war and run it as a
standalone process or under an application server such as Apache
Tomcat.
Some caveats apply:
Headless JVM and fonts: For OpenJDK builds on minimalized-footprint
systems, there may be issues running the headless JVM, because Jenkins
needs some fonts to render certain pages.
ZFS-related JVM crashes: When Jenkins runs on a system detected as a
SunOS, it tries to load integration for advanced ZFS features using
the bundled libzfs.jar which maps calls from Java to native libzfs.so
routines provided by the host OS. Unfortunately, that library was made
for binary utilities built and bundled by the OS along with it at the
same time, and was never intended as a stable interface exposed to
consumers. As the forks of Solaris legacy, including ZFS and later the
OpenZFS initiative evolved, many different binary function signatures
were provided by different host operating systems - and when Jenkins
libzfs.jar invoked the wrong signature, the whole JVM process crashed.
A solution was proposed and integrated in jenkins.war since weekly
release 2.55 (and not yet in any LTS to date) which enables the
administrator to configure which function signatures should be used
for each function known to have different variants, apply it to their
application server initialization options and then run and update the
generic jenkins.war without further workarounds. See the libzfs4j Git
repository for more details, including a script to try and "lock-pick"
the configuration needed for your particular distribution (in
particular if your kernel updates bring a new incompatible libzfs.so).
Also note that forks of the OpenZFS initiative may provide ZFS on
various BSD, Linux, and macOS distributions. Once Jenkins supports
detecting ZFS capabilities, rather than relying on the SunOS check,
the above caveats for ZFS integration with Jenkins should be
considered.
Some of modern infrastructure components such as Yaws and CouchDB can be installed on Ubuntu with
sudo apt-get install
and then they can be started with
{service_name} start or simply {service_name}
I wonder if there are any differences between this approach and the Erlang/OTP way, that is uploading an OTP release to the production server and then starting it with a rebar-generated script.
What is the industry standard? Install/start a repository-based binary or upload/start a rebar-generated release?
Also, do the repository-based binaries have all the OTP functionality in place, like OTP applications structure, supervision and the option to attach to the live application via console?
Every time, you are starting erlang, you are starting a release. Even, if you only type erl in terminal, it runs a release (you can find the .boot, .rel and .script files in erlang_rootdir/releases/name_of_release.
I think this answers your last question: packages installed from repository still have the OTP structure, supervision and all the goodies. There are just couple of bash scripts, that make starting and stopping them more friendly to someone used to service_name start. You should also be able to find a script similar to the one generated by rebar.
Check, where are those files and simply cat them. You should see, they simply start Erlang release.
The only thing, that you can't do with package managers, is hot code upgrade. Most package managers simply stop the running application, install new version and start it back. In Erlang, you can upgrade running release, but this is quite advanced stuff. Besides that - there are no disadvantages of using OS packages.
Is it possible to get Z3 running on a system providing posix API without having python installed?
I have seen the new version 4.3 uses python already in the build-process (scripts/mk_make.py).
Whats about older versions like 4.1? Is it imaginable to get it to run on posix without python?
Is Python not available in your system?
Python was always used to automatically generate some parts of the Z3 code base. In the first source code release, we have included the automatically generated code. Actually, at that time, we were using a combination of python + sed + awk + grep to generate these parts of the code. Another problem with the first release is that the build system for Windows (+ Visual Studio) was completely different from the build system for the other platforms. The Makefiles for Linux and OSX were derived from Visual Studio Project files. Some users also started to report problems with the build system for Linux and OSX. So, to reduce these problems and have a uniform build system, we decided to use python (and python only) to:
Automatically generate code (for bindings for different languages, API logging support, etc)
Check the system for requirements
Generate the Makefiles
And any other form of automation
Python is very attractive for us because it works in most systems (even non posix compliant ones). We can easily write portable scripts. Moreover, after we made the switch, we can compile Z3 in more platforms. We successfully compiled it on Windows, Linux (Mint, Ubuntu, Suse, etc), OSX, Cygwin, and FreeBSD.
In the "unstable" (aka working-in-progress) branch, we don't even require autoconf anymore, we use python to do all system specific configuration. To build Z3, we just need: python, C++ compiler (Visual Studio C++, g++ or clang++), ar (on non-windows platform), make (or nmake). This is very small set of requirements. Python is available in most platforms by default.
That being said, is it possible to remove the python requirement? Yes, it is, but it would have to replace python with something else. Something, that would allows us to perform all tasks described above. Take a look in the directory scripts at http://z3.codeplex.com/SourceControl/changeset/view/0c1f2a82818a,
we would have to port all these automation scripts to something that can be used on all platforms we support.
I have to configure my compilation depending on build hosts. Windows and Linux are easy and I have access to the build hosts to test it myself anyway.
What I have so far completely failed to find are the values of $(OS) and, just to check my expectations, $(OSPLAT). I assume OSPLAT to be X86 on x86 machines, similar to other QNX supported SDP packages
If anyone has access to a QNX/Neutrino system with installed QNX SDP, the Jam script below can produce the result:
Echo $(OS) $(OSPLAT) ;
I had a look at Jam source and it seems that depending on the platform version it is either QNX or QNXNTO. See jam.h for more details and OSPLAT values.
I'm trying to get Erlang working on my Fedora server, specifically to run rabbitmq, but when I yum install erlang yum complains that wxGTK requires a bunch of packages.
Wtf? Why is erlang trying to install a GUI? I intend to deploy this on a headless server.
Do I need to compile erlang from source? Is there no GUI-less version of erlang I can use?
I like to use the kurl script created by the folk at Basho to install Erlang. It works very well on ubuntu. I hope this will be ok on Fedora too.
This will actually automatically download the source code, and compile it. If you dont have Wx installed, it will not compile this library and will work perfectly without (as long as you dont use tools which need it, of course)
I guess by default your erlang installation has wxErlang enabled and so those packages are required for installation.
On https://github.com/erlang/otp/wiki/Installation you can find instructions on how to manually install Erlang/OTP.
In the configure part you can disable the wxErlang part. Usually no extra config is required since the wxErlang-support will be disabled by default when the required packages are not installed.