Compiling 32-bit python on a 64 bit machine - python-2.7

While I know this has been asked here before, it has been several years since the last time I can find, and there was no successful solution to this question, so here we go.
I have a copy of x64-bit SPSS for *nix that requires on a 32-bit python2.7.3 installation for extended functionality. Unfortunately for me, I run an ubuntu x64 machine, and I've been unable to compile 32bit python on it. I've been able follow both sets of instructions also tested at this link https://askubuntu.com/questions/29253/how-can-i-install-a-32bit-python-on-64-bit-ubuntu but have not had any success with it following the flags. Both resulted in the correct location/unicode settings, but compiled x64 versions. I've checked for missing packages, but none of the recommended packages seem to be missing.
Any help with compiling python (or even an alternative method) would be greatly appreciated. As it is, the only solution I can think of is to create a chroot jail.

Have you considered running 64-bit SPSS and using 64-bit Python?

Related

Using OpenAeroStruct with Fortran on Windows

I need to run several analyses with OpenAeroStruct on Python 2.7.15 on a Windows 8.1 platform. These are quite computationally expensive so I'm aware that using Fortran could improve performances but on OpenAeroStruct main github page (https://github.com/mdolab/OpenAeroStruct) it is stated that "there is no documented Windows support for the Fortran code". However, I found this question here: Failure to import pyOptSparseDriver that seems to be similar to my issue. If so, how do I install the pyoptsparse library ? I tried to copy the github in my python folder but still the driver seems not to be working.
The usage of pyOptSparse and the usage of Fortran for OpenAeroStruct are independent of each other. Compiling and using the Fortran version of the code will give you the biggest performance gain.
However, as you've found, successfully compiling this Fortran code on Windows is not straightforward. I'd suggest one of three options:
Obtain a system with Ubuntu Linux or Mac OS to use the Fortran version of the code.
Attempt to use Cygwin and a Fortran compiler to set up an environment within Windows where you could successfully install and run OpenAeroStruct's Fortran code.
You could set up an Ubuntu virtual environment within your Windows system, though this would take time and effort to set up and would be less computationally efficient than running it natively.

Cannot run HElib well, but it builds on Windows 10 x64

I'd really appreciate some help getting HElib to work on Windows 10 x64 using the MSVC 2017 compiler. I successfully managed to compile its dependency, NTL, using the same compiler by following this tutorial and also ran its tests, so it seems to work well.
However, in the case of HElib I tried generating Visual Studio projects using cmake and then compiled it successfully (see NOTE below), but running it fails. For example, I ran the Test_binaryCompare.cpp_exe test (has its own vcproj generated by cmake), but it fails because it reaches a part of code I doubt it's supposed to (it attempts to do an operation called bootstrapping and it is disabled for that test). However, on Linux it works.
LINUX: The reason I'd really like to run this on Windows is because I find it a lot easier to debug using Visual Studio. I'm also more used to Windows overall..
NOTE: Compiling HElib successfully required some modifications like fixing broken tr1 includes (e.g it was trying to include <tr1/memory> instead of just memory although the latter was actually available), suppressing the 4146 error (I also had to do this for NTL) and fixing two instances of variable-length arrays which Microsoft's compiler sadly does not support.
Without any error messages I can't really help you figure out your exact issues but I ported HElib to Windows some time ago: https://github.com/AlexanderViand/HElib/tree/Windows
It's a bit out of date but if the tests works in that version you can check the changes I made against your changes.
There's also the option that you're simply running into this issue: https://github.com/shaih/HElib/issues/228
If your linux version of NTL is slightly older, it might just be that your windows version of NTL is the buggy one.
Finally, I'd very much recommend against running HElib on Windows because without GMP it seems painfully slow.
Instead I ended up setting up a docker virtual machine and SSH'd into that from visual studio: https://hub.docker.com/r/alexanderviand/visual-studio-linux-build-box-with-helib/
Currently I'm using WSL and CLion (which supports WSL quite well) when I'm working with HElib on Windows.

Compiling and running c++ apps in different Ubuntu version

I've been trying to find a way to make my applications compatible between different Ubuntu LTS versions.
However, most of the time it ends up with the "symbol lookup error:" or "cannot find libxxxx.so.xx".
The requirement is very clear, developer should be able to compile the code on one of last 3 Ubuntu LTS (currently 12,14,16-04) versions and the output should be able to run on all 3 last versions. But the problem is getting complex.
Is there any way to do this?
Thanks in advance.
Linux binaries compiled on older distributions are generally compatible with newer ones. The kernel invests a lot of effort in being backwards compatible - as does glibc. This may not be true for all libraries, but in my experience; most try.
So, what you probably want to do is, compile your app on the oldest supported distro and it will most likely work on the newer one(s).
A really simple trick is to ... compile from source on the appropriate distro.
You can even almost automate this as Ubuntu / Canonical give you free accounts on Launchpad. For example, I use my PPA for either backports or unpackaged sources I want at either work, or home, or on Travis CI, ... in a particular release flavour.
Otherwise, the very obvious alternative is of course to create a static build which is independent of the runtimes of the particular release. That will work 'forever' or until the kernel changes. In the 20+ years I have used Linux, such a change occurred once (with the introduction of the Elf format).

FMIlibrary for PyFMI package(64 bit)

Anyone have idea to develop FMILibrary(64 bit) for PyFMI package.
FMILibrary(32 bit) compiled successfully with PyFMI package.
thanks for your useful ideas in advance
There is nothing that needs to be done on the FMI library side to be able to compile it as 64bit. You need to grab the source from http://www.jmodelica.org/FMILibrary and use a C-compiler that supports 64bit then you are good to go.
A similar problem was encountered also here.
As for the FMILibrary, as far as I understand, it is nothing you have to compile with PyFMI. It is a prerequisite for the operation of PyFMI. What you need to do is compiling FMILibrary(check the required version for PyFMI from here) using a compiler. And do not forget to show the path of FMILibrary to PyFMI.
What I would suggest, as in the first link stated, is installing Anaconda and working in a created environment.

Will a C++ Linux app built on version X.XX of the kernel run on an earlier version?

This question may seem blindingly obvious and I realise I am putting myself up for a large number of downvotes but I am very new to Linux dev and have only been working on it for a while.
I have been writing an application on ubuntu 12.04 (kernel 3.2.0) in C++ then copying this via scp to an ubuntu 8.04 (kernel 2.6.30) installation on another device. I have been noticing some very strange behaviour that I simply cannot explain. I have naively assumed that I can run this executable on a previous version, but it is beginning to dawn on me that this in fact may not be the case. In future must I ensure that the Linux version I build my application on is identical to that which it will be running on in the field?? Or must I actually build the application from source code directly on the device it will be running on??? I am very new to Linux dev but not new to C++ so I realise that this question may seem facile, but this is the kind of issue that I have simply not seen in books/tutorials etc.
Most of the time, it's not the kernel that stops you, it's glibc.
glibc is backwards compatible, meaning programs compiled and linked to an older version will work exactly the same with a newer version at runtime. The other way around is not that compatible.
Best is of course to build on the distro you want to run it. If you can't do that, build on the one with the oldest glibc install.
It's also very hard to build and link to an older glibc than the system glibc, installing/building glibc tends to mess up your system more than it's worth. Set up a VM with an old Linux, and use that instead.