Follow-up Comment #14, sr #108201 (project libtool):
Regarding the -no-undefined issue, I believe it is correct to
set -no-undefined in LDFLAGS in export.at. This is the case
since libtool is used to link in that test, and nothing else.
Or is LDFLAGS special in some way on Solaris, so
Follow-up Comment #5, sr #108201 (project libtool):
Here is my feable and first attempt to detect the problem using the
testsuite.
First, the test export.at seems to work by default, but it is only a gcc
(simple 'C') test:
richard@devzone:~/src/libtool$ gmake check-local TESTSUITEFLAGS=45 -d
cd
Follow-up Comment #6, sr #108201 (project libtool):
And here is the diff for the proposed patch.
After cleanup and rebuilding (seemed like a zillion autoreconfs)
running the export tests as indicated (both for standard and CC=g++) are
successful.
richard@devzone:~/src/libtool$ git diff --staged
Follow-up Comment #7, sr #108201 (project libtool):
Can you please re-post your patch as a file attachment? It seems that posting
as a comment trashes the patch.
Do any of the existing libtool test cases test the functionality you are
fixing?
Also, libtool.m4 is at m4/libtool.m4 in current git
Follow-up Comment #8, sr #108201 (project libtool):
Bob, please see comment #5
As I indicated, local test n° 45 export.at is the existing test.
I added the following line :
AT_CHECK([elfdump -d .libs/liba.so | grep SONAME],[], [ignore], [ignore])
to ensure that the SONAME was being added
Follow-up Comment #9, sr #108201 (project libtool):
BTW Bob, perhaps you didn't catch that I did a
$git checkout v2.4.2
since it appears much has changed since the last stable.
This is why, I believe, the tests indicate
## GNU Libtool 2.4.2 test suite
Follow-up Comment #10, sr #108201 (project libtool):
Dropping -no-undefined from LDFLAGS in export.at kills the test
on Windows and it's unacceptable to assume that elfdump
exists. Passing -no-undefined to libtool is NOT a misnomer and
-no-undefined is in fact a perfectly valid libtool option
On Wed, 12 Dec 2012, Peter Rosin wrote:
Follow-up Comment #10, sr #108201 (project libtool):
Dropping -no-undefined from LDFLAGS in export.at kills the test
on Windows and it's unacceptable to assume that elfdump
exists. Passing -no-undefined to libtool is NOT a misnomer and
-no-undefined
Follow-up Comment #11, sr #108201 (project libtool):
I guess I can add the following:
1. regarding -no-undefined, when I changed this to avoid the syntax error on
solaris (which should be, for example, -Wl,--no-undefined), the linker
complained that it was a duplicate option implying, I believe
Follow-up Comment #1, sr #108201 (project libtool):
trying to bootstrap git base to provide a test case and patch proposal, but I
notice some problems already in doing after ./bootstrap ./configure
gmake check syntax-check distcheck
## - ##
## Test results
Follow-up Comment #2, sr #108201 (project libtool):
I notice that the error message mentions the program name 'sed' rather than
'gsed'. Perhaps two different sed programs are being used? It seems likely
that the 'sed' which failed is Solaris 'sed' rather than GNU 'sed
Follow-up Comment #3, sr #108201 (project libtool):
Hello Bob,
I wonder too, which is why I indicated at the end of my last comment:
does libtool not like pkgsrc version of sed?
richard@devzone:~/src/libtool$ which sed
/opt/pkg/gnu/bin/sed
richard@devzone:~/src/libtool$ grep 'SED
Follow-up Comment #4, sr #108201 (project libtool):
I was working off of master. With git blame I noticed that the strcmp problem
was introduced recently, so I'm trying over after git checkout v2.4.2, which
is the latest tarball version I've tested with pkgsrc.
HEAD is now at fdb4c54... Release
- Original Message -
From: Bob Friesenhahn invalid.nore...@gnu.org
Date: Tuesday, December 11, 2012 9:57 am
Subject: [sr #108201] libtool problems with -export-symbols-regex on solaris
with gcc-4.7.x
To: Richard PALO richard.p...@baou.fr, Bob Friesenhahn
bfrie...@simple.dallas.tx.us
On Tue, 11 Dec 2012, Dennis Clarke wrote:
Follow-up Comment #2, sr #108201 (project libtool):
I notice that the error message mentions the program name 'sed' rather
than
'gsed'. Perhaps two different sed programs are being used? It seems
likely
that the 'sed' which failed is Solaris 'sed
URL:
http://savannah.gnu.org/support/?108201
Summary: libtool problems with -export-symbols-regex on
solaris with gcc-4.7.x
Project: GNU Libtool
Submitted by: risto3
Submitted on: lun. 10 déc. 2012 13:58:02 GMT
Category
Good morning, I was curious whether it is possible to force GNU libtool to use
the Solaris CC compiller instead of GCC? If so, how might that be done? Thank
you ___
https://lists.gnu.org/mailman/listinfo/libtool
./configure ... CXX=/opt/solarisstudio12.3/bin/CC
CC=/opt/solarisstudio12.3/bin/cc
On Mon, Dec 10, 2012 at 5:44 AM, Frank Chang frank_chan...@hotmail.comwrote:
Good morning, I was curious whether it is possible to force GNU libtool to
use the Solaris CC compiller instead of GCC? If so, how
.
Date: Mon, 10 Dec 2012 11:18:50 -0600
Subject: Re: Is it possible to force GNU libtool to use the Solaris CC
compiller instead of GCC?
From: rboe...@gmail.com
To: frank_chan...@hotmail.com
CC: libtool@gnu.org
./configure ... CXX=/opt/solarisstudio12.3/bin/CC
CC=/opt/solarisstudio12.3/bin/cc
ahead and close the bug report, leaving
the matter in the hands of the libtoolers.
I've closed this report now.
Regards,
Stefano
___
https://lists.gnu.org/mailman/listinfo/libtool
, but with automake 1.12:
$ autoreconf -f -i
...
ltlibrary.am: warning: 'libfoo.la': linking libtool libraries using a
non-POSIX
ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac'
Makefile.am:1: while processing Libtool library 'libfoo.la'
what gives ?
If you don't want *all* warnings
On 2012-11-16 21:02, Dennis Clarke wrote:
So I guess we have progress here .. sort of.
Good!
$ pwd
/usr/local/build/libtool-2.4.2_Nov_06_0153_SunOS5.10_sparcv9
$ cp -p ./test-suite.log
libtool-2.4.2_Nov_06_0153_SunOS5.10_sparcv9_test-suite.log
see attached testsuite log file.
If you
___
https://lists.gnu.org/mailman/listinfo/libtool
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 34fe402efa1e969cf902cf7370e29564c005d508 (commit)
via
/usr/local/src/libtool-2.4.2.tar.gz
/usr/local/src/libtasn1-2.14.tar.gz
/usr/local/src/libtool_git_Mon_Nov_05_2012.star.gz
$ /usr/sfw/bin/openssl dgst -sha1 /usr/local/src/libtool-2.4.2.tar.gz
SHA1(/usr/local/src/libtool-2.4.2.tar.gz
On 2012-11-06 12:45, Peter Rosin wrote:
The lt_libltdl_LTX_preloaded_symbols symbol is supposed to be in an
automatically
generated file, which isn't generated because configure does not recognize the
$NM output. Libtool wants BSD style output.
hex address symbol type symbol name
e.g
++
4 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/NEWS b/NEWS
index 081e82f..33beb68 100644
--- a/NEWS
+++ b/NEWS
@@ -98,6 +98,8 @@ New in 2.4.2 2011-10-17: git version 2.4.1a, Libtool team:
package names. This can be used to build some static libraries with PIC
* build-aux/ltmain.h(libtool_validate_options): Add *os2* to the list.
---
build-aux/ltmain.in |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 4e53936..ede32eb 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@
* m4/libtool.m4(_LT_COMPILER_PIC): Same as the title.
---
m4/libtool.m4 | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index f269fc4..3d36d5d 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3901,6 +3901,11 @@ m4_if([$1],
*build-aux/ltmain.in(func_mode_link): Set need_relink to no on OS/2.
---
build-aux/ltmain.in |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index ede32eb..10396a7 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@
*m4/libtool.m4(_LT_CHECK_MAGIC_METHOD): Same as the title.
---
m4/libtool.m4 |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 3d36d5d..3a80989 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3345,6 +3345,9 @@ sysv4 | sysv4.3*)
Link is not supported on OS/2.
*build-aux/ltmain.in(fund_mode_install): Create an import library.
(fund_mode_link): Likewise.
---
build-aux/ltmain.in | 23 ---
1 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index
Since it is safe for $lt_cv_sys_global_symbol_to_cdecl to match
with a simple /^T .* .*$/ type expression, it is ok for the other
transformations as well. At least if you require at least one
$symcode at the start of the line, so that the just generated output
doesn't match the next sed
* m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Break up long lines when
assigning the sed scripts that transform the extracted symbol lines.
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
m4/libtool.m4 | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git
for imported data symbols. Add new
lt_cv_sys_global_symbol_to_import which finds imported data
symbols if non-empty and export this variable to the libtool script
in the global_symbol_to_import variable. Adjust
lt_cv_sys_global_symbol_pipe so that data imports can be located.
* build-aux/ltmain.in
On 10/26/2012 07:22 PM, Dan Nicholson wrote:
Sorry if this is terse, I'm on my phone. In the first case, you're
using a library, liblog4cplus.so, that's installed in your home
directory. Libtool sees this as outside the dynamic linker's path and
adds a runpath so you're program will find
/liblog4cplus.so -pthread -Wl,-rpath
-Wl,/home/jwl/build/usr/local/lib -Wl,-rpath
-Wl,/home/jwl/build/usr/local/lib
whereas the last bit of the one that works has:
libtool: link: g++ -g -O2 -o vaprobe protoarduino.o pdbutil.o timer.o
arcserver.o probethread.o protocamera.o protosimple.o vaprobe.o
. Libtool
sees this as outside the dynamic linker's path and adds a runpath so you're
program will find the library at runtime without setting any environment
variables. This is either helpful or a nuisance depending on your
perspective.
One thing I'd suggest is rather than toying with prefix, which
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 cdd7f33f06e5864fdf0d13731398f5021e285647 (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 9f2b41f6d9a74e9d4e3a3d959da0e81a3f5d7a23 (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 f1a3325bf86a015d28930982bfa28f9c63621745 (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 d5c146580c21ee603458d92983d27e7af1260667 (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 7b059d5ad9ed1d35ba6aa0f4fb01501b07fdd6c3 (commit)
from
):
## -- ##
## Detailed failed tests. ##
## -- ##
# -*- compilation -*-
21. libtool.at:60: testing quote shell meta-characters in filenames ...
/home/bfriesen/src/gnu/libtool-head/tests/libtool.at:101: $LIBTOOL -n --mode=$mode
$preargs $preflag$flag:test
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 c82eaf360b1d2797054296c5e894c1271fffb7cf (commit)
from
With today's development libtool, I am seeing a number of errors like
# -*- compilation -*-
8. libtoolize.at:378: testing diagnose missing LT_CONFIG_LTDL_DIR ...
/home/bfriesen/src/gnu/libtool-head/tests/libtoolize.at:437: $LIBTOOLIZE --copy
--install --ltdl=ltdl
://lists.gnu.org/mailman/listinfo/libtool
it has stayed hidden for so long! :-o
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
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 6c51572ae0748629da0144ed5b640a3e7abc35d3 (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 0dd94ed521e52ca901e845b39bbc33f16174a325 (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 05bd3f8b862effa756b2bd1aa52a6926914290cd (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 cfcb7afd26a2c41f3dae62766002cac570417c77 (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 a3b06455e9c78ba5d3b7261f1c1d6e51029f6335 (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 92b77ed8bbf615ff2ed7710d9da1aae2e97755e8 (commit)
from
Hi!
I have pushed the below patch.
Cheers,
Peter
From cfcb7afd26a2c41f3dae62766002cac570417c77 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Thu, 18 Oct 2012 14:27:10 +0200
Subject: [PATCH] libtool: fix spelling nit
* build-aux/ltmain.in (func_generate_dlsyms): Fix
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 b3e96ce7d1566d6120112f3b10e7782cc62cff8d (commit)
from
Hello all,
I'm a Guile developer who is trying to figure out the best way to add a
Guile-specific 'extensions' directory to the library search path, while
retaining the ability of 'libtool --mode=execute -dlopen' to take
precedence over our default extensions directory.
As I understand
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 5962e9ab32b54d37d5cece3dea56cdd3fcf1f914 (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 b78fd9740ef6a2ed67a1ef14e76483af784fb5f0 (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 0b1b67186407f1b03cc0c5bf1882a8db8e0ee2e2 (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 9847559cef654e7ae587aea13b2a084ab2a5eb40 (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 a61a1114ae1464c39b54e88d1a30735c7daca4b2 (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 991b5e52a77c4705614387b370219b3a24e9dc1c (commit)
from
.
Awesome.
I'll push the merge now, along with some other resurrected patches that
got stuck in the review queue last year.
Now into nitpicking and other useless ramblings...
The patch libtool: unroll nested if into a single case statement has
whitespace issues (leading spaces instead of tabs
On 2012-10-05 13:15, Gary V. Vaughan wrote:
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.
ARRRGH!
I assume this is what you referred to when you talked about some stuff
a/Makefile.am b/Makefile.am
diff --git a/tests/cdemo.at b/tests/cdemo.at
index f50106c..885845c 100644
--- a/tests/cdemo.at
+++ b/tests/cdemo.at
@@ -117,7 +117,7 @@ int main ()
}
]])
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
[[Welcome to GNU libtool cdemo!
** This is libfoo **
hello returned: 57616
Hi Peter,
Apologies for having entirely forgotten about the old thread reviewing
those patches first time around.
And thanks for looking into it. Is there a legal way to get access
to Windows and the various flavours of gcc and MSVC that libtool users
care about, without spending hundreds
that libtool users
care about, without spending hundreds of dollars on software I would
never use for anything else? It pretty much sucks that everytime I
push a well tested (on various Unix varieties) patch, that Windows likes
to blow up gratuitously. I don't mind wasting a bit of time checking
that libtool users
care about, without spending hundreds of dollars on software I would
never use for anything else? It pretty much sucks that everytime I
push a well tested (on various Unix varieties) patch, that Windows likes
to blow up gratuitously. I don't mind wasting a bit of time checking
things
On 10/5/2012 12:03 PM, Gary V. Vaughan wrote:
And thanks for looking into it. Is there a legal way to get access
to Windows and the various flavours of gcc and MSVC that libtool users
care about, without spending hundreds of dollars on software I would
never use for anything else?
Yes.
MS
the world a better place! :-)
I just fired up a test suite run...
Good news! Clean runs on Cygwin, MSYS/MinGW and MSYS/MSVC.
Thanks! I'm crossing my fingers -- I'll sleep a lot better when we've put
this one behind us.
Now into nitpicking and other useless ramblings...
The patch libtool: unroll
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, gary/reredo-test-operand-order has been created
at d2dcd0094901ca961a4690647d17f887eb26208f (commit
Hi Peter,
Sorry for the delay, it was more complicated than I had imagined :-o
On 28 Sep 2012, at 11:08, Gary V. Vaughan g...@gnu.org wrote:
On 27 ก.ย. 2012, at 5:03, Peter Rosin p...@lysator.liu.se wrote:
On 2012-09-26 14:57, Peter Rosin wrote:
On 2012-09-22 05:31, Gary V. Vaughan wrote:
[snipped loads of stuff]
On 2012-10-02 16:54, Gary V. Vaughan wrote:
The new branch gary/reredo-test-operand-order (notice the double re) has
everything broken down into digestible chunks. All the differences between
that and master now look like improvements upon the original hand rolled
Hi Peter,
On Oct 3, 2012, at 12:32 AM, Peter Rosin p...@lysator.liu.se wrote:
[snipped loads of stuff]
[snipped a bit more stuff]
You're saying that you are about to:
$ git checkout master
$ git merge --strategy=recursive -X theirs gary/reredo-test-operand-order \
-m 'bla bla bla'
Hi Peter,
On 27 ก.ย. 2012, at 5:03, Peter Rosin p...@lysator.liu.se wrote:
On 2012-09-26 14:57, Peter Rosin wrote:
On 2012-09-22 05:31, Gary V. Vaughan wrote:
[Heavily snipped]
Why not commit the sc_prohibit_test_const_follows_var improvement
last, after fixing all violations?
That
with seven changesets that reverts the manual version of the
buggy original and redoes it with a painstaking awk script (also checked
in, for the morbidly curious).
I'm on the fence about committing in smaller pieces... the policy for
libtool has always been to make sure the testsuite passes
-test-operand-order to
savannah with seven changesets that reverts the manual version of the
buggy original and redoes it with a painstaking awk script (also checked
in, for the morbidly curious).
I'm on the fence about committing in smaller pieces... the policy for
libtool has always been
On 2012-09-26 14:57, Peter Rosin wrote:
On 2012-09-22 05:31, Gary V. Vaughan wrote:
[Heavily snipped]
Why not commit the sc_prohibit_test_const_follows_var improvement
last, after fixing all violations?
That doesn't make sense, sorry. But the idea would have worked
initially, before the
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, gary/redo-test-operand-order has been created
at 8aec0042b11b5e4f6c069260798fdaa4f0b715b5 (commit)
- Log
changesets that reverts the manual version of the
buggy original and redoes it with a painstaking awk script (also checked
in, for the morbidly curious).
I'm on the fence about committing in smaller pieces... the policy for
libtool has always been to make sure the testsuite passes (at least
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 d674eaa44cc8ce0ea3d148cfd43f243c3c819e2d (commit)
from
and library_names which are empty when
no shared library is built):
@@ -17,7 +17,7 @@
inherited_linker_flags=''
# Libraries that this one depends upon.
-dependency_libs='
-R/home/peda/libtool/git/cygwin/tests/testsuite.dir/047/foobar '
+dependency_libs='
-R/home/peda/libtool/git/cygwin/tests
with this patch is this (I have
elided changes to dlopen and library_names which are empty when
no shared library is built):
@@ -17,7 +17,7 @@
inherited_linker_flags=''
# Libraries that this one depends upon.
-dependency_libs='
-R/home/peda/libtool/git/cygwin/tests/testsuite.dir/047
?
The relevant difference in libb.la with this patch is this (I have
elided changes to dlopen and library_names which are empty when
no shared library is built):
@@ -17,7 +17,7 @@
inherited_linker_flags=''
# Libraries that this one depends upon.
-dependency_libs='
-R/home/peda/libtool
Hi Peter,
My bad, I'm embarrassed to say. I started to write a script to make the
appropriate changes, but ended up doing it manually rather than adding more and
more corner cases to the throwaway script... a poor choice in hindsight :-(
On 19 ก.ย. 2012, at 19:27, Peter Rosin
On 2012-09-19 16:20, Gary V. Vaughan wrote:
Hi Peter,
My bad, I'm embarrassed to say. I started to write a script to make the
appropriate changes, but ended up doing it manually rather than adding
more and more corner cases to the throwaway script... a poor choice in
hindsight :-(
It's
Peter Rosin wrote:
On 2012-09-19 09:31, Peter Rosin wrote:
* tests/runpath-in-lalib.at: Make sure shared libraries are created
on Windows by passing -no-undefined. Otherwise libb.la fails to record
a dependency on liba.la, and the final link of the program then fails
with undefined symbols.
On 2012-09-19 21:32, Roumen Petrov wrote:
Peter Rosin wrote:
On 2012-09-19 09:31, Peter Rosin wrote:
* tests/runpath-in-lalib.at: Make sure shared libraries are created
on Windows by passing -no-undefined. Otherwise libb.la fails to record
a dependency on liba.la, and the final link of the
Additional Item Attachment, sr #107959 (project libtool):
File name: 01-def-syntax.patchSize:0 KB
___
Reply to this item at:
http://savannah.gnu.org/support/?107959
___
Message
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 9b726f35db98da01a7edaf143788cba2c2ae900a (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 00ed0187c1c6cc3519188bc47d5ed0ff85f2d950 (commit)
from
On 2012-08-19 22:18, Peter Rosin wrote:
Oops, forgot a couple of backslashes, trying again.
Sorry for the noise.
Testsuite running, just in case...
The patch does not seem to affect the testsuite, so I'll push in
a few days. Unless someone speaks up against it of course.
Cheers,
Peter
On Mon, 20 Aug 2012, Peter Rosin wrote:
On 2012-08-19 22:18, Peter Rosin wrote:
Oops, forgot a couple of backslashes, trying again.
Sorry for the noise.
Testsuite running, just in case...
The patch does not seem to affect the testsuite, so I'll push in
a few days. Unless someone speaks up
On 2012-08-20 16:14, Bob Friesenhahn wrote:
On Mon, 20 Aug 2012, Peter Rosin wrote:
On 2012-08-19 22:18, Peter Rosin wrote:
Oops, forgot a couple of backslashes, trying again.
Sorry for the noise.
Testsuite running, just in case...
The patch does not seem to affect the testsuite, so
[Cygwinners: Taking this to the Libtool lists]
[Libtoolers: Following up on a post on the cygwin mailing list]
On 2012-08-19 19:03, Andreas Schiffler wrote:
The libtool distributed with cygwin has a bug that prevents use in paths
containing spaces.
This was encountered when trying to build
On 2012-08-19 22:09, Peter Rosin wrote:
[Cygwinners: Taking this to the Libtool lists]
[Libtoolers: Following up on a post on the cygwin mailing list]
On 2012-08-19 19:03, Andreas Schiffler wrote:
The libtool distributed with cygwin has a bug that prevents use in paths
containing spaces
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
On Sun, 19 Aug 2012, Jeff Martin wrote:
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
Bob,
Yes it was pulled from gnu.org.
-rw-r--r-- 1 root root 2632347 Oct 18 2011 libtool-2.4.2.tar.gz
I used:
wget
http://www.mirrorservice.org/sites/ftp.gnu.org/gnu/libtool/libtool-2.4.2.tar.gz
to retrieve the source.
Thanks,
Jeff
- Original Message -
From: Bob
801 - 900 of 5840 matches
Mail list logo
