Re: libtool 1.5.14 eats -framework option on Darwin/MacOSX

CoreAudio -o x x.c | Results in: | cc -o x x.c | | Please, advice. Use -Wl, or -Xlinker or libtool-1.5.16. Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQmbXNriDAg3OZTLPAQKapQP9F8Rs5ceGw0+VKVqmO

Re: Small fix for 1.5.16 to turn off installation on default

libor topic | | [1] /me waves to pogma I'll wave back, but there is little chance of me having free time enough to do a release until mother-in-law leaves (i.e. mid-May). Anyway, Ralf is better :) Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG

Re: libtool 1.5.14 eats -framework option on Darwin/MacOSX

c -o x x.c | | Please, advice. Use -Wl, or -Xlinker or libtool-1.5.16. Peter - -- Peter O'Gorman - http://www.pogma.com Peter, libtool-1.5.16 still has the same bug Well aren't I stupid, I did not notice that you specified *program* and I tried linking a library and it got passed through happil

Re: [rth@redhat.com: libjava build times]

rently). On many platforms maximum command line length is exceeded (about 95Kb of command line). Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQnlZE7iDAg3OZTLPAQLrlAP+LvrmAe0xtuh7Kd8oI+n75pM2e7QGVn1b hSnWB5a8iVmf1pxuuzIpHt2d

Re: [rth@redhat.com: libjava build times]

s, so they | matter less. | + $ECHO "$oldobjs" | $SP2NL | $SED -n -e '/./p' >_objs Ralf, you really rock! I do worry about this echo though. How big is $oldobjs? Will we exceed the max_cmd_len if echo is an external program? Peter - -- Peter O'Gorman - http://www.pogma.com

Re: Handling object name conflicts

it is simply a libtool-1.5.16's bug? | Thanks! | This change should only have affected convenience libraries. Is libfft3w a gnuradio convenience library? If so you should rebuild it. There is new code when making a convenience library that ensures there are no duplicated member names. Peter

Re: libtool fails without a CXX compiler installed

