Author Topic: C::B linker option generation issue  (Read 5852 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
C::B linker option generation issue
« on: April 24, 2013, 03:22:11 pm »
Hi, when I put a lib name "libcv210.dll.a" in the linker options, I see it generate such command line:  "-lcv210.dll"

Quote
-------------- Build: Debug in jjjjj (compiler: GNU GCC Compiler)---------------

[ 50.0%] g++.exe -g -IE:\code\opencv\opencv210_mingw\include -c E:\project\freescale_image_process\jjjjj\main.cpp -o obj\Debug\main.o
[100.0%] g++.exe -LE:\code\opencv\opencv210_mingw\lib -LE:\code\opencv\opencv210_mingw\bin -o bin\Debug\jjjjj.exe obj\Debug\main.o   -lcv210.dll -lcxcore210.dll -lhighgui210.dll
Output file is bin\Debug\jjjjj.exe with size 443.63 KB
Process terminated with status 0 (0 minute(s), 3 second(s))
0 error(s), 0 warning(s) (0 minute(s), 3 second(s))

But from what I see in MinGW/GCC document:
Quote
For instance, when ld is called with the argument -lxxx it will attempt to find, in the first directory of its search path,

libxxx.dll.a

xxx.dll.a

libxxx.a

cygxxx.dll (*)

libxxx.dll

xxx.dll

before moving on to the next directory in the search path.

I think the command line should be "-lcv210".

Any ideas?


If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9493
Re: C::B linker option generation issue
« Reply #1 on: April 24, 2013, 03:50:59 pm »
I think the command line should be "-lcv210".
Any ideas?
How would you differ between libfoo.dll.a (dynamic import lib) and libfoo.a (static lib) then? I think this is correct.

Also remember that a lot of libs are like libcom.foo.bar.a these days...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: C::B linker option generation issue
« Reply #2 on: April 24, 2013, 03:55:19 pm »
I think the command line should be "-lcv210".
Any ideas?
How would you differ between libfoo.dll.a (dynamic import lib) and libfoo.a (static lib) then? I think this is correct.
I think it is simple, if a library name (libfoo.dll.a) have such format:  have prefix "lib" and suffix "dll.a", then we should use the -lfoo.

Quote
Also remember that a lot of libs are like libcom.foo.bar.a these days...
In these cases, It simply should be: -lcom.foo.bar , as it does not have a suffix "dll.a". ;D
« Last Edit: April 25, 2013, 03:18:00 am by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9493
Re: C::B linker option generation issue
« Reply #3 on: April 24, 2013, 04:39:24 pm »
I think it is simple, if a library name have the format:  have prefix with "lib" and suffix with "dll.a", then we should use the -lfoo.
Maybe I am missing something... but...

Assume you have both of these libs in one folder (which is often the case). You would be unable to address the ".dll" import lib if you remove the DLL automagically. The linker would always pick the static lib.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: C::B linker option generation issue
« Reply #4 on: April 24, 2013, 04:52:42 pm »
Assume you have both of these libs in one folder (which is often the case). You would be unable to address the ".dll" import lib if you remove the DLL automagically. The linker would always pick the static lib.
Ok, Let me explain:

If I have both two libraries libfoo.dll.a (dynamic import library) and libfoo.a(static library) in the same folder.

Then, if user put "libfoo.dll.a" in the C::B linker library input control, then it generate "-lfoo.dll" command, the ld/gcc pick "libfoo.dll.a" as the third rule below, here "xxx" = "foo.dll"

Quote
libxxx.dll.a
xxx.dll.a
libxxx.a
cygxxx.dll (*)
libxxx.dll
xxx.dll

If the user put "libfoo.a" in the C::B library input control, it generate "-lfoo", and follow the rule, it pick "libfoo.dll.a" as it is the first rule, here here "xxx" = "foo", But in this case, the user just want to link to static library?
« Last Edit: April 25, 2013, 03:18:45 am by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11783
    • Travis build status
Re: C::B linker option generation issue
« Reply #5 on: April 24, 2013, 05:33:27 pm »
ollydbg:
So, what is the problem?
If you add "something.dll" in the settings, then "-lsomething.dll" is used for linking.
No automagic needed.

Also why do you have .dll.a files, as far as I know they are useless for GCC?
(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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9493
Re: C::B linker option generation issue
« Reply #6 on: April 24, 2013, 05:55:34 pm »
Also why do you have .dll.a files, as far as I know they are useless for GCC?
Uff... Why?

AFAIK there are libs (like FreeGLUT) that build two types of libs like described. For both builds different #defines are used, i.e. for the generation of the exported functions. Therefore, you have two completely different libs - and if you link against the static lib instead of the dynamic its definitely no what you want?! ???
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11783
    • Travis build status
Re: C::B linker option generation issue
« Reply #7 on: April 24, 2013, 06:03:33 pm »
Because you need libfoo.a (the static lib) and libfoo.dll (the dynamic lib).

What is the purpose of the libfoo.dll.a?
(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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9493
Re: C::B linker option generation issue
« Reply #8 on: April 24, 2013, 06:15:47 pm »
Because you need libfoo.a (the static lib) and libfoo.dll (the dynamic lib).
What is the purpose of the libfoo.dll.a?
Well either some of my project setups are wrong... but... I assumed (maybe until today) that I am linking against libfoo.dll.a if I want to use (and depend on) libfoo.dll and libfoo.a if I won't.

As I said: Their sizes are different and to my knowledge linking against libfoo.dll.a works just fine...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: C::B linker option generation issue
« Reply #9 on: April 25, 2013, 03:53:26 am »
Because you need libfoo.a (the static lib) and libfoo.dll (the dynamic lib).
What is the purpose of the libfoo.dll.a?
Well either some of my project setups are wrong... but... I assumed (maybe until today) that I am linking against libfoo.dll.a if I want to use (and depend on) libfoo.dll and libfoo.a if I won't.

As I said: Their sizes are different and to my knowledge linking against libfoo.dll.a works just fine...
I use OpenCV library, and it supplies dynamic import libraries like libcxcore210.dll.a for cxcore210.dll (mingw build)

ollydbg:
So, what is the problem?
If you add "something.dll" in the settings, then "-lsomething.dll" is used for linking.
No automagic needed.
It looks like there is no problem. But when user see an command line option "-lsomething.dll", they may thought that it will let the LD to directly link to a DLL file, not a dynamic import library. ;D (linking to a dynamic import library is preferred way than direct link to DLL)

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11783
    • Travis build status
Re: C::B linker option generation issue
« Reply #10 on: April 25, 2013, 07:58:22 am »
(linking to a dynamic import library is preferred way than direct link to DLL)
Explanation? Linux is pretty fine without these useless files :)
(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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: C::B linker option generation issue
« Reply #11 on: April 25, 2013, 08:18:46 am »
(linking to a dynamic import library is preferred way than direct link to DLL)
Explanation? Linux is pretty fine without these useless files :)
It takes me about 10 minutes to find a real good answer about this  ;D
http://article.gmane.org/gmane.comp.gnu.mingw.w64.general/6508
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11783
    • Travis build status
Re: C::B linker option generation issue
« Reply #12 on: April 25, 2013, 09:24:06 am »
OK...
It is strange they've bother to make ld link to DLLs directly, then...  :-\
(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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9493
Re: C::B linker option generation issue
« Reply #13 on: April 25, 2013, 06:04:28 pm »
It is strange they've bother to make ld link to DLLs directly, then...  :-\
I believe its done so that you can use MS(VC) DLL's directly, where you have no import lib for, or the MSVC import lib (*.lob) is incompatible... the latter was an issue with older GCC compilers.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