CVSROOT:/cvsroot/libtool
Module name:libtool
Branch:
Changes by: Ralf Wildenhues [EMAIL PROTECTED] 05/09/27 06:48:20
Modified files:
. : ChangeLog
Log message:
* tests/defs.m4sh, tests/testsuite.at (PREPARE_TESTS)
AUTORECONF:
CVSROOT:/cvsroot/libtool
Module name:libtool
Branch:
Changes by: Gary V. Vaughan [EMAIL PROTECTED] 05/09/27 10:03:49
Modified files:
. : ChangeLog Makefile.am
Log message:
* libltdl/ltdl.c (lt_dlcaller_register): Renamed to avoid
CVSROOT:/cvsroot/libtool
Module name:libtool
Branch:
Changes by: Gary V. Vaughan [EMAIL PROTECTED] 05/09/27 10:41:05
Modified files:
. : ChangeLog NEWS
Log message:
* libltdl/ltdl.h (lt_dlmutex_register, lt_dlmutex_lock)
CVSROOT:/cvsroot/libtool
Module name:libtool
Branch:
Changes by: Gary V. Vaughan [EMAIL PROTECTED] 05/09/27 13:09:20
Modified files:
. : ChangeLog libtoolize.m4sh
Log message:
* libtoolize.m4sh (func_scan_files): Support projects that
CVSROOT:/cvsroot/libtool
Module name:libtool
Branch: branch-1-5
Changes by: Ralf Wildenhues [EMAIL PROTECTED] 05/09/27 16:25:43
Modified files:
. : ChangeLog libtool.m4 ltdl.m4
Log message:
* libtool.m4 (AC_DEPLIBS_CHECK_METHOD)
Okay to apply to HEAD?
Symbol naming convention nit.
libltdl/lt_error.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
Index: libtool--devo--1.0/ChangeLog
from Gary V. Vaughan [EMAIL PROTECTED]
* libltdl/lt_error.c (lt__last_error, lt__error_strings): The
Ralf Wildenhues wrote:
Hi Gary,
Hallo Ralf!
Maybe we should add a couple of public #define's for ltdl API?
Like this:
#define LTDL_MAJOR 2
#define LTDL_MINOR 0
#define LTDL_REVISION 0
#define LTDL_RELEASE ((LTDL_MAJOR 16) | (LTDL_MINOR 8) | LTDL_REVISION)
so packages that have
Hi Gary,
* Gary V. Vaughan wrote on Tue, Sep 27, 2005 at 12:19:31PM CEST:
Okay to apply to HEAD?
Yes, please. Thank you!
Symbol naming convention nit.
I missed that bit! Oh no.. ;-)
Cheers,
Ralf
libltdl/lt_error.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
Hi Gary,
* Gary V. Vaughan wrote on Tue, Sep 27, 2005 at 12:52:44PM CEST:
Ralf Wildenhues wrote:
Maybe we should add a couple of public #define's for ltdl API?
Like this:
#define LTDL_MAJOR 2
#define LTDL_MINOR 0
#define LTDL_REVISION 0
#define LTDL_RELEASE ((LTDL_MAJOR 16) |
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Applied to HEAD.
* looking for [EMAIL PROTECTED]/libtool--devo--1.0--patch-294 to compare with
* comparing to [EMAIL PROTECTED]/libtool--devo--1.0--patch-294
M ChangeLog
M libltdl/lt_error.c
* modified files
Index: Changelog
Ralf Wildenhues wrote:
Hi Gary,
Hallo Ralf,
* Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 02:30:03AM CEST:
This fixes the remaining holes that allowed libltdl clients to stumble
across each others' loaded modules. Of course, there is nothing to
prevent clients from registering a dumb
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
94 hours without comment (on the repost addressing Ralfs feedback), so...
Applied to HEAD.
* looking for [EMAIL PROTECTED]/libtool--devo--1.0--patch-295 to compare with
* comparing to [EMAIL PROTECTED]/libtool--devo--1.0--patch-295
M
Hi!
(Using a real MUA for a change...)
* Ralf Wildenhues wrote on Sunday, September 25, 2005 15:10 CEST:
* Peter Ekberg wrote on Thu, Sep 22, 2005 at 12:43:46PM CEST:
* Ralf Wildenhues wrote on Thursday, September 22, 2005 10:06 CEST:
* Peter Ekberg wrote on Thu, Sep 22, 2005 at 10:00:32AM
Hallo Ralf,
Thanks for the review. This fixes the inline LT_CONFIG_LTDL_DIR problem
you report, but I'm not sure I understand how the aclocal.m4 problem came
to be:
Ralf Wildenhues wrote:
++ cat aclocal.m4 ./foo/libltdl/configure.ac
How did configure_ac get set to ./foo/libltdl/configure.ac?
On Tue, 27 Sep 2005, Gary V. Vaughan wrote:
Okay to apply to HEAD?
This patch looks good. It does not appear to have a de-stabilizing
effect.
Bob
Symbol naming convention nit.
libltdl/lt_error.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
Index:
On Mon, Sep 26, 2005 at 04:15:11PM +, Olly Betts wrote:
On 2005-09-23, Ralf Wildenhues [EMAIL PROTECTED] wrote:
[ By the way, I don't think everyone in this discussion has subscribed
this list; if in doubt, speak up, or even better, set Mail-Followup-To:
next time ]
I'm following it
Hi Enrico,
* Enrico Weigelt wrote on Mon, Sep 26, 2005 at 09:56:27PM CEST:
how does libtool decide whether to link against an .la library
dynamically vs. statically ?
For a program or a library? Uninstalled or installed library
(see recent bug report of Howard Chu)? On a system with both
Ralf Wildenhues wrote:
We have better support for sysroot and/or DESTDIR on our TODO list.
Why don't you help us improve and fix libtool? That is bound to be
a lot less work.
*time passes*
http://lists.gnu.org/archive/html/libtool-patches/2005-06/msg00161.html
Oh, you asked before. Why not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jacob Meuser wrote:
| I think perhaps you should ask [EMAIL PROTECTED] about this. he might
| be able to explain why -lstdc++ is not implicitly used in `g++ -shared',
| which could give you a good starting point on how to fix the
| problem.
|
I
Now that there are no doubts about the portability of shell functions
(in the sense that there's always a shell on the machine that supports
function ---and maybe the documentation should reflect this), I'm
curious about the support of return and local. Is there anything
known about them? ISTR
* Ralf Wildenhues [EMAIL PROTECTED] wrote:
Hi,
how does libtool decide whether to link against an .la library
dynamically vs. statically ?
For a program or a library? Uninstalled or installed library
(see recent bug report of Howard Chu)?
Each of these cases ...
I've now figured
[Cc:-ed to Mark Espie at Jacob's suggestion:
I think perhaps you should ask [EMAIL PROTECTED] about this. he might
be able to explain why -lstdc++ is not implicitly used in `g++ -shared'
If you need context, this is the whole thread:
http://thread.gmane.org/gmane.comp.gnu.libtool.general/6671
On 2005-09-22, Peter O'Gorman [EMAIL PROTECTED] wrote:
Do we know what the versions of the OS/gcc are where -lstdc++ is missing? We
can enplicitly add it (as we did recently for, I think, sunpro c++). Is this
a gcc bug, or is it by design?
I've only been able to test OpenBSD 3.7 with g++
Hi Enrico,
* Enrico Weigelt wrote on Tue, Sep 27, 2005 at 03:27:21PM CEST:
* Ralf Wildenhues [EMAIL PROTECTED] wrote:
how does libtool decide whether to link against an .la library
dynamically vs. statically ?
For a program or a library? Uninstalled or installed library
Each of
Hi Tim,
* Tim Rice wrote on Tue, Sep 27, 2005 at 07:56:31PM CEST:
On Tue, 27 Sep 2005, Howard Chu wrote:
First of all, my objective - other folks may have their own objectives
different than this: Build a suite of software that uses shared libraries,
such that any embedded runpaths only
Akim Demaille [EMAIL PROTECTED] writes:
Now that there are no doubts about the portability of shell functions
(in the sense that there's always a shell on the machine that supports
function ---and maybe the documentation should reflect this),
Yes, it should.
I'm curious about the support of
On Tue, 27 Sep 2005, Ralf Wildenhues wrote:
Hi Tim,
* Tim Rice wrote on Tue, Sep 27, 2005 at 07:56:31PM CEST:
I'd like to be able have the embedded runpath be /opt/lib even
if I install in /opt/foo/lib. (the package posinstall script would put
symbolic links in /opt/lib)
I believe
27 matches
Mail list logo