On Mar 2, 2014, at 8:48 PM, Werner LEMBERG w...@gnu.org wrote:
Some weeks ago I wrote:
I've now found out that it *is* a libtool problem:
libtool: link: \
(cd
/Users/wl/harfbuzz-0.9.26/src/.libs/libharfbuzz.lax/libhb-ucdn.a/unfat-91266/libhb-ucdn.a-i386
\
ar x
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
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
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
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.
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 vap...@gentoo.org
* m4/libtool.m4: Check
Hi,
On 03/23/2012 07:58 AM, Werner LEMBERG wrote:
I have a problem with libtool on Mac OS X Lion, trying to link
statically to (a statically compiled version of) Qt. Saying
make LDFLAGS=-all-static V=1
I get this link command together with the error message.
/bin/sh ../libtool \
On 03/23/2012 06:40 AM, Christian Egli wrote:
libtool --mode=execute -dlopen ../liblouis/liblouis.la -n python $(TEST_SCRIPT)
What is the drawback of just setting LD_LIBRARY_PATH in
TESTS_ENVIRONMENT?
Not all systems use LD_LIBRARY_PATH. You can find the variable that
libtool sets by
[I replied to Werner without copying the list by mistake. Here is the
reply.]
On 03/23/2012 09:50 AM, Werner LEMBERG wrote:
I get this link command together with the error message.
/bin/sh ../libtool \
--tag=CXX \
--mode=link \
g++ -pipe -O2
Please add a --debug after the
From: Peter O'Gorman pe...@pogma.com
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 se...@lavabit.com
---
m4/libtool.m4 |2 +-
1 files changed, 1 insertions(+), 1
Hi Paul,
On 03/12/2012 10:47 AM, Paul Seidler wrote:
Hello,
running the test suite of eina-1.1 with 1.0 installed and
libtool-2.4{.2,} the tests will fail (symbol lookup errors) because of
the LD_LIBRARY_PATH (same with glib, gst-plugins-base, ...). The libdir
is in front of the test-path:
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
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
9333e74fc7b76a11ed04a19343eb5dd75a1035f3
Merge: c0c49f2 b804ffa
Author: Peter O'Gorman pe...@pogma.com
Date: Sun Feb 19 16:21:00 2012 -0600
Merge branch 'master' of ssh://git.sv.gnu.org/srv/git/libtool
commit c0c49f289f22ae670066657c60905986da3b555f
Author: Titus von Boxberg ti...@v9g.de
Date: Sun Feb 19 15:33
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
On 02/06/2012 06:35 PM, Jan Engelhardt wrote:
Much to my disappointment, I found that the newly-released libkmod v5
has made the following non-trivial change to its source tree, the latter
of which I want to bring to attention:
commit e479598b7d19ae7be45bf5329d6e4df32d646c16
On 02/07/2012 07:06 PM, Lucas De Marchi wrote:
Yes. We can always learn. It seems that this is not the case here.
There are other projects releasing like this and no one pointed out to
a reasonable argument against it. That means these arguments are not
valid in our case:
Again, use
On 02/01/2012 05:49 PM, Bob Friesenhahn wrote:
The libltdl module loader does need to load the dependency libraries
since the system might not do this at all, or might not do it fully or
correctly. It can't do this without knowing the libraries used. This has
been known to be a definite factor
On 01/09/2012 08:50 AM, Diab Jerius wrote:
On Sat, 2012-01-07 at 13:31 -0600, Bob Friesenhahn wrote:
On Fri, 6 Jan 2012, Diab Jerius wrote:
and the installation is performed via
make AM_MAKEFLAGS=DESTDIR=/proj/axaf/simul/pkgs prefix=/lua_udunits2-0.1.2_01
On 01/09/2012 09:31 AM, Diab Jerius wrote:
make DESTDIR=/home/dj/stage prefix=/rbtree-1.0.9 exec_prefix=/rbtree-1.0.9/x86
install
The resultant file hierarchy is shallower:
/home/dj/stage
/home/dj/stage/rbtree-1.0.9
/home/dj/stage/rbtree-1.0.9/x86
/home/dj/stage/rbtree-1.0.9/x86/lib
On 01/06/2012 11:21 AM, Stepan Kasal wrote:
1) .la file always contains the recursively evaluated list of libraries.
While this is necessary for static linking and dumb dynamic linkers,
it is an issue for dyn. linkers that can do recursive resolution
(which is the case on GNU/Linux
On 01/06/2012 12:31 PM, Peter O'Gorman wrote:
On 01/06/2012 11:21 AM, Stepan Kasal wrote:
1) .la file always contains the recursively evaluated list of libraries.
While this is necessary for static linking and dumb dynamic linkers,
it is an issue for dyn. linkers that can do recursive
Hi Max,
Thanks, I did as you suggested and removed future.html.
Peter
On 12/21/2011 10:30 AM, Max Horn wrote:
Hi Peter,
I tried two times now to send the following email to webmast...@www.gnu.org, but the address seems
to be dead and not accepting any delivery; after several days, each with
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
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
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
On 12/07/2011 11:45 AM, Mark R Bannister wrote:
Hi,
I wonder if someone could point out my error. I've defined a function,
nothing special, takes a couple of args and returns a pointer to a
structure.
The function is not declared with any special keywords. It is not static.
Yet, when compiled
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 into
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 11/22/2011 11:36 PM, Adam Mercer wrote:
On Mon, Nov 21, 2011 at 15:39, Peter O'Gormanpe...@pogma.com wrote:
Glad it works around it. The problem is libtool brokenness, most vendors
patch around it in their packaged libtool, e.g.
Hi,
On 11/19/2011 01:03 AM, Adam Mercer wrote:
Hi
In building a development snapshot of one of my projects, to a custom
path, on SL6 I am running into what appears to be a linking problem.
The libtool command used to link the library is as follows:
libtool: link: gcc -std=gnu99 -shared -fPIC
On 11/21/2011 03:22 PM, Adam Mercer wrote:
Setting lt_cv_sys_lib_dlsearch_path_spec=/lib64 /usr/lib64 at
configure time results in -Wl,-rpath -Wl,/usr/lib64 not being passed
and the correct libraries linked. So this is a workaround but I'd like
to understand why these flags are being added in
On 10/24/2011 11:05 AM, Jason Self via RT wrote:
Josh wrote:
Hi,
I search the Emacs manual using Google's site: operator. For example:
http://www.google.com/search?q=site:www.gnu.org/software/emacs+EXAMPLE
I've been noticing that pages in the manual don't always show up in the
search results
On 10/24/2011 11:05 AM, Jason Self via RT wrote:
Josh wrote:
Hi,
I search the Emacs manual using Google's site: operator. For example:
http://www.google.com/search?q=site:www.gnu.org/software/emacs+EXAMPLE
I've been noticing that pages in the manual don't always show up in the
search
On 10/24/2011 01:54 PM, Peter O'Gorman wrote:
On 10/24/2011 11:05 AM, Jason Self via RT wrote:
Hello libtool maintainers, just forwarding the above feedback to you for
your consideration. Perhaps one option might be linking to the GNU Emacs
manual instead of maintaining an independent copy
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 hadn't read
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.
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
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 install
On 10/17/2011 05:02 PM, Adam Mercer wrote:
On Mon, Oct 17, 2011 at 16:40, Peter O'Gormanpe...@pogma.com wrote:
Peter
Does it work if you remove -mmacosx-version-min=10.4?
That resulted in the same error, but your idea led me to remove each
flag one by one and it turns out that the insane
On 10/14/2011 02:10 AM, David Aldrich wrote:
Hi
I am using libtool in a makefile to create a shared library containing my
application code, which also links to wxWidgets libraries. As a consequence of
changing both platform (including gcc version) and wxWidgets packages, my
makefile ceases
On 10/14/2011 08:45 AM, David Aldrich wrote:
Hi Peter
Thanks for your reply.
-shared is not a libtool flag
Oh, that's weird! We've been using that option for building other shared
libraries for a long time.
Yes, and older libtools used to pass it along to the compiler driver, so
on
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 49ae2888b43cad358e2ff60a69722341116e7b40 (commit)
from
Update of patch #7626 (project libtool):
Status:None = Done
Assigned to:None = pogma
Open/Closed:Open = Closed
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
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-warn flag from
On Sep 4, 2011, at 1:05 AM, Christophe Jarry wrote:
On Sat, 03 Sep 2011 16:34:51 -0500
Peter O'Gorman pe...@pogma.com wrote:
Please do not change the version type for libtool library versioning
from linux to gnu-linux. [...] I object to this change.
Could you please explain to me why
On 09/03/2011 02:10 PM, Christophe Jarry wrote:
Dear developers,
I have reported the following bug onbug-libt...@gnu.org (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
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 compile/link messages.
Would
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
---
On 06/14/2011 11:26 AM, Lasse Collin wrote:
On 2011-06-14 Bob Friesenhahn wrote:
On Tue, 14 Jun 2011, Lasse Collin wrote:
Please read the section Understanding shared libraries
number rules (it's short):
http://www.openbsd.org/faq/ports/specialtopics.html
If this web page text is
On 06/07/2011 08:07 PM, Michael Poole wrote:
Some of the files in my convenience libraries have static
initializers. By default, the linker discards these symbols because
they are not referenced. I am trying to figure out how to keep them
in an automake-driven build.
Mailing list threads I
On 04/27/2011 07:25 AM, Ed Hartnett wrote:
Howdy all!
Hi Ed,
Recently I managed to get my C library building and testing cleanly on
Linux for windows, using mingw32 and wine. This is the greatest idea
since sliced bread. (In fact, I would rather live without sliced bread!)
I am building
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 messing with PATH
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).
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
pasted lt_dlopenext testcase
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 and .so
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
-
c44468e0ec23e4b72f1e37e98be23ae71b6d0ed1
Author: Peter O'Gorman pe...@pogma.com
Date: Mon Feb 14 10:34:58 2011 -0600
Install ltmain.sh without execute bit set.
* Makefile.am: change install rule for ltmain.sh
Reported by KÅiÅ¡tof Želechovski
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 shebang
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 customers
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 pe...@pogma.com
Date: Thu, 27 Jan 2011 17:13:10 -0600
Subject: [PATCH] Don't loop
On 01/21/2011 08:19 AM, Michael Haubenwallner wrote:
Hello!
Hi.
Library versioning for AIX would be a great feature.
After playing around with different ways[1], this is my proposed one,
using an AIX feature called Import Files:
*) Create the shared object shr.o (using '-G' linker flag).
a85c4f5e4082f25b967c284be1d9f5080f0a0d5b
Author: Peter O'Gorman pe...@pogma.com
Date: Wed Jan 19 12:53:32 2011 -0600
Don't let verbose linker messages influence test results.
* libltdl/m4/libtool.m4 (_LT_REQUIRED_DARWIN_CHECKS): Ignore
stderr during tests for -flag unless it contains flag.
* tests
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 pe...@pogma.com
Date: Wed, 19 Jan 2011 10:09:46 -0600
Subject: [PATCH] Don't let verbose linker messages influence test
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 21 (order matters!)
Are you really grepping the binary intentionally here, rather than the
.err file?
Yes, and that
On 01/07/2011 06:30 AM, Ed Hartnett wrote:
libtool: link: g95 -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o
.libs/libnetcdff.0.dylib .libs/fort-attio.o .libs/fort-control.o
.libs/fort-dim.o .libs/fort-genatt.o .libs/fort-geninq.o
.libs/fort-genvar.o .libs/fort-lib.o
On 12/20/2010 10:54 AM, Bruce Korb wrote:
If the default build is 64 bit, why does it make sense that the
default library directory is the 32 bit library?
Because the user may not be building for multiple architectures, in
which case a default of $prefix/lib for libdir makes perfect sense
On 12/17/2010 11:09 AM, Nelson H. F. Beebe wrote:
I normally do builds on the AMD64 platforms with something like this
(at a minimum):
env LDFLAGS='-L/usr/local/lib64 -Wl,-rpath,/usr/local/lib64' ./configure
make all check
make install libdir=/usr/local/lib64
It does
On 12/17/2010 02:59 PM, Peter O'Gorman wrote:
On 12/17/2010 11:09 AM, Nelson H. F. Beebe wrote:
I normally do builds on the AMD64 platforms with something like this
(at a minimum):
env LDFLAGS='-L/usr/local/lib64 -Wl,-rpath,/usr/local/lib64' ./configure
make all check
make install libdir=/usr
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
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
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
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
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/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 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 your
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
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
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
On 06/23/2010 09:12 AM, Olly Betts wrote:
I posted just such a patch exactly 3 years ago today (coincidentally) -
here's the thread:
http://thread.gmane.org/gmane.comp.gnu.libtool.general/8339/focus=8345
Back then Ralf said Olly's solution should not be forgotten, though, but
it seems it has
On 06/19/2010 03:15 AM, Ralf Wildenhues wrote:
In texinfo, @var is for metasyntactic variables only, that is, things
that stand for other things *in the manual*. If you need a guideline,
then @var is only appropriate if you can replace the name with some
other name, say, the mathematician's
On 06/18/2010 08:09 AM, Charles Wilson wrote:
Here's the key bit:
Searching for preloaded symbol table for last
vs
Searching for preloaded symbol table for /usr/bin/last
SO, before preopen:vmopen is called, somebody -- one of the other
loaders? -- modified 'filename' simply because
On 06/18/2010 08:36 AM, Peter O'Gorman wrote:
On 06/18/2010 08:33 AM, Peter O'Gorman wrote:
On 06/18/2010 08:09 AM, Charles Wilson wrote:
Here's the key bit:
Searching for preloaded symbol table for last
vs
Searching for preloaded symbol table for /usr/bin/last
SO, before preopen:vmopen
I just tried to figure out lcov, and ran the testsuite with --coverage.
http://pogma.com/lcov/libltdl/index.html
I'll try at some stage to automate the process and do it weekly or so.
Peter
___
http://lists.gnu.org/mailman/listinfo/libtool
On 06/14/2010 04:41 PM, Peter O'Gorman wrote:
dlopen nonexisting file
dlopen existing file
check dlerror()
Ok, systems that return an error in this case:
Solaris, AIX, HPUX/IA64, FreeBSD
systems that don't return an error:
HP-UX/HPPA, Tru64 5.1, IRIX 6.5, linux/glibc, Mac OS X.
Whee
file not found.
Still, I am not overjoyed with this.
Peter
From 40202fade8f55891b5f4acfee54eba02636b91e8 Mon Sep 17 00:00:00 2001
From: Peter O'Gorman pe...@pogma.com
Date: Thu, 17 Jun 2010 12:42:28 -0500
Subject: [PATCH] Improve libltdl error messages.
* libltdl/lt_error.c: Add new functions
On 06/17/2010 08:36 PM, Charles Wilson wrote:
On 6/17/2010 4:54 PM, Peter O'Gorman wrote:
Well, this is what I ended up with, it does not change the currently
documented saving of error messages until lt_dlerror() is called, it
copies the error message to ensure that we don't return garbage
On 06/17/2010 10:21 PM, Charles Wilson wrote:
On 6/17/2010 10:24 PM, Peter O'Gorman wrote:
Unfortunately, this doesn't magically assist solving my problem with
71. dlloader-api.at:23: FAILED (dlloader-api.at:422)
but that's not a reason to object to the patch.
Well that sucks :(
I
On 06/17/2010 10:35 PM, Peter O'Gorman wrote:
On 06/17/2010 10:21 PM, Charles Wilson wrote:
On 6/17/2010 10:24 PM, Peter O'Gorman wrote:
Unfortunately, this doesn't magically assist solving my problem with
71. dlloader-api.at:23: FAILED (dlloader-api.at:422)
but that's not a reason to object
this. No test failures for me with --disable-shared now.
Peter
From 0263ff229bbf6f02a61d4ccad3bd4ab3a5601e1d Mon Sep 17 00:00:00 2001
From: Peter O'Gorman pe...@pogma.com
Date: Mon, 14 Jun 2010 11:04:17 -0500
Subject: [PATCH] Pass resident test with --disable-shared too.
* tests/resident.at: use
On 06/10/2010 12:33 AM, Peter O'Gorman wrote:
At least glibc and Mac OS X reset the dlerror() string to NULL every
time a dl*() api is called (I will check what other systems do in the
next few days). This is so programmers can do:
Sigh, but FreeBSD doesn't.
dlopen nonexisting file
dlopen
in full, below.
- Log -
commit 23c144c1bcc5c71e05b27e7233a8bbef331cf410
Author: Peter O'Gorman pe...@pogma.com
Date: Sun Jun 13 22:27:31 2010 -0500
Test with --disable-shared at release time too.
* HACKING: Note
On 06/11/2010 11:56 PM, Gary V. Vaughan wrote:
Hi Peter,
On 12 Jun 2010, at 11:39, Peter O'Gorman wrote:
On 06/10/2010 03:07 PM, Peter O'Gorman wrote:
On 06/10/2010 11:10 AM, Peter O'Gorman wrote:
Hi,
I got an off-list report from a user about test failures in 2.2.6b, that
turned out
On 06/11/2010 11:53 AM, Dave Korn wrote:
On 11/06/2010 16:18, Peter O'Gorman wrote:
Hello Dave,
The bindir.at test fails when libtool is configured with
--disable-shared, I am considering just skipping the test in that case,
but if the test is still useful, then perhaps we can change the check
On 06/10/2010 03:07 PM, Peter O'Gorman wrote:
On 06/10/2010 11:10 AM, Peter O'Gorman wrote:
Hi,
I got an off-list report from a user about test failures in 2.2.6b, that
turned out to be either because he'd configured with --disable-shared or
libtool had incorrectly guessed that his system did
1 - 100 of 773 matches
Mail list logo
