[SCM] GNU Libtool branch, master, updated. v2.2.6-182-g7e8be90
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 7e8be90f4872b8140a718a0af0a1544d1f9371d9 (commit)
via 2080fe964906bdb18771b6a461622212063c1a51 (commit)
from e4eefcd401b32081fe947b2a731dadcc6bfcd337 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 7e8be90f4872b8140a718a0af0a1544d1f9371d9
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date: Sun Jan 31 13:39:48 2010 +0100
Use --email with gendocs.sh.
* Makefile.maint (web-manual): Pass bug reporting address to
gendocs.sh.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
commit 2080fe964906bdb18771b6a461622212063c1a51
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date: Sun Jan 31 15:31:52 2010 +0100
Make testsuite code C++ clean again.
* tests/resident.at (resident modules): Fix for C++.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
---
Summary of changes:
ChangeLog |9 +
Makefile.maint|2 +-
tests/resident.at |6 +-
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index b25d9d9..f4b4a3f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2010-01-31 Ralf Wildenhues ralf.wildenh...@gmx.de
+
+ Use --email with gendocs.sh.
+ * Makefile.maint (web-manual): Pass bug reporting address to
+ gendocs.sh.
+
+ Make testsuite code C++ clean again.
+ * tests/resident.at (resident modules): Fix for C++.
+
2010-01-29 Peter Rosin p...@lysator.liu.se
Ralf Wildenhues ralf.wildenh...@gmx.de
diff --git a/Makefile.maint b/Makefile.maint
index 02284df..b90b31d 100644
--- a/Makefile.maint
+++ b/Makefile.maint
@@ -225,4 +225,4 @@ web-manual:
$(WGETSGO)'/texinfo/texinfo/util/gendocs.sh' \
$(WGETSGO)'/texinfo/texinfo/util/gendocs_template' \
chmod 755 gendocs.sh \
- ./gendocs.sh libtool GNU Libtool Manual
+ ./gendocs.sh --email bug-libt...@gnu.org libtool GNU Libtool Manual
diff --git a/tests/resident.at b/tests/resident.at
index 8667ca7..c16a72a 100644
--- a/tests/resident.at
+++ b/tests/resident.at
@@ -59,7 +59,7 @@ main (int argc, char* argv[])
{
int (*pf) (void);
printf (plugin opened successfully!\n);
- pf = lt_dlsym (plugin_handle, setup_plugin);
+ pf = (int (*) (void)) lt_dlsym (plugin_handle, setup_plugin);
if (pf)
pf ();
else
@@ -100,6 +100,7 @@ main (int argc, char* argv[])
AT_DATA([plugin.c],
[[#include stdlib.h
+#include stdio.h
void
bye (void)
@@ -107,6 +108,9 @@ bye (void)
puts (called from atexit handler);
}
+#ifdef __cplusplus
+extern C
+#endif
int
setup_plugin (void)
{
hooks/post-receive
--
GNU Libtool
Make testsuite code C++ clean again.
Applied to master as obvious.
Cheers,
Ralf
Make testsuite code C++ clean again.
* tests/resident.at (resident modules): Fix for C++.
diff --git a/tests/resident.at b/tests/resident.at
index 8667ca7..c16a72a 100644
--- a/tests/resident.at
+++ b/tests/resident.at
@@ -59,7 +59,7 @@ main (int argc, char* argv[])
{
int (*pf) (void);
printf (plugin opened successfully!\n);
- pf = lt_dlsym (plugin_handle, setup_plugin);
+ pf = (int (*) (void)) lt_dlsym (plugin_handle, setup_plugin);
if (pf)
pf ();
else
@@ -100,6 +100,7 @@ main (int argc, char* argv[])
AT_DATA([plugin.c],
[[#include stdlib.h
+#include stdio.h
void
bye (void)
@@ -107,6 +108,9 @@ bye (void)
puts (called from atexit handler);
}
+#ifdef __cplusplus
+extern C
+#endif
int
setup_plugin (void)
{
Use --email with gendocs.sh.
Following the recent recommendation on gnu-prog-discuss, I've applied this. Cheers, Ralf Use --email with gendocs.sh. * Makefile.maint (web-manual): Pass bug reporting address to gendocs.sh. diff --git a/Makefile.maint b/Makefile.maint index 02284df..b90b31d 100644 --- a/Makefile.maint +++ b/Makefile.maint @@ -225,4 +225,4 @@ web-manual: $(WGETSGO)'/texinfo/texinfo/util/gendocs.sh' \ $(WGETSGO)'/texinfo/texinfo/util/gendocs_template' \ chmod 755 gendocs.sh \ - ./gendocs.sh libtool GNU Libtool Manual + ./gendocs.sh --email bug-libt...@gnu.org libtool GNU Libtool Manual
Re: silent installs
Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 2010/01/31 08:38:38: [ moving to libtool@ from automake@; this is http://thread.gmane.org/gmane.comp.sysutils.automake.general/11347/focus=11374 this particular message is about whether the relinking warning and the warning about the need to --finish should be changed to be notices only, which would cause them to not be displayed with `libtool --silent' which implies that an Automake --enable-silent-rules build would not show them at `make install' time. ] If you additionally would like to not see output from libtool, pass LIBTOOLFLAGS=--silent I do so but still see those msgs. It just occurred to me that ltmain.sh could change those line from func_warning to func_verbose instead: My problem with that change is that, the relinking and finish really are information that some users need to know about. If you don't --finish, then your libraries won't be found by the runtime linker. If relinking happens as another user than the one who ran `make all', that is a problem to know about, too, because it can lead to problems with file ownership and directory write permission. But they are not errors so they should not be directed to stderr no matter what. Then one can argue if --silent should suppress these msgs too or not. So the question really is whether to make their life harder for making your life easier. Not really, I think autotools(including libtool) should support both the user trying to build some SW pkg he/she has downloaded and the developer who is working to improve the said pkg in his daliy work. I am in the latter group I'd like to know what other libtool people think about this, so feedback appreciated. Thanks, Ralf --- ltmain.sh (revision 57662) +++ ltmain.sh (working copy) @@ -2028,7 +2028,7 @@ relink_command=`$ECHO X$relink_command | $Xsed -e s...@inst_prefix_dir@%%` fi - func_warning relinking \`$file' + func_verbose relinking \`$file' func_show_eval $relink_command \ 'func_fatal_error error: relink \`$file'\'' with the above command before installing it' fi @@ -2269,7 +2269,7 @@ done test -n $future_libdirs \ - func_warning remember to run \`$progname --finish$future_libdirs' + func_verbose remember to run \`$progname --finish$future_libdirs' if test -n $current_libdirs; then # Maybe just do a dry run. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: silent installs
On 1/31/10 6:10 AM, Joakim Tjernlund wrote: Ralf Wildenhuesralf.wildenh...@gmx.de wrote on 2010/01/31 08:38:38: My problem with that change is that, the relinking and finish really are information that some users need to know about. If you don't --finish, then your libraries won't be found by the runtime linker. If relinking happens as another user than the one who ran `make all', that is a problem to know about, too, because it can lead to problems with file ownership and directory write permission. But they are not errors so they should not be directed to stderr no matter what. Then one can argue if --silent should suppress these msgs too or not. Moving these messages to stdout would have the positive side effect that `make distcheck /dev/null' would become silent. That would be nice but is not worth it, if it means users miss the --finsih warning and end up sending bug reports to me about runtime errors. Thanks, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: silent installs
Peter Johansson troj...@gmail.com wrote on 2010/01/31 16:28:52: On 1/31/10 6:10 AM, Joakim Tjernlund wrote: Ralf Wildenhuesralf.wildenh...@gmx.de wrote on 2010/01/31 08:38:38: My problem with that change is that, the relinking and finish really are information that some users need to know about. If you don't --finish, then your libraries won't be found by the runtime linker. If relinking happens as another user than the one who ran `make all', that is a problem to know about, too, because it can lead to problems with file ownership and directory write permission. But they are not errors so they should not be directed to stderr no matter what. Then one can argue if --silent should suppress these msgs too or not. Moving these messages to stdout would have the positive side effect that `make distcheck /dev/null' would become silent. That would be nice but is not worth it, if it means users miss the --finsih warning and end up sending bug reports to me about runtime errors. There has to be some middle ground here. If the user does /dev/null then he in trouble anyway. Why would he do that in the first place? And what if he does /dev/null 21 too? If the user really feels that he needs to use /dev/null, then perhaps there is something else that is wrong such as too much output in the first place? Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
JonY wrote: On 1/31/2010 02:14, Roumen Petrov wrote: I don't understand request as the usually final result is .../libfool.la .../libfool.dll.a .../libfool.dll .../libfool.a Also note that makefiles the macros(variables) are libfoo_. Did the requester expect if target is libfoo_ make command to search for libYYfoo_ or may be requested will contact all developers as will convince to use macros like @libpre...@foo_ in makefiles and LIBPREFIX is set by configure ? Uhh ... Hi, If you looked at the concept patch, it changes how libtool names the DLL by soname_spec, libname_spec stays the same. The makefiles do not see the DLLs at all, only the .la files if libtool is in use. The .la filenames stay the same. That is the whole point of libtool, devs don't need to bother about platform specific details and implementation of shared libs. Uhh and the libtool install la files and process installed. So after installation xx-bit will override yy-bit. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: silent installs
On Sun, 31 Jan 2010, Ralf Wildenhues wrote: So the question really is whether to make their life harder for making your life easier. I'd like to know what other libtool people think about this, so feedback appreciated. I think that some people are hypersensitive to seeing build text and that changes to behavior should be well-reasoned and based on the typical user/developer rather than a hypersensitive one. In the USA we call this using community standards. The install step is one of the most dangerous things that I do to my system and so I often do 'make -n install' and study what is going on before doing the actual 'make install'. The thought of requesting a silent install has never crossed my mind before. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: silent installs
Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote on 2010/01/31 18:23:30: On Sun, 31 Jan 2010, Ralf Wildenhues wrote: So the question really is whether to make their life harder for making your life easier. I'd like to know what other libtool people think about this, so feedback appreciated. I think that some people are hypersensitive to seeing build text and that changes to behavior should be well-reasoned and based on the typical user/developer rather than a hypersensitive one. In the USA we call this using community standards. The install step is one of the most dangerous things that I do to my system and so I often do 'make -n install' and study what is going on before doing the actual 'make install'. The thought of requesting a silent install has never crossed my mind before. Sort of makes sense when you install to your host but when install into a DESTDIR as a normal user to later transfer the whole image to another system (embedded in my case) it isn't such a big deal. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problem creating shared libraries (DLL's) on OS/2
Hi Paul, please keep the list in Cc:, thanks. * Paul Smedley wrote on Thu, Jan 28, 2010 at 09:16:50AM CET: On 28/01/10 16:04, Ralf Wildenhues wrote: 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? Not sure to be honest - but the copyright notice in ld.c at http://svn.netlabs.org/libc/browser/branches/libc-0.6/src/emx/src/ld states 'Copyright (C) 1988 Free Software Foundation, Inc.; so it's old :) Unfortunately whilst I have the rest of binutils working OK, I don't have a working ld from the latest GNU binutils. 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. Well from reading the docs, I figured this shouldn't be used as well, but haven't been able to decipher why it is occuring. http://smedley.info/build.log should the output from trying to build vlccore.dll http://smedley.info/libtool.config has the output of libtool --config Thanks. The resulting command line is a over half of the noted maximum detected on your system. Since the detection adds a safety margin, for this package you can probably get away simply by editing the generated libtool script after running configure and increasing max_cmd_len a bit, say doubling it. Does that ld support @-files (a command line argument of @FILE should cause it to read additional arguments from FILE) or --whole-archive? We'd need some way that is less buggy to shove more objects into a shared library, in order to deploy a better workaround in libtool. Or, preferably, somebody should fix your ld to support -r, or get the newer ld to work ... Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: silent installs
On Sun, 31 Jan 2010, Joakim Tjernlund wrote: Sort of makes sense when you install to your host but when install into a DESTDIR as a normal user to later transfer the whole image to another system (embedded in my case) it isn't such a big deal. True. Any task likely to be performed as 'root' becomes a big deal. To be honest, it would be nice if 'make install' displayed a dialog which specifies the install locations of all the files to be installed and requests that I confirm it. Even then, there is the assumption that the install scripting does not have a bug. We are putting huge trust in 'make install'. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: silent installs
Ralf Wildenhues ralf.wildenh...@gmx.de writes: My problem with that change is that, the relinking and finish really are information that some users need to know about. If you don't --finish, then your libraries won't be found by the runtime linker. If relinking happens as another user than the one who ran `make all', that is a problem to know about, too, because it can lead to problems with file ownership and directory write permission. Perhaps libtool could add some more logic around when that text is displayed? It's always been noise for me; I've never needed to run --finish despite the message, presumably because of the platform on which I'm running libtool. If libtool could suppress that message unless the platform actually needs to do something at --finish, that would probably solve the problem. That would also solve the problem of people like me who are so used to that message and so used to it being useless that we've mentally filtered it out and wouldn't see it even if we needed to. On Linux, all that --finish appears to do is update the library symlinks. I don't understand why libtool thinks that needs to be done, given that it installs the library symlinks itself properly in the first place. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
On 2/1/2010 01:18, Roumen Petrov wrote: JonY wrote: On 1/31/2010 02:14, Roumen Petrov wrote: I don't understand request as the usually final result is .../libfool.la .../libfool.dll.a .../libfool.dll .../libfool.a Also note that makefiles the macros(variables) are libfoo_. Did the requester expect if target is libfoo_ make command to search for libYYfoo_ or may be requested will contact all developers as will convince to use macros like @libpre...@foo_ in makefiles and LIBPREFIX is set by configure ? Uhh ... Hi, If you looked at the concept patch, it changes how libtool names the DLL by soname_spec, libname_spec stays the same. The makefiles do not see the DLLs at all, only the .la files if libtool is in use. The .la filenames stay the same. That is the whole point of libtool, devs don't need to bother about platform specific details and implementation of shared libs. Uhh and the libtool install la files and process installed. So after installation xx-bit will override yy-bit. GCC already does the correct install for import libs for multilib configuration with lib32,lib64. For other packages that are not explicitly designed with multilib in mind, use a different --prefix. ___ http://lists.gnu.org/mailman/listinfo/libtool
