no unexpected failures.
Peter
--
Peter O'Gorman
http://pogma.com
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
10.4, and i386 Mac OS X 10.4 and 10.5.
What versions of autoconf and automake did you use?
Peter
--
Peter O'Gorman
http://pogma.com
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
,
the generated libtool script should already have:
# An echo program that does not interpret backslashes.
echo=echo
Peter
--
Peter O'Gorman
http://pogma.com
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug
Ralf Wildenhues wrote:
* Peter O'Gorman wrote on Fri, Mar 07, 2008 at 08:40:08AM CET:
Peter O'Gorman wrote:
Ralf has already checked in a workaround for gcj being unable to create
objects/executables. I guess I will add to that so it tests that an
executable created by the compiler
Ralf Wildenhues wrote:
Hello Peter,
* Peter O'Gorman wrote on Fri, Mar 07, 2008 at 02:04:41AM CET:
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
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
Your gcj and automake are broken. Do you have a sane toolchain
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 nonfunctional. We would
have to issue
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.0.0.0
/convenience.at:211: exit code was 1, expected
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
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,
things can get a little messed up. This fixes the most common case,
gcc
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 ./.libs/liba2.a -Qoption ld --no-whole-archive
-Qoption ld -soname -Qoption ld liba12.so.0 -o
mailbox :)
Peter
--
Peter O'Gorman
http://pogma.com
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
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
===
RCS file: /sources/libtool
Peter O'Gorman wrote:
The gcj in /usr/local/bin does indeed add -liconv, thank you for
confirming my suspicion.
Ralf has already checked in a workaround for gcj being unable to create
objects/executables. I guess I will add to that so it tests that an
executable created by the compiler
: 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
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
Automake::generate_makefile('Makefile.am', 'Makefile.in') called at
/usr/local/bin/automake line 7834
Your gcj and automake are broken. Do you have a sane toolchain on any of
your systems?
Peter
--
Peter O'Gorman
http://pogma.com
___
Bug
, 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
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,text -Wl,-h
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 libtool requests a lzma package and it requires
' 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
: 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 intel to make sure that
things are working :)
Thanks,
Peter
--
Peter O'Gorman
http://pogma.com
):
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.gnu.org/mailman/listinfo/bug
--
Peter O'Gorman
http://pogma.com
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
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=link /usr/bin/gcc -m64 -g -O2
-mcpu=power
4 -fno-strict-aliasing
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
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
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo
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
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http
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_CHECK_BUILDDIR?
Peter
--
Peter O'Gorman
http://pogma.com
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
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 |
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 -xO4
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 +DD64 -Wl,+k -E
How odd! Could you post the entire config.log
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, Mike Frysinger wrote:
i just came across libupnp
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
list of exported symbols and pass it to ld so
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 host
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
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
, 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
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
http
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
___
Bug
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
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
[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
+#
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
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
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.
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
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
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-dirs to set
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
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_LDFLAGS
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=detailitemitem_id=105489
I'm not sure if that is the right
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]: ***
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\
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:
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 correct extension for loadable bundles on darwin
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
,
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]
Index: libltdl/m4/libtool.m4
-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]
When I look more
-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'Gorman
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, yes
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 2005
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter O'Gorman wrote:
| Eric Sandall wrote:
| | Quoting Bob Friesenhahn [EMAIL PROTECTED]:
| | snip
| |
| | The problems I have heard about up until now have been that autoconf
| | found a C++ compiler, but it was discovered not to work
Eric Sandall wrote:
Quoting Peter O'Gorman [EMAIL PROTECTED]:
snip
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 configure script
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
-BEGIN PGP SIGNATURE-
Version
, 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 happily enough.
I applied
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 v1.4.0 (Darwin
68 matches
Mail list logo
