g++ prefers to link against LIB instead of DLL

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

g++ prefers to link against LIB instead of DLL

Juan Navarro
Hello all,

I'm facing an unexpected problem: linker gets the wrong library file,
or at least not the one I expected.
My line is like this: -Lmylibdir -lglew32

And in mylibdir/ there are 2 files which come from the GLEW project
(http://glew.sourceforge.net/) binary files: glew32.lib and
glew32.dll.
glew32.lib is just a library hook (aka. import library) used by MSVC,
and glew32.dll is the actual library to be linked.
Both files are in the "mylibdir" directory, which includes a bunch of
libraries used for both compiling with MinGW GCC and MSVC.

The problem is that -lglew32 is picking automatically the wrong file.
It tries to link against glew32.lib, and it fails. But if I delete or
remove it, then the good one is chosen, and linking against glew32.dll
succeeds.

Is this the expected way of working for the linker in MinGW?

This wiki page explains that MinGW supports this way of linking files:
http://www.mingw.org/category/wiki/link
but it doesn't say a word about what is the preference in case of
having both types of files, and how to change that preference.

Please hint me about this problem, as the GLEW libraries do not provide a "
libglew32.a" import library (which I assume would make gcc to link to the expected file, but I'm just guessing).

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: g++ prefers to link against LIB instead of DLL

Eli Zaretskii
> Date: Wed, 6 Mar 2013 18:28:42 +0100
> From: Juan Navarro <[hidden email]>
>
> I'm facing an unexpected problem: linker gets the wrong library file,
> or at least not the one I expected.
> My line is like this: -Lmylibdir -lglew32
>
> And in mylibdir/ there are 2 files which come from the GLEW project
> (http://glew.sourceforge.net/) binary files: glew32.lib and
> glew32.dll.
> glew32.lib is just a library hook (aka. import library) used by MSVC,
> and glew32.dll is the actual library to be linked.
> Both files are in the "mylibdir" directory, which includes a bunch of
> libraries used for both compiling with MinGW GCC and MSVC.
>
> The problem is that -lglew32 is picking automatically the wrong file.
> It tries to link against glew32.lib, and it fails. But if I delete or
> remove it, then the good one is chosen, and linking against glew32.dll
> succeeds.
>
> Is this the expected way of working for the linker in MinGW?
>
> This wiki page explains that MinGW supports this way of linking files:
> http://www.mingw.org/category/wiki/link
> but it doesn't say a word about what is the preference in case of
> having both types of files, and how to change that preference.

>From the ld manual:

  [...] 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
            xxx.lib
            cygxxx.dll (*)
            libxxx.dll
            xxx.dll


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

So yes, what you see is the expected behavior.

Since you want to link against the DLL directly, not through an import
library, just mention the DLL name explicitly on the link command
line, as glew32.dll.  Then glew32.lib will not be found (untested).

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: g++ prefers to link against LIB instead of DLL

Juan Navarro
In reply to this post by Juan Navarro
Hi,

Eli Zaretskii:
I see then why the .lib file gets precedence; just stating the file
name seems to not find the file (I'll check more on this). Anyways I
think it should work as I'm using it now, because it works for other
similar files (see below).

NightStrike:
I'm using the MinGW-builds_64bit-4.7.2-posix-sjlj-rev9 package, as
that is the recommended by the Qt team for compilation under Windows.

I don't get to understand the reasons for this problem, because in the
same directory there are some other libs with same name in the DLL and
the LIB files (such as ftgl.dll/ftgl.lib, or
ltcsmpte.dll/ltcsmpte.lib), but they link without any problem. It is
just the glew32.dll/glew32.lib ones that fail. By now I have tried
both their binary package and compiling the source package offered in
the website (I'm using Visual Studio 2012), but the problem remains.

Also, scanning the glew32.lib with this command:
lib /list glew32.lib
reveals that it is actually an import lib, not a static library, so
all seems fine in this respect.

Please indicate any other test or command I should try to narrow the
search; if it is a bug in that specific library I'd like to report it
in their tracking systems, but right now I have no clue about the
issue.

Thank you,
Juan


On Wed, Mar 6, 2013 at 6:57 PM, NightStrike <[hidden email]> wrote:

>
> Juan,
>
> Did you resolve your issue?  Is there any way you can try your compile
> out using mingw-w64.sf.net?  I'd appreciate the compiler test if
> nothing else.  We support both 32-bit and 64-bit compiling.
>
> ---------- Forwarded message ----------
> From: Juan Navarro <[hidden email]>
> Date: Wed, Mar 6, 2013 at 12:28 PM
> Subject: [Mingw-users] g++ prefers to link against LIB instead of DLL
> To: [hidden email]
>
>
> Hello all,
>
> I'm facing an unexpected problem: linker gets the wrong library file,
> or at least not the one I expected.
> My line is like this: -Lmylibdir -lglew32
>
> And in mylibdir/ there are 2 files which come from the GLEW project
> (http://glew.sourceforge.net/) binary files: glew32.lib and
> glew32.dll.
> glew32.lib is just a library hook (aka. import library) used by MSVC,
> and glew32.dll is the actual library to be linked.
> Both files are in the "mylibdir" directory, which includes a bunch of
> libraries used for both compiling with MinGW GCC and MSVC.
>
> The problem is that -lglew32 is picking automatically the wrong file.
> It tries to link against glew32.lib, and it fails. But if I delete or
> remove it, then the good one is chosen, and linking against glew32.dll
> succeeds.
>
> Is this the expected way of working for the linker in MinGW?
>
> This wiki page explains that MinGW supports this way of linking files:
> http://www.mingw.org/category/wiki/link
> but it doesn't say a word about what is the preference in case of
> having both types of files, and how to change that preference.
>
> Please hint me about this problem, as the GLEW libraries do not
> provide a "libglew32.a" import library (which I assume would make gcc
> to link to the expected file, but I'm just guessing).
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list
> etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:[hidden email]?subject=unsubscribe

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: g++ prefers to link against LIB instead of DLL

Gisle Vanem-2
"Juan Navarro" <[hidden email]> wrote:

> Also, scanning the glew32.lib with this command:
> lib /list glew32.lib
> reveals that it is actually an import lib, not a static library, so
> all seems fine in this respect.

An import-lib is what you should link to IMHO. Not the DLL directly.
Imagine someone after 10 years is trying to figure out what you were
thinking then? Confused, not me. Use an explicit link command:
  ./mylibdir/glew32.lib

Then there should be no doubt. Please tell me (or someone else) what
advantage the GNU-kludge has over an explicit linkage?

--gv

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: g++ prefers to link against LIB instead of DLL

Manolo
In reply to this post by Juan Navarro
Just two ideas:

1) Did you downloaded 32 or 64 bits glew libs?

2) Don't bother with glew libs. Just use it statically:
   add glew.c to your project files
   add glew.h and wglew.h to your path
   #include glew.h the first
   #define GLEW_STATIC
   use glewExperimental = GL_TRUE before glewInit() but after creating
   your rendering context
It's so tiny that can't be harmful.



------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: g++ prefers to link against LIB instead of DLL

Eli Zaretskii
In reply to this post by Gisle Vanem-2
> From: Gisle Vanem <[hidden email]>
> Date: Wed, 06 Mar 2013 21:40:29 +0100
>
> Please tell me (or someone else) what advantage the GNU-kludge has
> over an explicit linkage?

If you mean the advantage of using -lFOO vs /some/path/foo.dll on the
link command line, then the advantage is that the command line doesn't
change when you upgrade from foo-1.dll to a newer version foo-42.dll,
since the import library still goes by the same name libfoo.dll.a.
Also, you can switch between static and dynamic link very easily, just
say "make LDFLAGS=-Bstatic" or some such.

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: g++ prefers to link against LIB instead of DLL

Kai Tietz-2
2013/3/6 Eli Zaretskii <[hidden email]>:

>> From: Gisle Vanem <[hidden email]>
>> Date: Wed, 06 Mar 2013 21:40:29 +0100
>>
>> Please tell me (or someone else) what advantage the GNU-kludge has
>> over an explicit linkage?
>
> If you mean the advantage of using -lFOO vs /some/path/foo.dll on the
> link command line, then the advantage is that the command line doesn't
> change when you upgrade from foo-1.dll to a newer version foo-42.dll,
> since the import library still goes by the same name libfoo.dll.a.
> Also, you can switch between static and dynamic link very easily, just
> say "make LDFLAGS=-Bstatic" or some such.

The real issue why people shouldn't link directly against .dll-files
is that for disabled pseudo-relocation you will run into serious
troubles for variables.
Another very good reason for not relying on physical DLL file is the
cross-compiling scenario.  In general you just need the
import-definition of the library, which actual is expressed in an
import-library.

The extensions .a and .lib are reserved for libraries and have to be
*always* searched before .dll files.  To specify the .dll file as
argument for linking is actual the kludge here.  A DLL is not a ELF
.so file.  And .so is a shared-library made out of single
object-files. A .dll is already a finally linked binary-image, and not
an archive of object-files anymore.  Mixing here ELF semantics into
PE-COFF world is actual the mistake here.

Kai

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: g++ prefers to link against LIB instead of DLL

Eli Zaretskii
> Date: Wed, 6 Mar 2013 22:26:39 +0100
> From: Kai Tietz <[hidden email]>
>
> The extensions .a and .lib are reserved for libraries and have to be
> *always* searched before .dll files.  To specify the .dll file as
> argument for linking is actual the kludge here.  A DLL is not a ELF
> .so file.  And .so is a shared-library made out of single
> object-files. A .dll is already a finally linked binary-image, and not
> an archive of object-files anymore.

I agree (and didn't say anything that could contradict this).  But
sometimes, you have no choice but to link against a DLL, e.g., if no
import library is available.

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: g++ prefers to link against LIB instead of DLL

Kai Tietz-2
2013/3/6 Eli Zaretskii <[hidden email]>:

>> Date: Wed, 6 Mar 2013 22:26:39 +0100
>> From: Kai Tietz <[hidden email]>
>>
>> The extensions .a and .lib are reserved for libraries and have to be
>> *always* searched before .dll files.  To specify the .dll file as
>> argument for linking is actual the kludge here.  A DLL is not a ELF
>> .so file.  And .so is a shared-library made out of single
>> object-files. A .dll is already a finally linked binary-image, and not
>> an archive of object-files anymore.
>
> I agree (and didn't say anything that could contradict this).  But
> sometimes, you have no choice but to link against a DLL, e.g., if no
> import library is available.

Well, you have always a choice.  If it is possible to link directly
against a DLL file, then it is always possible to generate a
*satisfying* .def file for it, too.  You can use for this tools like
peexport, or gendef, which are actual doing a pretty good job for it.
By this .def file you can generate via dlltool the required
import-library.  The only thing I agree here is that it is sometimes
just easier to link directly against a DLL as you avoid all these
steps :)

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe