bob issueshttps://gitlab.idiap.ch/bob/bob/-/issues2016-08-04T09:29:18Zhttps://gitlab.idiap.ch/bob/bob/-/issues/79cmake complains about BLAS library not found even after installing BLAS and L...2016-08-04T09:29:18ZAndré Anjoscmake complains about BLAS library not found even after installing BLAS and LAPACK libraries (Fedora 14)*Created by: thelinuxmaniac*
In Fedora Core 14, cmake complains about BLAS library not found even after installing BLAS and LAPACK libraries.
$ cmake -DCMAKE_BUILD_TYPE=Release ../git/bob/
.....
CMake Error at src/math/cxx/CMakeLists.tx...*Created by: thelinuxmaniac*
In Fedora Core 14, cmake complains about BLAS library not found even after installing BLAS and LAPACK libraries.
$ cmake -DCMAKE_BUILD_TYPE=Release ../git/bob/
.....
CMake Error at src/math/cxx/CMakeLists.txt:18 (message):
BLAS library not found!
The BLAS and LAPACK libraries were installed using
$ yum install blas-devel.x86_64 blas.x86_64 lapack-devel.x86_64 lapack.x86_64
https://gitlab.idiap.ch/bob/bob/-/issues/67Video support broken with ffmpeg 0.9 and superior2016-08-04T09:29:00ZAndré AnjosVideo support broken with ffmpeg 0.9 and superior*Created by: anjos*
Cannot read AVI files with ffmpeg 0.10 or 0.11. The last frames of long sequences seem all be set to zeros or cannot be read at all. To reproduce this problem, compile Bob against any of the above mentioned versions ...*Created by: anjos*
Cannot read AVI files with ffmpeg 0.10 or 0.11. The last frames of long sequences seem all be set to zeros or cannot be read at all. To reproduce this problem, compile Bob against any of the above mentioned versions and try to read and verify that an AVI file can be read as it is supposed to be.https://gitlab.idiap.ch/bob/bob/-/issues/50Solving/Simplifying the RPATH or INSTALL_DIR2016-08-04T09:28:29ZAndré AnjosSolving/Simplifying the RPATH or INSTALL_DIR*Created by: anjos*
Currently, to build our Ubuntu or OSX packages, we need to disable the setting of these variables as files get moved during installation using `debuild` or `MacPorts`. Here is a strategy to get rid of this annoyance:...*Created by: anjos*
Currently, to build our Ubuntu or OSX packages, we need to disable the setting of these variables as files get moved during installation using `debuild` or `MacPorts`. Here is a strategy to get rid of this annoyance:
1. Move the library `_core_array.so` to the `<prefix>/lib` directory and version it properly
2. Make all other python bindings depend on that instead of a library hidden at python directories
3. Make the python bindings use the RPATH by default (this is disabled when the user passes `-DCMAKE_SKIP_BUILD_RPATH=TRUE` to CMake. Under OSX, have a similar mechanism that will do that for the INSTALL_DIR property.
Notes:
1. The RPATH functionality is only required for the python bindings
2. The python bindings only require that functionality if the libraries they depend on are not installed in a standard location.https://gitlab.idiap.ch/bob/bob/-/issues/49On any Ubuntu version, bob gets linked to libvl.so2016-08-04T09:28:28ZAndré AnjosOn any Ubuntu version, bob gets linked to libvl.so*Created by: anjos*
The problem is that the pre-compiled Ubuntu versions are now depending on libvl.so instead of depending on libvl.so.0
If you have a 12.04 somewhere, you can test this. Just uninstall libvl0.
Now, install bob from...*Created by: anjos*
The problem is that the pre-compiled Ubuntu versions are now depending on libvl.so instead of depending on libvl.so.0
If you have a 12.04 somewhere, you can test this. Just uninstall libvl0.
Now, install bob from our ppa. Fire-up python and then try to import bob. You will get the error:
```sh
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import bob
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/pymodules/python2.6/bob/__init__.py", line 16, in <module>
from . import ip
File "/usr/lib/pymodules/python2.6/bob/ip/__init__.py", line 1, in <module>
from ._ip import *
ImportError: libvl.so: cannot open shared object file: No such file or directory
```
This can be (temporarily) fixed with the following commands:
```sh
$ sudo apt-add-repository ppa:biometrics/vlfeat
$ sudo apt-get update
$ sudo apt-get install libvl-dev
```
Besides, our packages do not (yet) depend on the packages libvl0 or libblitz1ldbl. They should.https://gitlab.idiap.ch/bob/bob/-/issues/48Bob, RPATH policy and versions on shared objects2016-08-04T09:28:26ZAndré AnjosBob, RPATH policy and versions on shared objects*Created by: anjos*
The current infrastructure does not use the properties VERSION (build) and SOVERSION (api) for marking the C++ libraries. I'm not sure the same should be done for python bindings written with Boost.Python.
Further...*Created by: anjos*
The current infrastructure does not use the properties VERSION (build) and SOVERSION (api) for marking the C++ libraries. I'm not sure the same should be done for python bindings written with Boost.Python.
Furthermore, when installing Bob globally, the RPATH mechanism should be disabled as it is totally useless.https://gitlab.idiap.ch/bob/bob/-/issues/43Writing external code that depends on Bob2016-08-04T09:28:15ZAndré AnjosWriting external code that depends on Bob*Created by: anjos*
Sometime ago we had the ability to compile external projects against Bob using CMake. Our CMake development environment does export its properties and all those files get installed properly. Remains untested though:
...*Created by: anjos*
Sometime ago we had the ability to compile external projects against Bob using CMake. Our CMake development environment does export its properties and all those files get installed properly. Remains untested though:
1. How to compile C++ extensions using Bob libraries
2. How to compile Python C++ bindings using Bob libraries and extensions to boost.python (e.g. const_ndarray objects)
This bug should remain opened until we get this functionality back.https://gitlab.idiap.ch/bob/bob/-/issues/5CMake Cleanup2016-08-04T09:26:55ZAndré AnjosCMake Cleanup*Created by: anjos*
This ticket keeps track of needed CMake script updates to tackle the following:
1. Clean-up the PCH support by removing this
2. Find a way to keep the "package" support, but do not depend on the "install" directo...*Created by: anjos*
This ticket keeps track of needed CMake script updates to tackle the following:
1. Clean-up the PCH support by removing this
2. Find a way to keep the "package" support, but do not depend on the "install" directory to find headers. This tends to work badly with template files and in other special cases.
3. Maybe port Cmake stuff to Scons?
4. Try other build systems?