Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: alle_meije on October 14, 2019, 11:51:11 pm

Title: does c::b include .so paths in linux but not .dll paths in windows?
Post by: alle_meije on October 14, 2019, 11:51:11 pm
In a workspace that I use in Linux I have 3 projects (let's call them A, B, and C). Project A and B are shared libraries and B depends on A, and project C is a program linked against A and B. Works like a dream, including 'build workspace', 'rebuild workspace' after which I can run the program from within c::b.

When I try to to the same in Windows, the program does not run because the .dll created from project B is missing.
(very likely if B was found the next problem would be project A's .dll -- that's in its own directory as well)

In Linux I did not externally set the library path to these project's directories and it just worked, but in Windows something extra seems to be needed. Is there a setting I can add so that it will still work if I move the workspace somewhere else? Perhaps in 'program arguments'? 
Title: Re: does c::b include .so paths in linux but not .dll paths in windows?
Post by: stahta01 on October 15, 2019, 12:28:04 am
C::B adds the linker library search path to the PATH used.

Tim S.
Title: Re: does c::b include .so paths in linux but not .dll paths in windows?
Post by: oBFusCATed on October 15, 2019, 10:54:37 am
What fails - Build -> Run or running from the command line/windows explorer?
Title: Re: does c::b include .so paths in linux but not .dll paths in windows?
Post by: alle_meije on October 16, 2019, 11:59:03 am
It's the running that fails in Windows and not in Linux, with the same project files.
Building goes fine because I provide the compiler and linker search directories.
Title: Re: does c::b include .so paths in linux but not .dll paths in windows?
Post by: oBFusCATed on October 16, 2019, 09:15:21 pm
You have not answered my question! So I repeat: what does fail:
1. Build -> Run
2. running from the command line
3. windows explorer
4. all of the above

Please answer with a number!
Title: Re: does c::b include .so paths in linux but not .dll paths in windows?
Post by: alle_meije on October 20, 2019, 04:52:56 pm
No need to get excited. As I thought I had already mentioned, when I run the program from C::B in Linux (using the green triangle) it works.
When I do the same in Windows I get a missing DLL message (see PNG) -- nifti.dll is produced by project B.

The same happens when I call the .exe from the command line in cmd.exe and when I click the .exe in Windows Explorer (so option 4).
What I was wondering was mainly if there's a solution for (1) -- is it possible to make a workspace so that DLLs from separate projects are also found in Windows?
Title: Re: does c::b include .so paths in linux but not .dll paths in windows?
Post by: oBFusCATed on October 20, 2019, 05:37:28 pm
I'm not excited, but if I have to ask the same question twice then it lowers my desire to continue trying to help.

Please post a full rebuild log?
What are you using for linking? By this I mean what kind of file (the log might answer this).
What happens if you place the missing dll next to the exe file?
Title: Re: does c::b include .so paths in linux but not .dll paths in windows?
Post by: alle_meije on October 20, 2019, 08:05:50 pm
Copying the .dll(s) does work but it's annoying that for developing it is necessary in Windows (while it isn't in Linux). I prefer to keep the projects in different directories.

In http://forums.codeblocks.org/index.php?topic=15998.0 (http://forums.codeblocks.org/index.php?topic=15998.0) it was explained that this is a platform issue and other than copying .dll files the best solution was static linking.

Fortunately though that's not necessary! This post http://forums.codeblocks.org/index.php?topic=8061.0 (http://forums.codeblocks.org/index.php?topic=8061.0) shows that the option [project]->[build options]->[linker]->[search directories] basically supplies a library path during 'Run'. It was a bit harder to find because of the alternative terminology, but this is very handy. Although it's not necessary to do this in Linux, having it in the workspace file anyway shouldn't hurt (will test soon)!