Re: strang dual-architecture problem under OS X

2014-03-07 Thread Peter O'Gorman
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

Re: libtool fails with uninstalled frameworks and the -F flag

2014-02-01 Thread Peter O'Gorman
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

[SCM] GNU Libtool branch, master, updated. v2.4.2-161-g9b726f3

2012-08-21 Thread Peter O'Gorman
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

Re: [PATCH] Update/simplify OpenBSD support

2012-08-21 Thread Peter O'Gorman
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

Re: [PATCH] Pass -g* through to linker

2012-08-21 Thread Peter O'Gorman
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

Re: [PATCH] Update/simplify OpenBSD support

2012-08-21 Thread Peter O'Gorman
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

Re: AIX PIC shared library support

2012-08-21 Thread Peter O'Gorman
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.

Re: [PATCH] libtool.m4: handle undefined from `getconf`

2012-04-18 Thread Peter O'Gorman
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

Re: static linking problem on Mac OS X Lion

2012-03-23 Thread Peter O'Gorman
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 \

Re: make check and LD_LIBRARY_PATH

2012-03-23 Thread Peter O'Gorman
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

Re: static linking problem on Mac OS X Lion

2012-03-23 Thread Peter O'Gorman
[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

Re: LD_LIBRARY_PATH - disappear of libdir after patch

2012-03-16 Thread Peter O'Gorman
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

Re: LD_LIBRARY_PATH - disappear of libdir after patch

2012-03-12 Thread Peter O'Gorman
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:

[SCM] GNU Libtool branch, master, updated. v2.4.2-154-g3b94c2d

2012-02-21 Thread Peter O'Gorman
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

Re: bug#10029: Fix GNU/Hurd linker flags such

2012-02-21 Thread Peter O'Gorman
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

[SCM] GNU Libtool branch, master, updated. v2.4.2-153-g9333e74

2012-02-19 Thread Peter O'Gorman
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

Re: Libtool error reporting.

2012-02-19 Thread Peter O'Gorman
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

Re: The case of libkmod's .so versioning attempts, and induced collisions

2012-02-07 Thread Peter O'Gorman
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

Re: The case of libkmod's .so versioning attempts, and induced collisions

2012-02-07 Thread Peter O'Gorman
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

Re: Libtool mishandling of C++ libraries requiring -pthread

2012-02-01 Thread Peter O'Gorman
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

Re: dlopen, DESTDIR, library dependencies and cannot install error

2012-01-09 Thread Peter O'Gorman
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

Re: dlopen, DESTDIR, library dependencies and cannot install error

2012-01-09 Thread Peter O'Gorman
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

Re: Several questions about libtool

2012-01-06 Thread Peter O'Gorman
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

Re: Several questions about libtool

2012-01-06 Thread Peter O'Gorman
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

Re: Fwd: http://www.gnu.org/software/libtool/future.html is outdated

2011-12-21 Thread Peter O'Gorman
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

[SCM] GNU Libtool branch, master, updated. v2.4.2-140-g88992fe

2011-12-12 Thread Peter O'Gorman
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

Re: PATCH: Add x32 support to _LT_ENABLE_LOCK

2011-12-12 Thread Peter O'Gorman
On 12/12/2011 11:32 AM, H.J. Lu wrote: * m4/libtool.m4 (_LT_ENABLE_LOCK): Support x32. Pushed, thanks. Peter

Re: PATCH: Add x32 support to _LT_ENABLE_LOCK

2011-12-12 Thread Peter O'Gorman
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

Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

2011-12-08 Thread Peter O'Gorman
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

Re: Local function in shared object?

2011-12-07 Thread Peter O'Gorman
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

Re: Libtool error reporting.

2011-12-07 Thread Peter O'Gorman
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

Re: Libtool, rpath, and libGL.so

2011-12-07 Thread Peter O'Gorman
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

Re: linking problems on SL6

2011-11-23 Thread Peter O'Gorman
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.

Re: linking problems on SL6

2011-11-21 Thread Peter O'Gorman
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

Re: linking problems on SL6

2011-11-21 Thread Peter O'Gorman
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

Re: [gnu.org #701121] Duplicate content?

2011-10-24 Thread Peter O'Gorman
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

Re: [gnu.org #701121] Duplicate content?

2011-10-24 Thread Peter O'Gorman via RT
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

Re: [gnu.org #701121] Duplicate content?

2011-10-24 Thread Peter O'Gorman via RT
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

Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-28-gadb7abd

2011-10-23 Thread Peter O'Gorman
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

Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-28-gadb7abd

2011-10-23 Thread Peter O'Gorman
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

Re: bug#9845: [PATCH 1/3] maint: use gnulib's maint.mk and support scripts release procedure.

2011-10-23 Thread Peter O'Gorman
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.

Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-28-gadb7abd

2011-10-23 Thread Peter O'Gorman
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

Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-28-gadb7abd

2011-10-23 Thread Peter O'Gorman
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

Re: potential linking issue with Xcode-4.2 on Lion

2011-10-17 Thread Peter O'Gorman
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

Re: Help needed to build shared library with libtool

2011-10-14 Thread Peter O'Gorman
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

Re: Help needed to build shared library with libtool

2011-10-14 Thread Peter O'Gorman
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

[SCM] GNU Libtool branch, master, updated. v2.4-56-g49ae288

2011-10-02 Thread Peter O'Gorman
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

[patch #7626] [PATCH] Better FreeBSD support

2011-10-02 Thread Peter O'Gorman
Update of patch #7626 (project libtool): Status:None = Done Assigned to:None = pogma Open/Closed:Open = Closed

Re: Bug 9210: fix to replace Linux with GNU/Linux where needed

2011-09-25 Thread Peter O'Gorman
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

Re: [PATCH] libtool -- don't print warnings with --silent

2011-09-05 Thread Peter O'Gorman
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

Re: Bug 9210: fix to replace Linux with GNU/Linux where needed

2011-09-04 Thread Peter O'Gorman
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

Re: Bug 9210: fix to replace Linux with GNU/Linux where needed

2011-09-03 Thread Peter O'Gorman
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

Re: [PATCH] libtool -- don't print warnings with --silent

2011-09-01 Thread Peter O'Gorman
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

Re: [PATCH] libtool -- don't print warnings with --silent

2011-08-29 Thread Peter O'Gorman
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 ---

Re: Shared library versioning

2011-06-14 Thread Peter O'Gorman
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

Re: What makes a convenience library (use --whole-archive)?

2011-06-07 Thread Peter O'Gorman
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

Re: why does libtool strip my -lm away on mingw32 builds?

2011-04-27 Thread Peter O'Gorman
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

Re: Mac OS X .dylib not working

2011-03-05 Thread Peter O'Gorman
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

Re: Patches for libtool support on NAG Fortran compiler for Darwin OS

2011-03-05 Thread Peter O'Gorman
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).

Re: Mac OS X .dylib not working

2011-03-04 Thread Peter O'Gorman
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

Re: Mac OS X .dylib not working

2011-03-04 Thread Peter O'Gorman
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

Re: Patches for libtool support on NAG Fortran compiler for Darwin OS

2011-03-01 Thread Peter O'Gorman
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 -

[SCM] GNU Libtool branch, master, updated. v2.4-48-gc44468e

2011-02-14 Thread Peter O'Gorman
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

Re: warnings from openSuSE rpmlint

2011-02-14 Thread Peter O'Gorman
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

Re: warnings from openSuSE rpmlint

2011-02-14 Thread Peter O'Gorman
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

Re: libtool 2.4 args parsing incredibly slow

2011-01-28 Thread Peter O'Gorman
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

Re: RFC: on AIX, which soname-equivalent to prefer with runtime linking?

2011-01-22 Thread Peter O'Gorman
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).

[SCM] GNU Libtool branch, master, updated. v2.4-42-ga85c4f5

2011-01-19 Thread Peter O'Gorman
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

[PATCH] Darwin - verbose linker messages influence configure results.

2011-01-19 Thread Peter O'Gorman
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

Re: [PATCH] Darwin - verbose linker messages influence configure results.

2011-01-19 Thread Peter O'Gorman
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

Re: shared library problem on macos with free software scientific package...

2011-01-07 Thread Peter O'Gorman
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

Re: How does one specify linking to 64 bit libraries when there is a choice?

2010-12-20 Thread Peter O'Gorman
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

Re: How does one specify linking to 64 bit libraries when there is a choice?

2010-12-17 Thread Peter O'Gorman
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

Re: How does one specify linking to 64 bit libraries when there is a choice?

2010-12-17 Thread Peter O'Gorman
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

Re: Libtool and CUDA

2010-12-06 Thread Peter O'Gorman
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

Re: Libtool and CUDA

2010-12-06 Thread Peter O'Gorman
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

Re: Libtool and CUDA

2010-12-06 Thread Peter O'Gorman
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

Re: Libtool and CUDA

2010-12-06 Thread Peter O'Gorman
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

Re: Libtool and CUDA

2010-12-05 Thread Peter O'Gorman
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.

Re: Libtool and CUDA

2010-12-05 Thread Peter O'Gorman
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.

Re: Fix linking from only convenience archives with gfortran on Darwin.

2010-10-14 Thread Peter O'Gorman
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

Re: [PATCH] relax -rpath argument test for Snow Leopard

2010-09-22 Thread Peter O'Gorman
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

Re: [PATCH] Correct typo: $sharedlib_from_linklib_cmd missing '_cmd'

2010-09-11 Thread Peter O'Gorman
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

Re: Next Libtool Point Release Pending

2010-08-09 Thread Peter O'Gorman
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

Re: libtool does not recognize /usr/lib64 as default location for libraries

2010-06-23 Thread Peter O'Gorman
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

Re: Clean up @var handling in the manual.

2010-06-19 Thread Peter O'Gorman
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

Re: lt_dlerror changes

2010-06-18 Thread Peter O'Gorman
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

Re: lt_dlerror changes

2010-06-18 Thread Peter O'Gorman
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

test coverage

2010-06-18 Thread Peter O'Gorman
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

Re: [RFC] [PATCH] libltdl error reporting

2010-06-18 Thread Peter O'Gorman
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

lt_dlerror changes

2010-06-17 Thread Peter O'Gorman
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

Re: lt_dlerror changes

2010-06-17 Thread Peter O'Gorman
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

Re: lt_dlerror changes

2010-06-17 Thread Peter O'Gorman
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

Re: lt_dlerror changes

2010-06-17 Thread Peter O'Gorman
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

Re: Multiple test failures with --disable-shared

2010-06-14 Thread Peter O'Gorman
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

Re: [RFC] [PATCH] libltdl error reporting

2010-06-14 Thread Peter O'Gorman
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

[SCM] GNU Libtool branch, master, updated. v2.2.10-14-g23c144c

2010-06-13 Thread Peter O'Gorman
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

Re: Multiple test failures with --disable-shared

2010-06-12 Thread Peter O'Gorman
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

Re: Multiple test failures with --disable-shared

2010-06-11 Thread Peter O'Gorman
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

Re: Multiple test failures with --disable-shared

2010-06-11 Thread Peter O'Gorman
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   2   3   4   5   6   7   8   >