reported by multiple ~people, multiple times. I guess it got rebroken :( Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQpOnN7iDAg3OZTLPAQKSrwP/dluV7b2HHEsM7cmdv08j/RS9E4hPjp+T sL1qNJxSL4/mVbIYi4XzPdIH1zmL9WR/

Re: libtool fails without a CXX compiler installed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter O'Gorman wrote: | Eric Sandall wrote: | | Quoting Bob Friesenhahn <[EMAIL PROTECTED]>: | | | | | |> The problems I have heard about up until now have been that autoconf | |> "found" a C++ compiler, but it was disco

Re: libtool fails without a CXX compiler installed

Eric Sandall wrote: Quoting Peter O'Gorman <[EMAIL PROTECTED]>: Replying to myself... it is still fixed. Please use a newer libtool. <http://www.opendarwin.org/~pogma/lt_no_cxx.txt> I was using 1.5.16, will try 1.5.18, thanks. :) Was also fixed in 1.5.16. If your co

Re: Handling object name conflicts

Chen-Mou Cheng wrote: Indeed, I meant libfftw3; sorry about the typo and the confusion. Below is the libtool line and the output it generated: I'll try and reproduce/debug this on darwin this weekend. Does this happen with released versions of these packages? Thanks, Peter --

Re: Handling object name conflicts

Chen-Mou Cheng wrote: Yes it happens with released version as well. Can you confirm that the attached patch to ltmain.sh fixes this issue for you? Thanks, Peter -- Peter O'Gorman - http://www.pogma.com --- ltmain.sh~ Mon May 16 18:39:29 2005 +++ ltmain.sh Sat May 28 07:38:05

Re: Handling object name conflicts

Chen-Mou Cheng wrote: On 5/27/05, Peter O'Gorman <[EMAIL PROTECTED]> wrote: Can you confirm that the attached patch to ltmain.sh fixes this issue for you? Yes it does fix the problem. That's awesome. Would you like to explain briefly why it fixed the problem? Becau

Re: Handling object name conflicts

Ralf Wildenhues wrote: What happens instead with your patch applied (sorry for not checking myself)? Attached is a gnuradio build snippit. Also passes all tests. I didn't get a chance to apply patches tonight, had visitors. Tomorrow, I hope. Peter -- Peter O'Gorman - http://www

Re: Handling object name conflicts

Ralf Wildenhues wrote: Hi Peter, * Peter O'Gorman wrote on Sat, May 28, 2005 at 05:56:03PM CEST: Ralf Wildenhues wrote: What happens instead with your patch applied (sorry for not checking myself)? Attached is a gnuradio build snippit. Also passes all tests. That looks fine

Re: FYI: ltmain.m4sh needs to handle spaces in paths

e are many places where we do cd & pwd and then use the result without quoting. I think you will find it very hard to get libtool to build stuff if there are spaces in the paths. However, if you have the time... Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE-

Re: [libtool 2.1a] testsuite: 5 15 failed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Oxenreider wrote: |5: inherited_flags.at:20 inherited_linker_flags | 15: stresstest.at:25 Link option thorough search test This patch, applied as obvious, should, I hope, fix the inherited linker flags test. Peter - -- Peter O'G

Re: soname (was Re: [ft-devel] Freetype library for LSB)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Behdad Esfahbod wrote: | On Mon, 25 Jul 2005, Owen Taylor wrote: | | |>-export-symbols is pretty straightforward to use - we use it (or |>actually, -export-symbols-regex for Pango). You probably could build |>the symbol file pretty easily by scanning

Re: /usr/bin/file, produces output that libtool cannot recognize

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Rucci wrote: | hi i was configuring something on my FreeBSD 5.4-RELEASE-p1 box and | libtool told me to contact you. so i did. | | *** Warning: the command libtool uses to detect shared libraries, | *** /usr/bin/file, produces output that libto

Re: inherited linker flags misses linker flags on darwin

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Egger wrote: | Hi! | | | Say you have the following Makefile.am: | | --- | lib_LTLIBRARIS = foo.la | | foo_la_SOURCES = foo1.c foo2.c | foo_la_LDFLAGS = -Xlinker -framework -Xli

Re: inherited linker flags misses linker flags on darwin

Christoph Egger wrote: But there is something going wrong later, when I link a program against libfoo.la While inherited_linker_flags contains the right values, libtool malforms them. The linker then see's this: Carbon ApplicationServices -framework Okay, I'll look into this when I get back.

Re: inherited linker flags misses linker flags on darwin

meone would be kind enough to commit it while I am gone. Peter 2005-08-06 Peter O'Gorman <[EMAIL PROTECTED]> * config/ltmain.m4sh (inherited_linker_flags): Work when output is an application too. Reported by Christopher Egger <[EMAIL PROTECTED]> Ind

Re: Running ranlib after installation - okay or not?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter O'Gorman wrote: | The problem is that libtool tries to run ranlib after install and that | ranlib can fail if the library is not writable? [crosspost - beware - for context see <http://gcc.gnu.org/ml/gcc/2005-08/msg00937.html>]

Re: Running ranlib after installation - okay or not?

1-5. Thank you, Peter 2005-09-01 Peter O'Gorman <[EMAIL PROTECTED]> * libltdl/m4/libtool.m4 (old_postintall_cmds): chmod 644 before running ranlib. Reported by Gerald Pfeifer <[EMAIL PROTECTED]&g

Re: libtool-1.5.20 fails sh.test

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sandro Bonazzola wrote: | Ralf Wildenhues wrote: | | |>>Thanks for reporting this. Could you please rerun |>> make check TESTS=sh.test VERBOSE=x |>>and post the output? | === Running sh.test | 65:if [ "x$EGREP" = x ] ; then | 68:if [ "x$LTCC" = x ]

Re: darwin: mix up of .dylib and .bundle

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Egger wrote: | Hi! | | libtool mixes up .dylib and .bundle. It thinks, | .dylib are modules and .bundle are shared libs. Not here it doesn't... | | This causes linking failures on darwin due to multiple defined symbols, | in cases where li

Re: darwin: mix up of .dylib and .bundle

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [cutting -patches for now] Christoph Egger wrote: |>I think I've seen this issue with the GNU libtool that Apple shipped (is |>shipping?), | | | You mean /usr/bin/libtool ? This is a binary used by gcc. If I meant that I'd have said so. Apple ships

Re: darwin: mix up of .dylib and .bundle

Christoph Egger wrote: Attached. libgii-debug-experimental.output.gz is the whole subdirectory as I sent in my last mail with debug info. libgii-debug-experimental.output2.gz is the failing libtool link line with debug info. Doh! In a directory named ggbundle, file -L /path/to/with/ggbundle/in

libtool-1.5.22, please hold a little

Hi, I'd like to fix this before 1.5.22: peter$ ./libtool --mode=link --tag=CC gcc -o libfoo.la foo.lo -rpath /nono -L../nothere ./libtool: line 1: cd: ../nothere: No such file or directory libtool: link: cannot determine absolute directory name of `../nothere' IMO, it should just keep any rela

Re: libtool uses incorrect module extension (.so instead of .dylib) under Darwin

On Mon, 2006-03-20 at 21:56 +0100, Vincent Lefevre wrote: > When modules are generated under Darwin (Mac OS X 10.4.5), the > extension ".so" is always used; I've been told that this comes > from libtool (there's this problem with Liferea 1.0.8, whose > tarball has been generated using libtool 1.5.2

Re: libtool uses incorrect module extension (.so instead of .dylib) under Darwin

On Tue, 2006-03-21 at 21:24 +0900, Peter O'Gorman wrote: > On Mon, 2006-03-20 at 21:56 +0100, Vincent Lefevre wrote: > > and this breaks GTK applications under Mac OS X. > > > > This is a bug with the glib2 package, either upstream or darwinports. > The "corre

Re: libtool 1.5.22 tests failed

On Mon, 2006-07-10 at 15:47 -0600, Stephen Cartwright wrote: > Hello, > > I tried to make the latest version of libtool in order to try to get automake > to work. > However these tests failed when I did a "make check". > > This is on an alpha/Tru65 5.1B box. > PASS: mdemo-conf.test > FAIL: mdem

Re: libtool 1.5.22 tests failed

On Wed, 2006-07-12 at 11:50 -0600, Stephen Cartwright wrote: > Here you go! > Thank you, since the post was too big for the list, I rejected it. Here (for the list) is the failure: cc -DPACKAGE_NAME=\"mdemo\" -DPACKAGE_TARNAME=\"mdemo\" -DPACKAGE_VERSION=\"0.1\" "-DPACKAGE_STRING=\"mdemo 0.1\"

Re: libtool 1.5.22 tests failed

compiling the mdemo program, but I don't really know. ltdl.h has typedef struct {} lt_dlinfo in it, so lt_dlinfo should "name a type" Libtool seems to be working aside from this, so I'd go ahead and use it regardless of the error. Sorry, Peter > > On Thu, 13 Jul

Re: 3 failed tests?

On Jul 28, 2006, at 12:49 AM, Jon Handler wrote: Hello, I ended up getting 3 failed tests, all being the same test, depdemo-inst.test. Im running off of Mac OS X 10.4.7, using the bash shell. Also it gave me this right under your email. make[2]: *** [check-TESTS] Error 1 make[1]: *** [ch

Re: --whole-archive doesn't work on OSX

On Aug 3, 2006, at 10:01 AM, Andrew Miller wrote: Peter O'Gorman wrote: On Aug 2, 2006, at 10:24 AM, Andrew Miller wrote: Hi, I have just posted a bug regarding libtool on OSX to http:// savannah.gnu.org/support/index.php?func=detailitem&item_id=105489 I'm not sure if tha

Re: lt__glibc includes argz.h even when HAVE_ARGZ_H is not defined

On Aug 14, 2006, at 8:28 PM, Andrew Miller wrote: Hi, libltdl/libltdl/lt__glibc.h includes argz.h even when HAVE_ARGZ_H is not defined. This breaks building with latest CVS on OSX, and probably a number of other non-glibc platforms. argz.h is a generated file on systems that do not have

Re: --whole-archive doesn't work on OSX

On Aug 14, 2006, at 11:26 PM, Andrew Miller wrote: Peter O'Gorman wrote: On Aug 3, 2006, at 10:01 AM, Andrew Miller wrote: ... However, the documentation seems to imply that the behaviour of whole-archive should happen on all platforms, for all convenience libraries. e.g. — Var

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER "gcc -print-search-dirs" problem

On Sep 13, 2006, at 11:34 PM, Bob Friesenhahn wrote: On Wed, 13 Sep 2006, Kate Minola wrote: On my x86_64-unknown-linux-gnu system, the m4 macro AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4 uses "gcc -print-search-dirs" to set sys_lib_search_path_spec. Unfortunately, -print-search-dirs lists

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER "gcc -print-search-dirs" problem

On Sep 13, 2006, at 11:39 PM, Ralf Wildenhues wrote: Hello Bob, Kate, * Bob Friesenhahn wrote on Wed, Sep 13, 2006 at 04:34:52PM CEST: On Wed, 13 Sep 2006, Kate Minola wrote: On my x86_64-unknown-linux-gnu system, the m4 macro AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4 uses "gcc -print-sea

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER "gcc -print-search-dirs" problem

On Sep 13, 2006, at 11:41 PM, Peter O'Gorman wrote: On Sep 13, 2006, at 11:34 PM, Bob Friesenhahn wrote: On Wed, 13 Sep 2006, Kate Minola wrote: On my x86_64-unknown-linux-gnu system, the m4 macro AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4 uses "gcc -print-search-di

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER "gcc -print-search-dirs" problem

On Sep 13, 2006, at 11:49 PM, Ralf Wildenhues wrote: Only as a last resort, if you ask me. Other compilers love to disguise as gcc, and Autoconf's AC_FC_LIBRARY_LDFLAGS is witness of how helplessly maintenance-intensive an approach like the above is. That's looking at all kinds of flags, in

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER "gcc -print-search-dirs" problem

On Sep 14, 2006, at 12:12 AM, Ralf Wildenhues wrote: * Peter O'Gorman wrote on Wed, Sep 13, 2006 at 04:55:11PM CEST: On Sep 13, 2006, at 11:49 PM, Ralf Wildenhues wrote: Only as a last resort, if you ask me. Other compilers love to disguise as gcc, and Autoconf's AC_FC_LIBRARY_

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER "gcc -print-search-dirs" problem

On Sep 15, 2006, at 1:08 AM, Ralf Wildenhues wrote: Hi Ralf, Okay, I don't think my solution solves anything :/. My gcc compiler in /opt/gcc-4.0.1 only passes -L flags for /opt/gcc-4.0.1/lib/gcc/ powerpc-apple-darwin8.2.0/4.0.1 and /opt/gcc-4.0.1/lib, but -print- search-dirs also includes /u

Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER "gcc -print-search-dirs" problem

On Sep 21, 2006, at 5:43 AM, Kate Minola wrote: To followup on my previous post on this subject, I propose that in libtool.m4 in the macro AC_LIBTOOL_SYS_DYNAMIC_LINKER the line Hi Kate, I just applied a patch that I believe fixes your issue.

Re: Crashes in 'make check' for 1.5.23a (1.1220.2.414 2006/10/19 05:05:55) on Mac OS X 10.4.8

On Oct 21, 2006, at 10:42 PM, Peter Dyballa wrote: Hello! make check reported that all tests were passed, but Mac OS X opened forms explaining these these programmes were interrupted (crashed): Link (dyld) error: Symbol not found: _nothing Referenced from:

Re: tries to link to 32-bit libs on 64-bit build

On Feb 6, 2007, at 11:38 PM, Paul Raines wrote: I am trying to build libgnomedb from RPM on a 64-bit box. It dies as follows: /bin/sh ../libtool --tag=CC --mode=link gcc -O2 -g -pipe -m64 -o libgnomedb-2.la -rpath /usr/lib64 -version-info 4:0:0 db-shell.lo sql-viewer.lo table-proper

Re: tries to link to 32-bit libs on 64-bit build

On Feb 7, 2007, at 12:52 AM, Paul Raines wrote: I took a guess and got the RPM to build by putting in a export LDFLAGS=-L/usr/lib64 before the configure line in the RPM spec file. That seems to have worked as it got a -L/usr/lib64 into the below. But I still don't understand why libtoo

Re: [GNU Autoconf 2.60] testsuite: 3 120 failed

[cutting autoconf-patches list] On Feb 11, 2007, at 6:33 PM, Ralf Wildenhues wrote: OK to apply? + +# Cheap backport of AS_EXECUTABLE_P and required macros +# from Autoconf 2.59; we should not use $as_executable_p directly. + +# _AS_TEST_PREPARE +# +m4_ifndef([_AS_TEST_PREPARE

Re: libtool-1.15.23b (i386-unknown-freebsd4.3) check results

On Feb 22, 2007, at 8:38 AM, David Fang wrote: Hi again, Here are my results for libtool-1.15.23b on i386-unknown-freebsd4.3 (most PASSes omitted): Hi David, Hmm, all tests pass for me with i386-unknown-freebsd4.8. Please rerun the failing tests with VERBOSE=1 e,g: env VERBOSE=1 TEST

Re: libtool 1.5.22: make check fails on universal binaries

On Feb 28, 2007, at 3:50 PM, Elias Pipping wrote: For some hopefully more useful information: env \ CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 - arch ppc" \ LDFLAGS="-arch i386 -arch ppc" \ ./configure \ --prefix=/opt/local \ --infodir=/o

Re: libjpeg.la

On Mar 23, 2007, at 1:40 PM, [EMAIL PROTECTED] wrote: Hi, I am installing GDAL1.3.2 and 1.4.0 but here I am getting error as follows.. usr/bin/sed: can't read /usr/lib/libjepg.la: No such file or directory libtool: link: '/usr/lib/libjpeg.la' is not a valid libtool

Re: Libtool fails to build working binary when -no-install is used

exposed by my last patch. Yes. Sorry, I have not been watching the list as closely as I should be. This looks okay to me, please apply. Thanks, Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org

Re: Libtool fails to build working binary when -no-install is used

information from Mac OS X experts. There is no -rpath on Mac OS X 10.4 and earlier, it is, or at least was, I believe, a planned feature for 10.5, but plans and reality don't always intersect... Peter -- Peter O'Gorman http://pogma.com _

Re: linking got broken on MacOSX

into this. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: linking got broken on MacOSX

k etc back to -framework Cocoa, but new_inherited_linker_flags has not. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: make check fails on sparc-sun-solaris2.10

with VERBOSE=1. You only need to use the daily snapshots (updated today after a while of not updating - sorry). Thanks, Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: make check fails on sparc-sun-solaris2.10

On May 10, 2007, at 10:10 PM, Bob Friesenhahn wrote: On Thu, 10 May 2007, Peter O'Gorman wrote: The tagdemo test involves the c++ compiler, I think something is wrong with yours. sparc-sun-solaris2.10 passes tagdemo for me with both gcc and sun studio compilers. Tests are compl

Re: make check fails on sparc-sun-solaris2.10

a valid libtool archive gmake[3]: *** [libfoo.la] Error 1 So, please let us know the contents,if the file exists, of /usr/sfw/ lib/libstdc++.la. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.or

Re: libtool_osx

On Sat, 2007-05-26 at 04:40 -0700, seth tyler wrote: > Hi! > > I'm new to the terminal and trying to install jpeg-6b on my ibook > running osx.3.9 and I tried the ./configure -enable-shared and got the > following. > > > seth-tylers-Computer:~/Desktop/jpeg-6b.1 sethtyler$ ./configure > checking

Re: version scripts and symbol prefixes

et to .. gcc always defines this and in my case, it's: #define __USER_LABEL_PREFIX__ _ unless someone has some cool ld/as/string foo to perform a similar test on object code ... What system are you running on? Peter -- Peter O'Gorman h

Re: version scripts and symbol prefixes

On Tue, 2007-05-29 at 19:17 -0400, Mike Frysinger wrote: > On Tuesday 29 May 2007, Peter O'Gorman wrote: > > On May 29, 2007, at 1:59 AM, Mike Frysinger wrote: > > > i just came across libupnp which uses some libtool functionality to > > > generate a > > >

Re: version scripts and symbol prefixes

On Wed, 2007-05-30 at 01:32 -0400, Mike Frysinger wrote: > On Tuesday 29 May 2007, Peter O'Gorman wrote: > > On Tue, 2007-05-29 at 19:17 -0400, Mike Frysinger wrote: > > > On Tuesday 29 May 2007, Peter O'Gorman wrote: > > > > On May 29, 2007, at 1:59 AM, Mik

Re: dlfcn.h (libtool 1.5.23b)

On Tue, 2007-06-05 at 14:29 -0600, deckrider wrote: > On 6/5/07, deckrider <[EMAIL PROTECTED]> wrote: > > On 5/30/07, deckrider <[EMAIL PROTECTED]> wrote: > > > I don't know whether this is a bug or not ... > > > > > > I'm on: > > > > > > $ uname -a > > > HP-UX omztdv1 B.11.23 U ia64 2505142627 unl

Re: dlfcn.h (libtool 1.5.23b)

On Tue, 2007-06-05 at 16:04 -0600, deckrider wrote: > On 6/5/07, Peter O'Gorman <[EMAIL PROTECTED]> wrote: > > > > So, why does AC_PROG_CPP set CPP="" for you? > > Not sure, but in the Makefile that was generated, it is this: > > CPP = cc +DD

Re: dlfcn.h (libtool 1.5.23b)

On Tue, 2007-06-05 at 16:42 -0600, deckrider wrote: > On 6/5/07, Peter O'Gorman <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-06-05 at 16:04 -0600, deckrider wrote: > > > On 6/5/07, Peter O'Gorman <[EMAIL PROTECTED]> wrote: > > > > >

Re: libtool generates incorrect option for Solaris ld

On Mon, 2007-07-02 at 15:48 +0200, Vincent Lefevre wrote: > I've done a "make dist" on the MPFR library under Debian, and with this > tarball, when I do a "./configure --enable-shared" under Solaris, "make" > fails: > > [...] > /bin/ksh ./libtool --tag=CC --mode=link cc -xtarget=native -xarch=v9

Re: libtool generates incorrect option for Solaris ld

On Mon, 2007-07-02 at 22:40 +0200, Ralf Wildenhues wrote: > Thanks for your feedback. Does this patch work for you? > > OK to apply to both branches? Or do you think I should hack in > $reload_cmds, or do a full link (I fear a situation where we may have to > add some extra libraries for some ob

Re: lt_dlsym() Doesn't Allow for a Symbol with Address of 0.

On Sun, 2007-07-22 at 11:01 +0100, Ralph Corderoy wrote: > Hi, > > I investigated a problem on the llvmdev mailing list where someone was > trying to find the value of a symbol that has an address of 0. > > $ nm /System/Library/Frameworks/Foundation.framework/Foundation | > > grep .objc_c

Re: lt_dlsym() Doesn't Allow for a Symbol with Address of 0.

On Sun, 2007-07-22 at 18:30 +0100, Ralph Corderoy wrote: > Hi Peter, > > > > I investigated a problem on the llvmdev mailing list where someone was > > > trying to find the value of a symbol that has an address of 0. > > > > > > $ nm /System/Library/Frameworks/Foundation.framework/Foundation

Re: libtool fails if user has environment variable D defined

On Wed, 2007-08-08 at 11:16 -1000, Sebastian Jester wrote: > We do not want portage's install root ($D) present. This is not in the official libtool release, probably from a gentoo patch. Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://l

Re: Cross-compiling and nmedit

Yevgen Muntyan wrote: > Hi everybody, > > I am cross-compiling libraries for Mac OS X on linux. Everything works > fine except one thing: the libtool script generated in the build directory > is trying to execute nmedit, which fails. It works fine after I replace all > instances of 'nmedit' with '

Re: cvs-hackers reference on libtool web page

;t think there have ever been any enquiries about mirroring our cvs repo. Thanks, Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool

Mac OS X 10.2.8 HEAD test failures.

(ltdl,'" Tests 05,29,30,31,39,40,41,43,44,45,46,47,48,52 and 53 fail because "aclocal: macro `_LT_CHECK_BUILDDIR' required but not defined" Looks like _LT_CHECK_BUILDDIR is m4_defun'ed but AC_REQUIRED. Should we skip 28,46,47 and 48 if autoconf is too old, and m4_require _LT_C

Re: Mac OS X 10.2.8 HEAD test failures.

Ralf Wildenhues wrote: > Hi Peter, > > * Peter O'Gorman wrote on Mon, Dec 10, 2007 at 08:42:25PM CET: >> So, I dug my old g3 tower out of the closet, started it up and ran the >> libtool testsuite (I wanted to see what failed currently before trying a >> p

Re: Mac OS X 10.2.8 HEAD test failures.

t a warning at make check time warning users that their versions of automake and autoconf are too old to run the testsuite? Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: portability of -L

> documentation. I didn't find it there. I think this is a bug in libtool that it encodes the build directory into the .la files, however, you are correct, it is a doc bug too, I will look making a patch to the docs tonight. Thanks, Peter -- Peter O'Gorman http://pogma.com

Re: libtool 1.5.26: link fails on Darwin 5.5 because of wrong detection of -single_module flag support

the meantime, it should be possible to build clamav on this system by adding 'lt_cv_apple_cc_single_mod=no' to the configure arguments. Darwin5.5 is pretty old, so I don't think that this affects a large number of people. Peter -- Peter O'Gorman http://pogma.com __

Re: Another powerpc64 biarch problem.

dency_libs. If you add --debug immediately prior to the --tag=CC and save stdout and stderr to a log, reading the log should tell you which one. Alternatively, grep for /usr/lib64/libpcre.la in /usr/lib64. Peter -- Peter O'Gorman http://pogma.com

Re: libltdl memory corruption

quick visual inspection. I'll try it on a couple of systems tonight (dyld on mac os x 10.2, and shl_load on hpux10.20). Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: libltdl memory corruption

o try the shl_load loader, only tested dyld. This patch causes no regressions on Mac OS X 10.2. If that is also true for the loaders you get around to trying, this is ok. Thank you. Once again you sent a patch for a bug before I even got around to reading the

Re: Another powerpc64 biarch problem.

Steven Munroe wrote: > On Sat, 2008-03-01 at 09:39 -0600, Peter O'Gorman wrote: >> Steven Munroe wrote: >>> I am trying to build a package on a OpenSuse-10.3 PowerMac G5. and I see >>> the following: >>> >>> /bin/sh ../../libtool --tag=CC --mode=li

Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [Solaris IA-32]

n/automake line 7493 > Automake::generate_makefile('Makefile.am', 'Makefile.in') called at > /usr/local/bin/automake line 7834 > stdout: > ./am-subdir.at:78: exit code was 2, expected 0 > ./am-subdir.at:78: grep 'require .*but have' stderr && (exit 77) > 35. am-subdir.at:33: 35. C subdir-objects (am-subdir.at:33): FAILED > (am-subdir.at:78) There appears to be a problem with your automake install that is causing most of these test failures. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]

27;t find default package `java.lang'. Check the CLASSPATH >> environment variable and the access to the archives. Your gcj install is broken. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]

t /usr/local/bin/automake line 6719 > Automake::file_contents('distdir', > 'Automake::Location=HASH(0x105b3d30)', 'DIST-TARGETS', '', 'GETTEXT', 0, > 'DISTCHECK-HOOK', '', 'FILENAME_F

Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32]

ystem add -liconv at link time, but somehow not add it to the rpath? What does: gcj -### -o /dev/null /dev/null show? Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: [libtool 2.2] testsuite: 19 64 failed [Solaris AMD64]

Nelson H. F. Beebe wrote: Hi Nelson, I admit that I don't understand the failures like this one yet. >> /convenience.at:265: $LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS $LDFLAGS >> -o liba12.la liba1.la liba2.la -rpath /notexist >> stderr: >> stdout: >> libtool: link: gcj -shared -Wl,-z -Wl,te

Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]

Bob Friesenhahn wrote: > On Wed, 5 Mar 2008, Peter O'Gorman wrote: >> >> Your gcj and automake are broken. Do you have a sane toolchain on any of >> your systems? > > That sounds a little harsh. I think that the LZMA complaint from > automake may be because lib

Re: [libtool 2.2] testsuite: 33 34 35 36 44 45 46 48 49 50 51 52 53 57 58 60 61 62 failed [NetBSD IA-32]

=$SHELL $SHELL ./configure $configure_options' does not appear to do anything? I think Ralf has seen this before, if not I will look at it. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: [libtool 2.2] testsuite: 18 23 49 60 61 64 failed [OSF/1 Alpha]

Nelson H. F. Beebe wrote: > libtool: link: (cd .libs/liba12.lax/liba1.a && ar x > "/local/build/bare/libtool-2.2/tests/testsuite.dir/18/./.libs/liba1.a") > libtool: link: (cd .libs/liba12.lax/liba2.a && ar x > "/local/build/bare/libtool-2.2/tests/testsuite.dir/18/./.libs/liba2.a") > libtool: lin

Re: [libtool 2.2] testsuite: 12 17 19 38 64 failed [Mac OS X Intel]

ted on Mac OS X with fortran and java for a while, but this looks like a broken compiler. > gcj: libgcj.spec: No such file or directory > libtool: compile: gcj -g -O2 -c A3.java > gcj: libgcj.spec: No such file or directory So does this. I am now building gfortran, gcj etc on Mac OS X int

Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux Alpha]

(convenience.at:229): > FAILED (convenience.at:277) Your gcj on this system does not appear to add the runpath to libgcj when linking. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.g

Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux AMD64]

chine too. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]

Ralf Wildenhues wrote: > Hello Nelson, Peter, > > * Peter O'Gorman wrote on Thu, Mar 06, 2008 at 06:18:42AM CET: >> Nelson H. F. Beebe wrote: >> >>> libtool: compile: gcj -g -O2 -c A3.java >>> gcj: libgcj.spec: No such file or directory > >>

Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]

Ralf Wildenhues wrote: > * Bob Friesenhahn wrote on Thu, Mar 06, 2008 at 08:43:15PM CET: >> On Thu, 6 Mar 2008, Peter O'Gorman wrote: >>> I think the test for a working GCJ should be in libtool, and unset GCJ, >>> avoid adding the tag etc.if it is found to be non

Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]

Peter O'Gorman wrote: > Nelson H. F. Beebe wrote: > > >>> libtool: link: f90 -shared -Qoption ld --whole-archive ./.libs/liba1.a >>> ./.libs/liba2.a -Qoption ld --no-whole-archive -Qoption ld -soname >>> -Qoption ld liba12.so.0 -o .libs/liba12.so

Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32]

ux/bin/../lib/gcc" > "-L/us > r/local/sys/FortranPlus/fplus_55h/lib" > "-L/usr/local/lib/gcc/i686-pc-linux-gnu/3 > .4.3" > "-L/export/local/i386-linux/bin/../lib/gcc/i686-pc-linux-gnu/3.4.3/../../. > ./../i686-pc-linux-gnu/lib" > "-L/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../ > ../../i686-pc-linux-gnu/lib" > "-L/export/local/i386-linux/bin/../lib/gcc/i686-pc- > linux-gnu/3.4.3/../../.." > "-L/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../.. > " "/dev/null" "-lgcc_s" "-lgcc" "-lgcj" "-lm" "-liconv" "-lpthread" "-ldl" > "-lgc > c_s" "-lgcc" "-lc" "-lgcc_s" "-lgcc" > "/export/local/i386-linux/bin/../lib/gcc/i6 > 86-pc-linux-gnu/3.4.3/crtend.o" "/usr/lib/crtn.o" Thank you. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]

Bob Friesenhahn wrote: > On Thu, 6 Mar 2008, Peter O'Gorman wrote: >>> >>> Libtool detected FC as f90, but otherwise used the gcc tools. I'll look >>> into this. >> >> Because we generally use the same archive_cmds for F77, FC as for CXX, >>

Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]

Gary V. Vaughan wrote: > On 6 Mar 2008, at 20:04, Peter O'Gorman wrote: >> Peter O'Gorman wrote: >>> Nelson H. F. Beebe wrote: >>> >>> >>>>> libtool: link: f90 -shared -Qoption ld --whole-archive >>>>> ./.libs/liba1.a

Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]

ry do not end up in spam mailbox :) Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: [libtool 2.2] testsuite: 19 64 failed [Solaris AMD64]

obvious. Thanks for pointing me in the right direction. Peter -- Peter O'Gorman http://pogma.com 2008-03-07 Peter O'Gorman <[EMAIL PROTECTED]> * libltdl/m4/libtool.m4 (_LT_LANG_GCJ_CONFIG): Need to set LD. Reported by Nelson H. F. Beebe. Index: libltdl/m4/libtool.m4

  1   2   >