Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.
On 2012-07-22 04:00, JonY wrote: On 7/22/2012 00:43, Peter Rosin wrote: On 2012-07-21 14:49, Vincent Torri wrote: On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin p...@lysator.liu.se wrote: On 2012-07-21 13:16, Vincent Torri wrote: absolutely NO reason to add to the linker static libraries that are ONLY used in my Evil library and that are not used elsewhere. I think that it is the best solution That disables (easy) static linking. I, as a library author, do not like to make that policy decision for the application author. on Windows DLL are good. I already pass --disable-static to all my Windows builds. That has been argued elsewhere, but I can still see the value of the other side. So again, I, as a library author, do not like to shove that policy decision down the throat of my library consumers. So how are you supposed to build it if *I* want it as a DLL? Rhetoric notwithstanding, how are you supposed to build a DLL that uses libuuid.a? No, cloning UUID constants is not a proper fix. By not using Libtool, I suppose, or by mucking about with Libtool internals. Libtool needs to change to handle this situation cleanly. I don't know how. Care should perhaps be taken so that libtool doesn't export stuff from static libraries such as libuuid though, since the DLL consumer could be using libuuid as well without knowing that some consumed DLL is also pulling it in. Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.
On 2012-07-20 17:49, Vincent Torri wrote:
hey
I'm using mingw-w64 gcc (4.8.0 experimental)
I have to link a library (named Evil) against libuuid.a. That is, in
Makefile.am :
libevil_la_LIBADD = -luuid etc..
I have the warning that I pasted in the topic:
** Warning: linker path does not have real file for library -luuid.
etc...
and no DLL is produced. I have worked around that by adding before LT_INIT :
lt_cv_deplibs_check_method='pass_all'
and I have now the DLL. I thought that it would have been sufficient.
It's not. Because of the .la files (dependency_libs fieldcontains
-luuid) , each time I link against Evil, -luuid is passed and I have
the warning above, and no DLL is produced. Even worse, some binaries
can not be compiled at all.
So I would like to know how I can forbid libtool to pass -luuid each
time I link against Evil.
I ended up with the following in a separate file to work around this
craziness. I'd also like a cleaner way to use libuuid.a/libdxguid.a
from a DLL...
Cheers,
Peter
/* libtool fails to link a dll against libdxguid.a which
* is what we really want to do here. When libtool can do
* that, kill this file and add -ldxguid to the link
* command line.
* IMHO, this is a horrid workaround. But it works, and we
* get a dll instead of a static lib.
*/
typedef struct _IID
{
unsigned long x;
unsigned short s1;
unsigned short s2;
unsigned char c[8];
} IID;
typedef IID GUID;
typedef IID CLSID;
const CLSID CLSID_DirectInput =
{0x25E609E0,0xB259,0x11CF,{0xBF,0xC7,0x44,0x45,0x53,0x54,0x00,0x00}};
const IID IID_IDirectInput2A =
{0x5944e662,0xaa8a,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const IID IID_IDirectInputDevice2A =
{0x5944e682,0xc92e,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_Key =
{0x55728220,0xd33c,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_XAxis =
{0xa36d02e0,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_YAxis =
{0xa36d02e1,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_ZAxis =
{0xa36d02e2,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_RxAxis =
{0xa36d02f4,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_RyAxis =
{0xa36d02f5,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_RzAxis =
{0xa36d02e3,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_Slider =
{0xa36d02e4,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_POV =
{0xa36d02f2,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_SysKeyboard =
{0x6f1d2b61,0xd5a0,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_SysMouse=
{0x6f1d2b60,0xd5a0,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.
another solution is to just kill the stupid .la file. There is
absolutely NO reason to add to the linker static libraries that are
ONLY used in my Evil library and that are not used elsewhere.
I think that it is the best solution
thank you
Vincent Torri
On Sat, Jul 21, 2012 at 10:34 AM, Peter Rosin p...@lysator.liu.se wrote:
On 2012-07-20 17:49, Vincent Torri wrote:
hey
I'm using mingw-w64 gcc (4.8.0 experimental)
I have to link a library (named Evil) against libuuid.a. That is, in
Makefile.am :
libevil_la_LIBADD = -luuid etc..
I have the warning that I pasted in the topic:
** Warning: linker path does not have real file for library -luuid.
etc...
and no DLL is produced. I have worked around that by adding before LT_INIT :
lt_cv_deplibs_check_method='pass_all'
and I have now the DLL. I thought that it would have been sufficient.
It's not. Because of the .la files (dependency_libs fieldcontains
-luuid) , each time I link against Evil, -luuid is passed and I have
the warning above, and no DLL is produced. Even worse, some binaries
can not be compiled at all.
So I would like to know how I can forbid libtool to pass -luuid each
time I link against Evil.
I ended up with the following in a separate file to work around this
craziness. I'd also like a cleaner way to use libuuid.a/libdxguid.a
from a DLL...
Cheers,
Peter
/* libtool fails to link a dll against libdxguid.a which
* is what we really want to do here. When libtool can do
* that, kill this file and add -ldxguid to the link
* command line.
* IMHO, this is a horrid workaround. But it works, and we
* get a dll instead of a static lib.
*/
typedef struct _IID
{
unsigned long x;
unsigned short s1;
unsigned short s2;
unsigned char c[8];
} IID;
typedef IID GUID;
typedef IID CLSID;
const CLSID CLSID_DirectInput =
{0x25E609E0,0xB259,0x11CF,{0xBF,0xC7,0x44,0x45,0x53,0x54,0x00,0x00}};
const IID IID_IDirectInput2A =
{0x5944e662,0xaa8a,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const IID IID_IDirectInputDevice2A =
{0x5944e682,0xc92e,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_Key =
{0x55728220,0xd33c,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_XAxis =
{0xa36d02e0,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_YAxis =
{0xa36d02e1,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_ZAxis =
{0xa36d02e2,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_RxAxis =
{0xa36d02f4,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_RyAxis =
{0xa36d02f5,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_RzAxis =
{0xa36d02e3,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_Slider =
{0xa36d02e4,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_POV =
{0xa36d02f2,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_SysKeyboard =
{0x6f1d2b61,0xd5a0,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_SysMouse=
{0x6f1d2b60,0xd5a0,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
___
https://lists.gnu.org/mailman/listinfo/libtool
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.
On 2012-07-21 13:16, Vincent Torri wrote: another solution is to just kill the stupid .la file. There is I don't think the .la file is stupid as it lists other important dependencies. absolutely NO reason to add to the linker static libraries that are ONLY used in my Evil library and that are not used elsewhere. I think that it is the best solution That disables (easy) static linking. I, as a library author, do not like to make that policy decision for the application author. Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.
On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin p...@lysator.liu.se wrote: On 2012-07-21 13:16, Vincent Torri wrote: another solution is to just kill the stupid .la file. There is I don't think the .la file is stupid as it lists other important dependencies. so what ? There is a HUGE problem, here. Currently, if a lib uses symbols in libuuid, it just can't be used to create progs/shared lib because the .la file lists it while it should (must) not. Static libs must not appear in the dependency_libs field. absolutely NO reason to add to the linker static libraries that are ONLY used in my Evil library and that are not used elsewhere. I think that it is the best solution That disables (easy) static linking. I, as a library author, do not like to make that policy decision for the application author. on Windows DLL are good. I already pass --disable-static to all my Windows builds. Vincent Torri ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.
On 2012-07-21 14:49, Vincent Torri wrote: On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin p...@lysator.liu.se wrote: On 2012-07-21 13:16, Vincent Torri wrote: another solution is to just kill the stupid .la file. There is I don't think the .la file is stupid as it lists other important dependencies. so what ? There is a HUGE problem, here. Currently, if a lib uses symbols in libuuid, it just can't be used to create progs/shared lib because the .la file lists it while it should (must) not. Static libs must not appear in the dependency_libs field. Oh, but static libs do need to be listed in dependency_libs as long as there is no other place to put them. That, or static linking is not working well at all. I'm not willing to sacrifice static linking. absolutely NO reason to add to the linker static libraries that are ONLY used in my Evil library and that are not used elsewhere. I think that it is the best solution That disables (easy) static linking. I, as a library author, do not like to make that policy decision for the application author. on Windows DLL are good. I already pass --disable-static to all my Windows builds. That has been argued elsewhere, but I can still see the value of the other side. So again, I, as a library author, do not like to shove that policy decision down the throat of my library consumers. Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.
On 7/22/2012 00:43, Peter Rosin wrote: On 2012-07-21 14:49, Vincent Torri wrote: On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin p...@lysator.liu.se wrote: On 2012-07-21 13:16, Vincent Torri wrote: another solution is to just kill the stupid .la file. There is I don't think the .la file is stupid as it lists other important dependencies. so what ? There is a HUGE problem, here. Currently, if a lib uses symbols in libuuid, it just can't be used to create progs/shared lib because the .la file lists it while it should (must) not. Static libs must not appear in the dependency_libs field. Oh, but static libs do need to be listed in dependency_libs as long as there is no other place to put them. That, or static linking is not working well at all. I'm not willing to sacrifice static linking. absolutely NO reason to add to the linker static libraries that are ONLY used in my Evil library and that are not used elsewhere. I think that it is the best solution That disables (easy) static linking. I, as a library author, do not like to make that policy decision for the application author. on Windows DLL are good. I already pass --disable-static to all my Windows builds. That has been argued elsewhere, but I can still see the value of the other side. So again, I, as a library author, do not like to shove that policy decision down the throat of my library consumers. So how are you supposed to build it if *I* want it as a DLL? Rhetoric notwithstanding, how are you supposed to build a DLL that uses libuuid.a? No, cloning UUID constants is not a proper fix. signature.asc Description: OpenPGP digital signature ___ https://lists.gnu.org/mailman/listinfo/libtool
mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.
hey I'm using mingw-w64 gcc (4.8.0 experimental) I have to link a library (named Evil) against libuuid.a. That is, in Makefile.am : libevil_la_LIBADD = -luuid etc.. I have the warning that I pasted in the topic: ** Warning: linker path does not have real file for library -luuid. etc... and no DLL is produced. I have worked around that by adding before LT_INIT : lt_cv_deplibs_check_method='pass_all' and I have now the DLL. I thought that it would have been sufficient. It's not. Because of the .la files (dependency_libs fieldcontains -luuid) , each time I link against Evil, -luuid is passed and I have the warning above, and no DLL is produced. Even worse, some binaries can not be compiled at all. So I would like to know how I can forbid libtool to pass -luuid each time I link against Evil. thank you Vincent Torri ___ https://lists.gnu.org/mailman/listinfo/libtool
