these
scripts to
build both native and cross-builds, depending on configuration /
arguments, so
using DESTDIR for prefixing the install tree is important. Right now, I'm
working on native builds on an Ubuntu 12.04 32-bit x86 machine; libtool
version = 2.4.2.)
When building/installing gmp, I use
Hi all,
I have a problem during mesalib installation which seems connected with
libtool. I guess the problem may be due to my environment since I have
automake and libtool installed in non-standard places.
libtool is under ${GLOBAL_PREFIX}/libtool/${LIBTOOL_VERSION}/
(version=2.4.2)
automake
wrote:
Hi all,
I have a problem during mesalib installation which seems connected with
libtool. I guess the problem may be due to my environment since I have
automake and libtool installed in non-standard places.
libtool is under ${GLOBAL_PREFIX}/libtool/${LIBTOOL_VERSION}/
(version=2.4.2
Hi,
Is it possible to link static libraries to shared ones using libtool? I
tried passing -Wl,whole-archive -lmylib -Wl,-no-whole-archive in LDFLAGS.
The compilation was fine, but when I checked the nm output of the shared
lib, none of the functions of mylib was present in the output. I also
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 0ebb734910bf56186dd0c0e84b1c8be507bad336 (commit)
from
pages at
http://lists.gnu.org/archive/html/libtool/2013-09/index.html
http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html
doesn't list any mails from me, but the ones from you from this thread
are there, so I don't know whether any of the mails I send arrive at
the list..)
That's
/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 96d876301b0b1423e8192b6e54eba6a88569d14f (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 2d744d9edab9819e15942d20e2f11fad14d8cbbb (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 75051fb536aa3a84324f61253765ab0e58e91fa2 (commit)
from
On 2013-09-10 16:10, Peter Rosin wrote:
On 2013-09-10 15:56, Ozkan Sezer wrote:
OK then, I'll keep an eye on mails from this list.
(On an irrelevant note, the archive pages at
http://lists.gnu.org/archive/html/libtool/2013-09/index.html
http://lists.gnu.org/archive/html/bug-libtool/2013-09
On 9/11/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 16:10, Peter Rosin wrote:
On 2013-09-10 15:56, Ozkan Sezer wrote:
OK then, I'll keep an eye on mails from this list.
(On an irrelevant note, the archive pages at
http://lists.gnu.org/archive/html/libtool/2013-09/index.html
with this library
*** or is declared to -dlopen it.
I am stuck with this. Can anyone see what I am doing wrong?
This needs to be taken up with the libtool developers.
libtool is technically correct, but libole32.a is a mixed shared lib
with static data inserted.
libtool should use dlltool --identify
On 2013-09-10 09:08, Ozkan Sezer wrote:
Tell me if you need anything else.
Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
you.
Can you provide the output from libtool --config and
config.log? I'm not set up to easily duplicate your
environment...
Cheers,
Peter
On 2013-09-10 09:47, Ozkan Sezer wrote:
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 09:08, Ozkan Sezer wrote:
Tell me if you need anything else.
Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
you.
Can you provide the output from libtool --config
On 2013-09-10 10:55, Ozkan Sezer wrote:
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 09:47, Ozkan Sezer wrote:
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 09:08, Ozkan Sezer wrote:
Tell me if you need anything else.
Let's focus on the libtool
, Ozkan Sezer wrote:
Tell me if you need anything else.
Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
you.
Can you provide the output from libtool --config and
config.log? I'm not set up to easily duplicate your
environment...
Cheers,
Peter
Attached ./libtool --config
, Ozkan Sezer wrote:
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 09:08, Ozkan Sezer wrote:
Tell me if you need anything else.
Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
you.
Can you provide the output from libtool --config and
config.log? I'm not set up
Rosin p...@lysator.liu.se wrote:
On 2013-09-10 09:47, Ozkan Sezer wrote:
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 09:08, Ozkan Sezer wrote:
Tell me if you need anything else.
Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
you.
Can you provide the output
On 2013-09-10 12:52, Ozkan Sezer wrote:
That effectively cripples libtool for cross-compilers. Can the behavior
be refined instead? Can you contact Charles Wilson about this?
He should be reading this list, if he has time...
Anyway, does this work?
Cheers,
Peter
diff --git a/m4/libtool.m4 b
On 2013-09-10 15:00, Ozkan Sezer wrote:
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 12:52, Ozkan Sezer wrote:
That effectively cripples libtool for cross-compilers. Can the behavior
be refined instead? Can you contact Charles Wilson about this?
He should be reading
On 2013-09-10 15:29, Ozkan Sezer wrote:
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 15:00, Ozkan Sezer wrote:
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 12:52, Ozkan Sezer wrote:
That effectively cripples libtool for cross-compilers. Can the behavior
with this library
*** or is declared to -dlopen it.
I am stuck with this. Can anyone see what I am doing wrong?
This needs to be taken up with the libtool developers.
libtool is technically correct, but libole32.a is a mixed shared lib
with static data inserted.
The thing is, libole32.a is _not_
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 12:52, Ozkan Sezer wrote:
That effectively cripples libtool for cross-compilers. Can the behavior
be refined instead? Can you contact Charles Wilson about this?
He should be reading this list, if he has time...
Anyway, does
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 09:47, Ozkan Sezer wrote:
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 09:08, Ozkan Sezer wrote:
Tell me if you need anything else.
Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
you.
Can you
will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
I am stuck with this. Can anyone see what I am doing wrong?
This needs to be taken up with the libtool developers.
libtool is technically correct, but libole32.a is a mixed shared lib
with static
anything else.
Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
you.
Can you provide the output from libtool --config and
config.log? I'm not set up to easily duplicate your
environment...
Cheers,
Peter
Attached ./libtool --config output after configuration. Attached
On 9/10/13, Ozkan Sezer seze...@gmail.com wrote:
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 09:08, Ozkan Sezer wrote:
Tell me if you need anything else.
Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
you.
Can you provide the output from libtool --config
On 2013-09-10 15:56, Ozkan Sezer wrote:
OK then, I'll keep an eye on mails from this list.
(On an irrelevant note, the archive pages at
http://lists.gnu.org/archive/html/libtool/2013-09/index.html
http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html
doesn't list any mails from
Rosin p...@lysator.liu.se wrote:
On 2013-09-10 09:08, Ozkan Sezer wrote:
Tell me if you need anything else.
Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
you.
Can you provide the output from libtool --config and
config.log? I'm not set up to easily duplicate your
environment
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 15:00, Ozkan Sezer wrote:
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 12:52, Ozkan Sezer wrote:
That effectively cripples libtool for cross-compilers. Can the behavior
be refined instead? Can you contact
-10 09:47, Ozkan Sezer wrote:
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote:
On 2013-09-10 09:08, Ozkan Sezer wrote:
Tell me if you need anything else.
Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
you.
Can you provide the output from libtool --config and
config.log? I'm
to -dlopen it.
I am stuck with this. Can anyone see what I am doing wrong?
This needs to be taken up with the libtool developers.
libtool is technically correct, but libole32.a is a mixed shared lib
with static data inserted.
libtool should use dlltool --identify when available.
signature.asc
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 2636f57059967d3438250234279edac7cfd13d35 (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 5d4a43d8747f71e677a1c8df574dc18036ff569d (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 ebeb8a62cd52a008a666bec1073cbbabb838acaf (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 5f7f7d9615bf650cf99d581a33b3e18357f79951 (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 d1ddb6fbbf5f25e0cac740662631d40110a6d4d3 (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 056889b838c7f7ce42281f095921b34973321e25 (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 bd998a7ea4f73f05aaa2143bf28469ee4b9d3d0c (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 a734603dc187086e3aa0e1482f39138a427fc33b (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 429d40a020348c7cd8e8af75c7cb29a64cf9708d (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 8a8dfaec78790ab3193c2751b3188925339fdacb (commit)
from
On 07/18/2013 02:54 AM, Dennis Clarke wrote:
CDPATH=${ZSH_VERSION+.}: cd . /usr/local/bin/bash
/usr/local/build/libtool-2.4.2_SunOS5.8_sparcv9.001/libltdl/config/missing --run aclocal-1.11 -I
libltdl/m4
/usr/local/build/libtool-2.4.2_SunOS5.8_sparcv9.001/libltdl/config/missing:
line 52
On 07/18/2013 01:59 PM, Dennis Clarke wrote:
from the source tarball .. here is try number five :
mimas$ sx ../src/libtool-2.4.2.tar.gz
star: 1165 blocks + 0 bytes (total of 11929600 bytes = 11650.00k).
mimas$ mv libtool-2.4.2 libtool-2.4.2_SunOS5.8_sparcv9.005
mimas$ cd libtool
Hi,
I wanted to use link-time optimization (LTO/-flto) of GCC with libtool. I
thought I only have to add -flto to CFLAGS and LDFLAGS and then I am
finished. But it seems that this is not enough because some CFLAGS aren't
copied to the linker command (e.g. -g). This results in a binary
On Sun, 5 May 2013, Schrober wrote:
Hi,
I wanted to use link-time optimization (LTO/-flto) of GCC with libtool. I
thought I only have to add -flto to CFLAGS and LDFLAGS and then I am
finished. But it seems that this is not enough because some CFLAGS aren't
copied to the linker command (e.g. -g
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 a4629ebff263dcb2e05feb9e41df649ea5ce3f78 (commit)
from
On 2013-04-28 09:21, Peter Rosin wrote:
On 2013-04-27 22:38, Mike Frysinger wrote:
On Saturday 27 April 2013 13:53:28 Peter Rosin wrote:
On 2013-04-27 07:58, Mike Frysinger wrote:
The current code tries to locate a compatible nm tool. It starts with
a prefixed nm tool (great!) and includes a
On 2013-04-29 04:45, Mike Frysinger wrote:
On Sunday 28 April 2013 03:21:15 Peter Rosin wrote:
And on re-reading, my IFS changes are not very constructive. I removed
those. I will push the attached in a couple of days, if there are no
objections.
i actually thought your IFS changes made
On Monday 29 April 2013 02:55:12 Peter Rosin wrote:
On 2013-04-29 04:45, Mike Frysinger wrote:
On Sunday 28 April 2013 03:21:15 Peter Rosin wrote:
And on re-reading, my IFS changes are not very constructive. I removed
those. I will push the attached in a couple of days, if there are no
On 2013-04-29 17:55, Mike Frysinger wrote:
On Monday 29 April 2013 02:55:12 Peter Rosin wrote:
On 2013-04-29 04:45, Mike Frysinger wrote:
On Sunday 28 April 2013 03:21:15 Peter Rosin wrote:
And on re-reading, my IFS changes are not very constructive. I removed
those. I will push the attached
, if there are no
objections.
Cheers,
Peter
From a4629ebff263dcb2e05feb9e41df649ea5ce3f78 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Sun, 28 Apr 2013 09:16:56 +0200
Subject: [PATCH] libtool: break all the way out when a good nm is found
The current code tries to locate a compatible nm tool
On Sunday 28 April 2013 03:21:15 Peter Rosin wrote:
On 2013-04-27 22:38, Mike Frysinger wrote:
On Saturday 27 April 2013 13:53:28 Peter Rosin wrote:
On 2013-04-27 07:58, Mike Frysinger wrote:
The current code tries to locate a compatible nm tool. It starts with
a prefixed nm tool
Hi.
I wonder if there is anybody maintaining libtool on MacOS X? My Google
Alerts have pointed me at this PR for MacPorts:
https://trac.macports.org/ticket/38879. Would it not be possible to
merge any changes they have done to support Clang/libc++ into the
official libtool?
--
VZ
$ ./configure --build=bfin-uclinux --host=bfin-uclinux
The code produced by the toolchain will execute fine here (because
we've configured the system to use qemu to transparently run the
programs), but libtool will end up defaulting to `nm` which does not
work with ELFs it does not know about.
* m4/libtool.m4
On Wed, 20 Feb 2013, Richard Shann wrote:
In the GNU/Denemo project we are trying to cross-build a for windows on
Debian stable using static libraries. The libtool step is re-ordering
the libraries before invoking the linker, and so it fails.
The cross-environment has version 2.22 of GNU
Follow-up Comment #31, sr #108201 (project libtool):
apparently Joyent believe that this isn't closed, if there is somebody that
has tested this too could determine whether or not to close the issue as
fixed, thanks in advance.
___
Reply
Thank you for the thoughtful response.
On Sun, 2013-02-24 at 10:50 -0600, Bob Friesenhahn wrote:
On Wed, 20 Feb 2013, Richard Shann wrote:
In the GNU/Denemo project we are trying to cross-build a for windows on
Debian stable using static libraries. The libtool step is re-ordering
In the GNU/Denemo project we are trying to cross-build a for windows on
Debian stable using static libraries. The libtool step is re-ordering
the libraries before invoking the linker, and so it fails.
The cross-environment has version 2.22 of GNU/Binutils, but I am not
clear where the actual
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 f67a13c5a01b6890c49b6370e0b37dcffe774d6d (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 68920ef8353f71c2e6c5c6b57a26cf55c0cff318 (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 8d2a63c23a2dfb424e4b2f934c73c1737f979062 (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 2e40f7209a10b9d814f558784eb5018d5e404be3 (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 a5a4944fbb2bbd20adb12bd357d3b41e9a44b246 (commit)
via
perform a test mass
rebuild of all mingw packages which are currently in Fedora (about 135)
against a libtool package which contains this patch. With this mass
rebuild we can at least find out whether the patch introduces
regressions or not. Running such a test mass rebuild will take about 36
for real things.
Thanks for the patch. To help out with testing I can perform a test mass
rebuild of all mingw packages which are currently in Fedora (about 135)
against a libtool package which contains this patch. With this mass
rebuild we can at least find out whether the patch introduces
in Fedora (about 135)
against a libtool package which contains this patch. With this mass
rebuild we can at least find out whether the patch introduces
regressions or not. Running such a test mass rebuild will take about 36
hours to complete, so I'll give an update in about 2 days.
Kind regards
On 2013-01-19 06:12, Gary V. Vaughan wrote:
Hi Peter,
Thanks for working on this.
On 19 Jan 2013, at 05:55, Peter Rosin p...@lysator.liu.se wrote:
On 2013-01-12 01:26, Peter Rosin wrote:
On 2013-01-11 12:34, Martin Doucha wrote:
I'd like to report a bug in libtool 2.4 (including
just noticed this, and while I'm perfectly fine with Libtool not
wanting Tested-by: tags, I fail to see how they can be
unsupported.
So, I'm just curious about what damage it was causing? Is it just
that the git origin of the ChangeLog shows, or something more
tangible?
Now I see, it breaks
Hi Martin, Erik,
On 2013-01-12 01:26, Peter Rosin wrote:
Hi Martin,
Thanks for the report.
On 2013-01-11 12:34, Martin Doucha wrote:
Hi,
I'd like to report a bug in libtool 2.4 (including the latest git revision)
which mangles valid DLL def files under MinGW and makes the linker barf
build-aux/ltmain.in (func_execute_cmds, func_mode_link): Don't collapse
tabs and surrounding whitespace into a single space when executing a
tilde-separated cmds construct, instead keep any tabs intact.
m4/libtool.m4: Convert indenting tabs to spaces for all *_cmds
variables affected by the above.
-in-archive.at \
diff --git a/NEWS b/NEWS
index c202c43..514768b 100644
--- a/NEWS
+++ b/NEWS
@@ -66,6 +66,9 @@ NEWS - list of user-visible changes between releases of GNU
Libtool
the Microsoft Visual C/C++ linker via the -export-symbols argument to
the libtool script, thus matching how .def files
Hi Peter,
Thanks for working on this.
On 19 Jan 2013, at 05:55, Peter Rosin p...@lysator.liu.se wrote:
On 2013-01-12 01:26, Peter Rosin wrote:
On 2013-01-11 12:34, Martin Doucha wrote:
I'd like to report a bug in libtool 2.4 (including the latest git revision)
which mangles valid DLL def
fine with Libtool not
wanting Tested-by: tags, I fail to see how they can be
unsupported.
So, I'm just curious about what damage it was causing? Is it just
that the git origin of the ChangeLog shows, or something more
tangible?
Cheers,
Peter
___
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 8152cf62a1fe86dedb5abb107276560fc9c47f2c (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 5ed7430fcb48c862c9d76ef497b73485d580338e (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 93cba573d25cc1f5dbae07b6828783dbf66130b7 (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 820e373cf2521e553db409e87c4ccc5e6cc4b074 (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 66acec8407935f13aad5ab7f86a0ec8e9ec0f8ce (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 b6bb7f9cdf66c632c2837be9ad0077f7f533b824 (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 e54f2dc19b965e57555974561059d2be0a070f8b (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 a9fac8df4df005dd03740675fa944107b9792adf (commit)
via
Follow-up Comment #30, sr #108201 (project libtool):
The following patch to export.at seems to work on solaris
now testing for ELF in the shared object and using shrext_cmds to generate the
.so extension.
(file #27141)
___
Additional
Follow-up Comment #29, sr #108201 (project libtool):
There are currently many unapplied patches. Several of them are useful for
Solaris.
___
Reply to this item at:
http://savannah.gnu.org/support/?108201
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 109bc05e0d356ab48cc363521b8cd0abc943a6f5 (commit)
via
Follow-up Comment #26, sr #108201 (project libtool):
I have pushed the code changes to m4/Libtool.m4 (as two separate
commits), but left the testsuite alone. Thank you for your work
on this!
I also added you to THANKS, I hope that was ok?
A libtool release is not on my table though.
Cheers
Follow-up Comment #27, sr #108201 (project libtool):
This is fine with me.
When *is* the next release planned then?
In the meanwhile I will try to finish a pkgsrc patch to the already released
bits (which seems to complain with auto* tools)...
cheers
Follow-up Comment #28, sr #108201 (project libtool):
On Thu 20 Dec 2012 04:48:06 GMT in comment #27 Richard PALO risto3 wrote:
When is the next release planned then?
Soon.
I had hoped to find time to do all the necessary testing before the end of the
year, but with wedding and honeymoon
Follow-up Comment #24, sr #108201 (project libtool):
Hi again!
I have no quarel with the original change to augment
archive_expsym_cmds with ${wl}-h $wl$soname. That looks
like a no-brainer as it just matches archive_cmds. That
can go in at any time, as far as I'm concerned.
The testsuite
Follow-up Comment #25, sr #108201 (project libtool):
These are good arguments, I offer as well some observations and/or arguments
before I sign off...
1. I thought about that last night, that *was* the advantage of elfdump, but
not all ELF systems have elfdump and objdump is used instead
Follow-up Comment #18, sr #108201 (project libtool):
I believe gcc 4.5.3 is the latest stable for Cygwin. I do not
trust myself to be able to build a new gcc and verify that it
actually works for Cygwin without investing far more time than I
think is warranted. I imagine that there is some good
Follow-up Comment #20, sr #108201 (project libtool):
FYI, Peter Rosin is able to commit fixes to libtool. That is one reason why
he focuses on the master version.
Barring some severe nightmarish security defect, there will be no follow-on
release based on the v2.4.2 sources. The next release
Update of sr #108201 (project libtool):
Operating System:*BSD = Solaris
___
Reply to this item at:
http://savannah.gnu.org/support/?108201
Follow-up Comment #21, sr #108201 (project libtool):
Here is the git diff for master (apparently the same except for the file
path).
(file #27107)
___
Additional Item Attachment:
File name: libtool.m4.git-diff-master Size:1 KB
Follow-up Comment #15, sr #108201 (project libtool):
could you please post your testsuite.log for the following command:
gmake CC=g++ check-local
it is possible that this is yet another bug (either in libtool or in gcc...)
When I only run test 45 with
gmake CC=g++ check-local
Follow-up Comment #16, sr #108201 (project libtool):
I had an old git checkout from some time back (with some totally
unrelated work in it) and I used that to run the export test.
I'm not wasting hours on a full testsuite runs for this.
I tested once configuring with CC=g++ and once with CC=gcc
Follow-up Comment #17, sr #108201 (project libtool):
I gather that your gcc is rather ancient (4.5.3 from april 2011) but I cannot
determine which version of libtool you are using.
Would it be possible to upgrade gcc to the latest 4.7.2 and
git checkout v2.4.2
in order to update your
Follow-up Comment #12, sr #108201 (project libtool):
perhaps to refine the test a bit more, would it be possible to check that the
value of SONAME is the value expected.
With elfdump, the SONAME could be extracted for example by:
elfdump -d $soname | grep SONAME | awk '{printf $4}'
Apparently
Follow-up Comment #13, sr #108201 (project libtool):
if the solaris developer/gnu-binutils or pkgsrc/devel/binutils is installed,
then objdump is on the system.
Just noticed that libtool's configure found objdump:
richard@devzone:~/src/libtool$ grep objdump config*
config.log:configure:5686
701 - 800 of 5840 matches
Mail list logo
