Installation path issue for ubuntu 14.04 -- Unable to load plugins (and starts tulip)

[rgiot]

Tulip installs its library in <install_path>/x86_64-linux-gnu/, however it seems to search them in <install_path>/bin/../lib/x86_64-linux-gnu/../lib/tulip (so <install_path>/lib/lib/tulip) that does not exists.
The message loadPlugins info: /data/rgiot/opt/bin/../lib/x86_64-linux-gnu/../lib/tulip - Aucun fichier ou dossier de ce type is printed in the console.

As a consequence it does not find perspectives and cannot launch.

A partial workaround is to copy past the files in the lib folder (so maybe even the error message does not correspond to the location where tulip loads plugins).
Why partial ?

• It launches the application tulip_perspective with the standard graph application
• It displays the error message loadPlugins info: /data/rgiot/opt/bin/../lib/x86_64-linux-gnu/../lib/tulip - Aucun fichier ou dossier de ce type for the tulip application
• It seems one of my application is unable to load its plugin ( but the isseu is maybe elswhere here)

The toolchain used:

• cmake version 2.8.12.2
• g++ (Ubuntu 7.2.0-1ubuntu1~14.04) 7.2.0

[rgiot]

to force cmake to generate the following line in CMakeCache.txt is another workaround for this issue:
CMAKE_INSTALL_LIBDIR:PATH=lib

In my case:

• the comment before this lines remains //object code libraries (lib/x86_64-linux-gnu)
• the 3 problematic points of the issue are solved

[anlambert]

Hum, this bug seems only to appear with CMake < 3 (see Kitware/CMake@620939e). Nevertheless, this effectively needs to be fixed. I will look at it during the week end.

[p-mary]

From my point of view, this can be easily fix with the following cleanup of the
char* getTulipLibDir(char* buf) and void tlp::initTulipLib(const char* appDirPath) functions
lin library/tulip/core/src/TlpTools.cpp.
Fix is attached in issue_27_fix.zip

[anlambert]

Yes this is indeed cleaner and remove some code duplications. Nevertheless, the implementation issue from the GNUInstallDirs module in CMake < 3 (see CMake commit fixing the issue referenced above) should also be handled in Tulip CMake configuration. In Debian, multi-arch install of libraries must only be performed when the install prefix is /usr. When this is not the case, CMAKE_INSTALL_LIBDIR should be "lib" instead of "lib/arch". You can commit the TlpTools improvements, I will handle the fix for CMake < 3 on Debian tomorrow.

By the way, you should fork the Tulip repo in your Github account and use git to share code modifications with others by creating and pushing branches. This is not really complicated and helps other contributors to view the diff directly on the Github web interface. Below are some hints on how to do it:

# this assumes you created a fork of the Tulip repo
# if this is has not been done yet, clone your fork and do some setup
$ git clone https://github.com/p-mary/tulip
$ cd tulip
# in order to interact with the main Tulip repo, set it as a new remote named upstream 
$ git remote add upstream https://github.com/Tulip-Dev/tulip

# Important thing is to keep your local master branch in sync with the upstream one 
$ git checkout master
$ git pull upstream master

# Then create a branch to work on a specific issue or feature
$ git checkout -b fix-bug-id
# modify the relevant source files to fix the issue, then
# add those files to the staging area
$ git add <modifed source files>
# commit those files with an appropriate message log
$ git commit -m "message log"
# push your branch to your fork on Giithub
$ git push origin fix-bug-id

You can then show your modifications to others by either opening a pull request to the main Tulip repo (but usually this is for external contributors) or simply redirecting them to your account on Github in order to view your branch with your commit fixing the issue.

Git may be complicated as first sight but once you will understand its main concepts, it really changes the way you work as a developer and make you more efficient. The learning curve is not so hard and as almost everyone using it today, you will easily find a tons of tutorials to learn the basics. If you want the rough details on why git was needed in the open source world, I suggest you to start by watching this: https://www.youtube.com/watch?v=4XpnKHJAok8&t=1236s

[rgiot]

Thanks.

I've not yet been able to test, I have lot of errors like error: use of old-style cast [-Werror=old-style-cast].
Maybe it comes from the fact that I enable c++17

[anlambert]

Since commit 3077b4e, the -Wold-style-cast warning is now activated to discourage the use of old style C casts in Tulip codebase and plugins. Nevertheless, this flag issue warnings not errors. Maybe C++17 forbids to use that style of cast by default ?

[rgiot]

I talked too fast...
I have not activate C++17 at all (I forget to do it, so I use the dealt version of g++7.2) and the issue comes from the CMakeLists.txt of my plugin (my own plugin compiled with the flag -Werror)
So once -Werroris removed, it compiled.GlScene.h` is one of the guilty files.

However I had not this compilation error before creating this issue

[anlambert]

-Werror turns all warnings into errors, that makes sense.

The commit adding the warnings for old style casts has been pushed during the week end so that's why they appear today.

Could you attach an ouput of the warnings you get? I took care of removing all of the old C style casts in the Tulip codebase so I don't understand why you still get some.

[rgiot]

It is seems it is the sole error, but maybe I have missed other.

library/tulip-ogl/include/tulip/GlScene.h:72:48: warning: use of old-style cast [-Wold-style-cast]
     assert(complexEntityId != (unsigned int)(-1));

[anlambert]

Okay I understand why I missed this one, I never compile Tulip in Debug mode and assert are deactivated in that case. Thanks!