Thomas E. Dickey [EMAIL PROTECTED] writes:
| On Tue, 8 Oct 2002, Lars Hecking wrote:
|
| Bob Friesenhahn writes:
| On 8 Oct 2002, Akim Demaille wrote:
|
|There is one big question which must be answered first: will it have
|to be Autoconf 2.13 compatible?
|
|I *strongly*
On Wed, Oct 09, 2002 at 12:09:09PM +0200, Andreas Schwab wrote:
In my experience almost all problems that occur while moving to autoconf
2.5x are outright bugs in the configure.in/aclocal.m4 scripts.
We've already discussed this before, and I decided not to rely upon your opinion
--
Thomas
On Wednesday, October 9, 2002, at 01:20 AM, Christoph Egger wrote:
so diff would be just in the last part around `-install_name
$parth/$soname`
Good to know. Is there an anonymous CVS access? If yes, where and how?
Then I could give you a diff against this branch, if merging makes you
On Wed, Oct 09, 2002 at 01:15:07PM +0200, Andreas Schwab wrote:
Thomas Dickey [EMAIL PROTECTED] writes:
| On Wed, Oct 09, 2002 at 12:09:09PM +0200, Andreas Schwab wrote:
| In my experience almost all problems that occur while moving to autoconf
| 2.5x are outright bugs in the
Thomas Dickey [EMAIL PROTECTED] writes:
| On Wed, Oct 09, 2002 at 12:09:09PM +0200, Andreas Schwab wrote:
| In my experience almost all problems that occur while moving to autoconf
| 2.5x are outright bugs in the configure.in/aclocal.m4 scripts.
|
| We've already discussed this before, and I
Sascha == Sascha Schumann [EMAIL PROTECTED] writes:
Sascha We use it for the PHP project (80k lines configure script),
Sascha because 2.5x is 5 to 6 times slower
That's because it does provide a better service too :( I have timed a
lot of the code, and I can tell that we're hitting a M4
Russ == Russ Allbery [EMAIL PROTECTED] writes:
Great thread people! I'm happy to see you're alive :)
Russ There were a variety of reasons for breaking backward
Russ compatibility, like choosing to clean up quoting, but that's a
Russ justification for doing it, not an argument that it didn't
Robert == Robert Boehne [EMAIL PROTECTED] writes:
Robert Ok, So a 1.4.3 version is desired, that's established. The
Robert million-dollar question is: Does current branch-1-4 Libtool do
Robert the trick?
Robert If so, then a roll out could be done within the week.
I would like to find a
Paolo Bonzini wrote:
Wouldn't it be better to get libtool 1.5 out the door? The resources
required to achieve a releasable product are similar and CVS libtool
already contains most of the fixes that would go into a 1.4.3.
But it also contains more features. Releasing 1.5 should be done
Hello there
Did you know that you can program smart
cards with files from the internet and open lots of pay per view chanells
for
your televisual pleasure.
Take a look at http://MagicFun.da.ru for the latest hex
files.
Many thanks Jay.
| Sascha and contains a dependency-ignorant cache system.
|
| What do you mean?
|
| Each of PHP's bundled extensions has a config.m4 which can be
| maintained separately. Autoconf 2.50 and later insert stale
| code into configure, when such a config.m4 file changes.
You want
On Wednesday, October 9, 2002, at 01:20 AM, Christoph Egger wrote:
so diff would be just in the last part around `-install_name
$parth/$soname`
Good to know. Is there an anonymous CVS access? If yes, where and how?
Then I could give you a diff against this branch, if merging
The community are the maintainers, therefore a maintainer has spoken for
a minor version increment, rather than a patch release increment.
Do you mean a minor version increment starting from branch-1_4 or from HEAD?
Paolo
___
Libtool mailing
After seeing what has happened with Autoconf, and given the current
state of libtool, I recommend that the focus of libtool development be
to produce a libtool 1.5 as soon as possible and not spend time
producing a libtool 1.4.3.
Time spent on libtool 1.4.3 is time spent doing work which must
Bob Friesenhahn wrote:
Time spent on libtool 1.4.3 is time spent doing work which must
either be done a second time, or has already been done, for libtool
1.5.
Not true. There were some patches backported even before now,
I was doing some of the work under the expectation that we can
see a
Akim Demaille [EMAIL PROTECTED] writes:
If people consider we deliberatedly broken bugward compatibility, then
fine, you're free to be wrong. It's not what happened (and I can tell
you that a lot of code would not have been written if that was our
intention), but I don't care what people
On Wed, Oct 09, 2002 at 12:29:44PM -0500, Bob Friesenhahn wrote:
On Wed, 9 Oct 2002, Guido Draheim wrote:
In my experience, the 1.5 code-base is a solid product on systems
supported by 1.4.2, and provided that it is patched and proven to work
under MinGW and Darwin then 1.5 should be
Yes, you already said that. The stuff above is about the libtool 1.4
_branch_, while the libtool-darwin patch is in the mainstream
development tree.
Right, and I have not yet seen anything that said there will be a
libtool 1.4.3 release, only that there will be a libtool release in
All,
I intend to spin a release 1.4.3 this weekend from the
branch-1-4 sources. Any properly formatted patches will
be considered for inclusion before the release. I have
seen a tendency to post patches on any list in any
format, which makes it more work to get that particular
patch installed
Hi Robert,
On Wed, Oct 09, 2002 at 02:57:39PM -0500, Robert Boehne wrote:
I intend to spin a release 1.4.3 this weekend from the
branch-1-4 sources. Any properly formatted patches will
be considered for inclusion before the release. I have
seen a tendency to post patches on any list in any
On Wed, 2002-10-09 at 16:15, Robert Boehne wrote:
Christoph,
The patch against libtool.m4 is different from what is in
CVS branch-1-4. Does today's branch-1-4 have the problem
your patch intends to fix? It appears that this may
be fixed in CVS.
If you would, please get Libtool cvs
From: Sascha Schumann [EMAIL PROTECTED]
Date: Wed, 9 Oct 2002 19:49:57 +0200 (CEST)
Did you send a bug report? Do you have a test case?
I'm sorry, it was noticed by so many people, I supposed it
would make its way to you.
It's the first I've heard of it. Do you have a URL
On Wed, Oct 09, 2002 at 02:57:39PM -0500, Robert Boehne wrote:
I intend to spin a release 1.4.3 this weekend from the branch-1-4
sources.
There is a bug in libtool 1.4.2 when using -prefer-non-pic on hppa:
libtool does not pass the -fPIC flag, and then the linker complains
about that.
Benjamin,
If we added support for library namespace, all of the
Darwin developers would start developing software with
Libtool that used it, and therefore wouldn't link on
other systems, correct? I'm not claiming I have ever
seen a Mac running X+ so you'll have to correct me if I'm wrong.
Ok, let me see if I understand this one,
under Linux hppa, (presumably with gcc) user has added -prefer-non-pic
to the CFLAGS explicitly, and configured with --enable-shared ??
What platforms (aside from Alpha RS/6000) does this work on?
--
Robert Boehne Software Engineer
Ricardo
On Wed, Oct 09, 2002 at 06:27:18PM -0500, Robert Boehne wrote:
Ok, let me see if I understand this one,
under Linux hppa, (presumably with gcc) user has added -prefer-non-pic
to the CFLAGS explicitly, and configured with --enable-shared ??
The package adds -prefer-non-pic to the CFLAGS
* Michel LESPINASSE [EMAIL PROTECTED] [20021009 19:57]:
On Wed, Oct 09, 2002 at 06:27:18PM -0500, Robert Boehne wrote:
Ok, let me see if I understand this one,
under Linux hppa, (presumably with gcc) user has added -prefer-non-pic
to the CFLAGS explicitly, and configured with --enable
Bob Friesenhahn [EMAIL PROTECTED] writes:
Ideas?
g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o
.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o
.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o
By the way, notice that this is a C++ DLL which is being linked
against a C DLL also built by libtool. The C DLL did successfully
link using libtool. The C DLL is based in part on a libtool
convenience library.
To be honest, I believe that there are still some run-time issues with
C++ DLLs
Bob Friesenhahn [EMAIL PROTECTED] writes:
g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o
.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o
.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o
Link your page to a free web survey.
Easy administration to create and modify your questions.
Just give us a try http://osp.net/survey
* This site allows you to create and modify a web survey very easily
* Excellent graphical output of survey responses
* Export your survey information
31 matches
Mail list logo