Hello,
currently I'm trying to build this software on Fedora 18. Due to the dependencies, especilly boost 1.49, I'm not able to compile the whole software. boost fails building with gcc 4.7.2 and compiling an older version of gcc fails due to changes in the glibc. Does openvibe run with newer versions of boost? Fedora ships 1.50.
Thanks in advance
Building OpenViBE with gcc 4.7.2
-
jtlindgren
- Posts: 775
- Joined: Tue Dec 04, 2012 3:53 pm
- Location: INRIA Rennes, FRANCE
Re: Building OpenViBE with gcc 4.7.2
Hi xcom,
you might want to try out our current SVN version. jlegeny patched the Fedora 18 build yesterday. Let us know if it doesn't work for you and we'll patch some more.
Cheers,
Jussi
you might want to try out our current SVN version. jlegeny patched the Fedora 18 build yesterday. Let us know if it doesn't work for you and we'll patch some more.
Cheers,
Jussi
Re: Building OpenViBE with gcc 4.7.2
Hi Jussi,
just got the new code and tried to compile it. The dependencies, omitting boost, now compile, but the main build breaks with error 2. Seems that's comming from some python related stuff and dynamic io. I attached the messages.
Thanks for your answer
just got the new code and tried to compile it. The dependencies, omitting boost, now compile, but the main build breaks with error 2. Seems that's comming from some python related stuff and dynamic io. I attached the messages.
Thanks for your answer
- Attachments
-
- error.log
- (8.45 KiB) Downloaded 350 times
Re: Building OpenViBE with gcc 4.7.2
Hello xcom,
the current Linux dependency installer does not compile boost, it gets it from the distribution packages. Did you do a fresh checkout? In the case you want to keep your build please delete the software folder in scripts folder and all generated (non-versioned) files in the scripts folder.
The errror you are seeing is probably tied to your python installation, do you have python 2.7 installed on your computer? Could it be that openvibe gets wrong headers? I do not understand German so I can only guess.
Cheers
Jozef
the current Linux dependency installer does not compile boost, it gets it from the distribution packages. Did you do a fresh checkout? In the case you want to keep your build please delete the software folder in scripts folder and all generated (non-versioned) files in the scripts folder.
The errror you are seeing is probably tied to your python installation, do you have python 2.7 installed on your computer? Could it be that openvibe gets wrong headers? I do not understand German so I can only guess.
Cheers
Jozef
Re: Building OpenViBE with gcc 4.7.2
Hello again,
well it's connected to the python distribution in Fedora. The include files are stored in /usr/include/python2.7. I did copy the contents do /usr/include and the build was successful, but now none of the tools will start.
The designer for example says:
... symbol lookup error: ../lib/libOpenViBE-plugins-python-dynamic.so: undefined symbol: PyIsInitialized
I am using the latest svn version of the source code by the revisionnumber 3447, and python 2.7.3 comming with Fedora. I used a brand new source folder for compiling.
Do you have some more hints or advices?
Thank you very much for your fast responses (you and the whole Team)
greets
well it's connected to the python distribution in Fedora. The include files are stored in /usr/include/python2.7. I did copy the contents do /usr/include and the build was successful, but now none of the tools will start.
The designer for example says:
... symbol lookup error: ../lib/libOpenViBE-plugins-python-dynamic.so: undefined symbol: PyIsInitialized
I am using the latest svn version of the source code by the revisionnumber 3447, and python 2.7.3 comming with Fedora. I used a brand new source folder for compiling.
Do you have some more hints or advices?
Thank you very much for your fast responses (you and the whole Team)
greets
Re: Building OpenViBE with gcc 4.7.2
Hello everyone,
just wanted to stress, as a side note, that using native packages for boost broke the builds in the past as boost API sometimes changes. Fedora releases are usually one step ahead from othe linux distros and turning back to native packages may hurt the release process in the future. I suggest you consider switching back to an updated version of the "built from source" package instead.
Hope this helps,
Best regards,
Yann
just wanted to stress, as a side note, that using native packages for boost broke the builds in the past as boost API sometimes changes. Fedora releases are usually one step ahead from othe linux distros and turning back to native packages may hurt the release process in the future. I suggest you consider switching back to an updated version of the "built from source" package instead.
Hope this helps,
Best regards,
Yann
my blog
my tweets
my linkedinRe: Building OpenViBE with gcc 4.7.2
It's working 
at least as far as I can say by now. I just used a new virtual machine setup from Fedora 18. The problems concerning python may have to do something with python2 and python3 packages which can coexist on Fedora. Before running the build scripts of openvibe be sure to remove any python3 packages from your system.
I used the latest svn version of the source by the revisionnumber 3449. Whatever you have changed in addition, it works, too!!!
at least as far as I can say by now. I just used a new virtual machine setup from Fedora 18. The problems concerning python may have to do something with python2 and python3 packages which can coexist on Fedora. Before running the build scripts of openvibe be sure to remove any python3 packages from your system.
I used the latest svn version of the source by the revisionnumber 3449. Whatever you have changed in addition, it works, too!!!
-
jtlindgren
- Posts: 775
- Joined: Tue Dec 04, 2012 3:53 pm
- Location: INRIA Rennes, FRANCE
Re: Building OpenViBE with gcc 4.7.2
Thats good to know. If python3 is interfering we may need to figure out how to ignore it.
Cheers,
Jussi
If python3 is interfering we may need to figure out how to ignore it.Cheers,
Jussi
Re: Building OpenViBE with gcc 4.7.2
A rather long response concerning the dependencies.
Currently our main effort is to make openvibe building and installation smoother on both Linux and Windows. This involves, among other things, work on a binary Linux package. At the moment our only way of distribution on Linux is the source code archive which is a source of many problems.
The main idea is to make openvibe behave the way users usually expect a Linux application to behave, including building, installing and distributing. Once the Linux packages are ready, there will be no more issues of backwards compatibility as the packages will remain locked to the distribution for which they were made. A person willing to install openvibe on a distribution which is not yet supported will be simply able to download an older package. The abstractions in the openvibe source code will make it easy for Box developer to create plugins without the need to care about versions o the underlying libraries.
It is true that a future boost update might result in a broken build of the application, but this is true for any of the dependencies. However, the development is only done with the latest (stable) versions of the available tools. This is true for most of the free projects and is even more so for a project with such a little development team. At some point the newer tools will inevitably break the builds of the old source code of the dependencies, and this has happened on almost every Fedora release, resulting in our home-baked patches to the source packages.
We would like to spend more time patching openvibe code rather than the code of our dependencies, which is why we are so eager to shift this task to distribution maintainers and upstream developers.
Kind regards
Jozef
Currently our main effort is to make openvibe building and installation smoother on both Linux and Windows. This involves, among other things, work on a binary Linux package. At the moment our only way of distribution on Linux is the source code archive which is a source of many problems.
The main idea is to make openvibe behave the way users usually expect a Linux application to behave, including building, installing and distributing. Once the Linux packages are ready, there will be no more issues of backwards compatibility as the packages will remain locked to the distribution for which they were made. A person willing to install openvibe on a distribution which is not yet supported will be simply able to download an older package. The abstractions in the openvibe source code will make it easy for Box developer to create plugins without the need to care about versions o the underlying libraries.
It is true that a future boost update might result in a broken build of the application, but this is true for any of the dependencies. However, the development is only done with the latest (stable) versions of the available tools. This is true for most of the free projects and is even more so for a project with such a little development team. At some point the newer tools will inevitably break the builds of the old source code of the dependencies, and this has happened on almost every Fedora release, resulting in our home-baked patches to the source packages.
We would like to spend more time patching openvibe code rather than the code of our dependencies, which is why we are so eager to shift this task to distribution maintainers and upstream developers.
Kind regards
Jozef