Re: module name on mac os x

On 04/21/2010 04:00 PM, Vincent Torri wrote: > > Hey, > > A guy mentioned that problem: on mac os x, a "standard" shared lib has > suffix name .dylib: > > lib_LTLIBRARIES = libfoo.la --> libfoo.dylib > > but with a "module": > > pkg_LTLIBRARIES = bar.la > bar_la_LDFLAGS = -module -avoid-versi

Re: module name on mac os x

On 04/22/2010 12:01 AM, Vincent Torri wrote: > > > On Wed, 21 Apr 2010, Peter O'Gorman wrote: > >> On 04/21/2010 04:00 PM, Vincent Torri wrote: >>> >>> Hey, >>> >>> A guy mentioned that problem: on mac os x, a "standard" share

Re: use of shrext_cmds on mac os x (fwd)

On 04/23/2010 01:30 PM, Vincent Torri wrote: > > > -- Forwarded message -- > Date: Fri, 23 Apr 2010 12:27:27 -0600 > From: Eric Blake > To: Vincent Torri > Cc: autoc...@gnu.org > Subject: Re: use of shrext_cmds on mac os x > > On 04/23/2010 12:09 PM, Vincent Torri wrote: >> >>

[RFC] [PATCH] libltdl error reporting

Hi, As I am sure many are aware, libltdl's error reporting is pretty dumb, lt_dlerror() regularly reports things like "file not found" where the actual problem might be something completely different, and a reasonable error string may be readily available from dlerror(). When I looked at the

Re: [RFC] [PATCH] libltdl error reporting

Aside: I'm leaning away from upholding the 'drop-in-with-minimum-edits' philosophy for my rewrite, since the dlfcn.h API seems like a pretty bad design to me. After all, all people really need to do is call functions with a known name and known signature which happen to be in another library. I'm

Re: rewrite of ltdl and c++ (was: Re: [RFC] [PATCH] libltdl error reporting)

On 06/10/2010 09:45 AM, Gary V. Vaughan wrote: I think it would be better in c++. No, that would mean you have to jump through hoops to use it from C. And it would make me cry myself to sleep at night. I avoid C++, Perl, McDonalds and suicide bomber recruiters as much as I possibly can. I'm

Re: [RFC] [PATCH] libltdl error reporting

On 06/10/2010 02:28 PM, Bob Friesenhahn wrote: On Thu, 10 Jun 2010, Peter O'Gorman wrote: As I am sure many are aware, libltdl's error reporting is pretty dumb, lt_dlerror() regularly reports things like "file not found" where the actual problem might be something complet

Re: [RFC] [PATCH] libltdl error reporting

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 f

test coverage

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

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 O

Re: Libtool and CUDA

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

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

Re: Libtool and CUDA

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: How does one specify linking to 64 bit libraries when there is a choice?

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 no

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

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 inst

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

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 an

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

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 .libs/fort

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

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

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

On 01/31/2011 11:21 AM, Ed Hartnett wrote: Peter O'Gorman writes: /usr/bin/libtool: unknown option character `f' in: -force_load Usage: /usr/bin/libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT] Usage: /usr/bin/libtool -dynami

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

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 i

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

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 hav

Re: Shared library versioning

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 corre

Re: Help needed to build shared library with libtool

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 t

Re: Help needed to build shared library with libtool

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 system

Re: potential linking issue with Xcode-4.2 on Lion

On 10/17/2011 01:48 PM, Adam Mercer wrote: Hi I testing some software I maintain using the recently release Xcode-4.2 on Mac OS X 10.7.2, and am running into the follow error during link: Hi, Does it work if you remove -mmacosx-version-min=10.4? Peter /bin/sh ../../../libtool --tag=CC

Re: potential linking issue with Xcode-4.2 on Lion

On 10/17/2011 05:02 PM, Adam Mercer wrote: On Mon, Oct 17, 2011 at 16:40, Peter O'Gorman 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 optimiz

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

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 result

Re: linking problems on SL6

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

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: linking problems on SL6

