Re: Test for dlloader API
Hi Peter,
* Peter Rosin wrote on Mon, Jan 25, 2010 at 04:12:47PM CET:
As promised, here's a testsuite addition for the dlloader API.
Thank you!
2010-01-25 Peter Rosin p...@lysator.liu.se
Testsuite exposure for dlloader API.
* tests/dlloader-api.at: New file, new test.
* Makefile.am (TESTSUITE_AT): Update.
So far I've only take a cursory look:
+static lt_module
+first_open (lt_user_data data, const char *filename, lt_dladvise advise)
+{
+ static char *first_module = first;
This pointer should be const char *, it may point to read-only memory.
There are several more instances that fail when using CC=g++. The patch
below makes it pass in this case for me, please look over it that I
haven't made any mistakes.
The test fails for me when Libtool is configured with --disable-shared.
I'm not sure that failure is specific to this test, whether we need to
fix it before committing the test or so; looking at this is probably
prudent.
Thanks,
Ralf
diff --git a/tests/dlloader-api.at b/tests/dlloader-api.at
index 25a01a9..e9b142e 100644
--- a/tests/dlloader-api.at
+++ b/tests/dlloader-api.at
@@ -42,7 +42,7 @@ first_init (lt_user_data data)
static lt_module
first_open (lt_user_data data, const char *filename, lt_dladvise advise)
{
- static char *first_module = first;
+ static const char *first_module = first;
const char *ctx = (const char *)data;
if (!filename || strcmp (filename, first))
@@ -71,7 +71,7 @@ first_sym (lt_user_data data, lt_module module, const char
*symbolname)
printf (first_sym (%s): %s\n, filename, ctx);
- return first_symbol;
+ return (void *) first_symbol;
}
static int
@@ -108,7 +108,7 @@ last_init (lt_user_data data)
static lt_module
last_open (lt_user_data data, const char *filename, lt_dladvise advise)
{
- static char *last_module = last;
+ static const char *last_module = last;
const char *ctx = (const char *)data;
if (!filename || strcmp (filename, last))
@@ -137,7 +137,7 @@ last_sym (lt_user_data data, lt_module module, const char
*symbolname)
printf (last_sym (%s): %s\n, filename, ctx);
- return last_symbol;
+ return (void *) last_symbol;
}
static int
@@ -169,10 +169,10 @@ main (int argc, char* argv[])
int err = 0;
lt_dlvtable *first;
lt_dlvtable *last;
- lt_module module = NULL;
+ lt_dlhandle module = NULL;
module_func *symbol;
- char *first_ctx = first_ctx;
- char *last_ctx = last_ctx;
+ const char *first_ctx = first_ctx;
+ const char *last_ctx = last_ctx;
const lt_dlvtable *finder;
if (lt_dlinit ())
@@ -181,7 +181,7 @@ main (int argc, char* argv[])
return 1;
}
- first = malloc (sizeof (*first));
+ first = (lt_dlvtable *) malloc (sizeof (*first));
if (!first)
{
printf (malloc failed\n);
@@ -196,7 +196,7 @@ main (int argc, char* argv[])
first-find_sym = first_sym;
first-dlloader_init = first_init; /* test that it isn't called twice */
first-dlloader_exit = first_exit;
- first-dlloader_data = first_ctx;
+ first-dlloader_data = (void *)first_ctx;
first-priority = LT_DLLOADER_PREPEND;
if (first_init (first-dlloader_data))
@@ -224,7 +224,7 @@ main (int argc, char* argv[])
printf (Found loader \%s\\n, finder-name);
- last = malloc (sizeof (*last));
+ last = (lt_dlvtable *) malloc (sizeof (*last));
if (!last)
{
printf (malloc failed\n);
@@ -239,7 +239,7 @@ main (int argc, char* argv[])
last-find_sym = last_sym;
last-dlloader_init = last_init; /* test that it isn't called twice */
last-dlloader_exit = last_exit;
- last-dlloader_data = last_ctx;
+ last-dlloader_data = (lt_user_data) last_ctx;
last-priority = LT_DLLOADER_APPEND;
if (last_init (last-dlloader_data))
@@ -276,7 +276,7 @@ main (int argc, char* argv[])
goto cleanup;
}
- symbol = lt_dlsym (module, symbol);
+ symbol = (module_func *) lt_dlsym (module, symbol);
if (!symbol)
{
@@ -297,7 +297,7 @@ main (int argc, char* argv[])
goto cleanup;
}
- symbol = lt_dlsym (module, symbol);
+ symbol = (module_func *) lt_dlsym (module, symbol);
if (!symbol)
{
@@ -318,7 +318,7 @@ main (int argc, char* argv[])
goto cleanup;
}
- symbol = lt_dlsym (module, symbol);
+ symbol = (module_func *) lt_dlsym (module, symbol);
if (!symbol)
{
@@ -357,7 +357,13 @@ cleanup:
AT_DATA([module.c],
[[
+#ifdef __cplusplus
+extern C
+#endif
const char *symbol (void);
+#ifdef __cplusplus
+extern C
+#endif
const char *
symbol (void)
{
Re: Extend libtool dll namespaces for mingw-w64
Den 2010-01-26 16:26 skrev JonY: I suggest the following naming scheme. mingw.org:libname-major.dll (unchanged) Cygwin:cygname-major.dll (unchanged) mingw-w64(64):lib64name-major.dll mingw-w64(32):lib32name-major.dll But then mingw-w64 invades the mingw.org namespace. Perhaps l64name-major.dll and l32name-major.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: libname-major.dll (unchanged) Cygwin: cygname-major.dll (unchanged) mingw-w64(64): lib64name-major.dll mingw-w64(32): lib32name-major.dll But then mingw-w64 invades the mingw.org namespace. Perhaps l64name-major.dll and l32name-major.dll? Cheers, Peter Hi, this is better than libbitness. 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:libname-major.dll (unchanged) Cygwin: cygname-major.dll (unchanged) mingw-w64(64):lib64name-major.dll mingw-w64(32):lib32name-major.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: libname-major.dll (unchanged) Cygwin: cygname-major.dll (unchanged) mingw-w64(64): lib64name-major.dll mingw-w64(32): lib32name-major.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: libname-major.dll (unchanged) Cygwin:cygname-major.dll (unchanged) mingw-w64(64): lib64name-major.dll mingw-w64(32): lib32name-major.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: libname-major.dll (unchanged)
Cygwin: cygname-major.dll (unchanged)
mingw-w64(64): lib64name-major.dll
mingw-w64(32): lib32name-major.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
