On 07/08/2010 08:27 AM, Gary V. Vaughan wrote:
Pushed as obvious:
While it looks large, the entire patch was made with a 5-line sed script
that replaces "XSI" with "Extended shell" or similar as appropriate to
each context, followed by some manual layout cleanups and a complete run
of the testsu
On 08/09/2010 12:33 AM, Gary V. Vaughan wrote:
By the reasoning I stated there, we should really have branched
for 2.2 releases before adding any new features. So, if we
want to release a 2.2.12, then we should make a branch at
v2.2.10 and merge only fixes to it.
I don't think having a stab
On 09/11/2010 10:09 AM, Charles Wilson wrote:
On 9/11/2010 2:47 AM, Peter Rosin wrote:
Den 2010-09-11 07:02 skrev Charles Wilson:
OK to push as obvious?
To me, pushing as obvious is the same as pushing without
asking (and when I do, I make damn sure I don't push anything
bad). This makes me c
On 09/22/2010 09:00 PM, Leo Davis wrote:
Hello,
I had to patch libtool in order to get shared libraries to build with
the Snow Leopard '@rpath/' syntax which stands in for the place where
the lib gets installed. I thought that this might be useful for more
than just myself.
Well, there is n
On 10/14/2010 02:27 PM, Ralf Wildenhues wrote:
The following patch should fix this. Paul, any chance you could try out
the patch on your system? OK to add your name&email to THANKS?
OK to commit? (I do have access to a darwin system, but no gfortran
installed there, so I cannot test this.)
On 10/14/2010 04:19 PM, Ralf Wildenhues wrote:
Hi Peter,
thanks for the quick feedback!
* Peter O'Gorman wrote on Thu, Oct 14, 2010 at 10:49:00PM CEST:
On 10/14/2010 02:27 PM, Ralf Wildenhues wrote:
The following patch should fix this. Paul, any chance you could try out
the patch on
On 12/05/2010 09:34 PM, Ralf Wildenhues wrote:
Does this patch fix things for you? As far as I see, you should be
getting -fPIC passed instead of -fno-common, so it's not completely
clear that this is right, or what other changes MacPorts has done to
their glibtool code over upstream Libtool.
On 12/06/2010 01:07 AM, Ralf Wildenhues wrote:
OK to apply?
Unless Pawel reports that it works for him, no. This doesn't make
sense to me.
Hi Ralf,
Why?
Well, perhaps I haven't been drinking enough coffee, but...
_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker '
This assign
On 12/06/2010 03:25 PM, Ralf Wildenhues wrote:
Where do you see that? As far as I understand, Paweł hasn't actually
tried configuring Libtool with something like
Yeah, I failed to read your entire email this morning, definitely didn't
have enough coffee. It makes sense now :)
We have some
ppen? If so I
will change this patch to just assume that ld exits with an error code
for unrecognized arguments.
Patch Ok?
Peter
>From 4f0eb4701ae67e7e52dcc4cb8eb7eb65f11645d3 Mon Sep 17 00:00:00 2001
From: Peter O'Gorman
Date: Wed, 19 Jan 2011 10:09:46 -0600
Subject: [PATCH] Don
On 01/19/2011 12:38 PM, Ralf Wildenhues wrote:
Hi Ralf,
Thanks for the quick review! Yes, the testsuite addition fails before
the patch, and passes after.
Also,>/dev/null 2>&1 (order matters!)
Are you really grepping the binary intentionally here, rather than the
.err file?
Yes, and tha
--lt-*) ;;
*) set x "$@" "$lt_wr_arg"; shift;;
esac
shift
done ;;
esac
func_exec_program_core ${1+"$@"}
}
Thank you!
Peter
>From 286e87b1030c353d9cfc89dbb72d59e0391cb693 Mon Sep 17 00:00:00 2001
From: Peter O'Gorman
Date: Thu, 27 Jan 2011 17
On 02/11/2011 11:10 AM, Peter O'Gorman wrote:
On 02/11/2011 10:52 AM, Křištof Želechovski wrote:
libtool.x86_64: W: script-without-shebang
/usr/share/libtool/config/ltmain.sh
This text file has executable bits set or is located in a path
dedicated for
executables, but lacks a sheban
On 02/14/2011 12:46 PM, Bob Friesenhahn wrote:
On Mon, 14 Feb 2011, Peter O'Gorman wrote:
I would say it is easier to install it with permissions matching its
status. What is easier depends on your POV. In the end, what is easier
to the customer should prevail because there are more cust
On 03/01/2011 05:24 AM, Jürgen Reuter wrote:
Dear libtool team (cc to Peter)
as discussed with Peter I send to you a diff (compared to the
2.4 official version of libtool) to support the NAG Fortran compiler
on Darwin 64bit machines.
Thanks for your work on this.
case $cc_basename in
-
On 03/04/2011 03:44 AM, Hans Aberg wrote:
On 4 Mar 2011, at 03:59, Peter O'Gorman wrote:
The important thing is to try .dylib - all libraries I have sen use it. It can
of course try .so as well.
Patch. Fails new testcase before (well, "new" testcase as in copy &
On 03/04/2011 12:47 PM, Ralf Wildenhues wrote:
[ dropping bug-libtool ]
Hi Peter,
* Peter O'Gorman wrote on Fri, Mar 04, 2011 at 07:07:30PM CET:
Ok?
A few copyright year bumps are missing.
Oh, yeah, will fix.
Some minor nits inline below.
+AT_SETUP(darwin can lt_dlopen .dylib an
On 03/04/2011 01:00 PM, Peter O'Gorman wrote:
On 03/04/2011 12:47 PM, Ralf Wildenhues wrote:
+if test "$shlibpath_var" = PATH; then
This looks wrong; shouldn't it be != here? Otherwise, ...
Looking at the original test, the above is correct there - it wants to
avoid
Hi Jürgen,
Does the attached patch work for you? I think it -Wl, quotes everything
necessary. Note that I hardcode -Wl, rather than ${wl} because some of
the options are supposed to be gcc options rather than ld ones (though
ld recently accepts them too, so it's not a big deal either way).
R
On 07/29/2011 07:55 PM, John David Anglin wrote:
Ping?
Hi Dave,
ltmain.sh is a generated file, so this patch is not correct. Perhaps
something like (pasted in mail, so wrapped):
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 9358ec5..bd5736c 100644
--- a/libltdl/
On 09/01/2011 09:25 AM, Bob Friesenhahn wrote:
On Mon, 29 Aug 2011, Peter O'Gorman wrote:
This turns off warnings for --silent (and turns them on again for
--verbose).
But I am not sure that --silent was meant to imply "no warnings",
rather it turns off the verbose compil
On 09/03/2011 02:10 PM, Christophe Jarry wrote:
Dear developers,
I have reported the following bug on (see
http://lists.gnu.org/archive/html/bug-libtool/2011-07/msg2.html and
http://lists.gnu.org/archive/html/bug-libtool/2011-08/msg1.html).
On the documentation of libtool, the word "li
On Sep 4, 2011, at 1:05 AM, Christophe Jarry wrote:
> On Sat, 03 Sep 2011 16:34:51 -0500
> Peter O'Gorman wrote:
>
>> Please do not change the version type for libtool library versioning
>> from linux to gnu-linux. [...] I object to this change.
>
> Could
On 09/01/2011 06:51 PM, Peter O'Gorman wrote:
Though I am sorely tempted to simply delete those warnings altogether, I
think the --no-warn option is better.
I'll give you a day to veto this patch, if you don't then I will commit
on Saturday. It essentially copies the --no
On 09/05/2011 02:10 PM, Christophe Jarry wrote:
Please learn to use git for sending patches; thanks!
The new patch is attached.
Please tell me if there are still issues with it.
Christophe
I just committed a slightly modified patch in your name.
Peter
Update of patch #7626 (project libtool):
Status:None => Done
Assigned to:None => pogma
Open/Closed:Open => Closed
_
One of these commits broke the daily snapshot. The machine does not yet
have autobuild installed. Now that it's a hard bootstrap requirement, I
will try to make time to install it.
Peter
On 10/23/2011 10:40 AM, Gary V. Vaughan wrote
This is an automated email from the git hooks/post-receive
On 10/23/2011 05:34 PM, Peter O'Gorman wrote:
One of these commits broke the daily snapshot. The machine does not yet
have autobuild installed. Now that it's a hard bootstrap requirement, I
will try to make time to install it.
Peter
Heh, didn't see the patches emails because I
On 10/23/2011 11:03 AM, Gary V. Vaughan wrote:
All,
By the end of this series, making a release still involves an awful lot
of waiting, but after passing the bevy of make distcheck variations
mandated in the README-release, is now a simple matter of:
1. libltdl/config/do-release-commit-and
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 b
On 10/23/2011 08:29 PM, Gary V. Vaughan wrote:
Hi Peter,
On 24 Oct 2011, at 05:34, Peter O'Gorman wrote:
One of these commits broke the daily snapshot. The machine does not yet have
autobuild installed. Now that it's a hard bootstrap requirement, I will try to
make time to instal
On 12/08/2011 04:21 AM, Gary V. Vaughan wrote:
The recently pushed series of patches included the controversial
introduction of an additional 3 forks per invocation, which might
add a minute or two of wall-clock time to giant builds on windows.
By assuming that windows will run shell scripts on s
On 12/08/2011 08:03 AM, Gary V. Vaughan wrote:
Any additional forks will slow down the script and should be avoided on all
platforms.
Agreed.
Following up just because "slow down" is not a number:
touch a.c
time (for x in {1..100}; do ./libtool --mode=compile --tag=CC gcc -c -o
a.lo a.c;
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 rar
On 12/12/2011 11:32 AM, H.J. Lu wrote:
* m4/libtool.m4 (_LT_ENABLE_LOCK): Support x32.
Pushed, thanks.
Peter
On 12/12/2011 03:01 PM, Roumen Petrov wrote:
It issue same as
http://lists.gnu.org/archive/html/libtool/2011-10/msg00019.html
It's not the same.
That section of code is a mess, for all the other systems checking $host
is correct, for the linux -> linux cross compile case, its logic looks
wr
Hello Samuel,
I pushed this, thank you.
Peter
On 11/12/2011 08:21 AM, Samuel Thibault wrote:
Samuel Thibault, le Sat 12 Nov 2011 14:52:20 +0100, a écrit :
libtool is missing the GNU/Hurd case in a few places, resulting to build
issues in Debin GNU/Hurd, the attached patch fixes it, could you
5d54d8ce Mon Sep 17 00:00:00 2001
From: Peter O'Gorman
Date: Fri, 16 Mar 2012 13:23:13 -0500
Subject: [PATCH] Fix typo that caused sys_lib_search_path_spec to be wrong.
* m4/libtool.m4: s/lt_fooi/lt_foo/.
Reported by Paul Seidler
---
m4/libtool.m4 |2 +-
1 files changed, 1 insertions(+)
Thanks, pushed.
Peter
On 04/18/2012 11:00 PM, Mike Frysinger wrote:
> If a getconf value doesn't have a limit, getconf will display
> "undefined". The libtool code though gets confused by this, so
> handle that specifically.
>
> Signed-off-by: Mike Frysinger
>
> * m4/libtool.m4: Check for "und
On 08/21/2012 09:03 PM, Brad Smith wrote:
I added the missing 'n' first though :)
Sorry about that. Looking at the commited diff there is still an
issue on line 2722.
Thanks Brad,
I 'fixed' it, but didn't commit. :( Now the 'n' gets a commit all by itself.
I have no excuse, it's not even
Pushed. Thanks!
Peter
On 08/21/2012 09:46 AM, Andreas Schwab wrote:
This is needed for -flto so that debugging information isn't dropped.
* ltmain.m4sh (func_mode_link): Pass through -g*.
---
build-aux/ltmain.m4sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/build
Hi Brad,
Thanks, I pushed this.
On 08/02/2012 01:46 AM, Brad Smith wrote:
+ if test -z "`echo __ELF__ | $CC -E - | $GREP __ELF__`"; the
I added the missing 'n' first though :)
Peter
Pushed. Thanks!
Peter
On 08/20/2012 12:12 PM, David Edelsohn wrote:
The GCC -fpic/-fPIC option has evolved to mean code generation for a
shared library and changes the optimization behavior of the compiler.
Code for AIX PowerPC always is PIC, but the optimization behavior is
affecting AIX.
lib
Hmm, -F should be passed through unmolested.
# Flags to be passed through unchanged, with rationale:
# -64, -mips[0-9] enable 64-bit mode for the SGI compiler
# -r[0-9][0-9]*specify processor for the SGI compiler
# -xarch=*, -xtarget=* enable 64-bit mode for th
I applied this to head and something similar to branch-2-0.
Peter
--
Peter O'Gorman - http://www.pogma.com
Index: ChangeLog
2005-02-21 Peter O'Gorman <[EMAIL PROTECTED]>
* config/ltmain.m4sh (func_extract_archives) [darwin]: This didn't
actually work
ggest installing a fileslist
file at install time which contains a copy of automakes DISTFILES variable.
Then we can make libtoolize look for that file and read it's contents to see
which files to copy.
In the meantime, okay to apply this and it's equivalent to all branches?
Peter
- --
Peter
port
that to branch-1-5 if necessary after approval.
Hi Gary,
I question that we can rely on tar being installed, although I have not come
across a system where it isn't. Please backport things to branch-1-5, it is
apparently the branch that never dies, no matter how much we want it to.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary V. Vaughan wrote:
| Okay to commit to HEAD and branch-2-0?
|
| If yes, I'll backport to branch-1-5 and post as a separate patch.
|
Looks like it may work, seems ugly, but yes, please apply.
Peter
- --
Peter O'Gorman - http://www
operation
(with 2 forked tars overall). I'll add that to TODO on HEAD.
Hi Gary,
Yes, I was referring to the two tars per file copy. Adding this to TODO
seems like a good idea.
Peter
--
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Egger wrote:
| The patch fixes the issues.
|
| ltmain_stable.m4sh.diff - patch against latest branch-2-0
| ltmain_head.m4sh.diff- patch against cvs head
Committed, thanks.
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary V. Vaughan wrote:
| Okay to apply?
|
Yes, thank you.
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (Darwin)
iQCVAwUBQh1WFLiDAg3OZTLPAQJXXQP9FtCkrSveI1mfVQ2zl3bs1fo3v+M
Hi,
Jeff tells me that this fixes the problem, okay to apply to branch-1-5 and
forward port later?
Thanks,
Peter
--
Peter O'Gorman - http://www.pogma.com
Index: ChangeLog
2005-02-24 Peter O'Gorman <[EMAIL PROTECTED]>
* libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS): The
Okay to apply to branch-1-5 and then forward port?
Peter
--
Peter O'Gorman - http://www.pogma.com
Index: ChangeLog
2005-02-24 Peter O'Gorman <[EMAIL PROTECTED]>
* libtool.m4: The compiler can be a program name with args, so
always check cc_basename against com
er used in case statements,
so lets set it with:
cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%;s%[].*$%%'`
Also I notice that there are a couple of instances of:
case "$cc_basename" in
where we should remove the quotes.
Okay, these are valid points, I
Gary V. Vaughan wrote:
Hi Peter!
Peter O'Gorman wrote:
Index: ChangeLog
2005-02-24 Peter O'Gorman <[EMAIL PROTECTED]>
* libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS): The Portland group's
compiler does not pass --whole-archive. Move gnu ld check for
the flag to the top so
geLog entry.
No problem, *I* should have googled.
Peter
--
Peter O'Gorman - http://www.pogma.com
, why not
just stop pretending that it is useful as a stand alone utility?
I'll go into hiding now,
Peter
--
Peter O'Gorman - http://www.pogma.com
ll need an
entry in sh.test to spot switches missing the '*' inside 'case $cc_basename'
to save us forgetting in the future as part of the patch too.
Hi all,
I'm confused as to whether all this means that my original patch is
acceptable or not :)
Peter
--
Peter O'Gorman - http://www.pogma.com
ibltdl/loaders/Makefile.am
| (install-data-local): Ditto.
Doesn't a backport of this need to go into branch-1-5 too?
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (Darwin)
iQCVAwUBQiXBDLiDAg3OZTLPAQIAfAQAtsHHWD/dNP+DVFeL1tqr
her
| hand I'm not sure I want to rock the boat too hard...
|
| +0.5 to remove installed libtool script in HEAD
| -0.5 for branch-2-0
| -1 for branch-1-5
|
| What say you?
I say remove it from HEAD and have a --disable-script-install (hopefully a
better name) configure option for 1.5 and 2.0.
P
s I could patch configure.ac to make --program-prefix=g the
default on darwin.
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (Darwin)
iQCVAwUBQihTJ7iDAg3OZTLPAQIemQP/dNIrFdBTs6xLbLcQmUpkD78lKyPxuoAk
5vNQW78h5u+sMD3a48o2eX9G3VNCx/RnP5IOlJQDLA8F
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Wildenhues wrote:
| * Peter O'Gorman wrote on Fri, Mar 04, 2005 at 01:23:04PM CET:
|
|>Ralf Wildenhues wrote:
|>|
|>| Do you know the difference between Apple's supplied `libtool' and GNU
|>| libtool, called `glibtool
etely different /usr/bin/libtoolize, so I
figured that it was better to leave libtoolize as is. However, when I
consider it, because apple installs /usr/bin/glibtoolize some software looks
for glibtoolize on darwin in their bootstrap/autogen scripts. Hmm...
Thanks for looking,
Peter
--
Peter O'Gorman - http://www.pogma.com
like:
./configure --prefix=/usr --program-prefix=g
make
sudo make install
This is what Apple does when building GNU libtool, and what most package
tools do too. Some packagers also add a symlink libtoolize -> glibtoolize,
you may wish to do so too.
Peter
- --
Peter O'Gorman - http://www.pogma.com
-
ntation claims that it is.
Where? They may have a documentation bug.
Peter
--
Peter O'Gorman - http://www.pogma.com
you.
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iQCVAwUBQjBTr7iDAg3OZTLPAQKxAAP/cEpfmKXeff5q3ihICo7TR2IgVpfvwlJD
SgNsI2vqixIRjE6AZCIEHCh7TAa/aOqtEpUcd+KZCh1IUJpfXPAtCi0N8k5AfFnA
KSG4WidxR3aRdGNBLayZ6BEusxXHaTEQ3W+DUEhSfS4H7++D
* NEWS: Update.
|
This looks okay to me, can we have a test too though?
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iQCVAwUBQjBV67iDAg3OZTLPAQKg1gP9HQVzcus0M9dpuUN0NokoNXtipBI41+GA
+wic4qcbsxxlF8DAPfiG/RFE2R6zhC5+/YevdYZPIo
alid version information"
| ;;
This is fine with me as long as "small" is removed, it is far too indefinite
and I would never think of 9 as a small number.
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin
adroom
|>
|>In the end it was 3/4 the original value..
|
|
| Yes, I looked around in the old code a bit, and think you are right
| about this. (16384 seems ok for C++ to me.) The patch to the current
| code[1] bears no obvious argument towards 0.25 vs 0.75.
This is fine with me, please
in the archive in the first place. Seems like a
good plan. I'll go look for it.
Thanks for reporting this,
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iQCVAwUBQlHc5biDAg3OZTLPAQJBgAQAru235ApQmAWD32oCRHuYiY8pcRt5NS52
T/0wbZu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter O'Gorman wrote:
| Maciej W. Rozycki wrote:
| | Hello,
| |
| | A change dated 2004-12-10 broke handling of archives containing multiple
| | members of the same name for GNU binutils. Unlike what the relevant
| | ChangeLog entry suggests m
uploading?
You have to send your ascii armoured gpg key to the right place, I believe
that it is documented in README-alpha on branch-1-5.
If it is to be in a couple of weeks I could probably do it, but since most
of the changes recently to branch-1-5 have been fixes you made...
Peter
- --
Peter
Ralf Wildenhues wrote:
* Peter O'Gorman wrote on Thu, Apr 07, 2005 at 03:04:17PM CEST:
Peter O'Gorman wrote:
| Maciej W. Rozycki wrote:
| |
| | A change dated 2004-12-10 broke handling of archives containing multiple
| | members of the same name for GNU binutils. Unlike what the rele
Ralf Wildenhues wrote:
Oh, I'd be happy either way. If you want to do it, fine with me, too. :)
In the unlikely event that you do not upload access to ftp.gnu.org in time,
please ask me. Otherwise, thanks for volunteering :)
Peter
--
Peter O'Gorman - http://www.pogma.com
l" ;;
+ *) deplibs="$depdepl $deplibs" ;;
I know that they look very similar though, and are only separated by 3
lines, it fooled me 'til just this second. (I just deleted a whole other
email I was about to send :-p).
Peter
- --
Peter O'Gorman - http://www.pogma.
Ralf Wildenhues wrote:
* Peter O'Gorman wrote on Mon, Apr 11, 2005 at 03:50:03PM CEST:
Ralf Wildenhues wrote:
| - *) deplibs="$deplibs $path" ;;
| + *) deplibs="$path $deplibs" ;;
This is different to the patch for Zachary's bug which was:
- -
ds~rm $filelist\"
can't you just do this?
output=$file_list_spec$filelist
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iQCVAwUBQl2mt7iDAg3OZTLPAQLzCwQAlNeoMOnHVJ2sqvMlp+12ui3S1x1kjflQ
w
David Edelsohn wrote:
Peter O'Gorman writes:
The patch is relative to libtool HEAD. Can you point me to the
location of the existing linker script support?
Sorry, can't pay close attention with a three year old sitting on lap
shouting :)
Peter> can't you just do t
grouping
feature more consistently in the long run.
Hi Ralf,
Please expand on what you think we need to do about autotest. What grouping
feature?
I'd like, for example, to be able to give the user feedback for each
AT_CHECK, but that does not seem to be possible.
Peter
--
Peter O'Gor
time saved by doing this is microscopic compared to the time saved by
avoiding the ld -r loops though :)
Peter
--
Peter O'Gorman - http://www.pogma.com
lled it is
given a unique directory, or I could 'fix' func_extract_archives to not
remove the dir.
Any preference?
Peter
--
Peter O'Gorman - http://www.pogma.com
to our advantage. Have
not thought yet how.
I'd be happy with just one AT_BANNER at the top saying "Running libtool
tests".
I too think that we should use AT_KEYWORDS, for example we could have a
keyword "cross" for tests that work when cross compiling etc.
Peter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter O'Gorman wrote:
| Hi,
|
| Currently libtool's func_extract_archives removes the dir, then
| recreates it. It is breaking my forward port of Alexandre Oliva's patch
| to rename objects before putting them in the archive if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter O'Gorman wrote:
|>>
|>> This is Alexandre Oliva's patch with a test case. OK to apply to
|>> branch-1-5
|>> and forward port?
|>
|>
|>
|> Yes. Please show the forward-port, though. Nice and clean
Ralf Wildenhues wrote:
Hi Peter,
* Peter O'Gorman wrote on Sat, Apr 16, 2005 at 05:30:01PM CEST:
Peter O'Gorman wrote:
|>>
|>> This is Alexandre Oliva's patch with a test case. OK to apply to
|>> branch-1-5
|>> and forward port?
|>
|> Yes. Please show
5]): Define file_list_spec.
(_LT_LANG_CXX_CONFIG, aix[45]): Define file_list_spec.
I just committed this to HEAD.
Thank you,
Peter
--
Peter O'Gorman - http://www.pogma.com
libor topic
|
| [1] /me waves to pogma
I'll wave back, but there is little chance of me having free time enough to
do a release until mother-in-law leaves (i.e. mid-May).
Anyway, Ralf is better :)
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG
c -o x x.c
|
| Please, advice.
Use -Wl, or -Xlinker or libtool-1.5.16.
Peter
- --
Peter O'Gorman - http://www.pogma.com
Peter,
libtool-1.5.16 still has the same bug
Well aren't I stupid, I did not notice that you specified *program* and I
tried linking a library and it got passed through happil
s, so they
| matter less.
| + $ECHO "$oldobjs" | $SP2NL | $SED -n -e '/./p' >_objs
Ralf, you really rock!
I do worry about this echo though. How big is $oldobjs? Will we exceed the
max_cmd_len if echo is an external program?
Peter
- --
Peter O'Gorman - http://www.pogma.com
Okay to apply?
Peter
--
Peter O'Gorman - http://www.pogma.com
Index: ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>,
Peter O'Gorman <[EMAIL PROTECTED]>
* config/ltmain.m4sh: Don't add files with the same base name to an
archive
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Wildenhues wrote:
| Does this need forward-porting to branch-2-0 and HEAD?
|
Hi Ralf,
I do not believe that it does.
Peter
|
|>2005-05-04 Peter O'Gorman <[EMAIL PROTECTED]>
|>
|> * ltmain.in [darwin]: Pass -framework
Ralf Wildenhues wrote:
Hi Peter,
* Peter O'Gorman wrote on Thu, May 05, 2005 at 03:02:03PM CEST:
Okay to apply?
Minor nits below, otherwise fine, I think.
(As fine as it is in HEAD currently, which will change soon)
Thanks, as always, for finding my stupidities. Will fix before committing.
approves in a few days I will look more closely.
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iQCVAwUBQoIXz7iDAg3OZTLPAQJLSAP/Ubd16UtZ+zgNH0v7lS023Cn5tTakcWSZ
QWm/Brwm8rJBBBXUwirm3yMhLSli6
en that the libtool folks had wanted to "keep
|>libtool outside of automake" because libtool is/had been supposed to be
|>a tool independent of the make infrastructure being used (automake is
|>just one of them).
|
|
| OK.
With keeping current libtool compile mode, automake doing this
rtions of this patch eliminate unnecessary loops, or have other
optimizations, I like them, just can't deal with the tempfiles.
Sorry, hope my explination makes some sense. I encourage other maintainers
to make their feelings clear.
Peter
--
Peter O'Gorman - http://www.pogma.com
Ralf Wildenhues wrote:
Hi Peter,
* Peter O'Gorman wrote on Thu, May 05, 2005 at 03:02:03PM CEST:
Okay to apply?
Minor nits below, otherwise fine, I think.
(As fine as it is in HEAD currently, which will change soon)
I applied this to branch-2-0.
Peter
--
Peter O'Gor
Ralf Wildenhues wrote:
Hi Peter,
* Peter O'Gorman wrote on Sat, May 28, 2005 at 05:56:03PM CEST:
Ralf Wildenhues wrote:
What happens instead with your patch applied (sorry for not checking
myself)?
Attached is a gnuradio build snippit. Also passes all tests.
That looks fine
I applied this to branch-1-5.
Peter
--
Peter O'Gorman - http://www.pogma.com
Index: ChangeLog
from Bob Friesenhahn <[EMAIL PROTECTED]>
* ltmain.in: Add fully-qualified paths to temp_rpath
rather than unqualified paths in order to avoid possible errors
whe
Hi,
Well, Apple is switching to Intel. I figure that this means more people will
want to build fat during the transition.
This patch (one for HEAD, one for branch-1-5) will allow -arch flags through
to the linker.
Okay?
Peter
--
Peter O'Gorman - http://www.pogma.com
Index: ChangeLog
20
Ralf Wildenhues wrote:
Hi Peter,
* Peter O'Gorman wrote on Mon, Jun 20, 2005 at 04:34:00PM CEST:
Hi,
Well, Apple is switching to Intel. I figure that this means more people
will want to build fat during the transition.
This patch (one for HEAD, one for branch-1-5) will allow -arch
1 - 100 of 394 matches
Mail list logo