I want to use any of the FLOSS implementations of MPI (i.e., OpenMPI or MPICH2) with my MSYS-MinGW environment and compilers. Please consider that I'm aware of the Microsoft MPI SDK mingw64/mingw-w64-x86_64-msmpi which you may find with
pacman -Ss msmpi
and install with
pacman -S msmpi
but I want to know if I can install any of the open-source implementations. I tried searching
pacman -Ss mpi
but there are too many results to check manually, and openmpi or mpich2 search queries do not return any results. So my questions are:
are any of the FLOSS implementations of MPI shipped with MinGW or MSYS2
if not how one can install them?
P.S.1. Cygwin does have some openmpi related packages, so it is a wonder why MSYS2, AFIK being a Cygwin fork, doesn't!
P.S.2. MPICH2 binaries are available here but they are way way behind the latest builds for other platforms. That's just sad!
P.S.3. Surprise that Microsoft's MPI implementation is actually open-source! It seems to be a fork of MPICH or at least compatible with it.
MSYS2's main objective is to provide you with an environment to build native Windows applications.
As such, it's natural that it will export bindings to the native Microsoft MPI implementation, while not providing ports of other MPI implementations such as OpenMPI or MPICH which have dependencies on a full POSIX layer.
From How does MSYS2 differ from Cygwin:
MSYS2 tries to provide an environment for building native Windows software. MSYS2 provides a large collection of packages containing such software, and libraries for their development. As a large portion of the software uses GNU build tools which are tightly coupled to the unix world, this environment is also POSIX-compatible, and is in fact based on Cygwin.
Cygwin tries to bring a POSIX-compatible environment to Windows so that most software that runs on unices will build and run on Cygwin without any significant modifications. Cygwin provides a large collection of packages containing such software, and libraries for their development.
There are more details on that page on how MSYS2 leverages Cygwin and a POSIX-compatible layer mainly to offer ports of tools needed in a build environment, mainly to support POSIX-like build systems (such as autoconf, make, meson, etc.), while mainly aiming at exposing these tools to support building Windows native binaries and porting applications to run natively on Windows.
Related
I'm a newbie in OpenCL.
Now I'm trying to compile one of the NVIDIA OPENCL SDK CODE SAMPLES named "OpenCL Bandwidth Test" linked here (https://developer.nvidia.com/opencl).
In this sample, a file named "oclBandwidthTest.cpp" is included.
And this file consults "oclUtils.h" and "shrQATest.h", so I added these two files path in makefile.
But when I try to compile it it still says "undefined reference to 'shrLog' 'shrLogEx' 'oclErrorString'" ... (too many).
I must do it until tomorrow but from last friday I'm still bound it.
I'm working on Ubuntu 12.04, I already installed SDK 4.2 and device driver.
Let me know what I must include (header file or library) in makefile.
II.B. Linux Installation Instructions
The OpenCL SDK samples in the NVIDIA GPU Computing SDK require a GPU with CUDA Compute
Architecture to run properly. For a complete list of CUDA-Architecture compute-enabled GPUs,
see the list online at: http://www.nvidia.com/object/cuda_learn_products.html
The OpenCL applications in the NVIDIA GPU Computing SDK require version 258.19 of the NVIDIA
Display Driver or later to run on 32 bit or 64 bit Linux. This required driver is made available to
registered developers at: https://nvdeveloper.nvidia.com/login.asp?action=login
Please make sure to read the Driver Installation Hints Document before you
install the driver: http://www.nvidia.com/object/driver_installation_hints.html
Uninstall any previous versions of the NVIDIA GPU Computing SDK
Install the NVIDIA GPU Computing SDK by running the installer provided for your OS.
The default installation folder for the OpenCL SDK is:
Linux
$(HOME)/NVIDIA_GPU_Computing_SDK/
In the following we will refer to the path that the SDK is installed into as .
Build the 32-bit or 64-bit (match the installation OS), release and debug
configurations, of the entire set of SDK projects and utility dependencies.
a. Go to /OpenCL
b. Build:
release configuration by typing "make".
debug configuration by typing "make dbg=1".
Running make at the top level first builds the shared and common utility libraries used by
the SDK samples (these libraries are simply for convenience and are not part of the OpenCL
distribution and are not required for your own OpenCL programs). Make then builds each
of the projects in the SDK.
Run the examples from the release or debug directory located in
/OpenCL/bin/linux/[release|debug].
Most of the SDK applications output messages to a console window that are of interest from the
standpoint of understanding basic OpenCL program flow, and several of the applications generate
graphics output in a separate OpenGL window.
Many of the SDK applications present some timing information useful for obtaining an
overall perspective of program structure and flow and the time required for setup and execution of
significant functions. The SDK example code, however, has generally been simplified for instructional
purposes and is not optimized. Advanced optimization techniques are beyond the scope of this SDK, and
any timing information presented by the samples is not intended for such usage as benchmarking.
All of the applications additionally log all the console information to a session log file in the
same directory as the executables. Those files are named clearly after the name of the sample app,
but with a .txt extension.
For convenience, the Makefile in /OpenCL can be used to execute all
SDK samples sequentially by typing "make runall" or "make dbg=1 runall".
I currently have a Java application packaged in an RPM that gets built for 32-bit RedHat platforms, and I want to create a 64-bit RPM, which is largely just the same as the 32-bit one, but with a couple different .so files included. All the Java stuff is the same on both platforms, so it's just JNI .so's.
My question is: Is it possible to have rpmbuild on a 32-bit system generate both the 32-bit and 64-bit RPMs (from different .spec files) since it's just repackaging already-built components, or do I need to build the 64-bit RPM on a 64-bit system?
N.B. I'm not actually building anything native on the system. I'm just repackaging stuff that's already built.
... or vice versa, can I build a 32-bit one on a 64-bit system? I really would prefer just to build and package this on one system than have two separate builds run for the separate RPMs.
As Aaron stated you can build an RPM for multiple distros on the same machine (64-bit), but you have to be very careful or you can run into issues. The biggest problem I've run into is you build on RHEL 5, then you try to deploy to RHEL 6, since RHEL 6 has a different version of RPM installed, it can cause conflicts and fail to install. So in this scenario you have a few options:
Build the RPM on two machines, you've stated you don't really want to do this.
If you have the disk space, configure Mock, I've used it a ton before and it's really easy to get going as long as you have the disk space and the package spec was designed to pull in requires properly.
Personally I'd give Mock a shot, it's quite simple to set up, and will allow you to do what you want with minimal effort as long as the proper repos are available. In the event the build fails the log is pretty comprehensive regarding what the RPM build error was.
Is there something similar to the Python utility virtualenv or Ruby utility rvm?
I want to switch SBCL to Clozure CL, for example.
Management of software systems would be done by something like ASDF (define software systems and actions for them) and Quicklisp (downloading of software systems via central registration). AFAIK it does not deal with multiple versions of a software systems, such that you can say which version to load. Using different Lisps with the same library should work, since each Lisp usually has a different file type for compiled code (and/or uses a different directory for the compiled code).
It's not "fully" in the sense of rvm. But the slime software has support for nearly any Common Lisp. You start in emacs with M-x lisp-you-want.
I'm not fully sure if Clozure CL is supported. Anyway the homepage of SLIME is at:
http://common-lisp.net/project/slime/
What it does not support is the installation of diverse Common Lisps. You either install them manualla or via your package management software (e.g apt in Debian)
I've been coding with Python and C++ and now need to work on building a gui for data visualization purposes. I work on Mac Snow Leopard (intel), python 3.1 using gcc 4.2.1 (from Xcode 3.1)
I wanted to first install Qt and then PyQt. And my goals are to be able to:
- quickly prototype GUI and the accompanied logic that drives the GUI using PyQt and python
- if I decided I need the speed, or if it's fairly easy to translate my GUI into C++ using the Qt tools, I have the options to translate my app into C++
- Be able to deploy my application onto Windows (both the python and c++ version of my app)
Give the goals above, what are the correct steps I should take and what issues i should be aware of when setting up Qt and PyQt. Which other deployment tools do I need?
From my readings so far, here's what I have:
download the Qt source for mac and configure it with
-platform macx-g++42 -arch x86_64 -no-framework
(i've read somewhere that
building as framework causes some
trouble in deployment and/or
debugging, can't find the article
anymore)
download latest SIP source and build
download latest PyQt and build from source (any special options I should pay attention to?)
For deployment, I've read that I would need to use py2exe/cx_freeze for windows, p2app for mac:
http://arstechnica.com/open-source/guides/2009/03/how-to-deploying-pyqt-applications-on-windows-and-mac-os-x.ars
but seems like what the article describe is deploying an app you build on windows on the windows platform and vice versa. How do you deploy to windows (is it even possible?) if you are writing your Qt app on a mac ?
Really appreciate the help
I'm guessing by deploying, you mean a compiled version to users that have no Python or Qt or anything.
I'm been trying py2app for a while now and never really worked out for me. You can try PyInstaller. It worked out pretty well for me since it's made to work with plugins like PyQt and PIL etc. I put up some instructions here
http://tech.xster.net/tips/deploy-pyqt-applications-on-mac-os-x-with-pyinstaller/
They don't really support cross-compilation though. Just recently, they made cross-compilation for windows binaries on linux possible. If you want to spend some time hacking it, it's probably possible. But probably easier just to get a windows machine and building a binary with it.
On windows applications are typically packaged as MSI, on Redhat Linux as RPM, what would be a best open source packaging method that could be used to deploy applications to all platforms including different flavors of unix and windows?
Contents would include exes, unix binaries, java jar files, user data, even database scripts to be run.
(I recognize contents would vary per destination OS, ie. binaries would be different, win exe vs unix binary etc, but for example config files may be the same or in the case of java even the bytecode jars)
Key feature I'd like the packaging to support is different users and permissions for different directories, however I recognize supporting this feature multiplatform may be very difficult.
Rather than build a package that is supposed to work across all of your platforms, which is likely impossible, you should have your build system build different packages for each target platform.
With CPack (It come with CMake) you can create packages for Windows (with NSIS), Linux (rpm and deb), and OS X with "make package". CMake also simplify cross-platform building.
For a sample you can look at avogadro's CMakeLists.txt and AvoCPack.cmake
I have a client that uses IzPack to create a single installer (it's Java-based) that installs their app on Windows, OS X and Linux.
http://izpack.org/
NSIS is an open-source solution which, as far as I know is able to build installers that run on Windows and UNIX-likes alike. However, for software deployment on Windows (especially in corporate environments) MSI is the way to go and NSIS is more of a headache.
So I wouldn't advise that you try to build a single package/installer for different platforms. But rather, as RibaldEddie indicated, multiple packages: one for each platform. That also allows to restrict the contents of the package to the files relevant to each platform.
If you'd like to support packaging for multiple distributions, I'd suggest helping the packagers for those distributions out; use some sort of well-known build system for your software (GNU's autotools or something like scons or waf), and document the build, optional dependencies, and so forth pretty well.
That way, when a Debian, Ubuntu, Red Hat, SuSE, whatever, packager comes along, they'll be able to create the package for you. You can optionally include packaging templates for one or more distributions in a separate VCS tree that is available, if you'd like.
If you are looking at packaging a closed-source/proprietary application for multiple systems, you'd probably do best to package up a .tar.gz file and document the installation process for it. You'll also want to make sure that the build process used doesn't embed any path information into the application, so that it can be run in /opt, /usr, or /usr/local, which are some popular choices for third-party add-on software.
BitRock InstallBuilder allows you to create installer packages for each one of the platforms you mentioned (as well as creating RPM, DEB, packages etc. from a single project file)