At How to install iZ3? there was a link provided to Z3 4.1 for Linux. In this archive, Z3 itself is 64-bit, but iZ3 unfortunately not.
I can not run the 32-bit iZ3 executable on my machine, because it is missing 32-bit shared libraries, which i can not install (they would replace my regular 64-bit libraries).
So, is there a 64-bit version of iZ3 for Linux?
Currently, the interpolating version of Z3 can only be built from source. Get the branch "interp" source from z3.codeplex.com. The file README contains build instructions, including how to get the external library that is required.
Related
I got a C++ project for Bazel, which by default builds for 64-bit Windows on my machine. However, I want to create a 32-bit executable, which, according to the documentation, is supported.
I have tried these commands:
bazel build :knusperli --platforms #bazel_tools//platforms:x86_32
Target #bazel_tools//platforms:x86_32 was referenced as a platform, but does not provide PlatformInfo
bazel build :knusperli --cpu i386_windows
ERROR: No toolchain found for cpu 'i386_windows'.
I thought, since Visual Studio can build 32-bit executables, it would be easy in Bazel as well, but I can't find any information on how to actually do this.
Bazel does not support building 32-bit binaries out-of-the-box. It's possible to add support via a custom CROSSTOOL file.
See:
https://github.com/bazelbuild/bazel/wiki/About-the-CROSSTOOL
https://github.com/bazelbuild/bazel/wiki/Building-with-a-custom-toolchain
https://github.com/bazelbuild/bazel/wiki/Yet-Another-CROSSTOOL-Writing-Tutorial
Is the Vala/Genie compiler available on the Windows and Mac OS X platforms? I know that it is possible to use GLib and GTK on Windows and Mac OS X, but there are no official downloads of Vala for either platform.
Vala 0.28 is currently available on Mac OS X in just the same way as the rest of the GLib/GTK platform is. Here are the official instructions for setting up a GLib/GTK development environment on Mac OS X. To build the Vala/Genie compiler, run jhbuild build vala after completing those instructions.
I don't know the answer for Windows.
There are no "official" builds of Vala as such. Vala is officially released as source code only. The source is then built by various distributors who package and distribute the builds.
On Linux this is done by distributions like Fedora and Ubuntu. On Mac OS X probably the most relevant is Brew and on Windows MSYS2. For more details on all of these ways see the Installing Vala section of the Vala wiki.
There are several ways of getting Vala compiler to work on Windows. The easiest solution would be installing MSYS2 which always provides fresh version of vala as one of it's packages.
Suppose I have a C++ project, and I compile it with gcc and with clang. You can assume that the gcc compiled version runs in another linux machine. Will this imply (in normal circumstances) that the clang version will also run on the other linux machine?
Clang binraries are as portable as gcc binaries are, as long as you are linking to the same libraries and you aren't passing flags like -march=native to the compiler.
Clang has one huge advantage over gcc, it can deal with alsmost all libstdc++ versions,
while gcc is bound to its bundled version and often can't parse any older versions.
So the following often happens in production environments:
Install an LTS distro (Ubuntu 12.04 for example)
Keep gcc, glibc and libstdc++ untouched
Install a recent clang version for C++11, etc
Build the release binaries with clang
So (in my specific example) those binaries will work on all
distros with libstdc++ >= 4.6 and glibc >= 2.15.
This may be an interesting read for you.
If the program is a simple Hello world, it should work on the other machine when compiled through Clang.
But when the program is a real program with a lot a lines and compilation units, and calls to many external libs everything is possible depending on the program itself and the compilation options :
hardware requirements (memory) being different (mainly depends on compilation options)
use of different (versions of) libraries between gcc and clang
UB giving expected results in one and not in the other
different usages for implementation defined rules
use of gcc extensions not accepted by clang
For all of the above except 2 first, it should run on other machines it it runs on one
linux programs depend on their build environment. If your glibc version or kernel is different there will be lots of possibilities that the executable will not be able to run. You could use the interpreter language of llvm though, it compiles into bytecode which can be interpreted on various operating systems.
The answer is, well, depends.
The first hard requirement is the same CPU architecture. 64 Bit is not enough of a qualifier. If you compile of x64 you won't have much success running it on 64-Bit ARM.
The next big one is libraries. If you use any libraries in the program, the target system needs to have those libraries. This includes the kernel headers. So if you compile for e.g. a current kernel version, using the most cutting-edge features, then you will have no joy running that program on a very old version of Linux.
The last one is hardware dependencies. If you create a program that e.g. requires 4 GB of RAM and then try to run it on a small embedded device with 256 MB RAM, that won't work either.
To fit better to your changed question: From my experience there shouldn't be much of a difference in portability between Clang and gcc. Also googling didn't turn up anything, so it should basically work. But better always test stuff like that before you publish some binary in production.
I need to run an F# program from another 32-bit executable. I don't have any access to source code of this one. How do I build 32-bit F# executable file under 64-bit OS from command line?
So, I've finally found an answer just after I asked the question on SO. (This somehow helps, you know). The answer is here:
Running a 32-bit C# application on a 64-bit machine
You need to run corflags /32BIT+ situated at \Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\corflags.exe, so that the executable runs with 32bit on 64bit OS.
Z3's dependency on libgmp.so.3 is unresolved in the linux package, leaving the user to provide this library. However, this library is very old and is not readily available.
Does anyone know a method for getting around this issue? I am currently running x86_64 and cannot get around this missing dependency without a great deal of hassle.
Is it possible the linux packages could be fixed such they include the expected library in the distribution?
You can get GMP3 by executing sudo apt install libgmp3-dev.
I'm not a Linux expert, but this is the command I used to install GMP before I compiled Z3.
When I installed the virtual machine for running Linux 64, I think I didn't find a package for the more recent versions of GMP.
I will try again. If it doesn't work, I will download the most recent GMP tar ball and build it from scratch.
BTW, the Z3 for Linux 32 comes with two .so files. One of them has GMP statically linked.
The trick I used for building this .so file didn't work for the 64 bit version.
As I said, I'm not a Linux expert, any suggestions on how to build a better Z3 library for Linux x86_64 users are welcome.