Re: Extend libtool dll namespaces for mingw-w64
Den 2010-01-26 16:26 skrev JonY: I suggest the following naming scheme. mingw.org:lib-.dll (unchanged) Cygwin:cyg-.dll (unchanged) mingw-w64(64):lib64-.dll mingw-w64(32):lib32-.dll But then mingw-w64 invades the mingw.org namespace. Perhaps l64-.dll and l32-.dll? Cheers, Peter -- They are in the crowd with the answer before the question. > Why do you dislike Jeopardy? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
On 1/27/2010 18:02, Peter Rosin wrote: Den 2010-01-26 16:26 skrev JonY: I suggest the following naming scheme. mingw.org: lib-.dll (unchanged) Cygwin: cyg-.dll (unchanged) mingw-w64(64): lib64-.dll mingw-w64(32): lib32-.dll But then mingw-w64 invades the mingw.org namespace. Perhaps l64-.dll and l32-.dll? Cheers, Peter Hi, this is better than lib. So, any ideas where to begin implementing this? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
On Tue, 2010-01-26 at 23:26 +0800, JonY wrote: ... > I suggest the following naming scheme. > > mingw.org:lib-.dll (unchanged) > Cygwin: cyg-.dll (unchanged) > mingw-w64(64):lib64-.dll > mingw-w64(32):lib32-.dll > > libtool should also check if GCC "-m32" or "-m64" is used, and select > the proper namespace accordingly (mingw-w64 GCC can do multilib). > > Comments? > AFAIK if you use automake, you have to have something like the following line in Makefile.am: lib_LTLIBRARIES = libfoo.la This means that the 'lib' prefix doesn't actually come from mingw, but from your automake setup, right? In order to be able to change the library name in a smarter way, something like lib_LTLIBRARIES = @lib...@foo.la # LIBrary PREfix would be needed, am I right? The LIBPRE value would be determined by the configure script. Or am I wrong at some point? This should allow some library name modifications as proposed here. What I would like to see one day though is that I am able to produce a library named foo.dll instead of libfoo.dll without any workarounds. That lib prefix tends to scare Windows users, but I am sure you know that too :-) I was not aware of possible conflicts that were mentioned here though. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
Den 2010-01-27 20:54 skrev Matěj Týč: On Tue, 2010-01-26 at 23:26 +0800, JonY wrote: ... I suggest the following naming scheme. mingw.org: lib-.dll (unchanged) Cygwin: cyg-.dll (unchanged) mingw-w64(64): lib64-.dll mingw-w64(32): lib32-.dll libtool should also check if GCC "-m32" or "-m64" is used, and select the proper namespace accordingly (mingw-w64 GCC can do multilib). Comments? AFAIK if you use automake, you have to have something like the following line in Makefile.am: lib_LTLIBRARIES = libfoo.la This means that the 'lib' prefix doesn't actually come from mingw, but from your automake setup, right? In order to be able to change the library name in a smarter way, something like lib_LTLIBRARIES = @lib...@foo.la # LIBrary PREfix would be needed, am I right? The LIBPRE value would be determined by the configure script. Or am I wrong at some point? This should allow some library name modifications as proposed here. What I would like to see one day though is that I am able to produce a library named foo.dll instead of libfoo.dll without any workarounds. That lib prefix tends to scare Windows users, but I am sure you know that too :-) I was not aware of possible conflicts that were mentioned here though. You are mistaken. The lib prefix on the dll files is coming from the libtool variable $libname_spec. It is typically set to something like this: # Format of library name prefix. libname_spec="lib\$name" Which is then warped on Cygwin by another libtool variable, namely $soname_spec which has a sed -e s/^lib/cyg/ in it. A similar tweak is needed to implement this for mingw-w64. Cheers, Peter -- They are in the crowd with the answer before the question. > Why do you dislike Jeopardy? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
On Wed, 2010-01-27 at 22:19 +0100, Peter Rosin wrote: > Den 2010-01-27 20:54 skrev Matěj Týč: > > On Tue, 2010-01-26 at 23:26 +0800, JonY wrote: > > ... > >> I suggest the following naming scheme. > >> > >> mingw.org: lib-.dll (unchanged) > >> Cygwin:cyg-.dll (unchanged) > >> mingw-w64(64): lib64-.dll > >> mingw-w64(32): lib32-.dll > >> > >> libtool should also check if GCC "-m32" or "-m64" is used, and select > >> the proper namespace accordingly (mingw-w64 GCC can do multilib). > >> > >> Comments? > >> > > > > AFAIK if you use automake, you have to have something like the following > > line in Makefile.am: > > lib_LTLIBRARIES = libfoo.la > > This means that the 'lib' prefix doesn't actually come from mingw, but > > from your automake setup, right? > > > > ... > > You are mistaken. The lib prefix on the dll files is coming from > the libtool variable $libname_spec. It is typically set to something > like this: > > # Format of library name prefix. > libname_spec="lib\$name" > > Which is then warped on Cygwin by another libtool variable, namely > $soname_spec which has a sed -e s/^lib/cyg/ in it. > > A similar tweak is needed to implement this for mingw-w64. > > Cheers, > Peter > Wow, this is interesting. I remember that one guy asked about the dll prefix and he has been advised to strip the prefix from the library name and add the '-module' flag to libtool in order to silence complaints. Actually, here it is: http://lists.gnu.org/archive/html/libtool/2007-04/msg00022.html http://lists.gnu.org/archive/html/libtool/2007-05/msg1.html So how it is? Is there a another, more correct solution to Bob's challenge? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
Matěj Týč wrote:
On Tue, 2010-01-26 at 23:26 +0800, JonY wrote:
...
I suggest the following naming scheme.
mingw.org: lib-.dll (unchanged)
Cygwin: cyg-.dll (unchanged)
mingw-w64(64): lib64-.dll
mingw-w64(32): lib32-.dll
libtool should also check if GCC "-m32" or "-m64" is used, and select
the proper namespace accordingly (mingw-w64 GCC can do multilib).
Comments?
AFAIK if you use automake, you have to have something like the following
line in Makefile.am:
lib_LTLIBRARIES = libfoo.la
This means that the 'lib' prefix doesn't actually come from mingw, but
from your automake setup, right?
No http://lists.gnu.org/archive/html/libtool/2007-07/msg00064.html
[SNIP]
This should allow some library name modifications as proposed here.
What I would like to see one day though is that I am able to produce a
library named foo.dll instead of libfoo.dll without any workarounds.
That lib prefix tends to scare Windows users, but I am sure you know
that too :-) I was not aware of possible conflicts that were mentioned
here though.
I'm not sure that idea for lib{64|32} is so good.
As I know for 32 bit process 64 bit microsoft windows os will return
%WINDOWS%\SysWOW64 as system folder. For 64 bit process it is
%WINDOWS%\System32 (no comment on design), "Program Files" for 64-bit
and "Program Files (x86)"(?) for 32-bit (more on MSDN).
I'm not sure that libtool has to know how lets call it "redirection" work.
Roumen
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
Matěj Týč wrote: [SNIP] Wow, this is interesting. I remember that one guy asked about the dll prefix and he has been advised to strip the prefix from the library name and add the '-module' flag to libtool in order to silence complaints. [SNIP] -module flag will install dll in $libdir and without flag in $libdir/..bin for stable release . Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
> I'm not sure that idea for lib{64|32} is so good.
Me neither, but,
> As I know for 32 bit process 64 bit microsoft windows os will return
> %WINDOWS%\SysWOW64 as system folder. For 64 bit process it is
> %WINDOWS%\System32
I fail to see what *that* has to do with it. Surely nobody builds any
DLL that is to be installed in the Windows system32 folder using
libtool?
--tml
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
* JonY wrote on Tue, Jan 26, 2010 at 04:26:32PM CET: > Currently, on Win32 platforms, Cygwin uses the "cyg" prefix for dlls, > and MinGW based systems uses the "lib" prefix. > > This works fine, until mingw-w64 showed up with 64bit dlls. This > problem is especially apparent with trying to build mingw-w64 cross > compilers. > > For example, both mingw and mingw-w64 builds libstdc++-6.dll from GCC. > When installed, there might be up to 3 incompatible versions of > libstdc++-6.dll, from mingw.org, 32bit mingw-w64 and 64bit mingw-w64. MinGW and MinGW64 should cooperate on issues like this. Libtool has little to no bearing here, except to follow. Libtool cannot decide what the runtime system will load. > I suggest the following naming scheme. I suggest we follow whatever naming scheme Windows uses. Including none if none. GNU libtool certainly shouldn't choose its own flavor. > libtool should also check if GCC "-m32" or "-m64" is used, and select > the proper namespace accordingly (mingw-w64 GCC can do multilib). No, the developer should have her $PATH set correctly. What does the Windows kernel do if it finds a needed shared library of the wrong ABI early in $PATH while trying to start a program? Fail or skip, and if skip, silently or verbosely? Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problem creating shared libraries (DLL's) on OS/2
Hello Paul, * Paul Smedley wrote on Mon, Jan 25, 2010 at 11:28:42PM CET: > I have libtool mostly working to create DLL's on SO/2 - with one problem. > > Our ld.exe is based on a very old version of GNU ld - and as such, > doesn't seem to correctly create reloadable object files. Which version? > Is there a way to tell libtool to NOT create reloadable object > files, and simple add all the individual object files to the > compiler linking command? Hmm, it should only do so when the command line exceeds the expected maximum length on your system. Can you post the --mode=link command that fails, plus all of its output, as well as the output of ./libtool --config please? Thanks. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
