Menu
▾
▴
mingw-users
|
From: Jason J. <jia...@gm...> - 2010-01-17 09:36:44
|
Dear developers,
I am working on a private project which is to create a Windows DLL that
communicate with USB device through libusb-win32. The project is managed by
automake/autoconf.
The problem is that source codes are compiled OK, but the objects can not be
linked to a DLL. When linking, libtool report that there are undefined
resolves, so it cannot link a Windows DLL, but to link a static library. The
warning message is
/bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -Os -g
> -DNDEBUG
-D__USE_MINGW_ANSI_STDIO -no-undefined -version-info 0:1:0 -g -o
> libsimplefoo.
la -rpath /usr/local/lib simplefoo.lo foo.lo log.lo -lws2_32 -lusb
> *** Warning: linker path does not have real file for library -lws2_32.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libws2_32 and none of the candidates passed a file format test
*** using a file magic. Last file checked: c:/mingw/lib/libws2_32.a
> *** Warning: linker path does not have real file for library -lusb.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libusb and none of the candidates passed a file format test
*** using a file magic. Last file checked: c:/mingw/lib/libusb.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
> *** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
libtool: link: ar cru .libs/libsimplefoo.a simplefoo.o foo.o log.o
libtool: link: ranlib .libs/libsimplefoo.a
libtool: link: ( cd ".libs" && rm -f "libsimplefoo.la" && ln -s "../
> libsimplefoo.la" "libsimplefoo.la" )
make[2]: Leaving directory `/d/wrkspc/simplefoo/simplefoo-lib/src'
make[2]: Entering directory `/d/wrkspc/simplefoo/simplefoo-lib'
make[2]: Leaving directory `/d/wrkspc/simplefoo/simplefoo-lib'
make[1]: Leaving directory `/d/wrkspc/simplefoo/simplefoo-lib'
The source code using ntohl() and libusb-win32 APIs, so I think I should
add -lws2_32 and -lusb to linker command. Here is the Makefile.am in the
project's src directory.
## Process this file with automake to produce Makefile.in.
> lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = foo.c \
simplefoo.c \
log.c
libfoo_la_LDFLAGS = -no-undefined -version-info 0:1:0
libfoo_la_LIBADD = $(MINGWLIBADD) $(LIBUSB)
> if IS_MINGW
MINGWLIBADD = -lws2_32
else
MINGWLIBADD =
endif
> if LIBUSB
LDUSB = -lusb
endif
Could anyone give me some advice on how to solve the linker problem to
create a DLL ?
--------------------
Best Regards
Jason JIANG
|
|
From: Vincent T. <vt...@un...> - 2010-01-17 09:56:38
|
On Sun, 17 Jan 2010, Jason JIANG wrote: > Dear developers, > > I am working on a private project which is to create a Windows DLL that > communicate with USB device through libusb-win32. The project is managed by > automake/autoconf. and libtool too > > The problem is that source codes are compiled OK, but the objects can not be > linked to a DLL. When linking, libtool report that there are undefined > resolves, so it cannot link a Windows DLL, but to link a static library. The > warning message is > > la -rpath /usr/local/lib simplefoo.lo foo.lo log.lo -lws2_32 -lusb > > >> *** Warning: linker path does not have real file for library -lws2_32. did you tell libtool to deal with DLL's ? That is either: 1) if you use AC_PROG_LIBTOOL, put *before* it the macro AC_LIBTOOL_WIN32_DLL 2) or if you use LT_INIT, pass win32-dll (see libtool doc) If it does not work, i know that i had problems like that with old versions of libtool. I use the latest one with mingw (2.2.6b iirc), using the winsock2 lib, and i can create DLL's Vincent Torri |
|
From: JonY <jo...@us...> - 2010-01-17 10:01:08
|
On 1/17/2010 17:36, Jason JIANG wrote: > > Could anyone give me some advice on how to solve the linker problem to > create a DLL ? > -------------------- > Best Regards > Jason JIANG > Hi, libtool is being overzealous in checking the link libs. You can try changing deplibs_check_method to "pass_all" in the libtool script. |
|
From: Sisyphus <sis...@op...> - 2010-01-17 10:43:27
|
----- Original Message ----- From: "Jason JIANG" <jia...@gm...> To: <min...@li...> > >> *** Warning: linker path does not have real file for library -lws2_32. > > *** I have the capability to make that library automatically link in when > > *** you link to this library. But I can only do this if you have a > > *** shared version of the library, which you do not appear to have > > *** because I did check the linker path looking for a file starting > > *** with libws2_32 and none of the candidates passed a file format test > > *** using a file magic. Last file checked: c:/mingw/lib/libws2_32.a I had essentially the same experience building freeglut - it kept looking for a "file starting with libgdi32". Eventually it occurred to me to try creating a copy of C:/Windows/System32/gdi32.dll named C:/Windows/System32/libgdi32.dll ... and that hack worked !! On the basis of that (and assuming you can run as Administrator), try creating a copy of your system's ws2_32.dll named libws2_32.dll (in the same directory). If that works, well and good ... if not, must be sumpin else :-) Cheers, Rob |
|
From: LRN <lr...@gm...> - 2010-01-17 11:34:43
|
On 17.01.2010 13:42, Sisyphus wrote: > ----- Original Message ----- > From: "Jason JIANG" <jia...@gm...> > To: <min...@li...> > > >> >>> *** Warning: linker path does not have real file for library -lws2_32. >>> >> *** I have the capability to make that library automatically link in when >> >> *** you link to this library. But I can only do this if you have a >> >> *** shared version of the library, which you do not appear to have >> >> *** because I did check the linker path looking for a file starting >> >> *** with libws2_32 and none of the candidates passed a file format test >> >> *** using a file magic. Last file checked: c:/mingw/lib/libws2_32.a >> > I had essentially the same experience building freeglut - it kept looking > for a "file starting with libgdi32". Eventually it occurred to me to try > creating a copy of C:/Windows/System32/gdi32.dll named > C:/Windows/System32/libgdi32.dll ... and that hack worked !! > > On the basis of that (and assuming you can run as Administrator), try > creating a copy of your system's ws2_32.dll named libws2_32.dll (in the same > directory). If that works, well and good ... if not, must be sumpin else :-) > > I prefer to create a special lib*.la in lib subdirectory instead. Did that for libdxgui.a (which doesn't have a corresponding .dll) and it worked just fine. The secret is to have dlname='' and both library_names and old_library = 'lib*.a' (not .dll.a) > Cheers, > Rob > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > 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 > |
|
From: Vincent T. <vt...@un...> - 2010-01-17 11:54:16
|
On Sun, 17 Jan 2010, LRN wrote: > On 17.01.2010 13:42, Sisyphus wrote: >> ----- Original Message ----- >> From: "Jason JIANG" <jia...@gm...> >> To: <min...@li...> >> >> >>> >>>> *** Warning: linker path does not have real file for library -lws2_32. >>>> >>> *** I have the capability to make that library automatically link in when >>> >>> *** you link to this library. But I can only do this if you have a >>> >>> *** shared version of the library, which you do not appear to have >>> >>> *** because I did check the linker path looking for a file starting >>> >>> *** with libws2_32 and none of the candidates passed a file format test >>> >>> *** using a file magic. Last file checked: c:/mingw/lib/libws2_32.a >>> >> I had essentially the same experience building freeglut - it kept looking >> for a "file starting with libgdi32". Eventually it occurred to me to try >> creating a copy of C:/Windows/System32/gdi32.dll named >> C:/Windows/System32/libgdi32.dll ... and that hack worked !! both should work : http://sourceware.org/binutils/docs/ld/WIN32.html see "direct linking to a dll" section. >> >> On the basis of that (and assuming you can run as Administrator), try >> creating a copy of your system's ws2_32.dll named libws2_32.dll (in the same >> directory). If that works, well and good ... if not, must be sumpin else :-) >> >> > I prefer to create a special lib*.la in lib subdirectory instead. Did > that for libdxgui.a (which doesn't have a corresponding .dll) and it > worked just fine. The secret is to have dlname='' and both library_names > and old_library = 'lib*.a' (not .dll.a) i don't need to do such hack to make libtool working with winsock2. Updrage libtool, verifiy that libtool is aware of dll built, no-undefined must be passed to libtool ldflags variable (that is already done by the OP) ; it should be sufficient. Vincent Torri |
|
From: LRN <lr...@gm...> - 2010-01-17 12:32:56
|
On 17.01.2010 14:54, Vincent Torri wrote: > > On Sun, 17 Jan 2010, LRN wrote: > > >> On 17.01.2010 13:42, Sisyphus wrote: >> >>> ----- Original Message ----- >>> From: "Jason JIANG" <jia...@gm...> >>> To: <min...@li...> >>> >>> >>> >>>> >>>>> *** Warning: linker path does not have real file for library -lws2_32. >>>>> >>>>> >>>> *** I have the capability to make that library automatically link in when >>>> >>>> *** you link to this library. But I can only do this if you have a >>>> >>>> *** shared version of the library, which you do not appear to have >>>> >>>> *** because I did check the linker path looking for a file starting >>>> >>>> *** with libws2_32 and none of the candidates passed a file format test >>>> >>>> *** using a file magic. Last file checked: c:/mingw/lib/libws2_32.a >>>> >>>> >>> I had essentially the same experience building freeglut - it kept looking >>> for a "file starting with libgdi32". Eventually it occurred to me to try >>> creating a copy of C:/Windows/System32/gdi32.dll named >>> C:/Windows/System32/libgdi32.dll ... and that hack worked !! >>> > both should work : > > http://sourceware.org/binutils/docs/ld/WIN32.html > > see "direct linking to a dll" section. > > >>> On the basis of that (and assuming you can run as Administrator), try >>> creating a copy of your system's ws2_32.dll named libws2_32.dll (in the same >>> directory). If that works, well and good ... if not, must be sumpin else :-) >>> >>> >>> >> I prefer to create a special lib*.la in lib subdirectory instead. Did >> that for libdxgui.a (which doesn't have a corresponding .dll) and it >> worked just fine. The secret is to have dlname='' and both library_names >> and old_library = 'lib*.a' (not .dll.a) >> > i don't need to do such hack to make libtool working with winsock2. > Updrage libtool, verifiy that libtool is aware of dll built, no-undefined > must be passed to libtool ldflags variable (that is already done by the > OP) ; it should be sufficient. > For winsock2 - yes, because you have actual ws2_32.dll in your system32 subdirectory (and myself, i never had any problems in linking with -lws2_32). But for some other libraries (such as the ones that i've named) that might not be sufficient. > Vincent Torri > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > 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 > |
|
From: Vincent T. <vt...@un...> - 2010-01-17 13:50:38
|
On Sun, 17 Jan 2010, LRN wrote: > On 17.01.2010 14:54, Vincent Torri wrote: >> >> On Sun, 17 Jan 2010, LRN wrote: >>> I prefer to create a special lib*.la in lib subdirectory instead. Did >>> that for libdxgui.a (which doesn't have a corresponding .dll) and it >>> worked just fine. The secret is to have dlname='' and both library_names >>> and old_library = 'lib*.a' (not .dll.a) >>> >> i don't need to do such hack to make libtool working with winsock2. >> Updrage libtool, verifiy that libtool is aware of dll built, no-undefined >> must be passed to libtool ldflags variable (that is already done by the >> OP) ; it should be sufficient. >> > For winsock2 - yes, because you have actual ws2_32.dll in your system32 > subdirectory (and myself, i never had any problems in linking with > -lws2_32). But for some other libraries (such as the ones that i've > named) that might not be sufficient. it's not a problem of having or not a dll. It's a problem of libtool not doing correctly its job. For example : libiberty.a. I have no problem when i pass -liberty during the link. Look in ltmain.sh, the function func_win32_libid() Vincent Torri |
|
From: LRN <lr...@gm...> - 2010-01-17 14:30:48
|
On 17.01.2010 15:28, Vincent Torri wrote: > > > On Sun, 17 Jan 2010, LRN wrote: > >> On 17.01.2010 14:54, Vincent Torri wrote: >>> >>> On Sun, 17 Jan 2010, LRN wrote: >>>> I prefer to create a special lib*.la in lib subdirectory instead. Did >>>> that for libdxgui.a (which doesn't have a corresponding .dll) and it >>>> worked just fine. The secret is to have dlname='' and both >>>> library_names >>>> and old_library = 'lib*.a' (not .dll.a) >>>> >>> i don't need to do such hack to make libtool working with winsock2. >>> Updrage libtool, verifiy that libtool is aware of dll built, >>> no-undefined >>> must be passed to libtool ldflags variable (that is already done by the >>> OP) ; it should be sufficient. >>> >> For winsock2 - yes, because you have actual ws2_32.dll in your system32 >> subdirectory (and myself, i never had any problems in linking with >> -lws2_32). But for some other libraries (such as the ones that i've >> named) that might not be sufficient. > > it's not a problem of having or not a dll. It's a problem of libtool > not doing correctly its job. For example : libiberty.a. I have no > problem when i pass -liberty during the link. > Are you linking -liberty to an executable or to a library? > Look in ltmain.sh, the function func_win32_libid() > > Vincent Torri |
|
From: Vincent T. <vt...@un...> - 2010-01-17 14:38:20
|
On Sun, 17 Jan 2010, LRN wrote: > On 17.01.2010 15:28, Vincent Torri wrote: >> >> >> On Sun, 17 Jan 2010, LRN wrote: >> >>> On 17.01.2010 14:54, Vincent Torri wrote: >>>> >>>> On Sun, 17 Jan 2010, LRN wrote: >>>>> I prefer to create a special lib*.la in lib subdirectory instead. Did >>>>> that for libdxgui.a (which doesn't have a corresponding .dll) and it >>>>> worked just fine. The secret is to have dlname='' and both >>>>> library_names >>>>> and old_library = 'lib*.a' (not .dll.a) >>>>> >>>> i don't need to do such hack to make libtool working with winsock2. >>>> Updrage libtool, verifiy that libtool is aware of dll built, >>>> no-undefined >>>> must be passed to libtool ldflags variable (that is already done by the >>>> OP) ; it should be sufficient. >>>> >>> For winsock2 - yes, because you have actual ws2_32.dll in your system32 >>> subdirectory (and myself, i never had any problems in linking with >>> -lws2_32). But for some other libraries (such as the ones that i've >>> named) that might not be sufficient. >> >> it's not a problem of having or not a dll. It's a problem of libtool >> not doing correctly its job. For example : libiberty.a. I have no >> problem when i pass -liberty during the link. >> > Are you linking -liberty to an executable or to a library? a library. Vincent Torri |
|
From: LRN <lr...@gm...> - 2010-01-17 14:52:02
|
On 17.01.2010 17:38, Vincent Torri wrote: > > > On Sun, 17 Jan 2010, LRN wrote: > >> On 17.01.2010 15:28, Vincent Torri wrote: >>> >>> >>> On Sun, 17 Jan 2010, LRN wrote: >>> >>>> On 17.01.2010 14:54, Vincent Torri wrote: >>>>> >>>>> On Sun, 17 Jan 2010, LRN wrote: >>>>>> I prefer to create a special lib*.la in lib subdirectory instead. >>>>>> Did >>>>>> that for libdxgui.a (which doesn't have a corresponding .dll) and it >>>>>> worked just fine. The secret is to have dlname='' and both >>>>>> library_names >>>>>> and old_library = 'lib*.a' (not .dll.a) >>>>>> >>>>> i don't need to do such hack to make libtool working with winsock2. >>>>> Updrage libtool, verifiy that libtool is aware of dll built, >>>>> no-undefined >>>>> must be passed to libtool ldflags variable (that is already done >>>>> by the >>>>> OP) ; it should be sufficient. >>>>> >>>> For winsock2 - yes, because you have actual ws2_32.dll in your >>>> system32 >>>> subdirectory (and myself, i never had any problems in linking with >>>> -lws2_32). But for some other libraries (such as the ones that i've >>>> named) that might not be sufficient. >>> >>> it's not a problem of having or not a dll. It's a problem of libtool >>> not doing correctly its job. For example : libiberty.a. I have no >>> problem when i pass -liberty during the link. >>> >> Are you linking -liberty to an executable or to a library? > > a library. > Then why am i getting *** Warning: linker path does not have real file for library -liberty. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libiberty and none of the candidates passed a file format test *** using a file magic. Last file checked: /mingw/lib/libiberty.a and you don't? :-\ > Vincent Torri |
|
From: Roumen P. <bug...@ro...> - 2010-01-17 16:11:23
|
LRN wrote: > On 17.01.2010 17:38, Vincent Torri wrote: [SNIP] > Then why am i getting > *** Warning: linker path does not have real file for library -liberty. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have > *** because I did check the linker path looking for a file starting > *** with libiberty and none of the candidates passed a file format test > *** using a file magic. Last file checked: /mingw/lib/libiberty.a > and you don't? :-\ [SNIP] May be because import library is installed in one of the paths returned from "gcc --print-search-dirs" Roumen |
|
From: LRN <lr...@gm...> - 2010-01-17 17:39:48
|
On 17.01.2010 19:11, Roumen Petrov wrote: > LRN wrote: > >> On 17.01.2010 17:38, Vincent Torri wrote: >> > [SNIP] > > >> Then why am i getting >> *** Warning: linker path does not have real file for library -liberty. >> *** I have the capability to make that library automatically link in when >> *** you link to this library. But I can only do this if you have a >> *** shared version of the library, which you do not appear to have >> *** because I did check the linker path looking for a file starting >> *** with libiberty and none of the candidates passed a file format test >> *** using a file magic. Last file checked: /mingw/lib/libiberty.a >> and you don't? :-\ >> > [SNIP] > > May be because import library is not installed in one of the paths returned > from "gcc --print-search-dirs" > $ gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012 libraries: f:/mingw/lib/gcc/mingw32/4.4.0/ f:/mingw/lib/gcc/ /usr/lib/gcc/mingw32/4.4.0/ f:/mingw/mingw32/lib/mingw32/4.4.0/ f:/mingw/mingw32/lib/ f:/mingw/lib/mingw32/4.4.0/ f:/mingw/lib/ /mingw/lib/mingw32/4.4.0/ /mingw/lib/ So, as you can see, /lib subdirectory is in the library search path. I still think that this is exactly how libtool is supposed to work - it refuses to link a dll against a static library. As far as i remember, this is exactly what libtool developers wanted, because things may get ugly otherwise. What i don't understand is why it lets Vincent Torri to get away with such linking. Maybe there is a magic option somewhere that i don't know of? |
|
From: Roumen P. <bug...@ro...> - 2010-01-18 22:17:00
|
LRN wrote: [SNIP] > I still think that this is exactly how libtool is supposed to work - it > refuses to link a dll against a static library. As far as i remember, > this is exactly what libtool developers wanted, because things may get > ugly otherwise. yes for shared libraries, no for applications. > What i don't understand is why it lets Vincent Torri to get away with > such linking. Maybe there is a magic option somewhere that i don't know of? As example you could use -Wl,-liberty added to XXX_la_LDFLAGS. Roumen |
|
From: LRN <lr...@gm...> - 2010-01-17 16:36:50
|
On 17.01.2010 19:11, Roumen Petrov wrote: > LRN wrote: > >> On 17.01.2010 17:38, Vincent Torri wrote: >> > [SNIP] > > >> Then why am i getting >> *** Warning: linker path does not have real file for library -liberty. >> *** I have the capability to make that library automatically link in when >> *** you link to this library. But I can only do this if you have a >> *** shared version of the library, which you do not appear to have >> *** because I did check the linker path looking for a file starting >> *** with libiberty and none of the candidates passed a file format test >> *** using a file magic. Last file checked: /mingw/lib/libiberty.a >> and you don't? :-\ >> > [SNIP] > > May be because import library is installed in one of the paths returned > from "gcc --print-search-dirs" > > That is not very enlightening. |
|
From: Roumen P. <bug...@ro...> - 2010-01-17 17:27:32
|
LRN wrote: > On 17.01.2010 19:11, Roumen Petrov wrote: >> LRN wrote: >> >>> On 17.01.2010 17:38, Vincent Torri wrote: >>> >> [SNIP] >> >> >>> Then why am i getting >>> *** Warning: linker path does not have real file for library -liberty. >>> *** I have the capability to make that library automatically link in when >>> *** you link to this library. But I can only do this if you have a >>> *** shared version of the library, which you do not appear to have >>> *** because I did check the linker path looking for a file starting >>> *** with libiberty and none of the candidates passed a file format test >>> *** using a file magic. Last file checked: /mingw/lib/libiberty.a >>> and you don't? :-\ >>> >> [SNIP] >> >> May be because import library is installed in one of the paths returned >> from "gcc --print-search-dirs" >> >> > That is not very enlightening. > subst /is/is not/ |
|
From: Vincent T. <vt...@un...> - 2010-01-17 20:38:25
|
On Sun, 17 Jan 2010, LRN wrote: > On 17.01.2010 19:11, Roumen Petrov wrote: >> LRN wrote: >> >>> On 17.01.2010 17:38, Vincent Torri wrote: >>> >> [SNIP] >> >> >>> Then why am i getting >>> *** Warning: linker path does not have real file for library -liberty. >>> *** I have the capability to make that library automatically link in when >>> *** you link to this library. But I can only do this if you have a >>> *** shared version of the library, which you do not appear to have >>> *** because I did check the linker path looking for a file starting >>> *** with libiberty and none of the candidates passed a file format test >>> *** using a file magic. Last file checked: /mingw/lib/libiberty.a >>> and you don't? :-\ >>> >> [SNIP] >> >> May be because import library is not installed in one of the paths returned >> from "gcc --print-search-dirs" >> > $ gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t > 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012 > libraries: > f:/mingw/lib/gcc/mingw32/4.4.0/ > f:/mingw/lib/gcc/ > /usr/lib/gcc/mingw32/4.4.0/ > f:/mingw/mingw32/lib/mingw32/4.4.0/ > f:/mingw/mingw32/lib/ > f:/mingw/lib/mingw32/4.4.0/ > f:/mingw/lib/ > /mingw/lib/mingw32/4.4.0/ > /mingw/lib/ > > So, as you can see, /lib subdirectory is in the library search path. > I still think that this is exactly how libtool is supposed to work - it > refuses to link a dll against a static library. As far as i remember, > this is exactly what libtool developers wanted, because things may get > ugly otherwise. > What i don't understand is why it lets Vincent Torri to get away with > such linking. Maybe there is a magic option somewhere that i don't know of? because libtool recognise libiberty.a as an import lib and does its job. i think that you should port on the libtool ML for more informations. I'm not a libtool gourou :-) Vincent Torri |
|
From: Charles W. <cwi...@us...> - 2010-01-18 00:57:05
|
Vincent Torri wrote: > because libtool recognise libiberty.a as an import lib and does its job. > > i think that you should port on the libtool ML for more informations. I'm > not a libtool gourou :-) Unless Vincent has done something very special, libiberty.a is a static library. libiberty is not normally built as a DLL, and so does not usually have an accompanying import library. Frankly, I'm not sure WHY Vincent can successfully link a DLL which depends on libiberty.a -- I think it would probably be classed as a BUG by the libtool devs, even tho Vincent is happy with the result. -- Chuck |
|
From: Jason J. <jia...@gm...> - 2010-01-18 15:46:22
|
LRN, I have also tested your method by creating a special la file, and tried to link to the .la instead of the DLL. It works well. This is a good solution. Thank you very much. -------------------- Best Regards Jason JIANG On Sun, Jan 17, 2010 at 7:34 PM, LRN <lr...@gm...> wrote: > On 17.01.2010 13:42, Sisyphus wrote: > > ----- Original Message ----- > > From: "Jason JIANG" <jia...@gm...> > > To: <min...@li...> > > > > > >> > >>> *** Warning: linker path does not have real file for library -lws2_32. > >>> > >> *** I have the capability to make that library automatically link in > when > >> > >> *** you link to this library. But I can only do this if you have a > >> > >> *** shared version of the library, which you do not appear to have > >> > >> *** because I did check the linker path looking for a file starting > >> > >> *** with libws2_32 and none of the candidates passed a file format test > >> > >> *** using a file magic. Last file checked: c:/mingw/lib/libws2_32.a > >> > > I had essentially the same experience building freeglut - it kept looking > > for a "file starting with libgdi32". Eventually it occurred to me to try > > creating a copy of C:/Windows/System32/gdi32.dll named > > C:/Windows/System32/libgdi32.dll ... and that hack worked !! > > > > On the basis of that (and assuming you can run as Administrator), try > > creating a copy of your system's ws2_32.dll named libws2_32.dll (in the > same > > directory). If that works, well and good ... if not, must be sumpin else > :-) > > > > > I prefer to create a special lib*.la in lib subdirectory instead. Did > that for libdxgui.a (which doesn't have a corresponding .dll) and it > worked just fine. The secret is to have dlname='' and both library_names > and old_library = 'lib*.a' (not .dll.a) > > Cheers, > > Rob > > > > > > > ------------------------------------------------------------------------------ > > Throughout its 18-year history, RSA Conference consistently attracts the > > world's best and brightest in the field, creating opportunities for > Conference > > attendees to learn about information security's most important issues > through > > interactions with peers, luminaries and emerging and established > companies. > > http://p.sf.net/sfu/rsaconf-dev2dev > > _______________________________________________ > > MinGW-users mailing list > > Min...@li... > > > > 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 > > > > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > 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 > |
|
From: Jason J. <jia...@gm...> - 2010-01-18 15:03:45
|
Thank you very much :) I had tested your method, and it works. -------------------- Best Regards Jason JIANG On Sun, Jan 17, 2010 at 6:42 PM, Sisyphus <sis...@op...> wrote: > > ----- Original Message ----- > From: "Jason JIANG" <jia...@gm...> > To: <min...@li...> > > > > >> *** Warning: linker path does not have real file for library -lws2_32. > > > > *** I have the capability to make that library automatically link in when > > > > *** you link to this library. But I can only do this if you have a > > > > *** shared version of the library, which you do not appear to have > > > > *** because I did check the linker path looking for a file starting > > > > *** with libws2_32 and none of the candidates passed a file format test > > > > *** using a file magic. Last file checked: c:/mingw/lib/libws2_32.a > > I had essentially the same experience building freeglut - it kept looking > for a "file starting with libgdi32". Eventually it occurred to me to try > creating a copy of C:/Windows/System32/gdi32.dll named > C:/Windows/System32/libgdi32.dll ... and that hack worked !! > > On the basis of that (and assuming you can run as Administrator), try > creating a copy of your system's ws2_32.dll named libws2_32.dll (in the > same > directory). If that works, well and good ... if not, must be sumpin else > :-) > > Cheers, > Rob > > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > 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 > |
|
From: LRN <lr...@gm...> - 2010-01-18 22:36:47
|
On 19.01.2010 1:16, Roumen Petrov wrote: > LRN wrote: > [SNIP] > >> I still think that this is exactly how libtool is supposed to work - it >> refuses to link a dll against a static library. As far as i remember, >> this is exactly what libtool developers wanted, because things may get >> ugly otherwise. >> > yes for shared libraries, no for applications. > > >> What i don't understand is why it lets Vincent Torri to get away with >> such linking. Maybe there is a magic option somewhere that i don't know of? >> > As example you could use -Wl,-liberty added to XXX_la_LDFLAGS. > He claims that he uses plain and simple -liberty , without circumventing libtool with -Wl, (or, at least i think that he claims, he didn't say much) |
|
From: Vincent T. <vt...@un...> - 2010-01-18 23:05:45
|
On Tue, 19 Jan 2010, LRN wrote: > On 19.01.2010 1:16, Roumen Petrov wrote: >> LRN wrote: >> [SNIP] >> >>> I still think that this is exactly how libtool is supposed to work - it >>> refuses to link a dll against a static library. As far as i remember, >>> this is exactly what libtool developers wanted, because things may get >>> ugly otherwise. >>> >> yes for shared libraries, no for applications. >> >> >>> What i don't understand is why it lets Vincent Torri to get away with >>> such linking. Maybe there is a magic option somewhere that i don't know of? >>> >> As example you could use -Wl,-liberty added to XXX_la_LDFLAGS. >> > He claims that he uses plain and simple -liberty , without circumventing > libtool with -Wl, (or, at least i think that he claims, he didn't say much) actually, maybe i passed pass_all to a libtool variable as a workaround. I can't remember exactly. I'll try with a simple example in the next days Vincent Torri |
