According to its developer, the Cuba library (for numerical integration) will not run(?) on a Windows machine since the OS is missing the function fork(2).
Windows users: Cuba 3 and up uses fork(2) to parallelize the execution threads. This POSIX function is not part of the Windows API, however, and is furthermore used in an essential way such that it cannot be worked around simply with CreateProcess etc. The only feasible emulation seems to be available through Cygwin.
See [http://www.feynarts.de/cuba/][1].
Since Cuba.jl is just a wrapper for the Cuba library, does this mean that Windows users must install Cygwin in order to use this Julia package?
You don't have to install Cygwin to use Cuba.jl, a normal Windows system is sufficient. The package is tested on AppVeyor without any problem
Related
There is a package CefSharp.OffScreen.NETCore
There is an example of its use under Windows
In theory, the package CefSharp.OffScreen.NETCore should be different from CefSharp.OffScreen cross-platform, that is, the ability to work under Linux. But judging by the example code of its use, it still depends on Windows.
Can this package CefSharp.OffScreen.NETCore work under Linux?
If it can, where can I see an example of its use under Linux?
CefSharp is built with Visual C++ which only runs on Windows.
I am having trouble getting nvBLAS to work in R. I'm using RStudio on a Windows 10 machine, and I have no idea how to link nvBLAS and the original Rblas together for R to start up with both. From the nvBLAS documentation:
To use the NVBLAS Library, the user application must be relinked
against NVBLAS in addition to the original CPU Blas (technically only
NVBLAS is needed unless some BLAS routines not supported by NVBLAS are
used by the application). To be sure that the linker links against the
exposed symbols of NVBLAS and not the ones from the CPU Blas, the
NVBLAS Library needs to be put before the CPU Blas on the linkage
command line.
How exactly do I do this in Windows? Caveat, I am a pretty solid R user, but I am by no means an R expert or a computer scientist. I would ideally like to avoid using an Ubuntu-build for this as well.
I want to know that if a shell script is created and tested on ubuntu kernel, then will it always without fail also run on RHEL kernel provided the correct shell is invoked for running the script.
Ways in which the execution may differ when used on different distributions and different kernels:
Differences in the version and configuration of the Linux kernel - this may affect presence and format of the contents of files such as those in /proc and /sys, or the presence of particular device drivers.
Differences in the version of the shell used - /bin/sh may be Bash on one system and Dash on another, or Bash 3.x on one system and Bash 4.x on the other.
Differences in the installed programs your script invokes (and, if you got your package dependencies wrong, whether those programs are even present - what's "essential" on one distribution may be "optional" on another).
In short, different distributions have the same issues as different versions of one distribution, but more so.
It depends on what shell/interpreter it was written for and versions of the particular shell it was written for. For example, a bash script written using bash-4.4 may not work in bash-2.0 and so on. It's not quite related to to the distribution/kernel version you use but the shell you use.
So, without details, it's not possible to assert whether a script that works on Ubuntu will work on RHEL. If you use the same shell and same version
on both machines then yes, it's going to work as expected (barring some very odd cases).
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.
I have an R script which I want to deploy so that it's idiot-proof, one click runs it etc. Unfortunately I don't have the means to pay for a server, and the environment in which it needs to run does not allow the installation of new software, only portable style apps can be run. (School computers) My script also relies on several non-base packages.
Is there any way to deploy R and my script in an easy to run way so it can be used off a usb stick?
You can install R on a USB drive and use it on any computer running the same OS. If you're using Windows, see question 2.6 of the R for Windows FAQ.
If you made the USB stick a bootable disk environment (say linux) with R installed on it, you could boot off it and do it that way.