On 11/22/2011 11:36 PM, Adam Mercer wrote: On Mon, Nov 21, 2011 at 15:39, Peter O'Gorman wrote: Glad it works around it. The problem is libtool brokenness, most vendors patch around it in their packaged libtool, e.g. http://pkgs.fedoraproject.org/gitweb/?p=libtool.git;a=blob;f=libtool-2

daily snapshot broken again

Hi, Looks like there was no daily snapshot for a couple of weeks because the script was doing (the apparently naive): git pull ./bootstrap ./configure make make distcheck and the gnulib submodule never got updated, so bootstrap failed with: top/README-release top/maint.mk 2 out of 2 hunks

Re: Local function in shared object?

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.

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 int

Re: Libtool, rpath, and libGL.so

On 11/29/2011 11:48 PM, Adam Mercer wrote: On Mon, Nov 28, 2011 at 23:30, Andy Spencer 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 configured to use the nvidi

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

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

Re: Several questions about libtool

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 distributions

Re: Several questions about libtool

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 recu

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

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 exec_prefix=/lua_udunits2-0.1.2_01/

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

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 /home/dj/

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

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 f

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

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 diff

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

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 -version-n

Re: Libtool error reporting.

n 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-archiv

Re: LD_LIBRARY_PATH - disappear of libdir after patch

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": LD

Re: LD_LIBRARY_PATH - disappear of libdir after patch

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(+)

Re: static linking problem on Mac OS X Lion

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 \ --t

Re: make check and LD_LIBRARY_PATH

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 checkin

Re: static linking problem on Mac OS X Lion

