Consider these 4 pieces of software:
COBRA 2.05
LibSBML 5.10
MATLAB R2013a (Also known as 8.1, 64-bit; MATLAB no longer supports 32-bit Linux anyway)
A 64-bit Linux OS (such as Ubuntu 14.04 or the latest Mint but not restricted to them)
Intro
The COBRA toolbox is an optimization suite that runs on top of MATLAB aimed at the development of MATLAB code for metabolic network modelling. Such a "network" is a system of equations that can have a very large number of equations and variables (such as thousands). Therefore, routines to read and write those large models according to some format specification are a must-have, and COBRA uses the standard SBML for that.
Problem
Unlike the Windows versions, the Linux binary packages do not integrate well out-of-the-box: to begin with, the pre-compiled Linux binary of libSBML (open-source) available for download does not come with MATLAB support. If one tries to use the pre-compiled libSBML, COBRA won't find the "MATLAB bindings" and therefore won't be able to, for example, read and write SBML XML files from the disk in a m-script.
The question
What needs to be done to make COBRA 2.05 running on top of MATLAB R2013a under Linux (Ubuntu 14.04 or the latest Mint, but this is not likely distro-specific) able to read and write SBML XML files? In other words, what needs to be done system-wide to make COBRA pass its own testSBML test?
This is how I got it working and what I could learn from all the hassle regarding how my Linux box works. I hope I am not forgetting/missing/mistaking anything.
1. MATLAB
1.1. Install MATLAB
Install it in its default location (you will need root access for this), don't be stubborn like I tried to be. Why:
1.1.1. Integration
It is very likely you will want to install some other software that uses the MATLAB framework at some point, and in the real world software doesn't always find other software even if you know how to tell it where to look for.
1.1.2. Make your life easier
Even though it seems like a good idea to install a big software in a place where you have lots of available space and that you can use in multiple machines (specially in Linux, which doesn't have that abomination called Registry, and has symbolic links), that would only perhaps be a good idea - apart from item 1.1.1 - if that place is a partition with a Linux filesystem, since at some point, some executable/script will need execution permission, and mounting the entire partition with execution permission for all its files is rather unsafe. Therefore, do not put MATLAB in an NTFS partition of an external HD; perhaps creating a Linux partition in the external HD just for Linux-specific stuff could work for this matter, but how much hassle is that?
1.2. Setup MATLAB so people and other software can launch it
Even though I have seen somewhere that the MATLAB installer eventually shows an option to create symbolic links in the system path for convenience, it didn't in my case. But that is OK, since I would have to replace the symbolic link /usr/local/bin/matlab by the following shell-script (same path, same filename) anyway:
#!/bin/sh
export LD_LIBRARY_PATH=/usr/local/lib:/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH
exec /usr/local/MATLAB/R2013a/bin/matlab $*
OBS: That LD_LIBRARY_PATH is needed for MATLAB to find SBML bindings later and to be able to use them. Also, if you install some third-party solver such as TOMLAB, you will most likely need to add some more paths in this little launcher script.
OBS 2: In my case, the installation script didn't automatically create any launchers or shortcuts, but I have found an iconless and extension-less Matlab 8.01 file and a matlab icon as a png file, and that first file was a template .desktop file that I could edit to fit my needs and put in /usr/share/applications so the Unity Dash would find it. The contents of this Matlab.desktop file are:
[Desktop Entry]
Type=Application
Icon=/usr/local/MATLAB/R2013a/Matlab.png
Name=Matlab 8.01
Comment="Start Matlab 8.01"
Exec=/usr/local/MATLAB/R2013a/bin/matlab -desktop
Categories=Development;
Name=Matlab 8.01
GenericName=Matlab 8.01
Comment="Start Matlab 8.01"
2. libSBML
2.1. Install libSBML
libSBML is provided by a deb package specific for Ubuntu (and for CentOS), and also versions for several flavours of Windows and MacOSX (their home page: http://sbml.org/Software/libSBML). Guess which is the only platform whose binaries weren't compiled with MATLAB support? Linux, of course. That means you will need to compile from source (and that the deb package is therefore useless to you). To compile:
2.1.1. Install dependencies
The dependency libxml2-dev (from software manager or from a terminal):
sudo apt-get install libxml2-dev
2.1.2. Save yourself some time in the future
Usually, one would do configure, make and then make install. But this is not recommended for the same reason as installing anything that doesn't come in a pretty little package: you will loose control of which files went where, and will need to keep the source-code to be able to run make uninstall if you need to uninstall it later. So, install checkinstall and use it to replace the step make install, since checkinstall creates a package for your system that can be later uninstalled or reinstalled just as any regular packaged software (from software manager or from a terminal):
sudo apt-get install checkinstall
2.1.3. Configure the compiling-process
Get LibSBML source code and extract it to some folder. From a terminal, navigate to that folder and configure the compilation:
./configure --with-matlab
OBS: with the with-matlab flag, the configure script will fail it it cannot find an executable whose filename is matlab. If it fails, it outputs that the matlab file could not be found, but the test it performs is actually both for the existence of the file and whether it is executable. So, if the file is in an NTFS partition, configure will fail even if it finds the file, but will tell you the file couldn't be found. You can enforce it to look for the executable in /path/to/matlab/root by passing (it will look for a bin folder inside that path, and for the executable inside that bin folder):
./configure --with-matlab=/path/to/matlab/root
OBS: This will install libSBML in the default location: /usr/local/lib. Again, it is a good idea to just let it install in its default location, but if you need to change it, you can pass the path with the flag: --prefix=/your/installation/path
OBS 2: You might ask why libSBML needs to find and execute matlab to be compiled with support for it: it needs to fire up MATLAB later to build MEX-files (compiled MATLAB code), so I would speculate you wouldn't be able to install libSBML after all if your MATLAB has no compiler to generate MEX-files.
2.1.4. Build and install libSBML
make
checkinstall
VERY IMPORTANT OBS:
I) checkinstall asks for confirmation of the metadata of the package it is about to create. In my case, the string for the version field came by default as "Source" (without the quotes), which caused checkinstall to fail because dpkg (the system tool that actually builds the deb file) failed complaining the version number must start with, well, a number. So, save yourself some time and make sure the string in the version field starts with a number (i.e. "5.10", without the quotes obviously)
II) checkinstall asks if you want to exclude from the future package files that the make install command would put in your home folder and says it is a good idea to exclude them. LibSBML has a test.xml file that it needs to be in the $HOME folder later, or else it won't let you integrate with MATLAB. And even though it tells you a test.xml is missing, it doesn't tell you where that file should be or if that file was something that came with the library. I only noticed it because checkinstall had found a $HOME/test.xml reference earlier (that I excluded from the package, of course) and I had found that odd. So, save yourself some time and exclude $HOME/test.xml from the package generated by checkinstall, and then search for test.xml inside the source-code folder and copy it to $HOME as soon as libSBML finishes being installed by checkinstall.
2.2. Integrate libSBML to MATLAB
Fire up MATLAB, navigate to where the SBML MATLAB-bindings were installed in step 2.1.5 (in my case: /usr/local/lib) and run the file installSBML.m that should be there.
2.2.1. Shared libraries problems
In my case, I had an error due to an old unresolved issue: libstdc++.so.6 not having a reference to GLIBCXX_3.4.15. Turns out that MATLAB was trying to use a libstdc++.so.6.0.13 (libstdc++.so.6 was a symbolic link pointing to this file) that came with it in /usr/local/MATLAB/R2013a/sys/os/glnxa64, which indeed didn't have that reference (one could verify that by issuing:
strings /usr/local/MATLAB/R2013a/sys/os/glnxa64/libstdc++.so.6.0.13 | grep GLIBC
). My system has a libstdc++.so.6.0.19 located in /usr/lib/x86_64-linux-gnu that has that reference, so I enforced MATLAB to use 6.0.19 one by setting the LD_LIBRARY_PATH properly (refer to step 1.2) and also by renaming the libstdc++.so.6 that came with MATLAB to something else so it would not find it and would keep looking until it found my system's. A friend of mine running Linux Mint didn't need to rename anything: for him, setting the LD_LIBRARY_PATH was enough.
2.2.2. Other problems
installSBML.m will fail if it doesn't find that $HOME/test.xml file mentioned in step 2.1.5, regardless of whether the library actually works. It assumes that if it could not test itself using a file that it assumes to be in $HOME, the user shouldn't have the option to install it anyway.
3. COBRA / SBML toolbox
3.1. Setup COBRA
In MATLAB, navigate to <YOUR_COBRA_ROOT_FOLDER_HERE>/external/toolboxes/SBMLToolbox-4.1.0/toolbox and run the file install.m there. You should have all set so it finds the MATLAB-bindings you set up in step 2.2.
3.2. MATLAB setpaths problems
I had to manually edit the file /usr/local/MATLAB/R2013a/toolbox/local/pathdef.m as root to include the folder /usr/local/lib (where libSBML and its MATLAB-bindings are) to make that setting persistent. Every time I restarted MATLAB, its setpath had gone back to the default, no matter if I started MATLAB as root when setting its setpath via the MATLAB GUI.
3.3. Test
Now you have hopefully connected all the dots. Try it: in MATLAB, navigate to <YOUR_COBRA_ROOT_FOLDER_HERE> and issue:
initCobraToolbox
testAll
If you haven't got any third-party solvers installed and configured, it should pass 14 of the 19 tests, including the SBML test (testSBML). Now you can load SBML files into MATLAB and play with them.
I also needed to add a symbolic link from /usr/local/lib/libsbml.so.5 to the MATLAB sys folder by:
sudo ln -s /usr/local/lib/libsbml.so.5 /usr/local/MATLAB/R2014a/sys/os/glnxa64/
This finally made the installation possible.
I installed using Cmake. To do this it is necessary to find the FindMatlab.cmake in the source package and insert the MATLAB path manually!
.............
elseif(EXISTS "/Applications/MATLAB_R2008a.app/")
set(MATLAB_ROOT_PATH "/Applications/MATLAB_R2008a.app/")
endif()
else()
if (EXISTS "/usr/local/MATLAB/R2014a/")
set(MATLAB_ROOT_PATH "/usr/local/MATLAB/R2014a/")
endif()
endif()
..........
FYI, to resolve the shared library issue at point 2.2.1 I needed to install the package matlab-support (in Ubuntu repositories)
Related
Once a program is installed in Linux, sometimes I find out that it is easier to put in a different location. In general, what is the significance of the location of the files of an installed program on Linux?
Often the advice on the internet is to add the (wrong or inconvenient) paths to environment variables. I'd much rather move the files to locations where they are automatically found by commands and programs.
One recent example is site-packages of Python. My Python did not appear to check the PYTHONPATH variable, moving the libraries there to the Python2.7/ directory worked well.
Now Ia m facing the same issue with OpenCV.
I also wonder why Linux installation does not prompt (like Windows) for the desired installation directory and why, so often, things wind up in places where they don't work?
In general, programs are installed in /usr/bin (for binaries) and /usr/lib, or a specific path to that specific linux distro, so that any program that you install that uses a specific library/program will search in that path for it. If you install a program in a different path, let's say /home/user/program, it will be installed locally and other programs won't be able by default to access it.
You can install any program wherever you want. However, it is good use to use the repo and install them in the general path.
I don't know how you install programs, but I use apt-get and dpkg on Ubuntu. You can also install some python modules this way.
Generally you are supposed to use the package system provided by your distro (IMHO).
If you do not use packages then you are on your own.
About PYTHONPATH. Did you add it to your .bashrc and made sure that it was set in the terminal you are using?
Also please see:
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
I have the 3.0.1 version of Alex installed on my /usr/bin. I think the Haskell Platform originally put it there (although I'm not 100% sure...).
Unfortunately, version 3.0.1 is bugged so I need to upgrade it to 3.0.5. I tried using cabal to install the latest version of Alex but cabal install alex-3.0.5 it installed the executable on .cabal/bin over on my home folder instead of on /usr/bin
Do I just manually copy the executable to /usr/bin? (that sound like a lot of trouble to do all the time)
Do I change my PATH environment variable so that .cabal/bin comes before /usr/bin? (I'm afraid that an "ls" executable or similar over on the cabal folder might end up messing up my system)
Or is there a simpler way to go at it in general?
I want to first point out the layout that works well for me, and then suggest how you might proceed in your particular situation.
What works well for me
In general, I think that a better layout is to have the following search path:
directories with important non-Haskell related binaries
directory that cabal install installs to
directory that binaries from the Haskell platform are in
This way, you can use cabal install to update binaries from the Haskell platform, but they cannot accidently shadow some non-Haskell related binary.
(On my Windows machine, this layout is easy to achieve, because the binaries from the Haskell platform are installed in a separate directory by default. So I just manually adapt the search path and that's it. I don't know how to achieve it on other platforms).
Suggestion for your particular situation
In your specific situation with the Haskell platform binaries already installed together with the non-Haskell related binaries, maybe you can use the following layout for the search path:
directory containing links to some of the binaries in 3
directory with important non-Haskell related binaries and Haskell platform binaries
directory that cabal install installs to.
This way, binaries from cabal install cannot accidently shadow the important stuff in 2. But if you decide you want to shadow something form the Haskell platform, you can manually add a link to 1. If it's a soft link, I think you only have to do that once per program name, and then you can call cabal install for that program to update it. You could even look up what executables are bundled with the Haskell platform and do that once and for all.
On second though, putting /.cabal/bin in front of /usr/bin in the PATH is simpler and is what most people do already.
Its also not a big deal since only cabal will put files in .cabal/bin so it should be predictable and with little risk of overwriting stuff.
I have an application that relies on Qt, GDCM, and VTK, with the main build environment being Qt. All of these libraries are cross-platform and compile on Windows, Mac, and Linux. I need to deploy the application to Linux after deploying on Windows. The versions of vtk and gdcm I'm using are trunk versions from git (about a month old), more recent than what I can get apt-get on Ubuntu 11.04, which is my current (and only) Linux deployment target.
What is the accepted method for deploying an application that relies on these kinds of libraries?
Should I be statically linking here, to avoid LD_LIBRARY_PATH? I see conflicting reports on LD_LIBRARY_PATH; tutorials like this one suggest that it's the 'right way' to modify the library path to use shared libraries through system reboots. Others suggest that I should never set LD_LIBRARY_PATH. In the default version of GDCM, the installation already puts libraries into the /usr/local/lib directory, so those libraries get seen when I run ldd <my program>. VTK, on the other hand, puts its libraries into /usr/local/lib/vtk-5.9, which is not part of the LD_LIBRARY_PATH on most user's machines, and so is not found unless some change is made to the system. Copying the VTK files into '/usr/local/lib' does not allow 'ldd' to see the files.
So, how can I make my application see VTK to use the libraries?
On windows, deploying the dlls is very straightforward, because I can just include them in the installer, and the application finds them because they are in the local directory. That approach does not work in Linux, so I was going to have the users install Qt, GDCM, and VTK from whatever appropriate source and use the default locations, and then have the application point to those default locations. However, since VTK is putting things into a non-standard location, should I also expect users to modify LD_LIBRARY_PATH? Should I include the specific versions of the libraries that I want and then figure out how to make the executable look in the local directory for those libraries and ignore the ones it finds in the library path?
Every "serious" commercial application I have ever seen uses LD_LIBRARY_PATH. They invariably include a shell script that looks something like this:
#!/bin/sh
here="${0%/*}" # or you can use `dirname "$0"`
LD_LIBRARY_PATH="$here"/lib:"$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH
exec "$0".bin "$#"
They name this script something like .wrapper and create a directory tree that looks like this:
.wrapper
lib/ (directory full of .so files)
app1 -> .wrapper (symlink)
app1.bin (executable)
app2 -> .wrapper (symlink)
app2.bin (executable)
Now you can copy this whole tree to wherever you want, and you can run "/path/to/tree/app1" or "/path/to/tree/app2 --with --some --arguments" and it will work. So will putting /path/to/tree in your PATH.
Incidentally, this is also how Firefox and Chrome do it, more or less.
Whoever told you not to use LD_LIBRARY_PATH is full of it, IMHO.
Which system libraries you want to put in lib depends on which Linux versions you want to officially support.
Do not even think about static linking. The glibc developers do not like it, they do not care about supporting it, and they somehow manage to break it a little harder with every release.
Good luck.
In general, you're best off depending on the 'normal' versions of the libraries for whatever distribution you're targetting (and saying you don't support dists that don't support recent enough versions of the lib), but if you REALLY need to depend on a bleeding edge version of some shared lib, you can link your app with -Wl,-rpath,'$ORIGIN' and then install a copy of the exact version you want in the same directory as your executable.
Note that if you use make, you'll need $$ in the makefile to get a single $ into the argument that is actually sent to the linker. The single qutoes are needed so the shell doesn't munge things...
Well, there are two options for deploying Linux application.
The correct way:
make a package for your app and for the libraries, if they are so special, that they can't be installed from standard repositories
There are two major package formats. RPM and DEB.
The easy way:
make a self-extract file that will install the "windows way" into /opt.
You can have libraries in the same directory as the executable, it's just not the preferred way.
I am trying to create a Debian package for a Java application.
In my package there is a .jar file which is executable, a script which will run this jar file and a .so file for fmod.
I've read this tutorial.
In the control file there is a 'Depends' field which basically describes the packages that need to be installed in order to install my application. My question is, how do I find which packages are required for my application? I followed the instructions in the tutorial for one of the .so files, and got this:
$ dpkg -S libfmodex64-4.28.09.so
dpkg: *libfmodex64-4.28.09.so* not found.
Also, my application requires Java 1.5 to be installed in order for it to run. How do I specify this in my debian package?
I strongly recommend building your package from source within the Debian packaging infrastructure. Everything will be pretty much automatically taken care of if you use the Ant class in CDBS.
If you do insist on assembling a binary .deb only, equivs is much less hackish than the method described by your document.
You'll want to get the canonical name for your library:
apt-cache search libname
Take care to note the nomenclature at the end of the package. You don't want to specify a specific version in the control file, just the earliest version of the library that is suitable for your application.
You would then use canonical_libname >= major.minor , which lets the system decide if you have (or can update to) the version of the library that can support your application. If you carve this in time, i.e. specifying the full version of your current library, you'll break in the future.
For instance, if you specify libfoo-1.2.34 and future versions of Debian ship libfoo-2.3.45, your package won't install, because it thinks you have an incompatible version of libfoo.
I'm trying to build a Win32 DLL from an audio-DSP related Linux library (http://breakfastquay.com/rubberband/). There are makefiles and config scripts for Linux, but no help for Windows. The author provides a Win32 binary of a sample app using the library, and I see a number of "#ifdef MSVC" and "#ifdef WIN32" scattered around, so I don't think I'm starting completely from scratch but I'm stuck nevertheless.
As my programming knowledge in either platform is rather limited, I'd appreciate any help.
First of all, what is the right way to get started here? Visual Studio? Cygwin? Initially I started off creating a Win32 DLL project in Visual Studio, adding the source files, thinking about adding a .def file, etc, but at some point I felt like this was going nowhere.
As for Cygwin, this was the first time using it, and I don't even know if this is the sort of thing that Cygwin is designed for. Is it?
On Cygwin, I ran ./configure and got stuck at something like this:
"checking for SRC... configure: error: Package requirements (samplerate) were not met: No package 'samplerate' found"
After looking through the log, it appears that pkg-config is looking for samplerate.pc. How do I handle packages in Windows? libsamplerate is just an open source library, and I have source and a DLL for this. But I'm not sure how to use them to satisfy the dependency requirements for librubberband (which is what I'm trying to build)
I'm completely lost at this point and if anyone can give me a nudge in the right direction... and, is there an easier way to do this?
Many thanks in advance.
If you're still stuck on this I can throw a little light.
You may have to build everything from sources (or have the libraries installed in your environment). You're using Cygwin, I would recommend MinGW and MSYS too, but sometimes it's just not possible to use this combination to build the program or library.
So if using Cygwin, first ensure that you have a proper environment installed. This is that you have the correct development headers installed.
Then download libsndfile. Extract the sources to a directory and from the Cygwin bash shell navigate to that directory. There perform:
./configure
make
make install prefix=/cygdrive/c/cygwin
Notice that I use a prefix, that prefix should point to the directory Cygwin is installed in order to correctly install the libraries (the same happens to MinGW and MSYS, the prefix should point to the MinGW installation directory). Maybe using the usr directory in the prefix works too, I've never tried it.
Now download FFTW, as it will be needed for libsamplerate and rubberband. Same procedure as with libsndfile: extract, configure, make & make install using the prefix. Now copy the header files of FFTW (in the example they'd be in /cygdrive/c/cygwin/include) to the include directory in the usr directory (in the example /cygdrive/c/cygwin/usr/include).
Next SRC (libsamplerate), same procedure.
Then the Vamp plugin SDK. In order to compile the it you may need to edit the file src\vamp-hostsdk\PluginLoader.cpp, deleting RTLD_LOCAL from a dlopen() call (it's safe, it's already the default behaviour).
Also, you may need to install it by hand (in my experiences it didn't like the prefix). Or set the environmental variable PKG_CONFIG_PATH pointing to the paths of pkgconfig, e.g.:
set PKG_CONFIG_PATH=/cygdrive/c/cygwin/lib/pkgconfig:/usr/local/lib/pkgconfig
Now, create a file called ladspa.h in the include directory with the contents of the LADSPA header
Finally, configure and build rubberband, it should find everything it needs.
To build in MSYS using MinGW follow the same procedure, using the according prefix. Using Visual Studio is another alternative, but you may need to use some of the pre-built libraries (for example for libsndfile) as building Linux libraries natively in Windows may be complicated or even impossible (without hacking the source code) in VS.
Anyway, the autor of rubberband provides binaries; I think you should consider use them instead of going through all of this.
Linux to w32 is mostly a tricky thing.
For each of your dependencies, download the source and:
./configure
make
sudo make install
Also, I recommend you to use MinGW + msys in place of CygWin (as the latter produces executables that depend on its libraries). However in your situtation, use the VS approach -- 't will save you a lot of time.