As a heads-up, yesterday libtool was passing the normal number of
tests (usually fails 2) under Solaris 10. With latest changes from
today, libtool tests are failing badly:
26 of 53 tests failed
(53 tests were not run)
Please report to bug-libt...@gnu.org
Hi Bob,
On 30 Jun 2010, at 01:40, Bob Friesenhahn wrote:
As a heads-up, yesterday libtool was passing the normal number of tests
(usually fails 2) under Solaris 10. With latest changes from today, libtool
tests are failing badly:
26 of 53 tests
On Wed, 30 Jun 2010, Gary V. Vaughan wrote:
I can't reproduce this one. But that might be something to do with the fix I
just committed...
I am dutifully re-running the tests with your latest patch
(d8bdf9339ba7de82f40c49705650506e0cc3f979). Early impressions are
that there are far fewer
On Wed, 30 Jun 2010, Gary V. Vaughan wrote:
26 of 53 tests failed
(53 tests were not run)
Please report to bug-libt...@gnu.org
I can't reproduce this one. But that might be something to do with the fix I
just
With OS-X Leopard PowerPC:
## - ##
## Test results. ##
## - ##
100 tests behaved as expected.
15 tests were skipped.
but with FreeBSD 8.0:
3 of 96 tests failed
(10 tests were not run)
Please report to bug-libt...@gnu.org
got a new libtool generated by this test-run? That test is
copying
func_append from libtool into tests/testsuite.dir/006/options and running a
test to
make sure that it works correctly. What does tests/testsuite.dir/006/options
contain?
What is the error message in tests/testsuite.dir/006
Hi Bob,
On 30 Jun 2010, at 08:10, Bob Friesenhahn wrote:
but with FreeBSD 8.0:
3 of 96 tests failed
(10 tests were not run)
Please report to bug-libt...@gnu.org
I found that the file tests/testsuite.log was from
Hallo Ralf,
On 27 Jun 2010, at 00:44, Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Tue, Jun 22, 2010 at 10:23:39PM CEST:
This is the improved (and renamed) `Use getopt.m4sh to generate libtool
option parser.' patch I promised yesterday. I'm pretty happy with this,
save that even though
work in actuality.
So, a false warning is not a sign of bad engineering?
If there was anything other than a vanishingly small probability that
someone would accidentally set _lt_xsi_replace_fail=: in the environment,
I would agree.
Please search the lists for the numerous complaints Libtool has
Hi Gary,
* Gary V. Vaughan wrote on Sun, Jun 27, 2010 at 12:53:39PM CEST:
On 27 Jun 2010, at 17:23, Ralf Wildenhues wrote:
The warning is almost never the last line I'd see, because for me,
configure gets triggered by 'make' which then happily proceeds to do
nasty things. No, if the disk
Hello Gary,
* Gary V. Vaughan wrote on Sat, Jun 26, 2010 at 07:14:34PM CEST:
commit b8dd17aeba9ae235d189b30ce38d64ba0ff2a309
Author: Gary V. Vaughan g...@gnu.org
Date: Sat Jun 12 00:12:09 2010 +0700
getopt.m4sh generated libtool option parser, and XSI improvements
* Gary V. Vaughan wrote on Tue, Jun 22, 2010 at 10:23:39PM CEST:
This is the improved (and renamed) `Use getopt.m4sh to generate libtool
option parser.' patch I promised yesterday. I'm pretty happy with this,
save that even though _LT_PROG_XSI_REPLACE correctly generates sed
scripts
Hi Gary,
another partial review:
* Gary V. Vaughan wrote on Tue, Jun 22, 2010 at 10:23:39PM CEST:
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
+func_stripname ()
+{
Trailing whitespace.
+case ${2} in
+ .*) func_stripname_result=`$ECHO ${3} | $SED
Hallo Ralf,
Thanks again for the review.
On 27 Jun 2010, at 04:26, Ralf Wildenhues wrote:
another partial review:
* Gary V. Vaughan wrote on Tue, Jun 22, 2010 at 10:23:39PM CEST:
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
+func_stripname ()
+{
Trailing
I forgot to commit the following chunk before extracting the
patch from git:
diff --git a/libltdl/config/getopt.m4sh b/libltdl/config/getopt.m4sh
index 1487755..76f9d35 100644
--- a/libltdl/config/getopt.m4sh
+++ b/libltdl/config/getopt.m4sh
@@ -49,6 +49,13 @@ m4_pattern_forbid([^_?m4go_])
## 1.
for this bug: libtool does not consider /usr/lib64 as default
location for libraries. On Fedora for x86_64 it's however default location for
libraries.
We would kindly ask you to incorporate patch to add /usr/lib64 as default
location for libraries to the official source code.
http
and Fedora packagers mailing list we have
found a reason for this bug: libtool does not consider /usr/lib64 as
default
location for libraries. On Fedora for x86_64 it's however default location
for
libraries.
We would kindly ask you to incorporate patch to add /usr/lib64 as default
location
libtool and write a ChangeLog entry.
Please do, you're obviously correct, the right answer slowly is always
better than the wrong one quickly.
Peter
Hallo Ralf,
[transplanted from another thread]
On 22 Jun 2010, at 00:59, Ralf Wildenhues wrote:
However, this makes me more cautious
about your other patch for using this machinery for the libtool script
itself: that is created in packages using Libtool,
Not true. We distribute
* Gary V. Vaughan wrote on Tue, Jun 22, 2010 at 07:42:27AM CEST:
# First we set _m4go_xsi_shell if the standard shell supports XSI features
# that allow us to avoid (expensive on Windows) forks:
BTW, the number of forks in libtool is even measureable for builds on
GNU/Linux. The list archive
* Gary V. Vaughan wrote on Tue, Jun 22, 2010 at 07:42:27AM CEST:
On 22 Jun 2010, at 00:59, Ralf Wildenhues wrote:
However, this makes me more cautious
about your other patch for using this machinery for the libtool script
itself: that is created in packages using Libtool,
Not true. We
you add to libtool at
configure time. I suppose we need to put them in, say,
libltd/config/xsi.m4sh where libtoolize, commit, announce-gen,
mailnotify and any future m4sh scripts can reap the benefits. This
in turn means we need to move it into a separate macro to contribute
back to Autoconf
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 fdc9248662c9473ac68b6d4c430b26298215e7d6 (commit)
via
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 1f6f90797f1c461faecaae1928c5e728b71c35b5 (commit)
from
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 c4901206cff33e5e1eae76684a9d8f416df29af5 (commit)
from
* Ralf Wildenhues wrote on Wed, Jun 09, 2010 at 08:14:45PM CEST:
I can't access an OSF1 system for testing right now, but I'm guessing
the patch below should fix this failure for good. Can you try it, by
running
make check-local TESTSUITEFLAGS='-v -d -x -k execute'
I've been able to
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 4d3ac408c863b1110ce7782d44c80b24f24111f1 (commit)
via
On 6/15/2010 1:04 AM, Charles Wilson wrote:
On 6/14/2010 11:26 PM, Ralf Wildenhues wrote:
Can you try whether this fixes the issue?
It does, but I only tried to run test 048. I'll report back tomorrow
after the whole test suite finishes. Then I'll try incrementally to
address your points
against the patch below to fix this? I'll otherwise push it
soonish.
Print Libtool project URL in program --help output.
* configure.ac (AC_INIT): Set PACKAGE argument to `GNU Libtool',
so Autoconf knows this is GNU software. For Autoconf 2.64,
if AC_PACKAGE_URL is not defined
correctly at all. And more fallout.
Any reasons against the patch below to fix this? I'll otherwise push it
soonish.
For what it's worth, this change also looks fine to me. You should be
able to apply this and advance to step #3, which is hopefully a NOP.
Bob
Print Libtool project URL
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 d640a3f4fca82e18b16eed3d6cc2f91e5cc8d74e (commit)
from
* Charles Wilson wrote on Sun, Jun 13, 2010 at 08:51:00PM CEST:
On 6/12/2010 4:58 AM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Fri, Jun 11, 2010 at 02:28:41PM CEST:
In 48, the problem occurs during libtool --clean:
/usr/src/packages/libtool/git/build/libtool: line 1693:
sub3
On 6/14/2010 11:26 PM, Ralf Wildenhues wrote:
Thanks. $objdir is a global variable set in the initial section of
the libtool script, and temporarily overriding it in func_mode_uninstall
is the wrong thing to do.
It looked fishy to me, but I assumed it was put there for a reason...but
I
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 6558f036e358528fa5d849d4ce56ebd057474d72 (commit)
from
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 23c144c1bcc5c71e05b27e7233a8bbef331cf410 (commit)
via
Is Autoconf = 2.64 spread widely enough for Libtool development by now?
If not, that could probably be hacked around in configure.ac, but I'd
need to test with old Autoconf then.
Anyway, this updates --help output of libtool, libtoolize, and the
testsuite script to match current GNU Coding
* Ralf Wildenhues wrote on Sun, Jun 13, 2010 at 01:41:47PM CEST:
Print Libtool project URL in program --help output.
* configure.ac (AC_PREREQ): Require Autoconf 2.64 for Libtool.
(AC_INIT): Set URL argument.
* Makefile.am (edit): Substitute PACKAGE_URL.
($(srcdir
Updated patch. This one doesn't require 2.64 any more, it just sets
PACKAGE_URL itself with older Autoconfs, and it changes the PACKAGE_NAME
to GNU Libtool. The GNU prefix lets Autoconf = 2.64 compute the
right gnu.org web page automatically.
This:
* Ralf Wildenhues wrote on Sun, Jun 13, 2010
On Sun, 13 Jun 2010, Ralf Wildenhues wrote:
* Ralf Wildenhues wrote on Sun, Jun 13, 2010 at 01:41:47PM CEST:
I'd like to change PACKAGE to be 'GNU libtool' eventually, but that
affects things like grepping generated .lo and .la files, and I don't
want to go there right now.
turned out
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 2a4278537315a9b073f2669e56753b41d5ab493d (commit)
from
(formerly execute_dlfiles)
with newlines, rather than, as formerly, with spaces?
The indentation in the generated libtool script is a bit awkward,
but I guess there's little we can do about it with this scheme.
The handling of --dlopen=..., --mode=..., --tag=..., now increased by
two forks and one
busy work to me when the existing ';' works very
well, and is more general.
The indentation in the generated libtool script is a bit awkward,
but I guess there's little we can do about it with this scheme.
I did try to fix that by injecting tabs after each newline, but
couldn't get the m4 quoting
func_opt_split any more. My guess is that this
would increase libtool execution time for typical compile commands by
a noticeable amount, since we got them down to about half a dozen forks.
Please fix this.
That's quite an invasive change, since the core of the M4SH_GETOPTS
generated code
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 cc051734a33855b2aeca4be96610feb4f4a8d49a (commit)
from
--git a/ChangeLog b/ChangeLog
index 48b26f8..fe68bd4 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
2010-06-11 Gary V. Vaughan g...@gnu.org
+ Use getopt.m4sh to generate libtool option parser.
+ * libltdl/config/ltmain.m4sh: Replace hand written shell code
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 90231d3e97cc87fd19872832f57f879e68163380 (commit)
from
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 cd0b95778b73f5101d4e10bda30a24191d8e1eae (commit)
from
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 c0aed9ccd030563897155ec3013086d213fcf8b8 (commit)
from
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 a50e0106eac68939708e1b6bb69d2da61556c426 (commit)
from
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 8f241f6eaa8acbbe3f4b766a40a1bef7b45f56c2 (commit)
from
whether to skip.
(LT_AT_EXEC_TAG): New macro, to also ensure runnability.
* tests/convenience.at (Java convenience archives): Use
LT_AT_EXEC_TAG, simplify accordingly.
* tests/flags.at (passing lt_tag flags through libtool): Use
m4_defn for tag so LT_AT_TAG works.
* tests/infer
: Update.
Report by Jay K.
diff --git a/tests/execute-mode.at b/tests/execute-mode.at
index a1a1ee2..55f776c 100644
--- a/tests/execute-mode.at
+++ b/tests/execute-mode.at
@@ -1,6 +1,6 @@
# execute-mode.at -- libtool --mode=execute -*- Autotest -*-
#
-# Copyright (C) 2008, 2009 Free
Hello,
I link 3 libraries with libtool. The first one is linked with hdf lib that
is in system (/usr/lib), the
second one is linked with vtk lib that is not in system ($VTKHOME) and the
third one is linked
with the 2 previous libs.
The problem is that there is another vtlk lib in system (/usr
Salut Christian,
On 9 Jun 2010, at 14:41, Christian CAREMOLI wrote:
Hello,
I link 3 libraries with libtool. The first one is linked with hdf lib that is
in system (/usr/lib), the
second one is linked with vtk lib that is not in system ($VTKHOME) and the
third one is linked
with the 2
. Vaughan (g...@gnu.org)
___
http://lists.gnu.org/mailman/listinfo/libtool
not trying to subvert it or criticize it. I
was just trying to make the Windows libtool support better.
But you are subverting it and you are criticizing it when you say
that it should be done right. Of course it can be done better. That's
true of all software. But you have to understand that I'm
there.
dependency_libs in libhdf5.la does not contain -L/usr/lib. I have already
checked that.
dependency_libs=' -lpthread -lz -lm'
Regards
Christian
I link 3 libraries with libtool. The first one is linked with hdf lib that
is in system (/usr/lib), the
second one is linked with vtk lib that is not in system
the install process of libhdf not to record
-L/usr/libs there.
dependency_libs in libhdf5.la does not contain -L/usr/lib. I have already
checked that.
dependency_libs=' -lpthread -lz -lm'
Are you using a stock libtool? Or a patched version packaged by your OS vendor?
Have you looked along
Hi Christian,
[[Libtool list added back in to Cc:]]
On 9 Jun 2010, at 21:17, christian caremoli wrote:
2010/6/9 Gary V. Vaughan g...@gnu.org
Most likely your libhdf.la has -L/usr/libs in its dependency_libs entry.
You can fix that by editing the libhdf.la file to pass the library name
Libtoolers!
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl, which
hides the complexity of loading dynamic runtime libraries (modules) behind
a consistent, portable interface.
Here are the compressed sources
/
___
http://lists.gnu.org/mailman/listinfo/libtool
Hi Christian,
[[Libtool list added back in to Cc:]]
Please don't top post on technical lists, but thanks for not sending the long
logs to the list :)
On 9 Jun 2010, at 23:10, christian caremoli wrote:
2010/6/9 Gary V. Vaughan g...@gnu.org
Hi Christian,
[[Libtool list added back in to Cc
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 e0c89b9a0768516b8f67a33af15838679821ee3b (commit)
from
just use gnulib's
announce-gen if it is good enough for us? And if it isn't, shouldn't we
try to get the improvements of your version into gnulib's, or even try
to get gnulib to adopt the libtool variant?
In general, I agree. But personally, I despise perl, and even had I
invested the effort
/convenience.at (Java convenience archives): Use
LT_AT_EXEC_TAG, simplify accordingly.
* tests/flags.at (passing lt_tag flags through libtool): Use
m4_defn for tag so LT_AT_TAG works.
* tests/infer-tag.at (GCJ inferred tag): Simplify.
* THANKS: Update.
Report by Warren Dodge.
diff
[[Adding Libtool List]]
On 8 Jun 2010, at 08:56, Charles Wilson wrote:
What happens if libltdl is
used to load (say) libtiff which has an automatic dependency on libjpeg?
The initial LoadLibrary from libltdl pulls in libtiff.dll AND
libjpeg.dll, but only libtiff.dll gets a registered handle
[[Adding Libtool List]]
On 8 Jun 2010, at 08:42, Charles Wilson wrote:
Which is why I don't think even the Peter's long-ready MSVC patches, nor
my pile of pending patches, are candidates for this extremely shortened
release cycle.
Regarding these patches, I honestly have paid very little
On Tue, 8 Jun 2010, Gary V. Vaughan wrote:
[[Adding Libtool List]]
On 8 Jun 2010, at 08:42, Charles Wilson wrote:
Which is why I don't think even the Peter's long-ready MSVC patches, nor
my pile of pending patches, are candidates for this extremely shortened
release cycle.
Regarding
Hi Gary!
Den 2010-06-08 09:34 skrev Gary V. Vaughan:
[[Adding Libtool List]]
On 8 Jun 2010, at 08:42, Charles Wilson wrote:
Which is why I don't think even the Peter's long-ready MSVC patches, nor
my pile of pending patches, are candidates for this extremely shortened
release cycle
Hi Vincent,
On 8 Jun 2010, at 15:17, Vincent Torri wrote:
On Tue, 8 Jun 2010, Gary V. Vaughan wrote:
[[Adding Libtool List]]
On 8 Jun 2010, at 08:42, Charles Wilson wrote:
Which is why I don't think even the Peter's long-ready MSVC patches, nor
my pile of pending patches, are candidates
to cherry-pick from the branch it's another
story, then my request for advise will be applicable.
Please advice.
No longer needed, but thanks for your time anyway. :-)
Cheers,
Peter
___
http://lists.gnu.org/mailman/listinfo/libtool
virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
___
http://lists.gnu.org/mailman/listinfo/libtool
,
Peter
___
http://lists.gnu.org/mailman/listinfo/libtool
to represent merges?
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
___
http://lists.gnu.org/mailman/listinfo/libtool
On Tue, Jun 8, 2010 at 4:22 AM, Peter Rosin p...@lysator.liu.se wrote:
Hi Gary!
Den 2010-06-08 09:34 skrev Gary V. Vaughan:
[[Adding Libtool List]]
On 8 Jun 2010, at 08:42, Charles Wilson wrote:
Which is why I don't think even the Peter's long-ready MSVC patches, nor
my pile of pending
://lists.gnu.org/mailman/listinfo/libtool
On 8 Jun 2010, at 15:22, Peter Rosin wrote:
Hi Gary!
Hey Peter!
Den 2010-06-08 09:34 skrev Gary V. Vaughan:
[[Adding Libtool List]]
On 8 Jun 2010, at 08:42, Charles Wilson wrote:
Which is why I don't think even the Peter's long-ready MSVC patches, nor
my pile of pending patches
the Peter's long-ready MSVC patches, nor
my pile of pending patches, are candidates for this extremely shortened
release cycle.
Regarding these patches, I honestly have paid very little attention to
Windows fixes for libtool because I can't test them, and don't use them:
So I figured someone
On 6/8/2010 2:46 AM, Gary V. Vaughan wrote:
[[Adding Libtool List]]
On 8 Jun 2010, at 08:56, Charles Wilson wrote:
What happens if libltdl is
used to load (say) libtiff which has an automatic dependency on libjpeg?
The initial LoadLibrary from libltdl pulls in libtiff.dll AND
libjpeg.dll
have paid very little attention to
Windows fixes for libtool because I can't test them, and don't use them:
So I figured someone else was taking care of it. Since that obviously
isn't the case, and because I'd hate to see them bitrotting indefinitely
in the list archives, we can either commit them
might have to work around
any issues created from the merge of the pr-msvc-support branch.
So, me working around issus with your patches is better exactly how?
Obviously making more work for 1 person shouldn't stop libtool
progress, but I think taking the time to come up with a plan on what
. What I
meant is that it is more work than the status quo. I can keep up with
libtool master right now with ease, I don't know what would happen
after the pr-msvc-branch was merged. I would like it if the few people
interested in Windows support would collaborate more (more on that
below
might have to work around
any issues created from the merge of the pr-msvc-support branch.
Obviously making more work for 1 person shouldn't stop libtool
progress, but I think taking the time to come up with a plan on what
will be supported when the branch is merged in and making it useful
)
___
http://lists.gnu.org/mailman/listinfo/libtool
, and the
attitude of just get that out the door first doesn't seem to be an
approach in the right direction. I realize you have done a lot of work
on that branch, and I am not trying to subvert it or criticize it. I
was just trying to make the Windows libtool support better.
But you are subverting
used.
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
)
___
http://lists.gnu.org/mailman/listinfo/libtool
that libltdl is not aware of.
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
file do add value.
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
trying to make the Windows libtool support better.
But you are subverting it and you are criticizing it when you say
that it should be done right. Of course it can be done better. That's
true of all software. But you have to understand that I'm at a point
where I since long have stopped adding new
for compilers on BlueGene BG/L.
thanks for the new release! The IBM BlueGene compiler tests were done on
BG/P systems, not on BG/L systems though.
Cheers,
Christian
___
http://lists.gnu.org/mailman/listinfo/libtool
___
http://lists.gnu.org/mailman/listinfo/libtool
)
___
http://lists.gnu.org/mailman/listinfo/libtool
libtool versioning -*- Autotest -*-
#
-# Copyright (C) 2009 Free Software Foundation, Inc.
+# Copyright (C) 2009, 2010 Free Software Foundation, Inc.
#
# This file is part of GNU Libtool.
#
@@ -190,18 +190,17 @@ AT_CHECK([$LIBTOOL --mode=uninstall rm -f
$libdir/liba.la
* Ralf Wildenhues wrote on Mon, Jun 07, 2010 at 10:42:42PM CEST:
Fix versioning test for LDFLAGS=-Wl,--as-needed.
As a followup, I'm fixing the test for w32 systems with this obvious
patch.
Cheers,
Ralf
Make versioning test stricter for w32, enable shared libs.
*
if it is good enough for us? And if it isn't, shouldn't we
try to get the improvements of your version into gnulib's, or even try
to get gnulib to adopt the libtool variant?
In general, I agree. But personally, I despise perl, and even had I
invested the effort in figuring out the correct string
gnulib's
announce-gen if it is good enough for us? And if it isn't, shouldn't we
try to get the improvements of your version into gnulib's, or even try
to get gnulib to adopt the libtool variant?
I realize my reaction to an earlier suggestion of yours about this was a
bit inconsistent
, but on a general note, shouldn't we either just use gnulib's
announce-gen if it is good enough for us? And if it isn't,
shouldn't we
try to get the improvements of your version into gnulib's, or even try
to get gnulib to adopt the libtool variant?
In general, I agree. But personally, I despise perl
, but on a general note, shouldn't we either just use gnulib's
announce-gen if it is good enough for us? And if it isn't,
shouldn't we
try to get the improvements of your version into gnulib's, or even try
to get gnulib to adopt the libtool variant?
In general, I agree. But personally, I despise perl
looked in detail at these
changes
yet, but on a general note, shouldn't we either just use gnulib's
announce-gen if it is good enough for us? And if it isn't,
shouldn't we
try to get the improvements of your version into gnulib's, or even try
to get gnulib to adopt the libtool variant
1401 - 1500 of 5838 matches
Mail list logo
