C::B linker option generation issue

[ollydbg]

Hi, when I put a lib name "libcv210.dll.a" in the linker options, I see it generate such command line:  "-lcv210.dll"

-------------- 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:

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?

[MortenMacFly]

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...

[ollydbg]

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.

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".

[MortenMacFly]

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.

[ollydbg]

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"

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?

[oBFusCATed]

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?

[MortenMacFly]

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?!

[oBFusCATed]

Because you need libfoo.a (the static lib) and libfoo.dll (the dynamic lib).

What is the purpose of the libfoo.dll.a?

[MortenMacFly]

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...

[ollydbg]

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. (linking to a dynamic import library is preferred way than direct link to DLL)

[oBFusCATed]

(linking to a dynamic import library is preferred way than direct link to DLL)

Explanation? Linux is pretty fine without these useless files

[ollydbg]

(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 
http://article.gmane.org/gmane.comp.gnu.mingw.w64.general/6508

[oBFusCATed]

OK...
It is strange they've bother to make ld link to DLLs directly, then... 

[MortenMacFly]

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.