Re: Is it a typo in libltdl?
Hello James,
* Zhe Su wrote on Wed, Jan 24, 2007 at 11:51:52AM CET:
> Hi,
> I found a possible typo in libltdl in lt_dlmutex_register(). while reading
> its source code. Patch is attached.
Thanks very much. I've applied the patch.
Please note though that the CVS HEAD branch has removed the locking
functionality, partly because it was deemed impossible to provide a
useful and efficient interface, and better if the user using libltdl
implemented that. So it's better if you don't depend on it.
Cheers,
Ralf
2007-01-27 James Su <[EMAIL PROTECTED]>
* libltdl/ltdl.c (lt_dlmutex_register): Fix usage of old unlock
function. Also replace the seterror function.
* THANKS: Update.
Index: THANKS
===
RCS file: /cvsroot/libtool/libtool/THANKS,v
retrieving revision 1.34.2.20
diff -u -r1.34.2.20 THANKS
--- THANKS 21 Jan 2007 16:16:05 - 1.34.2.20
+++ THANKS 27 Jan 2007 16:19:51 -
@@ -88,6 +88,7 @@
Howard Chu [EMAIL PROTECTED]
Ian Lance Taylor [EMAIL PROTECTED]
Jacob Meuser [EMAIL PROTECTED]
+ James Su [EMAIL PROTECTED]
Jeff Squyres [EMAIL PROTECTED]
Jeremy C. Reed [EMAIL PROTECTED]
Joel N. Weber II [EMAIL PROTECTED]
Index: libltdl/ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.174.2.23
diff -u -r1.174.2.23 ltdl.c
--- libltdl/ltdl.c 13 Oct 2006 14:13:31 - 1.174.2.23
+++ libltdl/ltdl.c 24 Jan 2007 12:52:14 -
@@ -918,7 +918,7 @@
lt_dlmutex_seterror *seterror;
lt_dlmutex_geterror *geterror;
{
- lt_dlmutex_unlock *old_unlock = unlock;
+ lt_dlmutex_unlock *old_unlock = lt_dlmutex_unlock_func;
int errors = 0;
/* Lock using the old lock() callback, if any. */
@@ -929,6 +929,7 @@
{
lt_dlmutex_lock_func = lock;
lt_dlmutex_unlock_func = unlock;
+ lt_dlmutex_seterror_func = seterror;
lt_dlmutex_geterror_func = geterror;
}
else
Re: strings.h in argz.c?
* Paul Eggert wrote on Mon, Jan 22, 2007 at 03:22:51AM CET: > > My experience is that everyone who's reported a bug against SunOS > 4.1.x for several years, is either (1) doing it only because they're > worried we might still want to be portable to SunOS 4.1.x, or (2) > maintaining a computer museum. Neither of these cases are worth > worrying about. OK. > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > > Is it likely (in practice) to have math functions like sin, cos, > > available but not math.h? Similarly, is it likely to have string > > functions but not string.h? > > Not these days, no. However it is possible that a freestanding > environment would have neither math.h nor the math functions. PalmOS > is one fairly-contemporary example. It's less likely for string.h to > be missing (PalmOS has it, albeit in a shim mode if memory serves). OK, that's good enough for Libtool. If a test fails due to missing math.h, I won't be worried, if it would fail later anyway due to a missing sine function. * Simon Josefsson wrote on Mon, Jan 22, 2007 at 08:53:37AM CET: > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > > > We got a bug report about Libtool 1.5.22 and SunOS 4.1.x this year, so > > I'm not doing any C89 cleanup on branch-1-5. > > That's not a problem, I only meant it to apply to future version. (I > assume there will be future versions not based on branch-1-5 ;-)). I do hope so, too. > > OTOH, the change may eventually cause 2 less header checks in user code; > > that is, once all other checks for string.h and strings.h are eliminated > > from their configury. > > Yes, and another problem might be code that checks for strings.h > and/or memory.h, but not string.h. It seems they might get the wrong > headers.. Well, currently, Autoconf's _AC_INCLUDES_DEFAULT_REQUIREMENTS still tests for these anyway. > I don't know about math.h. Math functions seem generally more > optional than other functions to me, depending on platform. If your > patch only changed this for the self tests, that is probably OK, but > it seems weird for libtool/ltdl to require math functions. ACK. Only the test suite requires them. I applied the patch, with a NEWS bit added, to HEAD. Cheers, Ralf Assume C89 for included headers, and throughout the testsuite. * NEWS: Update. * libltdl/argz.c: Do not include strings.h nor memory.h, include string.h unconditionally. Patch by Simon Josefsson <[EMAIL PROTECTED]>. * libltdl/libltdl/lt__private.h: Likewise. * libltdl/m4/ltdl.m4 (LTDL_INIT): Do not check for string.h, strings.h, memory.h. * tests/cdemo/configure.ac: Assume presence of math.h. * tests/cdemo/foo.c: Likewise. * tests/demo/configure.ac: Likewise for math.h, string.h. Assume 'const'. Drop obsolete AC_EXEEXT. * tests/demo/dlmain.c: Likewise. * tests/demo/foo.c: Likewise. * tests/depdemo/configure.ac: Likewise. * tests/depdemo/l4/l4.c: Likewise. * tests/f77demo/configure.ac: Likewise. Also drop obsolete AC_OBJEXT. * tests/fcdemo/configure.ac: Likewise. * tests/mdemo/configure.ac: Likewise. * tests/mdemo/foo1.c: Likewise. * tests/mdemo/foo2.c: Likewise. * tests/mdemo2/configure.ac: Likewise. * tests/pdemo/configure.ac: Likewise. * tests/pdemo/longer_file_name_dlmain.c: * tests/pdemo/longer_file_name_foo.c: Likewise. * tests/pdemo/longer_file_name_foo2.c: Likewise. * tests/tagdemo/configure.ac: Likewise. * tests/tagdemo/foo.cpp: Likewise. Index: NEWS === RCS file: /cvsroot/libtool/libtool/NEWS,v retrieving revision 1.197 diff -u -r1.197 NEWS --- NEWS24 Oct 2006 20:17:37 - 1.197 +++ NEWS27 Jan 2007 16:44:19 - @@ -36,6 +36,9 @@ * Initial support for the Sun compiler suite on GNU/Linux. * Improved support for GNU/kFreeBSD and GNU/NetBSD. * Search paths with GCC on multilib systems like x86_64 have been fixed. +* The Libtool and libltdl macros and the testsuite now assume a C89 + environment, consequently do not test for headers such as string.h, + strings.h, memory.h any more. * Bug fixes. New in 1.9f: 2004-10-23; CVS version 1.9e, Libtool team:
FYI: branch-1-5: backport --tag documentation
I've backported those bits of the --tag documentation from HEAD that
apply to branch-1-5, see below.
Cheers,
Ralf
2007-01-27 Ralf Wildenhues <[EMAIL PROTECTED]>
* doc/libtool.texi (Invoking libtool): Document `--tag'.
(Tags): New node, backported from HEAD.
(Other languages): Adjust.
* NEWS: Update.
Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.109.2.50
diff -u -r1.109.2.50 NEWS
--- NEWS21 Jan 2007 14:34:43 - 1.109.2.50
+++ NEWS27 Jan 2007 17:26:00 -
@@ -14,6 +14,8 @@
* Initial support for the Sun compiler suite on GNU/Linux.
* Improved support for GNU/kFreeBSD and GNU/NetBSD.
* Search paths with GCC on multilib systems like x86_64 have been fixed.
+* The libtool --tag argument which has been supported since version 1.5
+ is documented now.
* Bug Fixes.
New in 1.5.22: 2005-12-18; CVS version 1.5.21a, Libtool team:
Index: doc/libtool.texi
===
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.134.2.18
diff -u -r1.134.2.18 libtool.texi
--- doc/libtool.texi23 Jan 2007 23:49:27 - 1.134.2.18
+++ doc/libtool.texi27 Jan 2007 17:26:02 -
@@ -172,7 +172,8 @@
Using libtool with other languages
-* C++ libraries::
+* C++ libraries:: Writing libraries for C++
+* Tags::Tags
Troubleshooting
@@ -1066,6 +1067,9 @@
Display basic configuration options. This provides a way for packages
to determine whether shared or static libraries will be built.
[EMAIL PROTECTED] [EMAIL PROTECTED]
+Use configuration variables from tag @var{tag} (@pxref{Tags}).
+
@item --preserve-dup-deps
Do not remove duplicate dependencies in libraries. When building packages
with static libraries, the libraries may depend circularly on each other
@@ -3652,7 +3656,8 @@
and what special considerations you need to make if you do not use C.
@menu
-* C++ libraries::
+* C++ libraries:: Writing libraries for C++
+* Tags::Tags
@end menu
@node C++ libraries
@@ -3693,6 +3698,42 @@
initialized.
[EMAIL PROTECTED] Tags
[EMAIL PROTECTED] Tags
[EMAIL PROTECTED] tag names
[EMAIL PROTECTED] language names
[EMAIL PROTECTED] inferring tags
+
+Libtool supports multiple languages through the use of tags. Technically
+a tag corresponds to a set of configuration variables associated with a
+language. These variables tell @command{libtool} how it should create
+objects and libraries for each language.
+
+Tags are defined at @command{configure}-time for each language activated
+in the package. Here is the correspondence between language names and tags
+names.
+
[EMAIL PROTECTED] {Windows Resource} {Tag name}
[EMAIL PROTECTED] Language name@tab Tag name
[EMAIL PROTECTED] C@tab CC
[EMAIL PROTECTED] C++ @tab CXX
[EMAIL PROTECTED] Java @tab GCJ
[EMAIL PROTECTED] Fortran 77 @tab F77
[EMAIL PROTECTED] Windows Resource @tab RC
[EMAIL PROTECTED] multitable
+
[EMAIL PROTECTED] tries to automatically infer which tag to use from
+the compiler command being used to compile or link. If it can't infer
+a tag, then it defaults to the configuration for the @code{C} language.
+
+The tag can also be specified using @command{libtool}'s
[EMAIL PROTECTED]@var{tag}} option (@pxref{Invoking libtool}). It is a good
+idea to do so in @file{Makefile} rules, because that will allow users to
+substitute the compiler without relying on @command{libtool} inference
+heuristics. When no tag is specified, @command{libtool} will default
+to @code{CC}; this tag always exists.
+
+
@node Troubleshooting
@chapter Troubleshooting
@cindex troubleshooting
Re: Is it a typo in libltdl?
Hi,
Thanks for your reply.
Regards
James Su
On 1/28/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
Hello James,
* Zhe Su wrote on Wed, Jan 24, 2007 at 11:51:52AM CET:
> Hi,
> I found a possible typo in libltdl in lt_dlmutex_register(). while
reading
> its source code. Patch is attached.
Thanks very much. I've applied the patch.
Please note though that the CVS HEAD branch has removed the locking
functionality, partly because it was deemed impossible to provide a
useful and efficient interface, and better if the user using libltdl
implemented that. So it's better if you don't depend on it.
Then how should I make the code thread safe? Adding mutex locks around each
libltdl call?
When will the CVS HEAD branch be released as stable version?
Cheers,
Ralf
2007-01-27 James Su <[EMAIL PROTECTED]>
* libltdl/ltdl.c (lt_dlmutex_register): Fix usage of old unlock
function. Also replace the seterror function.
* THANKS: Update.
Index: THANKS
===
RCS file: /cvsroot/libtool/libtool/THANKS,v
retrieving revision 1.34.2.20
diff -u -r1.34.2.20 THANKS
--- THANKS 21 Jan 2007 16:16:05 - 1.34.2.20
+++ THANKS 27 Jan 2007 16:19:51 -
@@ -88,6 +88,7 @@
Howard Chu [EMAIL PROTECTED]
Ian Lance Taylor [EMAIL PROTECTED]
Jacob Meuser [EMAIL PROTECTED]
+ James Su [EMAIL PROTECTED]
Jeff Squyres [EMAIL PROTECTED]
Jeremy C. Reed [EMAIL PROTECTED]
Joel N. Weber II [EMAIL PROTECTED]
Index: libltdl/ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.174.2.23
diff -u -r1.174.2.23 ltdl.c
--- libltdl/ltdl.c 13 Oct 2006 14:13:31 - 1.174.2.23
+++ libltdl/ltdl.c 24 Jan 2007 12:52:14 -
@@ -918,7 +918,7 @@
lt_dlmutex_seterror *seterror;
lt_dlmutex_geterror *geterror;
{
- lt_dlmutex_unlock *old_unlock = unlock;
+ lt_dlmutex_unlock *old_unlock = lt_dlmutex_unlock_func;
int errors = 0;
/* Lock using the old lock() callback, if any. */
@@ -929,6 +929,7 @@
{
lt_dlmutex_lock_func = lock;
lt_dlmutex_unlock_func = unlock;
+ lt_dlmutex_seterror_func = seterror;
lt_dlmutex_geterror_func = geterror;
}
else
Re: Is it a typo in libltdl?
* Zhe Su wrote on Sat, Jan 27, 2007 at 06:52:59PM CET: > On 1/28/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > > >Please note though that the CVS HEAD branch has removed the locking > >functionality, partly because it was deemed impossible to provide a > >useful and efficient interface, and better if the user using libltdl > >implemented that. So it's better if you don't depend on it. > > Then how should I make the code thread safe? Adding mutex locks around > each libltdl call? That is a safe possibility. But for example if you only have one thread that uses libltdl functions anyway, you should be able to cope without locking. > When will the CVS HEAD branch be released as stable version? Good question. I guess it's wiser if I don't speculate. If you want to try it, there are links to daily snapshots on the web page. Cheers, Ralf
Re: Is it a typo in libltdl?
On Sun, 28 Jan 2007, Zhe Su wrote: Then how should I make the code thread safe? Adding mutex locks around each libltdl call? That should work as long as there are no other users of libltdl in the application. If you use a 3rd party library which also uses libltdl, then you won't be able to protect for thread safety. When will the CVS HEAD branch be released as stable version? A year (or two) ago. ;-) Libtool 2.0 seems to be like wine. The longer it remains unopened, the better it gets. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
