Hello Nelson, Peter,
* Peter O'Gorman wrote on Thu, Mar 06, 2008 at 06:49:39AM CET:
> Nelson H. F. Beebe wrote:
>
> > ./old-m4-iface.at:85: CONFIG_SHELL=$SHELL $SHELL ./configure
> > $configure_options
> > stderr:
> > stdout:
> > ./old-m4-iface.at:85: $MAKE
> > stderr:
> > make[4]: *** No tar
Hello Jakub,
Thanks for the bug report.
* Jakub Bogusz wrote on Wed, Mar 12, 2008 at 11:23:16PM CET:
>
> I noticed that libtool sometimes rejects to create shared library using -l...
> to link with some import libraries failing to recognize those import
> libraries as such.
>
> It happens if AC
Hello Henning,
I have applied your patch now, including a NEWS entry, as below, and put
you in THANKS. Please check that I did not make any errors, thanks.
Gathering from the testsuite failure, the shared library support has
some work ahead yet.
Cheers,
Ralf
2008-03-12 Henning Nielsen Lund <
Hello Henning,
* Henning Nielsen Lund wrote on Fri, Feb 15, 2008 at 07:05:05PM CET:
> > * Henning Nielsen Lund wrote on Sun, Feb 10, 2008 at 07:16:17PM CET:
> >>
> >> Since July 2007 AmigaOS4 officially supports .so libraries. It would be
> >> nice if it would be possible to add support for it in
* Roumen Petrov wrote on Sun, Mar 09, 2008 at 05:01:30PM CET:
>
> Please find attached my check.log (12 of 77 tests failed).
Can you also post verbose log output, and also test the new testsuite's
results (see README for details on how to do all this)? Thanks.
> Tested libtool 2.2.
> env:
> gc
* Ralf Wildenhues wrote on Thu, Mar 06, 2008 at 08:42:02PM CET:
> Playing on the rather safe side, I consider applying this patch for now.
> OK?
No comments, so I applied this now.
Cheers,
Ralf
> 2008-03-06 Bruno Haible <[EMAIL PROTECTED]>
> and Ralf Wildenhues
Hi Thien-Thi,
* Thien-Thi Nguyen wrote on Sun, Mar 09, 2008 at 10:29:13AM CET:
> () Peter O'Gorman <[EMAIL PROTECTED]>
> () Sat, 08 Mar 2008 17:33:47 -0600
>
>It seems likely that you have a configure that was created with
>a different version of libtool than ltmain.sh was created with.
>
Hi Gary,
* Gary V. Vaughan wrote on Sat, Mar 08, 2008 at 05:39:38PM CET:
> On 8 Mar 2008, at 07:03, Ralf Wildenhues wrote:
>> we have a couple of problems wrt. cross compilation to w32 in 2.2.
>> When I cross-compile from GNU/Linux to MinGW using Debian's mingw32
>> pack
Hi Alexis,
* Alexis Ballier wrote on Sat, Mar 08, 2008 at 02:50:09PM CET:
>
> Perhaps it's the desired behavior, but I get a failure on test 55 when
> using -Wl,--as-needed in LDFLAGS (and its ok if I remove it).
> From my poor understanding of template.at, the test is run for the case
> when lib
On Sat, Mar 08, 2008 at 09:58:38AM +0100, Roberto Bagnara wrote:
> Ralf Wildenhues wrote:
> >
> >What I instead meant was: the installed libltdl.la file is missing,
> >but the libltdl.so.7 file is still present, as is the ltdl.h header
> >in the include directory.
> &
On Sat, Mar 08, 2008 at 08:27:38AM +0100, Roberto Bagnara wrote:
> Ralf Wildenhues wrote:
> >
> >I can reproduce this error under the following circumstances:
> >
> >A libltdl 2.1 or newer has previously been installed in a place
> >where the preprocessor and the
* Bob Friesenhahn wrote on Fri, Mar 07, 2008 at 08:17:03PM CET:
> On Fri, 7 Mar 2008, Ralf Wildenhues wrote:
>>>
>>> Because we generally use the same archive_cmds for F77, FC as for CXX,
>>
>> No we don't. archive_cmds _is_ tagged. In a casual test, it wor
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 -soname
> >>>
* 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 will actually run.
>
* Peter O'Gorman wrote on Fri, Mar 07, 2008 at 06:42:13AM CET:
> Gary V. Vaughan wrote:
> > On 6 Mar 2008, at 20:04, Peter O'Gorman wrote:
> >>
> >> 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,
> >>
* Gary V. Vaughan wrote on Thu, Mar 06, 2008 at 10:41:47PM CET:
> On 6 Mar 2008, at 15:03, Bob Friesenhahn wrote:
>> There needs to be a way to output any warnings at the tail end of
>> configure so that at least someone is more likely to see them.
>> Without adequate notification to the user,
* Peter O'Gorman wrote on Thu, Mar 06, 2008 at 08:57:56PM CET:
> Ralf Wildenhues wrote:
> >
> > I'm considering doing that (the stop-gap measure).
>
> Your call.
I've applied that now.
> > Yes, and I can conceive just as well a libtool-using package wh
* 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 a warning during configure
* Ralf Wildenhues wrote on Mon, Jan 21, 2008 at 08:18:26AM CET:
> * Bruno Haible wrote on Mon, Jan 21, 2008 at 12:46:12AM CET:
> [...]
> > if ${opt_dry_run-false}; then :; else
> > + eval "$lt_switch_to_user_locale"
> > eval "$my_cmd&quo
Hello Nelson,
* Nelson H. F. Beebe wrote on Thu, Mar 06, 2008 at 02:18:18AM CET:
> # -*- compilation -*-
> 35. am-subdir.at:33: testing ...
> libtoolize: putting auxiliary files in `.'.
> libtoolize: copying file `./ltmain.sh'
> libtoolize: putting macros in `m4'.
> lib
pilers should be done in configure
already?
Cheers,
Ralf
2008-03-06 Ralf Wildenhues <[EMAIL PROTECTED]>
* tests/convenience.at (Java convenience archives): Skip test if
gcj cannot compile a .java file.
Report by Nelson H
Hello Peter,
* Peter O'Gorman wrote on Thu, Mar 06, 2008 at 06:36:22AM CET:
>
> I admit that I don't understand the failures like this one yet.
>
> Nelson H. F. Beebe wrote:
> >> /convenience.at:265: $LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS
> >> $LDFLAGS -o liba12.la liba1.la liba2.la -rpa
Hello Roberto,
your posts are good sources of bug reports ...
* Roberto Bagnara wrote on Sun, Mar 02, 2008 at 08:48:07AM CET:
> ## --- ##
> ## libtool 2.2 test suite. ##
> ## --- ##
[...]
> ## ##
> ## Summary of the failures. ##
> #
* Bob Friesenhahn wrote on Thu, Mar 06, 2008 at 06:28:10AM CET:
> 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 becau
* Roberto Bagnara wrote on Wed, Mar 05, 2008 at 07:37:58AM CET:
>
> It is better now, but there is still the problem that, apparently,
> libtool redirects stdin for the program it is running.
Gosh. How embarrassing. I've applied this patch.
Thanks for testing!
Ralf
2008-03-05 R
;\$0: cannot exec \$program \$*\" 1>&2
exit 1
fi
else
--- /dev/null 2008-03-02 10:33:19.200041011 +0100
+++ tests/execute-mode.at 2008-03-04 22:15:22.0 +0100
@@ -0,0 +1,92 @@
+# execute-mode.at -- libtool --mode=execute -*- Autotest -*-
+#
+#
veral times, please speak up if I forgot to
mention a reporter. The hard part with this patch was ensuring that
none of the libtool code uses this bit in a sed pattern (in some parts
script headers are checked, but not this one, apparently).
Cheers, and thanks to both of you for the report (I
Hi Peter,
* Peter O'Gorman wrote on Tue, Mar 04, 2008 at 07:14:51AM CET:
> Ralf Wildenhues wrote:
> >
> > So I'd appreciate a review of this, and also test results on systems
> > with loaders other than preopen and dlopen. (I haven't even tested
> > suc
ble.
So I'd appreciate a review of this, and also test results on systems
with loaders other than preopen and dlopen. (I haven't even tested
successful compilation on those other systems.)
Thanks,
Ralf
2008-03-03 Ralf Wildenhues <[EMAIL PROTECTED]>
* libltdl/loaders/dld_li
Hello Roberto,
* Roberto Bagnara wrote on Sun, Mar 02, 2008 at 08:48:07AM CET:
>
> I got errors on a Fedora 7 system (x86_64): the log file
> is attached. I have also tried using Libtool 2.2 on one
> of my projets, but I get the following:
>
> /bin/sh ../libtool --tag=CXX --mode=compile g++ -DH
Hello Jens,
* Jens Schleusener wrote on Sun, Mar 02, 2008 at 10:01:19AM CET:
>
> congratulations for releasing GNU Libtool 2.2!
>
> But probably you have enjoyed too many (doubtless hard-earned) bottles of
> champagne ...
>
> ... or how is the date
>
> Saturday, March 1st 2009, 22:22:22
>
> on t
Hi Neil,
* Neil Roberts wrote on Sat, Mar 01, 2008 at 08:24:22PM CET:
>
> As I understand it, when linking a shared library libtool checks
> whether all of the dependencies are found and that they are valid
> libraries. In the old version of libtool it just did this using
> objdump which reports
Hi Karl,
* Karl Berry wrote on Tue, Feb 26, 2008 at 06:11:34PM CET:
> Good, except that I'd prefer if argz_count used strlen instead of
>
> Ok, since you prefer it, I copied the strlen loop from libc. Below is a
> revised patch (for both files for convenience).
Thanks. Applied as shown bel
Hi Karl,
* Karl Berry wrote on Mon, Feb 25, 2008 at 06:59:39PM CET:
> A Texinfo contributor made use of two argz functions that are not in the
> implementation in gnulib, argz_add and argz_count. As a result, of
> course compilation failed on non-glibc systems. They seemed trivial to
> implement
Hello Bruno,
* Bruno Haible wrote on Sun, Feb 24, 2008 at 02:51:08PM CET:
>
> A while ago someone said that if in a build directory I have a (not yet
> installed) ../lib/libfoo.la, to link with this library I should *not* use
>
>libtool ... -L../lib -lfoo
>
> but rather mention the .la file
* Ralf Wildenhues wrote on Mon, Feb 11, 2008 at 11:01:53PM CET:
>
> In an empty directory this happens:
>
> $ libtoolize --copy --ltdl
> touch: cannot touch `/ltmain.sh': Permission denied
> libtoolize: can not copy `/home/ralf/local/share/libtool/config/ltmain.sh&
* Mike Frysinger wrote on Wed, Feb 13, 2008 at 07:26:16PM CET:
> On Wednesday 13 February 2008, Ralf Wildenhues wrote:
> > * Mike Frysinger wrote on Wed, Feb 13, 2008 at 05:38:05AM CET:
> > > the argz.m4 header checks to see if error_t is defined, but only does so
> > &
[ Cc:ing bug-libtool, it's upstream for argz ]
Hi Mike,
* Mike Frysinger wrote on Wed, Feb 13, 2008 at 05:38:05AM CET:
> the argz.m4 header checks to see if error_t is defined, but only does so by
> including the argz.h header. if you try to build on a system that does
> provide error_t, but n
Hello,
In an empty directory this happens:
$ libtoolize --copy --ltdl
touch: cannot touch `/ltmain.sh': Permission denied
libtoolize: can not copy `/home/ralf/local/share/libtool/config/ltmain.sh' to
`/'
libtoolize: copying file `libltdl/config/compile'
libtoolize: copying file `libltdl/config/c
That should've been _AS_DETECT_REQUIRED instead of _AS_DETECT_SUGGESTED,
sorry.
2008-02-05 Ralf Wildenhues <[EMAIL PROTECTED]>
* configure.ac: Do not override $SHELL late in configure.ac.
Use undocumented Autoconf interface _AS_DETECT_REQUIRED to
require $(.
* Clint Adams wrote on Wed, Jan 30, 2008 at 08:19:22PM CET:
> On Wed, Jan 16, 2008 at 08:59:46PM +0100, Ralf Wildenhues wrote:
> > Let's find out what the differences in the setups are. Which version
> > of dash? Which m4 and autoconf versions were used to bootstrap the
>
* Ralf Wildenhues wrote on Wed, Jan 16, 2008 at 08:59:46PM CET:
> * Clint Adams wrote on Wed, Jan 16, 2008 at 08:43:22PM CET:
> > On Wed, Jan 16, 2008 at 06:44:30PM +, Colin Watson wrote:
> > > In my failing test case, I have /bin/sh in both these places, not
> > &g
* Bruno Haible wrote on Mon, Jan 21, 2008 at 12:46:12AM CET:
[...]
> if ${opt_dry_run-false}; then :; else
> + eval "$lt_switch_to_user_locale"
> eval "$my_cmd"
> my_status=$?
> + eval "$lt_switch_to_safe_locale"
> if test "$my_status" -eq 0; then :; else
[
Hello Bruno,
* Bruno Haible wrote on Mon, Jan 21, 2008 at 12:46:12AM CET:
> Ralf Wildenhues wrote:
> > func_show_eval is also called like this:
> >
> > | func_show_eval '( cd "$output_objdir" && $RM "$outputname" && $LN_S
> >
Hello Bruno,
* Bruno Haible wrote on Sun, Jan 20, 2008 at 05:28:40PM CET:
>
> I have my environment variables set to German (LANG=de_DE.UTF-8), and
> nevertheless the gcc compiler emits its warnings in English *if* invoked
> by libtool.
Thank you for the bug report.
> Find attached a patch for
* Clint Adams wrote on Wed, Jan 16, 2008 at 08:43:22PM CET:
> On Wed, Jan 16, 2008 at 06:44:30PM +, Colin Watson wrote:
> > In my failing test case, I have /bin/sh in both these places, not
> > /bin/bash.
>
> Same here.
Let's find out what the differences in the setups are. Which version
of
* Colin Watson wrote on Wed, Jan 16, 2008 at 07:44:30PM CET:
> On Wed, Jan 16, 2008 at 07:18:08PM +0100, Ralf Wildenhues wrote:
> >
> > Actually, the generated libtool script should just have
> > #! /bin/bash
> >
> > as its first line, and not re-exececute its
[ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447022 aka.
http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5879/focus=342902 ]
Hello, and sorry for the long delay.
* Clint Adams wrote on Sat, Dec 15, 2007 at 02:39:36AM CET:
> On Fri, Dec 14, 2007 at 01:59:34AM +, Colin Watson wrote:
* Rainer Tammer wrote on Sun, Jan 13, 2008 at 05:48:10PM CET:
> >
> > TESTS="tagdemo-static.test tagdemo-make tagdemo-exec.test
> > tagdemo-conf.test tagdemo-make tagdemo-exec.test
> > tagdemo-shared.test tagdemo-make tagdemo-exec.test" \
> > VERBOSE=yes make -e check
> >
> >
>
Hello Rainer,
could you do this for me?
temporarily remove /opt/freeware/bin from your $PATH, ensure the only
`ld' and `ar' and `nm' programs found are those from AIX, if need be
specify gcc and g++ with full path: CC=/path/to/gcc CXX=/path/to/g++ and
post output of:
TESTS="tagdemo-static.test
Hi Bob,
* Bob Friesenhahn wrote on Sat, Jan 12, 2008 at 05:30:39PM CET:
> On Sat, 12 Jan 2008, Ralf Wildenhues wrote:
> >
> >I still don't know why it doesn't "just work". But here is a somewhat
> >less crude hack. OK to apply?
> This patch looks ok
* Ralf Wildenhues wrote on Thu, Jan 10, 2008 at 10:20:30PM CET:
> > * Rainer Tammer wrote on Tue, Jan 08, 2008 at 05:03:30PM CET:
> >
> > > did not find the `myfunc' function
> > > error was: Function not implemented (myfunc)
> > > did not find the `m
Hello Rainer,
* Rainer Tammer wrote on Tue, Jan 08, 2008 at 05:03:30PM CET:
> Ralf Wildenhues wrote:
>>
>> please post whatever Libtool testsuite log of AIX 6.1 you have to
>> .
> No problem. Is there a size limitation to the post ??
Yes, there is. For large outputs
[ Cc:ing bug-libtool ]
Hello Bruno, Paul, all,
* Bruno Haible wrote on Sat, Dec 29, 2007 at 05:36:01PM CET:
> Paul Eggert wrote:
> > I do have a bit of trouble reading the code, though.
> > It doesn't seem to match the comment: e.g., it strips a leading "lt-"
> > even when there's no "/.libs/".
>
Hi Peter,
* Peter O'Gorman wrote on Tue, Dec 11, 2007 at 05:11:47PM CET:
> Ralf Wildenhues wrote:
>
> > That's a bug, thanks for catching. Does it work if _LT_CHECK_BUILDDIR
> > is only m4_require'd?
> >
> > I assume if that's fixed, there w
Hi Eric,
* Eric Blake wrote on Tue, Dec 11, 2007 at 08:16:21PM CET:
>
> But now with m4 head, this is tripping up libtool, which doesn't respect
> circular library dependencies:
And rightly and documentedly so.
> How do we go about solving this?
Put --preserve-dup-deps in AM_LIBTOOLFLAGS.
Ch
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
> patch to see what failed after it).
>
> There are a number of failures rel
Hello Sam,
Thanks for the report and patch.
* Sam Steingold wrote on Mon, Dec 03, 2007 at 06:08:47PM CET:
> VERSION=1.5.22
> TIMESTAMP=" (1.1220.2.365 2005/12/18 22:14:06)"
>
> ltmain.sh install does not support spaces in destdir, because it does
> not quote destdir. this can be a serious proble
Hi Peter,
* Peter Rosin wrote on Thu, Nov 22, 2007 at 09:03:41AM CET:
> On Thu, Nov 22, 2007 at 08:19:56AM +0100, Ralf Wildenhues wrote:
> > +AT_DATA([nopicfail.c],
> > +[[
> > +#ifndef PIC
> > +choke me
> > +#endif
> > +int ans = 42;
> > +]])
> &g
nst HEAD. It costs one more fork of `rm' per
compile, and makes the typical echoed command line longer, but saves
the user from having to type something like
make || env CFLAGS='... -no-suppress' make -e
WDYT? (Adding Ed to THANKS not shown.)
Cheers,
Ralf
2007-11-20
Hello Sven,
Replying to this issue only for now:
* Sven Verdoolaege wrote on Thu, Nov 15, 2007 at 10:48:40AM CET:
>
> In any case, I "solved" this problem by specifying AC_DISABLE_SHARED.
> However, my own library not only depends on a static library
> but also on some other libtool libraries (no
* Ralf Wildenhues wrote on Thu, Nov 08, 2007 at 09:05:24PM CET:
>
> LIBLTDL = ${top_builddir}/ltdl/libltdl.la
[...]
> New config files output variable `top_build_prefix'.
Thanks to Paul and Benoit for reviewing my Autoconf patch.
Here's what I could think of for Libtoo
* Ralf Wildenhues wrote on Thu, Nov 08, 2007 at 09:05:24PM CET:
>
> New config files output variable `top_build_prefix'.
>
> * lib/autoconf/status.m4 (_AC_OUTPUT_FILE): Substitute
> `top_build_prefix'.
> * doc/autoconf.texi (Preset Output Variables
Hello Autoconf patchers,
We have hit another bug in HEAD Libtool, for which we could use help
from Autoconf.
This is the setting: a third-party package (GraphicsMagick) that uses
libltdl in nonrecursive mode in a nonrecursive Makefile[1]. In this
Makefile, the library is given as
noinst_LTLIBR
Hello Sergey,
* Sergey Pribilskiy wrote on Mon, Nov 05, 2007 at 09:51:33PM CET:
>
[...]
> configure:2033: checking for a BSD-compatible install
> configure:2089: result: /usr/bin/install -c -o root -g wheel
> configure:2100: checking whether build environment is sane
> configure:2137: error: newl
Hello Amit,
* amit pansuria wrote on Mon, Nov 05, 2007 at 11:49:24AM CET:
> i m using RHEL 4 with kdevelope 3.1.1 and when i run aclocal i got the
> following error
>
> d '/root/cti' && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" gmake -f
> Makefile.cvs
> aclocal
> aclocal:configure.in:8: warning
* Thomas Koeller wrote on Sun, Nov 04, 2007 at 08:28:41PM CET:
> On Sonntag, 4. November 2007, Ralf Wildenhues wrote:
> > * Thomas Koeller wrote on Sun, Nov 04, 2007 at 01:48:43PM CET:
> > >
> > > Because I am cross-building, my CFLAGS and LDFLAGS variables contain
>
Hello Thomas,
* Thomas Koeller wrote on Sun, Nov 04, 2007 at 01:48:43PM CET:
>
> I am encountering problems using libtool-1.5.24 in a cross-build
> environment (build system x86_64-pc-linux-gnu, target mips-linux-gnu).
> I am trying to build the Linux-PAM-0.99.8.1 package. Building works
> fine,
* Ralf Wildenhues wrote on Sun, Oct 28, 2007 at 01:16:56PM CET:
> It would be good to have a test to put in the Libtool testsuite, to
> ensure this doesn't happen again. Now I'm not that experienced with
> pthreads, could you provide a small test program source (like a
>
Hello Bruno,
* Bruno Haible wrote on Sat, Oct 27, 2007 at 04:37:20PM CEST:
>
> A special "feature" in libtool 1.5.24 is making some multithreaded programs
> nonfunctional on HP-UX 11.00.
[... -lc before -lpthread ...]
Thank you for the bug report. This looks like an ugly one, I haven't
looked
Hello Michael,
* Michael Haubenwallner wrote on Mon, Oct 15, 2007 at 03:52:04PM CEST:
> On Fri, 2007-10-12 at 18:20 +0200, Ralf Wildenhues wrote:
> >
> > is "no", it doesn't currently work. fast_install is no on HP-UX/PA
> > because we don't use node
[ http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/7149/focus=5820 ]
* Eric Blake wrote on Tue, Oct 02, 2007 at 02:11:25PM CEST:
> According to Ralf Wildenhues on 10/1/2007 12:16 PM:
> >
> > I guess branch-1-5 Libtool is affected just as well, and I wonder
> > whether, i
* Eric Blake wrote on Fri, Sep 28, 2007 at 06:33:45AM CEST:
> >> 2006-09-26 Eric Blake <[EMAIL PROTECTED]>
> >>and Ralf Wildenhues <[EMAIL PROTECTED]>
> >
> >>* lib/autoconf/general.m4 (AC_CACHE_VAL): Warn if cache-id is not
> >&
Hello Bill,
* William Aiken wrote on Wed, Aug 29, 2007 at 08:34:43PM CEST:
>
> I am trying to build libtool-1.5 on a Solaris 10 x64 (AMD) system
> using gmake and Sun Studio 12. I downloaded, built and installed m4
> (m4-1.4.4) and autoconf (2.60) before building libtool.
Is that really libtool
Hello all,
* Peter Rosin wrote on Fri, Aug 17, 2007 at 09:24:39PM CEST:
>
> Just pointing out that for libtool the archiver is never invoked as
> either of:
> $AR $AR_FLAGS cru ...
> $AR $AR_FLAGS x ...
> $AR $AR_FLAGS t ...
> it is always one of these instead:
> $AR $AR_F
Hello Ilya,
* Ilya N. Golubev wrote on Mon, Aug 20, 2007 at 07:42:53PM CEST:
>
> [...] one needs to
> figure which files installed by libtool are run-time ones, and which
> are development, to obtain lists of run-time and development files.
> Currently there is no (documented) way to do so, let a
* Dirk Mueller wrote on Wed, Aug 15, 2007 at 10:51:54AM CEST:
> On Wednesday, 15. August 2007, Ralf Wildenhues wrote:
>
> > Could you post such a corrupted .la file, preferably gzip'ed so that it
> > won't be harmed by mail transport? How did it get corrupted BTW?
Hello Daniel,
* Daniel Richard G. wrote on Wed, Aug 15, 2007 at 07:14:58PM CEST:
> I have a software project that builds using Libtool 1.5.24. At one point,
> it produces a gigantic static archive library, that is composed of several
> smaller static convenience libraries. Libtool extracts each
Hello Dirk,
Thanks for the report.
* Dirk Mueller wrote on Tue, Aug 14, 2007 at 01:17:34PM CEST:
>
> when libtool .la files contain NUL bytes due to a corruption, there is a very
> ugly memory eating loop triggered in libltdl. the problem is that it believes
> the buffer was too small, and kee
Hi Tilman,
* Tilman Koschnick wrote on Fri, Aug 03, 2007 at 05:43:22PM CEST:
>
> the Portland Group C++ compiler has two equivalent names that do the
> same: pgCC and pgcpp. libtool currently only supports the former one; it
> would be good if you could add support for both versions.
Thanks! Ap
Hello Philip,
Thanks for the report. Please don't forget to choose a meaningful
subject next time, that lowers your chances of not being moderated
into oblivion. ;-)
* Philip Courier wrote on Tue, Jul 17, 2007 at 07:16:11AM CEST:
>
[...]
> PASS: tagdemo-static.test
> PASS: tagdemo-make.test
>
* Vincent Lefevre wrote on Tue, Jul 03, 2007 at 01:22:35AM CEST:
> On 2007-07-02 22:40:37 +0200, Ralf Wildenhues wrote:
> > Thanks for your feedback. Does this patch work for you?
>
> Yes, it solves the problem. Thanks.
Thanks to both of you. Applied.
* Peter O'Gorman
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 obscure setup)?
Cheers,
Ralf
HEAD:
2007-07-02 Ralf Wildenhues
* Vincent Lefevre wrote on Mon, Jul 02, 2007 at 08:29:22PM CEST:
> On 2007-07-02 11:20:54 -0500, Peter O'Gorman wrote:
> > Please show '/usr/ccs/bin/ld -V' output, and the version of solaris.
>
> bar:~> /usr/ccs/bin/ld -V
> ld: Software Generation Utilities - Solaris/ELF (3.0)
>
> This is Solaris
Hello Kyle,
* Kyle Stemen wrote on Sat, Jun 30, 2007 at 08:29:50AM CEST:
> I'm building libtool on AIX 5.3 release 4. I have gcc and other
> development tools installed from
> http://www-03.ibm.com/servers/aix/products/aixos/linux/download.html.
>
> Make check is failing on the CVS snapshot, 2.1a
Hello Dmitri,
Please keep the mailing list in Cc: so this information is conserved,
thanks.
* Dmitri Chubarov wrote on Mon, May 14, 2007 at 03:27:57PM CEST:
>
> That's right. The most recent version of libtool handles
> AC_LIBTOOL_PROG_COMPILER_PIC with Sun 5.9 C/C++ compilers correctly.
>
> Alth
Hello Dmitri,
Thanks for the report.
* Dmitri Chubarov wrote on Sat, May 12, 2007 at 12:06:23PM CEST:
> When defining AC_LIBTOOL_PROG_COMPILER_PIC, the values libtool assigns
> for SunStudio 11 and 12 compilers on Linux are not correct. The values
> should be
> lt_prog_compiler_wl='-Wl,'
> lt_pr
* [EMAIL PROTECTED] wrote on Fri, May 11, 2007 at 10:44:33PM CEST:
>
> Ok, also built bash-3.2 (finding out which options don't work with that
one...)
> and rebuilt libtool using bash; it all works now:
Good to know; thanks.
> Sorry in case I have overlooked some warning about ksh somewhere but I
* Mike Frysinger wrote on Tue, May 08, 2007 at 06:34:31PM CEST:
>
> -Bstatic would be valid for the compiler driver regardless ... if you had a
> directory in $PWD named "static" ...
If you have a directory named static and used that as argument for -B,
you deserve trouble. Also, isn't -B to be
Hello Arto,
Thanks for the report.
* [EMAIL PROTECTED] wrote on Wed, May 09, 2007 at 08:55:12AM CEST:
> libtool-1.5.22 asks me to report:
>
> 7 of 102 tests failed
> (10 tests were not run)
[...]
> the failed tests are ('grep FAIL $LOGFILE'):
>
> FAIL: depdemo-make.test
> FAIL: depdemo-make.tes
Hello Mike,
* Mike Frysinger wrote on Tue, May 08, 2007 at 12:41:44AM CEST:
> looking through current libtool code, i dont see any places that it allows
> gcc's -B arguments through to the linking stage ... is there such code
Currently not. It would have to be at least a bit smart, too, to avoi
Hello Peter, Christoph, all,
* Peter O'Gorman wrote on Wed, May 02, 2007 at 02:22:28PM CEST:
>
> Ralf, if you don't have a patch handy, I can look into this.
I don't care if you do the work or I, but it was me who broke it. ;-)
All I can say is that a test case should be added, and that I probab
Hello Christoph,
* Christoph Egger wrote on Tue, May 01, 2007 at 10:36:29AM CEST:
>
> In cvs head, the last change in libltdl/config/ltmain.m4sh
> broke linking on MacOSX.
Darn. Thanks for the report.
> I want to link against -framework ApplicationServices -framework Cocoa
> -framework Carbon
Thanks Noah. I installed that, but changed the constant to be a #define
in the header file.
To ease Jeff's concerns about -shared: if libtool supports shared
libraries for the system/compiler in question, then they will be
preferred over static libs. So -shared is not needed in order for the
tes
[ http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5697
http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5465 ]
Hello all, and apologies for the huge delay,
* Peter Wainwright wrote on Sun, Jul 23, 2006 at 11:06:36PM CEST:
> I'm trying to compile a large existing project which uses libtoo
* Peter O'Gorman wrote on Wed, Apr 04, 2007 at 12:06:58AM CEST:
> On Apr 3, 2007, at 4:44 PM, Ralf Wildenhues wrote:
> >
> >Do I understand correctly that Darwin has no way to hardcode library
> >paths (other than the ones given by -install-name)? OK to apply and
ound.
[...]
Ouch. What a brown bag. Thanks. I'm applying this obvious fix.
Cheers,
Ralf
2007-04-10 Ralf Wildenhues <[EMAIL PROTECTED]>
* ltmain.in (execute mode): Do not unset locale variables that
have not been set previously. Do not use uninitialized
$l
Hello Dave,
Thanks for the report.
* deckrider wrote on Fri, Apr 06, 2007 at 01:30:26AM CEST:
>
> I ran libtool 1.5.23b tests on ia64-hp-hpux11.23 and alphaev56-dec-osf4.0f.
>
> ia64-hp-hpux11.23 had only one fail: hardcode.test.
Known failure.
> alphaev56-dec-osf4.0f. reported that All 10
Hi Peter, all,
* quoting myself:
> * Simon Josefsson wrote on Thu, Mar 29, 2007 at 12:17:32PM CEST:
> >
> > /bin/sh ../libtool --tag=CC --mode=link gcc -DLIBSSH2_DARWIN -I/
> > usr/include -I/usr/include -no-install -L/usr/lib -lcrypto -L/usr/lib
> > -lz -o simple simple.o ../src/libssh2.la
hair for quotes. Why don't you use
> functions? My usual $0.02 :)
Well if your $0.02 were multiplied by an, umm, large factor, you could
probably pay someone (else) to do a nice clean rewrite of Libtool.
Alternatively, I'd welcome you to do to Libtool what you did to Autoconf
some y
1 - 100 of 355 matches
Mail list logo