[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 ../libt

Re: strang dual-architecture problem under OS X

On Mar 2, 2014, at 8:48 PM, Werner LEMBERG 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: Creating two-level namespace binaries on Mac OS 10.2?

and Mac OS X will build a two level namespace shared library. Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQjWGoriDAg3OZTLPAQIBQAQAvFs86QlHceCNJcXIi9rPB/iyvrFADIxV /YJiRNICLoosgSLqTKkFJlNcfwP2EKdBLBvIuQrBKbudItH4HEWoUJyAil

Re: totally confused by versioning system of libtool...

install time? Mac OS X/darwin support for library versioning in GNU libtool uses a scheme that is similar to GNU/linux, it works fine. Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQoYRariDAg3OZTLPAQJE/QQAuJZxAA41saLqnV9ZMn8S

Re: totally confused by versioning system of libtool...

<http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachOTopics/Articles/loading_code.html> (alternatively <http://tinyurl.com/a376e>). Peter -- Peter O'Gorman - http://www.pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: totally confused by versioning system of libtool...

, compatibility_version is used by dyld (darwin's dynamic linker) when loading libraries. It checks that the library version it loaded has a compatibility_version greater than or equal to the one it saw when it was created by the static linker. An example is attached. Peter -- Peter O'Gor

Re: totally confused by versioning system of libtool...

Bill Northcott wrote: On 15/05/2005, at 12:55 AM, Peter O'Gorman wrote: It what sense do you think 'it works fine'? How does a single libtool version string get translated into the two possibly different version strings required by MacOS X? I don't follow what you think

Re: Preserving Object / Library Order

aries in the link command-line. libtool | appears (see below) to reorder the objects/libraries. | Is there a way to tell libtool to not reorder? | As far as I am aware, this reordering problem as been apparent for a long time, but nobody has been able to find a solution for it. Peter - --

Mac OS X 10.4 test failures on HEAD

environment variable to 10.3 or later and ./configure; make; make check will pass all tests. Thanks, Peter -- Peter O'Gorman - http://www.pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: Mac OS X 10.4 test failures on HEAD

GET environment variable to 10.3 or later and ./configure; make; make check will pass all tests. Thanks for this information. Should this be in doc/notes.texi? Dunno, what do you think? Peter -- Peter O'Gorman - http://www.pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: Mac OS X 10.4 test failures on HEAD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Egger wrote: | * Peter O'Gorman wrote on Fri, Jun 17, 2005 at 03:45:12PM CEST: | |>Hi, |>In case anyone is wondering (Gary) why HEAD fails one of the new tests on |>Mac OS X 10.4, it is because of a bug in the linker. I hav

Re: Mac OS X 10.4 test failures on HEAD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter O'Gorman wrote: | Christoph Egger wrote: | | * Peter O'Gorman wrote on Fri, Jun 17, 2005 at 03:45:12PM CEST: | | | |>Hi, | |>In case anyone is wondering (Gary) why HEAD fails one of the new tests on | |>Mac OS X 10.4, it is

Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Albert Chin wrote: |>05:00 PM dogbert ~$PS1='$ ' /bin/sh |>$ echo Xbla | sed 1s,^X,, |>X,,: not found |>$ sed: Function 1s, cannot be parsed. | | | What system is this? Works fine on 4.0D and 5.1. | I don't think you tried /bin/sh. Works okay with z

Re: branch 2.0, make install DESTDIR=

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: | | OK. Does `id -u' tell you whether you are SYSTEM (id 0?) or not? | What would be an appropriate solution for cygwin? Perhaps instead of going through hoops here we need to rethink the whole idea of using tar to keep the

Re: linking of indirect dependencies (dependency_libs) on Linux

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Langasek wrote: | Hi again, | | Is there no one out there who can answer this question from my mail of last | week, or was the message simply drowned out in the flood of spam on the | list? :) | | Thanks, Another thread:

Re: linking of indirect dependencies (dependency_libs) on Linux

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Langasek wrote: | Hi again, | | Is there no one out there who can answer this question from my mail of last | week, or was the message simply drowned out in the flood of spam on the | list? :) It is in the TODO file also, but it, obviously, is

Re: libtool ChangeLog [branch-2-0]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Ekberg wrote: | CVSROOT: /cvsroot/libtool | Module name: libtool | Branch: branch-2-0 | Changes by: Peter Ekberg <[EMAIL PROTECTED]> 05/07/28 09:06:07 Thank you very much for all these commits. Peter -BEGIN PGP SIGNATURE

Re: -F parameter appears not to be passed in OS X

Matthew Landauer wrote: Thanks for that! That's a really good workaround. I'm productive again! :-) Maybe I'm misunderstanding things but shouldn't libtool understand "-F"? It knows how to interpret -framework and -F goes with that as much as -L goes along with -l for normal linking. Most pe

Re: unwanted moderation/spam measures

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: | Just a short heads-up for people who have posted recently: | | In an attempt to improve upon the spam situation, I've probably messed | up mailman filtering rules to the extent that currently, everyone is | moderated. Please

Re: unwanted moderation/spam measures

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter O'Gorman wrote: | Ralf Wildenhues wrote: | | | | Regards, and sorry for the inconvenience, | | I have posted recently and had my mail queued for moderator approval. | Not happy. Okay, this one came through, improving my mood :)

Re: libtool/ltmain.sh pulling in wrong stdc++

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Graham Leggett wrote: | I am completely baffled - can anyone reveal what method libtool uses to | detect libraries? What steps are followed to create the dependency_libs | variable within the .la file? I am trying to find out where the referencce | t

Re: Fix ltdl files installation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: | Proposed patch OK for branch-1-5? Unfortunately, the forward ports will | need more work. Looks good to me. Thank you! Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQvNzuLiDAg3OZTLPAQLewAP8DbG

Re: branch-2-0 vs CVS HEAD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary V. Vaughan wrote: |> |> Hear! Hear! | | | Blast. Seems I'm outvoted. To my mind there are good arguments for | either case... but I'm not rabid about keeping branch-2-0 alive, so if | the concensus is to drop the current branch-2-0 then so be i

daily cvs snapshot does not exist

Hi, Looks like there is no gnu/cvs dir on alpha.gnu.org, so no daily snapshot. Do we need one? Peter ___ http://lists.gnu.org/mailman/listinfo/libtool

makeinfo --plaintext

Is there any reason to use --plaintext, it causes bootstrap to fail with texinfo 4.6 (well, actually bootstrap succeeds, but the make command used during bootstrap fails, bootstrap doees not notice). --no-headers appears to produce identical output and works with 4.6. Peter _

Re: libtool: link: cannot find the library `'

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Paljak wrote: | Hi, | On 9/9/05, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: | |>Thanks for reporting this. |> |>Please post contents of http/libhttp.la, and the output of the above |>command with "--debug" added before "--tag=CXX". | | | Everyt

Re: libtool: link: cannot find the library `'

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: | @@ -2194,7 +2194,7 @@ | esac # case $deplib | if test "$found" = yes || test -f "$lib"; then : | else | - $echo "$modename: cannot find the library \`$lib'" 1>&2 | + $echo "$modename: ca

Re: libtool: link: cannot find the library `'

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Paljak wrote: | On 9/9/05, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: | Hmm, this patch helps and proves the -framework Carbon thing: | libtool: link: cannot find the library `' or unhandled argument `Carbon' | | What could i do to fix it? only

Re: Why am I linking to an installed library?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruce Korb wrote: | Another quick question: | | |>+ relink_command='{ test -z "${COMPILER_PATH+set}" || unset COMPILER_PATH || { COMPILER_PATH=; export COMPILER_PATH; }; }; { test -z "${GCC_EXEC_PREFIX+set}" || unset GCC_EXEC_PREFIX || { GCC_EXEC_PREF

Re: postdeps empty on OpenBSD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: | | Probably libtool needs to be adjusted (on OpenBSD, | output_verbose_link_cmd is set to `echo' in the C++ case). | | Brad, you changed this with this patch: | http://lists.gnu.org/archive/html/libtool-patches/2004-07/msg0

Re: postdeps empty on OpenBSD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thorsten Glaser wrote: | gcc -shared creates a shared library. | | On OpenBSD, shared libraries do not link against other shared libraries. | The main programme must link against all these. Is there a reason for this? Peter -BEGIN PGP SIGNATURE-

Re: postdeps empty on OpenBSD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacob Meuser wrote: | And changing output_verbose_link_command won't fix Olly's problem | anyway, because as Olly has shown, -lstdc++ doesn't get added by the | linker when -shared is used. | Do we know what the versions of the OS/gcc are where -lstd

Re: postdeps empty on OpenBSD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacob Meuser wrote: | | Thorsten's statement is somewhat misleading. you can definitely link | libraries and dlopened modules against libraries without having all | those libraries linked directly to the executable. | | but, there was something of a

Re: postdeps empty on OpenBSD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacob Meuser wrote: | | just add -lstdc++ manually. trust me, that works fine. I really don't | see why libtool should be adding this automatically. is it _always_ | needed? what about -lsupc++? | Apparently, it is not always needed, see:

Re: Fwd: Configure is checking for fortran yet I have no fortran code or checks

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: | the CXX check is especially annoying ... if you have a host which only has a C | compiler and you try to build a library which is pure C, configure will abort | because it cant find a C++ compiler even though none of the source

Re: postdeps empty on OpenBSD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacob Meuser wrote: | I think perhaps you should ask [EMAIL PROTECTED] about this. he might | be able to explain why -lstdc++ is not implicitly used in `g++ -shared', | which could give you a good starting point on how to "fix" the | "problem". | I

Re: mode=link and full path to dependent shared library?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: | Doesn't that patch break other libtool instances which do not have it? | (i.e.: libfoo.la will contain `/path/to/libintl.so' in dependency_libs, | but libtool's without your patch will refuse to read the .la file) | Untested

Re: problem with libtool on Darwin

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Federico Carminati wrote: | Hello, | may be I am completely wrong... however. If I use service libraries | in subdirectories to create a main library with Fortrran on Darwin I | have a problem. libtool correctly compiles the objects for the share

1.5.22 ?

Hi, I just looked at the ChangeLog on branch-1-5, there are quite a few changes in the last 2 months... So, I could do a 1.5.22 next week sometime, or Ralf might want to, thoughts? Peter ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: 1.5.22 ?

Ralf Wildenhues wrote: I should be able to post all outstanding 1.5 stuff within the next, say, three days. OK? Sure. Don't hurry, just that I was a little surprised by the number of changes in branch-1-5 and figured that a new release would be a good idea. A more complete release is an eve

Re: Libtool(?) frustrations

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David N. Welton wrote: | Hello, | | We're using the various auto tools for Apache Rivet | (http://tcl.apache.org/rivet/), but things seem to have taken a turn for | the worse... I'm able to compile and run everything just fine on Ubuntu, | but there s

Re: Libtool(?) frustrations

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David N. Welton wrote: | That comes from this Makefile.am line: | | lib_libexec_LTLIBRARIES = librivet.la librivetparser.la | | What might be the cause of this problem? Is there a better place to ask? | | Thanks for your help, # ... and these two.

Re: AIX5.x bug in libtool as generated by configure script used by courier-authlib-0.57)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jørgen Moth wrote: | Hi I was requested to forward the following description (and solution) of | an error in the libtool generating part of the configure script used by | the courier people. Please respond to [EMAIL PROTECTED] for any | further inform

Re: Libtool chops valid `-framework OpenGL' on Darwin

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian wrote: | Libtool appears to be trying to clean up the command line and in the process | removing a valid extension to apple's version of gcc. I can't think of a way | I can get around this which means my build process is broken on the mac. | | N

Re: response file support in GCC

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: | With response file support in GCC [1] we need to adjust Libtool | accordingly. Minimally to let the option through as below, but | ideally we should probably parse its contents. | | Any volunteers? Comments? | This is fine.

HEAD build failure, just me?

cd . && /bin/sh ./config.status libtool config.status: executing libtool commands cp ../libtool/libltdl/argz_.h libltdl/argz.h-t cp: cannot create regular file `libltdl/argz.h-t': No such file or directory make: *** [libltdl/argz.h] Error 1 For a VPATH build in an empty dir. creating the libltdl

Re: HEAD build failure, just me?

Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Thu, Nov 24, 2005 at 05:36:50PM CET: * Peter O'Gorman wrote on Thu, Nov 24, 2005 at 03:29:24PM CET: cd . && /bin/sh ./config.status libtool config.status: executing libtool commands cp ../libtool/libltdl/argz_.h libltdl/argz.h

Re: HEAD build failure, just me?

Ralf Wildenhues wrote: This is still the case. However, cvs-over-ssh access works, it seems they just killed ECHO reply. HTTP works as well, and the webpage shows an apology from a sysadmin who accidentally shut down the machine. I sent them a note: https://savannah.gnu.org/forum/forum.php?for

Re: libtool "no symlinked libs" patch

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: | The way I see it, there are two possible ways out: | | 1) Move all paths to uninstalled libraries (in the correct order) before | all other path specs. This is pretty much in the spirit of the patch | you posted in the other

Re: Fw: Problem with libtool under HPUX: BIND_FIRST flag is required

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: | | Hrmpf. I did not find this during my earlier search. | | I don't know really what to do. I'm reluctant to change branch-1-5 in | this respect. It's supposed to be a stable series, after all. :-/ I'd rather not see this

Use of printf in libtool.m4

Hi, Just looking to put in an honest check for -single_module support into libtool.m4 and I see this in _LT_COMPILER_OPTION: printf "$lt_simple_compile_test_code" > conftest.$ac_ext with similar usage elsewhere. Why do we go to so much effort to find a working echo if printf works everywhere

Re: Daily snapshot broken [Was: Re: Fix variables_saved_for_relink / LD_LIBRARY_PATH with libtool wrapped files]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kurt Roeckx wrote: | On Mon, Dec 19, 2005 at 10:22:04AM +0100, Ralf Wildenhues wrote: | |>Hmm. Teaches me to get people to test whether their bugs are indeed |>fixed. Luckily with HEAD we can point them to the nightly tarball. | | | I think the gene

Re: libtool shared convenience library problems on AIX?

On Dec 24, 2005, at 12:51 PM, Ralf Wildenhues wrote: Hi Ed, Ed Hartnett writes: When I run on AIX, unless I used --disable-shared, the link fails, because it can't find the contents of one of the convenience libraries. This is the symptom. PS - I'm using libtool version 1.9f. This shows

  1   2   3   4   5   >