Author Topic: Linking to the non system libcodeblocks.a on Linux?  (Read 6302 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Linking to the non system libcodeblocks.a on Linux?
« on: October 21, 2011, 11:24:47 am »
Hello,
Here is my setup:
1. I have locally modified source tree for the debuggers branch, built with codeblocks
2. I have a plugin, which I want to build against the modified version of C::B
3. I have installed version of C::B which has different SDK, than the local version
4. The plugin is setup to run the modified C::B as a host

The problem is that when I've modifications to the SDK, C::B refuses to start, when I hit run/debug->start in the plugin project.
I'm not sure what is the exact problem. Using the run.sh shell script works or running C::B from inside C::B used to build C::B works, too.
Also, I have the strange feeling that my plugin is not loaded correctly, I'm making obvious changes to the code, but they are not reflected :(

What can I do to improve the situation?
1. Install the modified SDK lib, this is the obvious solution, but the iteration time is extreme
2. Move libcodeblocks to a non system path and probably use rpath
3. Use the version numbers for the lib
4. Rename the lib, when building from C::B
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7252
Re: Linking to the non system libcodeblocks.a on Linux?
« Reply #1 on: October 21, 2011, 01:09:53 pm »
I would try the second solution (rpath), because it seems the easiest way to set up.
If it does not work, try to set LD_LIBRARY_PATH with the environment variable plugin.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Linking to the non system libcodeblocks.a on Linux?
« Reply #2 on: October 21, 2011, 02:49:33 pm »
I would try the second solution (rpath), because it seems the easiest way to set up.
What should I change? The autotools files or the Codeblocks-unix.cbp
If it is autotools, where/what/how?

If it does not work, try to set LD_LIBRARY_PATH with the environment variable plugin.
This doesn't work, I've tried it. And I don't know why it doesn't work :(
But I know that the env plugin works for host apps/share library projects, because I'm using it at work!
When using the debugger, Codeblocks calls exit somewhere in the IMPLEMENT_APP macro :( I don't think it reaches the main function.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7252
Re: Linking to the non system libcodeblocks.a on Linux?
« Reply #3 on: October 21, 2011, 09:41:46 pm »
Adding
Code
-Wl,-rpath=/path/to/codeblocks-root/src/devel
to the src-targets "Other linker options" (of the modified C::B) works for me.

Using LD_LIBRARY_PATH with envvar-plugin also works, but I had to manually activate the checkbox after modifying it.
« Last Edit: October 21, 2011, 09:44:02 pm by jens »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Linking to the non system libcodeblocks.a on Linux?
« Reply #4 on: October 21, 2011, 09:56:15 pm »
Patch? Do you change the C::B or the plugin?

Edit: -rpath in the src target in Codeblocks-unix.cbp does it (but it is not working 100% O_O)
Now I have to correctly link the libcodeblocks.a, do you know how. This is in the external plugin project?
« Last Edit: October 21, 2011, 10:03:56 pm by oBFusCATed »
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Linking to the non system libcodeblocks.a on Linux?
« Reply #5 on: October 21, 2011, 10:10:02 pm »
It turned out that I was doing
1. generate libmyplugin.so to the src/devel/share/plugins/
2. cp myplugins_path/libmyplugin.so to src/devel/share/plugins/

So, I was copying an old version to the new one. Stupid me. Sorry for the noise :(
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]