Hello,
I am trying to compile libtool so I can install another package which requires
it. I have successfully compiled M4, Automake, Autoconf and installed in
/usr/gnu.
When I try to do the same for libtool, I receive errors.
I have tried the following:
./configure --prefix=/usr/gnu
/usr/css
Hi Christophe,
Thanks for your interest in GNU Libtool.
I'm redirecting this conversation to the libtool mailing list, as there are
many other people
here who will also be interested in the answer to this question.
On 10 Apr 2012, at 01:18, Christophe Jarry wrote:
I browsed
http
When I try to build existing GNU toolchain projects
using the Android and NDK sometimes I run into
problems with pthread. I get errors like this:
../../arm-linux-androideabi/bin/ld: cannot find -lpthread
Is there a switch to libtool to would ignore -lpthread
if it is found since Android
On Tue, 3 Apr 2012, greno wrote:
When I try to build existing GNU toolchain projects
using the Android and NDK sometimes I run into
problems with pthread. I get errors like this:
../../arm-linux-androideabi/bin/ld: cannot find -lpthread
Is there a switch to libtool to would ignore -lpthread
because there is no external pthread library for Android.
And that is why I was mentioning about
a libtool switch to ignore -lpthread or some kind of conditional that could be
used to detect Android.
Libtool does not add the -lpthread request. The configure script for
whatever project you
And that is certainly an option although a highly intrusive one which for many
projects is not necessary.
I mean we have many different GNU toolchain projects that work on many
different platforms from a single codebase.
Libtool makes adjustments for other types of platforms. And this is just
the error I
showed above.
The error is correct because there is no external pthread library for
Android. And that is why I was mentioning about
a libtool switch to ignore -lpthread or some kind of conditional that could
be used to detect Android.
Libtool does not add the -lpthread request
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 11cd425e7d47111956381dba28f8c1b34e14653f (commit)
from
file is processed by libtool then it automatically
performs
this
set of commands:
libtool: link: if test x`/bin/sed 1q .libs/libcairo.def` = xEXPORTS;
then
cp .libs/libcairo.def .libs/libcairo-2.dll.def; else echo EXPORTS
.libs/libcairo-2.dll.def; cat .libs/libcairo.def
.libs/libcairo
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 3b94c2d8e804d485cf6124adb1572f45ae697216 (commit)
from
.def file for example:
LIBRARY mylib.dll
EXPORTS
my_func
If this .def file is processed by libtool then it automatically performs
this
set of commands:
libtool: link: if test x`/bin/sed 1q .libs/libcairo.def` = xEXPORTS; then
cp .libs/libcairo.def .libs/libcairo-2.dll.def; else echo
.
Let's take this simple .def file for example:
LIBRARY mylib.dll
EXPORTS
my_func
If this .def file is processed by libtool then it automatically performs
this
set of commands:
libtool: link: if test x`/bin/sed 1q .libs/libcairo.def` = xEXPORTS;
then
cp .libs/libcairo.def .libs
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 9333e74fc7b76a11ed04a19343eb5dd75a1035f3 (commit)
via
and Math Division
Oak Ridge National Laboratory
On Dec 8, 2011, at 12:19 AM, Peter O'Gorman wrote:
On 12/05/2011 11:48 AM, Shamis, Pavel wrote:
Hi,
As have been mentioned on the list, libtool error reporting - file not found is not
perfect. People suggested to fix it (hxxp://www.mail-archive.com
URL:
http://savannah.gnu.org/support/?107959
Summary: Libtool generates invalid .def files
Project: GNU Libtool
Submitted by: epienbro
Submitted on: Sun 19 Feb 2012 10:45:44 PM GMT
Category: None
Priority
.
In my opinion, it would be better to be able to provide him with a
single .a library that includes the entirety of the frontend and backend
libraries. Right now I am at a loss on how to accomplish this with
Libtool. Perhaps Libtool is not the way to accomplish this as suggested
by the Automake
of the frontend and backend
libraries. Right now I am at a loss on how to accomplish this with
Libtool. Perhaps Libtool is not the way to accomplish this as suggested
by the Automake documentation and perhaps a specific Makefile target is
needed to build the single archive?
Libtool does support
Hi,
Please do not post single issue to multiple mailing lists
without consideration about appropriate list. You have
posted this message to fontconfig and libtool mailing list.
In my impression (with your messages in other mailing lists),
your experience is insufficient to execute autogen.sh
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 b804ffabee2ce373d9bac6ae2b235ec68e0b55e8 (commit)
from
Hullo Users,
on running ./autogen.sh while installing pangocairo i get the errors below
Making all in opentype
make[4]: Entering directory `/usr/local/src/pango-1.28.4/pango/opentype'
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H
-I. -I../.. -DHAVE_GLIB -pthread -I/include
On Wed, 1 Feb 2012, Russ Allbery wrote:
I think the primary question is why Libtool is using -nostdlib when
linking C++ libraries. The bug discussion at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460
says that it's because of some other issue with libstdc++ linkage with
dlopened
have done the same.
The easiest fix is likely for libtool to know that if -pthread was
specified to the compiler that it should add -lthread while linking.
Well, I don't know why libtool insists on -nostdlib, but I think we
should just give up on it and assume the compiler works.
If g++ creates
:
On 12/05/2011 11:48 AM, Shamis, Pavel wrote:
Hi,
As have been mentioned on the list, libtool error reporting - file not
found is not perfect. People suggested to fix it
(hxxp://www.mail-archive.com/libtool@gnu.org/msg12156.html) but it seems,
that the changes have never been
On 1/8/12 2:27 AM, Werner LEMBERG wrote:
And another ping!
Werner
I've found this interesting mail:
http://lists.gnu.org/archive/html/libtool-patches/2011-08/msg0.html
Interestingly, there was no comment at all. So my question: Is this
the `right' approach? Will libtool
years since I've used them.
You are somehow forgetting Windows, probably the most widespread system of
them all. On Windows, you have to specify all libraries at link time and
Libtool helps with that.
Cheers,
Peter
___
https://lists.gnu.org/mailman
to specify all libraries at link time
and Libtool helps with that.
Indeed, I did forget Windows. (Although while it's the most widespread
system of them all, it's a small fraction of the platforms on which people
use Libtool on a day-to-day basis.)
I wouldn't argue for breaking Libtool's ability
On Sat, 7 Jan 2012, Russ Allbery wrote:
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes:
I think that it is wrong to solely blame libtool for this state of
affairs. In order for a project to work properly on non-ELF systems, or
where installed shared libraries have abbreviated/truncated
the whole problem
For detecting library features such as the availabilty of functions.
Over the years, Autoconf principles have not changed much. It could
have usefully absorbed knowledge of libtool and its installed .la
files (but it did not).
Pkg-config is optional software which only
And another ping!
Werner
I've found this interesting mail:
http://lists.gnu.org/archive/html/libtool-patches/2011-08/msg0.html
Interestingly, there was no comment at all. So my question: Is this
the `right' approach? Will libtool provide something similar
Hello,
I'm sad when I hear people rant about libtool, and I would like to
know the answers to that rants. The following bugs were, as I
supposed, known for years, but I may be wrong - perhaps they were
resolved years ago or they were never filed.
I would be very grateful if you could give me
distributions for many years).
(I believe that the rule that forbids packing .la files to -dev and
-devel subpackages on Debian and Fedora (respectively), is there just
to work around this problem.)
This is still an issue, libtool always adds all dependencies. Many
packages assume this and don't explicitly
On Fri, 6 Jan 2012, Peter O'Gorman wrote:
This is still an issue, libtool always adds all dependencies. Many packages
assume this and don't explicitly add required dependencies to Makefile.am
etc. I don't recall the arguments for not changing this when building shared.
IIRC Scott tried
These questions are quite common, and what they really come down to is that
many (or most) users want to solve a *different problem* than the one that
Libtool was designed to solve.
Libtool will deal with the platform specific vagaries of shared libraries
in a uniform manner. It isn't designed
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes:
On Fri, 6 Jan 2012, Peter O'Gorman wrote:
This is still an issue, libtool always adds all dependencies. Many
packages assume this and don't explicitly add required dependencies to
Makefile.am etc. I don't recall the arguments
://www.eyrie.org/~eagle/
___
https://lists.gnu.org/mailman/listinfo/libtool
resolution
(which is the case on GNU/Linux distributions for many years).
(I believe that the rule that forbids packing .la files to -dev and
-devel subpackages on Debian and Fedora (respectively), is there just
to work around this problem.)
This is still an issue, libtool always adds all dependencies
an executable named testuseragent_shared that gets linked
against libxtls.la:
testuseragent_shared_SOURCES=testuseragent.C
testuseragent_shared_LDADD=libxtls.la
From this, libtool produces a wrapper for testuseragent_shared in the source
tree, that reads as follows (linewrapped):
LD_LIBRARY_PATH
libxtls_la_LDFLAGS=-version-info 1 $(GNUTLS_LIBS) $(GCRYPT_LIBS)
-lpthread
libtool use LDFLAGS before LIBADD as result paths form LDFLAGS will be
used first.
Move $(GNUTLS_LIBS) $(GCRYPT_LIBS) -lpthread to LIBADD adn try again.
Roumen
___
https
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 7a78cca31bca68f3cf2e398d26b03f3980331d72 (commit)
via
with a timeout, trying
again, I finally got a retry timeout exceeded.
Anyway, since I know that you are (were?) involved with libtool development, I
thought you might know a different way to deliver the message below to whoever
it might be suitable for :).
Cheers,
Max
Anfang der weitergeleiteten E
On 12/17/2011 10:22 PM, Gary V. Vaughan wrote:
libtool: minimise forks per invocation under bash.
* build-aux/general.m4sh (lt_HAVE_PLUSEQ_OP, lt_HAVE_ARITH_OP)
(lt_HAVE_XSI_OPS): Set these without forking a test script when
running under bash, to avoid a few unnecessary
On 12/18/2011 06:33 AM, Gary V. Vaughan wrote:
Can anyone think of something better than just removing the whole
lt_HAVE_PLUSEQ_OP
clause from the patch quoted above, and letting the shell figure it by
itself later
on?
Adding an extra eval seems to do the trick:
Yes - hiding behind eval
On 12/18/2011 06:49 AM, Gary V. Vaughan wrote:
* build-aub/general.m4sh (lt_HAVE_PLUSEQ_OP): Instead of using
$((..)) arithmetic, which causes an error on dash, use a case
based bash version check.
Dash understands $(( )). What it doesn't understand is ${BASH_VERSINFO[0]}.
Solaris /bin/sh
Hi Eric.
On 12/19/2011 02:44 PM, Eric Blake wrote:
On 12/17/2011 10:22 PM, Gary V. Vaughan wrote:
We should try to minimise forks, especially on Windows where they are
+# unreasonably slow, so skip the feature probes when bash is being used:
+if test set = ${BASH_VERSION+set}; then
+:
On 12/18/2011 06:15 AM, Gary V. Vaughan wrote:
+# We should try to minimise forks, especially on Windows where they are
+# unreasonably slow, so skip the feature probes when bash is being used:
+if test set = ${BASH_VERSION+set}; then
+: ${lt_HAVE_ARITH_OP=yes}
+: ${lt_HAVE_XSI_OPS=yes}
On 12/18/2011 10:52 AM, Stefano Lattarini wrote:
On 12/18/2011 06:15 AM, Gary V. Vaughan wrote:
+# We should try to minimise forks, especially on Windows where they are
+# unreasonably slow, so skip the feature probes when bash is being
used:
+if test set = ${BASH_VERSION+set}; then
+:
Hi Stefano,
On 18 Dec 2011, at 17:02, Stefano Lattarini wrote:
On 12/18/2011 10:52 AM, Stefano Lattarini wrote:
On 12/18/2011 06:15 AM, Gary V. Vaughan wrote:
+# We should try to minimise forks, especially on Windows where they are
+# unreasonably slow, so skip the feature probes when bash
On 12/18/2011 11:07 AM, Gary V. Vaughan wrote:
Hi Stefano,
On 18 Dec 2011, at 17:02, Stefano Lattarini wrote:
On 12/18/2011 10:52 AM, Stefano Lattarini wrote:
On 12/18/2011 06:15 AM, Gary V. Vaughan wrote:
+# We should try to minimise forks, especially on Windows where they are
+#
Hi Stefano,
On 18 Dec 2011, at 17:19, Stefano Lattarini wrote:
On 12/18/2011 11:07 AM, Gary V. Vaughan wrote:
On 18 Dec 2011, at 17:02, Stefano Lattarini wrote:
On 12/18/2011 10:52 AM, Stefano Lattarini wrote:
On 12/18/2011 06:15 AM, Gary V. Vaughan wrote:
+# We should try to minimise forks,
* build-aub/general.m4sh (lt_HAVE_PLUSEQ_OP): Instead of using
$((..)) arithmetic, which causes an error on dash, use a case
based bash version check.
(lt_HAVE_ARITH_OP, lt_HAVE_XSI_OPS): Also short circuit the
feature probing forks and set these automatically when zsh is
detected.
Reported by
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 4099c121a131784d3ab103bee848e971d8bfafcb (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 51c1877e70cdf5ca617d7ff403c1ae740d8b3a40 (commit)
from
Thanks to Eric Blake, Peter O'Gorman and Bob Friesenhahn for steering
me in this direction.
* build-aux/general.m4sh (lt_HAVE_PLUSEQ_OP, lt_HAVE_ARITH_OP)
(lt_HAVE_XSI_OPS): Set these without forking a test script when
running under bash, to avoid a few unnecessary forks.
Signed-off-by: Gary V.
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 88992fe6771ec3258bde1b03314ce579da0ac2d5 (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 8a59ee7f0acdb83c3df12f47638966675a8af051 (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 f7bd6bd9ccc54a061702b66d3fe9da4fdadcd2fc (commit)
via
that libtool wants, this patch
eliminates even those 3 new forks.
Okay to push?
* build-aux/general.m4sh (lt_HAVE_PLUSEQ_OP, lt_HAVE_ARITH_OP)
(lt_HAVE_XSI_OPS) [cygwin, mingw]: Set these without a test on
the assumption that a modern shell (i.e. bash) will be used to
run libtool and libtoolize
on some shell with
all the modern optional features that libtool wants, this patch
eliminates even those 3 new forks.
Okay to push?
I'm a bit reluctant to do this via a host check;
+# Forks are unreasonably slow under Windows, so we assume that, for at
+# least cygwin and mingw, /bin/sh
on windows.
By assuming that windows will run shell scripts on some shell with
all the modern optional features that libtool wants, this patch
eliminates even those 3 new forks.
Okay to push?
The whole reason these checks were done in configure and not in libtool was
to avoid these forks
on windows.
By assuming that windows will run shell scripts on some shell with
all the modern optional features that libtool wants, this patch
eliminates even those 3 new forks.
Okay to push?
I'm a bit reluctant to do this via a host check;
+# Forks are unreasonably slow under Windows, so we
On Thu, 8 Dec 2011, Gary V. Vaughan wrote:
Instead of doing it this way, I'd almost rather see:
if test ${BASH_VERSION+set} = set; then
Face palm! Absolutely, that is far more sensible. Assuming we decide
to push this patch, I'll do it that way and ditch the host check. Thanks!
Is the
On 12/08/2011 08:04 AM, Bob Friesenhahn wrote:
On Thu, 8 Dec 2011, Gary V. Vaughan wrote:
Instead of doing it this way, I'd almost rather see:
if test ${BASH_VERSION+set} = set; then
Face palm! Absolutely, that is far more sensible. Assuming we decide
to push this patch, I'll do it that
on some shell with
all the modern optional features that libtool wants, this patch
eliminates even those 3 new forks.
Okay to push?
Has anybody done a comparison between:
cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)
cygwin + libtool + bash (e.g. big bloated slow shell
it is important to minimize forks so that parallel compiles
don't hit an bottleneck.
Simply removing $(SHELL) from the LIBTOOL variable should fix the bug that
this is attempting to fix, without slowing down libtool.
Will this approach work ok if the Cygwin/MinGW user is using something
like zsh or dash
.
By assuming that windows will run shell scripts on some shell with
all the modern optional features that libtool wants, this patch
eliminates even those 3 new forks.
Okay to push?
Has anybody done a comparison between:
cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)
Umm
On 12/8/2011 11:22 AM, Eric Blake wrote:
On 12/08/2011 08:29 AM, Charles Wilson wrote:
cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)
Umm, dash has XSI features (where XSI features covers things like
${var##prefix}). ... Meanwhile, libtool is using more than just XSI
On 12/08/2011 09:29 AM, Charles Wilson wrote:
Has anybody done a comparison between:
cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)
cygwin + libtool + bash (e.g. big bloated slow shell -- with XSI)
to see which is better?
Because I installed mingw32 yesterday on my
been mentioned on the list, libtool error reporting - file not
found is not perfect. People suggested to fix it
(hxxp://www.mail-archive.com/libtool@gnu.org/msg12156.html) but it seems,
that the changes have never been incorporated into the trunk. I'm not well
familiar with all the details
On 12/05/2011 11:48 AM, Shamis, Pavel wrote:
Hi,
As have been mentioned on the list, libtool error reporting - file not found is not
perfect. People suggested to fix it (http://www.mail-archive.com/libtool@gnu.org/msg12156.html) but
it seems, that the changes have never been incorporated
On 11/29/2011 11:48 PM, Adam Mercer wrote:
On Mon, Nov 28, 2011 at 23:30, Andy Spencerandy753...@gmail.com wrote:
This seems to be caused by libtool adding a -rpath flag which forces the
application to use the /usr/lib64 version provided by mesa even though
ld.so.conf has been properly
On Wed, Dec 7, 2011 at 23:26, Peter O'Gorman pe...@pogma.com wrote:
Does anyone want to try again?
http://lists.gnu.org/archive/html/libtool-patches/2010-11/msg00027.html
I only have red hat like distros, so if someone could update the patch and
look at other distros that'd be great.
I can
Hi,
As have been mentioned on the list, libtool error reporting - file not found
is not perfect. People suggested to fix it
(http://www.mail-archive.com/libtool@gnu.org/msg12156.html) but it seems, that
the changes have never been incorporated into the trunk. I'm not well familiar
with all
.* but any
application built against my library uses /usr/lib64/libGL.so.* instead.
This seems to be caused by libtool adding a -rpath flag which forces the
application to use the /usr/lib64 version provided by mesa even though
ld.so.conf has been properly configured to use the nvidia version.
I can fix
On Mon, Nov 28, 2011 at 23:30, Andy Spencer andy753...@gmail.com wrote:
This seems to be caused by libtool adding a -rpath flag which forces the
application to use the /usr/lib64 version provided by mesa even though
ld.so.conf has been properly configured to use the nvidia version.
I ran
Ping! Is this really an unimportant issue?
Werner
I've found this interesting mail:
http://lists.gnu.org/archive/html/libtool-patches/2011-08/msg0.html
Interestingly, there was no comment at all. So my question: Is this
the `right' approach? Will libtool provide something
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 6a4426ee0a17cbb8fcae3e06890cd1b6dc1237b6 (commit)
from
I've found this interesting mail:
http://lists.gnu.org/archive/html/libtool-patches/2011-08/msg0.html
Interestingly, there was no comment at all. So my question: Is this
the `right' approach? Will libtool provide something similar?
Werner
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 88224124e4f57166cdcc78be29730372762a147e (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 a5ef08182ce0fb80b8adcff5872f190afd915908 (commit)
via
Hi,
I'm building our OpenSpeedShop performance tool to run on the backend
nodes of a Cray-XE machine. We use the libtool, m4, autoconf, and
automake autotools.
Everything is working accept I'm getting the wrong libstdc++ library
when linking the main program that runs on the backend nodes
++ library that is
associated with the gcc and g++ version is used.
Thanks,
Jim G
On 11/08/2011 04:56 PM, Jim Galarowicz wrote:
Hi,
I'm building our OpenSpeedShop performance tool to run on the backend
nodes of a Cray-XE machine. We use the libtool, m4, autoconf, and
automake autotools
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 0569ec6cd2df2b10136e5701411961b83142d567 (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 e73a3b080bd498c2d87314abffe0a5239b676b93 (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 c188507816c4b43f3411677116ce4ab4b926958e (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 e2c4184c38c48654e2da6728ead73314052516f6 (commit)
via
Hello,
I am trying to install a program called srecord found at
http://srecord.sourceforge.net . The author of srecord suggested also
installing libtool. I am working with the srecord in order to convert a hex
file over to a binary which I am attempting to use to program a CPU
Hi Joe,
On 1 Nov 2011, at 20:08, Joe Breedlove wrote:
Hello,
I am trying to install a program called srecord found at
http://srecord.sourceforge.net . The author of srecord suggested also
installing libtool. I am working with the srecord in order to convert a hex
file over
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 af4537cd8a1308a1c783519fccd71e08392ea66c (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 166da4d2a269b101bda8022f0a44f9c3e7ae56f9 (commit)
from
Hi Peter,
On 24 Oct 2011, at 09:13, Gary V. Vaughan wrote:
One day I'm going to have to read the documentation, so I can figure out how
to close bugs.
http://debbugs.gnu.org/db/pa/llibtool.html
I'm pretty sure you just reply to the thread with a one liner:
close 12345
Bzzzt. Wrong
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 48a213a24808a11fef0ce40cb857d3ad609ace7b (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 5db3dbc5b71d8b344a30010d00eb0f00a7af1b15 (commit)
from
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 adb7abda11c748e3c8ffc05736fd8205e2c84f74 (commit)
via d4afacc29cc3f620439854ad54ed0e14d4425ec0 (commit)
via
the bug-libtool
list yet :-)
Peter
on
the machine because 'make check' ends up using a formally-installed
gnulib .m4 file rather than the one in the libtool source tree. I
know this because I don't have gnulib installed on my machine and so
'make check' fails. The issue is due to an m4 include path problem.
Bob
--
Bob
Heh, didn't see the patches emails because I hadn't read the bug-libtool list
yet :-)
My bad... I've been away from libtool development so long that I totally forgot
to
differentiate between bug-libtool and libtool-patches. Sorry about that.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
libtool_cleanup_empty_dirs
## Resource management. ##
## ##
+# Although autobuild is awesome, libtool will bootstrap without it.
+require_autobuild_buildreq=:
+
# require_package_url
# ---
# Ensure that package_url has a sensible default.
Cheers,
--
Gary
On 10/23/2011 08:24 PM, Gary V. Vaughan wrote:
My bad... I've been away from libtool development so long that I totally forgot
to
differentiate between bug-libtool and libtool-patches. Sorry about that.
One day I'm going to have to read the documentation, so I can figure out
how to close
/bootstrap.conf
@@ -440,6 +440,9 @@ func_add_hook func_fini libtool_cleanup_empty_dirs
## Resource management. ##
## ##
+# Although autobuild is awesome, libtool will bootstrap without it.
+require_autobuild_buildreq=:
+
Yes, this lets bootstrap complete.
Thanks,
Peter
Hi Bob,
On 24 Oct 2011, at 06:34, Bob Friesenhahn wrote:
It seems that there is also a problem if gnulib is not installed on the
machine because 'make check' ends up using a formally-installed gnulib .m4
file rather than the one in the libtool source tree. I know this because I
don't have
901 - 1000 of 5838 matches
Mail list logo
