Code::Blocks Forums

User forums => General (but related to Code::Blocks) => Topic started by: cacb on September 15, 2012, 10:40:32 pm

Title: C::B execution paths
Post by: cacb on September 15, 2012, 10:40:32 pm
I'm on Kubuntu 12.04 running C::B nightly build svn 8248 (from jens Lody repository).

My application uses boost that I have compiled from source and installed in a non-standard location. If I try to run the application from the command line I get the following error message at startup
Code
error while loading shared libraries: libboost_thread.so.1.51.0: cannot open shared object file: No such file or directory

This is all quite logical as I am using boost::thread and didn't include the directory where boost is installed in LD_LIBRARY_PATH.

But what is surprising, is that the application starts just fine from within Code::Blocks.
How does C::B find the boost shared object files, when I haven't really told it where to look?
Title: Re: C::B execution paths
Post by: oBFusCATed on September 15, 2012, 11:20:58 pm
You have by specifying the path for the linker.
C::B uses it to modify the LD_LIBRARY_PATH variable.
C::B makes it work automagically.
Title: Re: C::B execution paths
Post by: cacb on September 15, 2012, 11:51:21 pm
You have by specifying the path for the linker.
C::B uses it to modify the LD_LIBRARY_PATH variable.
C::B makes it work automagically.

Ok, thanks. Now I understand.

I think that automagic behaviour is often confusing, although quite convenient for those who understand what is happening. Now that default compiler behaviour is to provide a full command line log, perhaps it would be an idea to also display the automagic modifications to LD_LIBRARY_PATH when running a program from within the IDE:

Now it says:
Checking for existence: /path/to/program
Executing: /path/to/program  (in /path/to/project/.)


It could be more explicit:
Checking for existence: /path/to/program
Added to LD_LIBRARY_PATH: /path/to/my/boost/lib
Executing: /path/to/program  (in /path/to/project/.)


Title: Re: C::B execution paths
Post by: Freem on September 20, 2012, 10:43:21 am
If you enabled full debug logs, you will have, at least when you debug.

note: A 'recent' (2-3 months ago if I am right) modification made compilation logs full by default, but it have not been made for debug, as far as I know (and if your configuration is older it will not change anyway).
But it is doable: I did when having problems with debugger plug-in and wanted to try with command-line ;)
Title: Re: C::B execution paths
Post by: oBFusCATed on September 20, 2012, 08:25:05 pm
note: A 'recent' (2-3 months ago if I am right) modification made compilation logs full by default, but it have not been made for debug, as far as I know (and if your configuration is older it will not change anyway).
Yes, and this won't change in the future, because the log slows down the debugging.
Title: Re: C::B execution paths
Post by: oBFusCATed on September 22, 2012, 02:13:19 pm
I'm playing with this patch: http://cmpt.benbmp.org/codeblocks/patches/path_env_log.patch
And the results are rather strange. The code to set the env variable seems to be executed after the command for launching the program.
I've tried both "Build & Run" and "Run".

Can someone test the patch on windows and paste the log from the "Build log" tab?
Title: Re: C::B execution paths
Post by: MortenMacFly on September 23, 2012, 12:03:51 pm
Can someone test the patch on windows and paste the log from the "Build log" tab?
I'll try, but from what I can say personally: In a private project of mine I had the issue that wxSetEnv is unreliable for some reason. So what I did was the following:
Code
bool mySetEnv(const wxString& name, const wxString& value)
{
  // The WX-way...
  bool success = wxSetEnv(name, value);

  // The MinGW-way...
  wxString putenv_var = name + wxT("=") + value;
#if wxUSE_UNICODE
  std::string stl_putenv_var = (const char*)putenv_var.mb_str(wxConvLocal);
#else
  std::string stl_putenv_var = putenv_var.c_str();
#endif
  char buffer[stl_putenv_var.length()+1]; memset(buffer, 0x00, sizeof(buffer));
  memcpy(buffer, stl_putenv_var.c_str(), stl_putenv_var.length());
  success &= ( putenv(buffer)==0 ); // returns 0 on success
  // success &= ( _putenv(stl_putenv_var.c_str())==0 );

  return success;
}// mySetEnv
...then (and only then!), all my low-level code that relies on envvars being set worked properly. You may face a similar issue here.
Title: Re: C::B execution paths
Post by: oBFusCATed on September 23, 2012, 12:49:07 pm
I don't know it wxSetEnv works, but I think there is a logic error. As the setenv is called after the program (xterm+project executable) is executed. So there is no point in setting LD_LIBRARY_PATH there.
Title: Re: C::B execution paths
Post by: Pecan on September 23, 2012, 02:18:14 pm
...I had the issue that wxSetEnv is unreliable ...

I too found that setting env vars via wxWidgets did *not* work.
Title: Re: C::B execution paths
Post by: MortenMacFly on September 23, 2012, 02:40:39 pm
I too found that setting env vars via wxWidgets did *not* work.
Well sometimes it does, sometimes not. The envvar plugin within C::B works fine for me (as an example) which only used wxSetEnv. However, in my own application when I used it it did not work on Windows... or at least not all the time. I didn't find a pattern and didn't digged further into it, as my work-around (as posted) worked just fine.

but I think there is a logic error
Oh, I see...
Title: Re: C::B execution paths
Post by: oBFusCATed on December 08, 2012, 02:37:25 pm
but I think there is a logic error
Oh, I see...
Any idea how to fix this?