I just made a sandbox with autoconf-2.69, automake-1.15 and git libtool.
Running the tests on NetBSD-current/amd64, gcc 5.4.0, binutils 2.26, I see
several failures, including:
61: flags.at:24passing CXX flags through libtool
libtool cxx
which appears to be the same problem, as sh
I'm trying to create a C++ loadable module. I thought it would be as easy
as:
=== configure.ac ===
AC_INIT(hellow, 0.0.1)
AC_CONFIG_MACRO_DIR(m4)
AC_PROG_CXX
AM_INIT_AUTOMAKE([foreign])
LT_INIT
AC_CONFIG_FILES(Makefile)
AC_OUTPUT
My project builds fine on NetBSD, but I just tried it on Ubuntu 12.04.1
and linking the final dasher binary fails with unresolved symbols which
are in libatspi. I am playing spot the difference, but not getting far...
Overall, the binary dasher links to Gtk2/libdashergtk.la, and
libdashergtk.la is
On Tue, Sep 20, 2011 at 04:45:34PM +0200, Alessandro Candini wrote:
> >>../src $ ldd hello
> >> not a dynamic executable
Well spotted by Nick! (I should have asked for "file hello")
Cheers,
Patrick
___
https://lists.gnu.org/mailman/listinfo/libtoo
On Mon, Sep 19, 2011 at 03:34:22PM +0200, Alessandro Candini wrote:
> Hi everyone.
> I have a problem making ltdl library work with some C++ code.
> I have implemented my personal version of the example at the end of
> Chapter 7 in the book "Autotools" by John Calcote.
> Basically it is the same, b
On another list a poster thought that libtool was doing the wrong thing(tm),
but it seems to be rather that config.guess needs to be given hints about
sun4u. This means that this probably isn't the right list - but which one
is?
Essentially, he is running a 64 bit system, and is hoping for sparc64
On Fri, Sep 19, 2008 at 07:56:28PM +0200, Ralf Wildenhues wrote:
> Please note that Automake 1.10 has changed handling of *_LDFLAGS,
> quoting from the NEWS file:
So that explains why everyone isn't clamouring - I am using automake 1.10a
Thanks,
Patrick
___
On Wed, Sep 17, 2008 at 10:25:00PM +0200, Ralf Wildenhues wrote:
> >> I'm trying to debug the libsasl make install error:
> >>
> >> libtool: install: /usr/bin/install -c .libs/libsasldb.lai
> >> /usr/local/lib/sasl2/libsasldb.la
> >> install: .libs/libsasldb.lai: stat: No such file or directory
>
I'm trying to debug the libsasl make install error:
libtool: install: /usr/bin/install -c .libs/libsasldb.lai
/usr/local/lib/sasl2/libsasldb.la
install: .libs/libsasldb.lai: stat: No such file or directory
but I can't seem to find any documentation on where/when a .lai is created.
(Just a refere
Hello Ralf!
> > I think that question still stands, but my rm -f is actually from just above
> > that spot:
>
> Sorry, I haven't had time to look at this issue, and it may well be
> a few more days.
> Adding it to delfiles makes the algorithm use quadratic amount of
> disk space, rather than lin
On Thu, Dec 20, 2007 at 06:21:30PM +, Patrick Welche wrote:
> On Sun, Dec 16, 2007 at 10:04:59AM +0100, Ralf Wildenhues wrote:
> > Hello,
> >
> > * Patrick Welche wrote on Fri, Dec 14, 2007 at 08:58:51PM CET:
> > > On Fri, Dec 14, 2007 at 12:2
On Sun, Dec 16, 2007 at 10:04:59AM +0100, Ralf Wildenhues wrote:
> Hello,
>
> * Patrick Welche wrote on Fri, Dec 14, 2007 at 08:58:51PM CET:
> > On Fri, Dec 14, 2007 at 12:27:48PM -0700, Eric Blake wrote:
> > >
> > > The general idiom for this is 'rm -f
On Sun, Dec 16, 2007 at 10:04:59AM +0100, Ralf Wildenhues wrote:
> Only if you have a dummy file to remove. In libtool it's easier to just
> add
> test -z "$files" || $RM $files
>
> as appropriate. Which tests are failing for you, Patrick? I assume
> this is NetBSD?
First good news: it is te
On Fri, Dec 14, 2007 at 12:27:48PM -0700, Eric Blake wrote:
>
> The general idiom for this is 'rm -f dummy $files', so that even if $files
> is empty, you are still passing an argument to rm, and the -f avoids
> failure on the dummy argument.
Elegant!
P
I am seeing trivial test failures just because
% rm -f
usage: rm [-f|-i] [-dPRrvW] file ...
e.g.,
> /stresstest.at:251: eval '$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o "$rel"s
ub2/liba.la "$rel"sub/a.lo' $linkargs
> stderr:
> usage: rm [-f|-i] [-dPRrvW] file ...
> stdout:
> libtool: link: rm
On Mon, Jul 03, 2006 at 11:14:09PM +0200, Ralf Wildenhues wrote:
> * Tim Mooney wrote on Mon, Jul 03, 2006 at 10:50:23PM CEST:
...
> Probably, yes.
>
> > I seem to recall discussion on this list in the past about why
> > distributions were doing that, but I don't recall what any of the reasons
> >
On Sat, Oct 21, 2006 at 01:31:53PM +0200, Ralf Wildenhues wrote:
> Hello Patrick,
>
> * Patrick Welche wrote on Mon, Oct 16, 2006 at 01:17:42PM CEST:
> >
> > /usr/X11R6/lib doesn't need to be in the default set of paths searched
> > by the loader. As I mentioned,
On Sat, Oct 28, 2006 at 12:57:09AM +0200, Ralf Wildenhues wrote:
> Hello Patrick,
>
> * Patrick Welche wrote on Fri, Oct 27, 2006 at 06:35:31PM CEST:
> >
> > (Spent the afternoon teaching reciprocal space in hexagonal crystals, so
> > I'm quite sure sin(pi/2) =
On Thu, Oct 26, 2006 at 10:39:12PM +0200, Ralf Wildenhues wrote:
> * Patrick Welche wrote on Thu, Oct 26, 2006 at 04:37:39PM CEST:
> > All with CVS autotools, the following tests fail for me:
> >
> > 16: link-order2.at:25 Link order of deplibs.
> > libtool
>
All with CVS autotools, the following tests fail for me:
16: link-order2.at:25 Link order of deplibs.
libtool
35: nonrecursive.at:70 compiling softlinked libltdl
libtoolize automake autoconf
36: nonrecursive.at:94 compiling copied libltdl
libtoolize automake autoconf
37
On Sat, Oct 21, 2006 at 01:31:53PM +0200, Ralf Wildenhues wrote:
> Hello Patrick,
>
> * Patrick Welche wrote on Mon, Oct 16, 2006 at 01:17:42PM CEST:
> >
> > /usr/X11R6/lib doesn't need to be in the default set of paths searched
> > by the loader. As I mentioned,
On Mon, Oct 16, 2006 at 10:18:31AM +0530, Jaimon Jose wrote:
> ltmain.sh (GNU libtool 1.2345 2006/09/20 19:08:21) 2.1a
^^
just raised a smile :-)
Patrick
___
http://lists.gnu.org/mailman/listinfo/libtool
On Sun, Oct 15, 2006 at 08:17:54PM -0500, Albert Chin wrote:
> On Sun, Oct 15, 2006 at 08:53:41PM +0100, Patrick Welche wrote:
> > With CVS autotools of this month I am getting in a pickle trying
> > to build a program which depends on a shared library which depends
> > on a
P.S. libtool --config tells me:
hardcode_automatic=no
inherit_rpath=no
link_all_deplibs=unknown
Patrick
___
http://lists.gnu.org/mailman/listinfo/libtool
With CVS autotools of this month I am getting in a pickle trying
to build a program which depends on a shared library which depends
on a shared library. This is on NetBSD which uses rpath. An example
based on one from autobook is attached which builds
hello -> libhello -> (libSM,libICE)
.libs/l
Hi Ralf!
> Yes. Please send
> ../../libtool --config
> ../../libtool --debug --mode=link ...(rest of link line)...
OK - attached..
Cheers,
Patrick
toralf.gz
Description: Binary data
___
http://lists.gnu.org/mailman/listinfo/libtool
While trying to build cvs-freetds with cvs autotools, I got:
gmake[3]: Entering directory `/usr/src/local/freetds/src/odbc'
/bin/ksh ../../libtool --tag=CC --mode=link gcc -pthread -g -O2
-I/usr/include -Wdeclaration-after-statement -export-symbols-regex
'^(SQL|ODBCINST).*' -module -Wl,-R/usr
On Thu, Aug 11, 2005 at 04:41:46PM +0200, Ralf Wildenhues wrote:
> They also have position-independent relocations.
> Try 'objdump -x' on my above example.
Ah yes:
.libs/foo.o:
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0019 R_386_GOTPC _GLOBAL_OFFSET_TABLE_
0
On Thu, Aug 11, 2005 at 03:41:22PM +0200, Ralf Wildenhues wrote:
> Because in general they are _not_ identical on NetBSD. Show foo.c.
Ah - it was a very simple foo.c ;-)
quartz% cat foo.c
void foo(void);
void foo(void)
{
int i;
i=0;
}
Cheers,
Patrick
___
On Wed, Jul 20, 2005 at 02:23:06PM +0200, Jeremie LE HEN wrote:
> IMO, the user is confused while reading this. Furthermore, the
> first statement is wrong in regard to the example on the NetBSD box
> (burger) :
> burger$ libtool compile gcc -g -O -c foo.c
> mkdir .libs
On Wed, Jul 06, 2005 at 09:41:41PM +0200, Ralf Wildenhues wrote:
> Are you aware of the recent macro loop in CVS HEAD/branch-2-0 Libtool in
> conjunction with special Autoconf versions?
/me checks it isn't 1 April...
nope
> Which exact Autoconf/Automake/Libtool versions do you use (if CVS
> vers
I don't really know where to ask for help: trying libtool as the last
macro mentioned is an autoconf fixup for libtool..
I'm trying to build apr with cvs autotools, and essentially do
libtoolize
sinclude(build/{libtool,ltsugar,ltversion,ltoptsion,argz}.m4) in configure.in
(instead of aclo
I was just reading LTDL_CONVENIENCE, where it states:
Note that LIBLTDL and LTDLINCL are not AC_SUBSTed, nor is
AC_CONFIG_SUBDIRS called.
Yet, a few lines below it:
AC_SUBST([LIBLTDL])
AC_SUBST([LTDLINCL])
Just an oversight?
Cheers,
Patrick
__
What is libtoolize meant to do these days?
It used to copy necessary files such as libtool.m4 ltsugar.m4 and friends
into . or MACRO_DIR if defined. Now it seems it just copies ltmain.sh ?!
That patch I sent to libtool-patches was just because I noticed that
libtool's "install" tries to delete ${
On Sun, Nov 14, 2004 at 09:04:31PM +, Gary V. Vaughan wrote:
> You mean that the installed .pc files need to be altered by the
> user to give things a hope of linking? ;-)
Hate to chime in, but I always seem to have to add -Wl,-R... to the *.pc
files, so have not ended up being a fan of pkg-co
I just came across a difference between between GNU make and BSD make:
% cat makefile1
$(var)/foo: bar
$(var)/bar:
echo "making bar"
% make var=. -f makefile1 ./foo
make: don't know how to make bar. Stop
make: stopped in /usr/src/local/libtool/err
% gmake var=. -f makefile1 ./foo
ec
On Mon, Aug 23, 2004 at 08:29:07PM +0100, Patrick Welche wrote:
> I just tried to build cvs libtool with cvs auto* all from today, and get:
>
> make all-recursive
> Making all in .
> cd . && /bin/ksh /usr/src/local/libtool/config/missing --run automake-1.9a --gnits
&
I just tried to build cvs libtool with cvs auto* all from today, and get:
make all-recursive
Making all in .
cd . && /bin/ksh /usr/src/local/libtool/config/missing --run automake-1.9a --gnits
libltdl/Makefile.am: C objects with per-target flags but `AM_PROG_CC_C_O' not in
`configure.ac'
Am I
With cvs code from just now:
make all-recursive
Making all in .
cd . && /bin/ksh /usr/src/local/libtool/config/missing --run automake-1.9a --gnits
libltdl/Makefile.am: C objects with per-target flags but `AM_PROG_CC_C_O' not in
`configure.ac'
Cheers,
Patrick
__
On Wed, Jul 28, 2004 at 11:22:09AM -0700, Paul Eggert wrote:
> Patrick Welche <[EMAIL PROTECTED]> writes:
>
> > -elif test -n "${BASH_VERSION+set}${KSH_VERSION+set}" && (set -o posix) >/dev/null
> > 2>&1; then
> > +elif test -n &qu
On Wed, Jul 28, 2004 at 06:38:56PM +0100, Gary V. Vaughan wrote:
> If you revert my patch, or fetch the prepatch revision from my arch
> mirror, and bootstrap with HEAD autoconf, does the new AS_SHELL_SANITIZE
> from autoconf prevent the crash when setting output_verbose_link_cmd?
That's it - I fi
On Tue, Jul 27, 2004 at 01:25:43PM -0700, Paul Eggert wrote:
> "Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
> The workaround in this case is easy. Just omit the outer quotes and
> remove the inner backslashes:
>
> output_verbose_link_cmd=`$echo "X$output_verbose_link_cmd" | $Xsed -e
> "$no_glob
On Tue, Jul 27, 2004 at 11:23:29AM -0500, Bob Friesenhahn wrote:
> There must be a syntax which works in all cases. We have encountered
> (and fixed) this backslash problem before.
Just removing the extra backslashs in that line "work for me", but I don't
know if that will work always..
Cheers,
On Tue, Jul 27, 2004 at 04:07:14PM +0100, Patrick Welche wrote:
> The great part is this is a ksh quoting problem:
> Oh joy... (ksh version @(#)PD KSH v5.2.14 99/07/13.2)
.. and it is explained in TFM:
The following is a list of things that are affected by the state of the
I can reproduce the
sed: 1: ""s/\*/\\\*/g"": invalid command code "
error with the minimum configure.ac which contains LT_LANG(C++)
which calls _LT_LANG_CXX_CONFIG,
which calls AC_LIBTOOL_PROG_LD_SHLIBS,
which calls AC_LIBTOOL_POSTDEP_PREDEP,
which has
# The `*' in the case matches for archite
On Mon, Jul 26, 2004 at 07:29:10PM +0100, Patrick Welche wrote:
> sed: 1: ""s/\*/\\\*/g"": invalid command code "
PS that comes from
# Sed substitution to avoid accidental globbing in evaled expressions
no_glob_subst='s/\*/\\\*/g'
not sure how that gets n
I get:
libtool: Version mismatch error. This is libtool 1.5b, revision AR=ar
AR_FLAGS...
libtool: but the definition used by this AC_PROG_LIBTOOL comes from revision
libtool: 1.1527.
libtool: You should recreate aclocal.m4 with macros from revision AR=ar
AR_FLAGS...
libtool: of libtool 1.5b and r
On Mon, Jul 05, 2004 at 08:37:18AM +0100, Gary V.Vaughan wrote:
> Counting parens shows that removing a set will stop the AC_DEFUN from
> being closed.
Yes, you are right! and now I can't remember what I was doing way back when
when I thought this solved a problem, so all I'm left with is my wrong
I just did a cvs update and found that my ancient patch must have been
missed.. Please apply!
Cheers,
Patrick
Index: m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v
retrieving revision 1.76
diff -u -r1.76 libtool
All tests pass before and after this patch.. but the configure scripts
become happier..
Cheers,
Patrick
Index: m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v
retrieving revision 1.69
diff -u -r1.69 libtool.m4
--
It seems that libtool.m4 may depend on
argz.m4 ltdl.m4 ltoptions.m4 ltsugar.m4 ltversion.m4
How stable do you think that list is? (for those programmes which don't
want to depend on automake for the sake of aclocal)
Cheers,
Patrick
___
Libtool mai
On Fri, Apr 16, 2004 at 02:21:11PM -0500, Albert Chin wrote:
> On Thu, Apr 15, 2004 at 11:10:20AM -0500, Bob Friesenhahn wrote:
> > If a program which is based on C language depends on a library which
> > is implemented in C++, the C++ compiler should be used to link the
> > program. Otherwise C++
On Wed, Mar 10, 2004 at 04:48:13PM +, Gary V. Vaughan wrote:
> Exactly right. I have a half cocked patch to fix this that needs testing
> before I commit...
>
> | (There is more to this still, as then:
> |
> | src/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined
> | src/Makefile
LT_INIT is defined using AC_DEFUN_ONCE. There is no documentation for
this macro in autoconf.texi, and aclocal doesn't know about it, or at
least, it doesn't pick up the fact that as LT_INIT appears in configure.ac,
it should include m4/libtool.m4. (s/AC_DEFUN_ONCE/AC_DEFUN/ changes this)
I don't
brary used but `LIBTOOL' is undefined
src/Makefile.am:1:
src/Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
src/Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again.
from automake)
Cheers,
Patrick
On Thu, Feb 26, 2004
about LT_INIT or not)
Cheers,
Patrick
On Thu, Feb 26, 2004 at 04:41:54PM +, Patrick Welche wrote:
> libtoolize: warning: no serial number on `/usr/local/share/libtool/m4/libtool.m4',
> not copying.
>
> libtoolize (GNU libtool 1.1434 2004/02/23 16:59:14) 1.5a
> -rw-r-
I needed the following to get a clean build..
Cheers,
Patrick
Index: doc/libtool.texi
===
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.149
diff -u -r1.149 libtool.texi
--- doc/libtool.texi22 Feb 2
libtoolize: warning: no serial number on `/usr/local/share/libtool/m4/libtool.m4', not
copying.
libtoolize (GNU libtool 1.1434 2004/02/23 16:59:14) 1.5a
-rw-r--r-- 1 root wheel 206060 Feb 26 14:55 /usr/local/share/libtool/m4/libtool.m4
% grep serial /usr/local/share/libtool/m4/libtool.m4
# ser
On Wed, Feb 18, 2004 at 01:25:20PM -0800, Lon Canaday wrote:
> Sorry,
> Here are the details.
> main.o(.text+0xe): In function `main':
> /usr/include/g++-3/iostream.h:106: undefined reference to `cout'
Does this help?
Cheers,
Patrick
Index: tests/tagdemo/foo.cpp
=
On Wed, Feb 18, 2004 at 01:25:20PM -0800, Lon Canaday wrote:
> Sorry,
> Here are the details.
> -Wl,/home/lcanaday/build_tmp/libtool/libtool-1.5.2/tests/_inst/lib
> main.o(.text+0xe): In function `main':
> /usr/include/g++-3/iostream.h:106: undefined reference to `cout'
>
* Makefile.am (pkgmacro_DATA): We have to distribute
m4/ltversion.m4 because it can be needed before the Makefile
that generates it exists.
but:
libtoolize: warning: no serial number on `/usr/local/share/libtool/m4/ltversion.m4',
not copying.
:-(
Cheers,
Patrick
On Thu, Jan 29, 2004 at 09:26:50AM +0100, Alexandre Duret-Lutz wrote:
..
> Anyway, the point is that you should not fear this. Installing
> third-party macros in /usr/share/aclocal will continue to work.
I think the problem arises when packages assume that libtool.m4 lives
in /usr/share/aclocal
On NetBSD-1.6ZH/i386, with today's cvs:
Making all in libltdl
gmake[2]: Entering directory `/usr/src/local/libtool/libltdl'
/usr/local/bin/bash ../libtool --mode=compile --tag=CC gcc
-DHAVE_CONFIG_H="" -I. -I. -I.. -I.. -g -O2 -c -o ltdl.lo ltdl.c
mkdir .libs
gcc "-DHAVE_CONFIG_H=" -I. -I. -I
On Fri, Nov 28, 2003 at 09:40:36AM +, Gary V. Vaughan wrote:
> Patrick Welche wrote:
> | I was hoping to not create shared modules [[snip]]
> |
> | libtool --mode=link gcc -module -export-dynamic -o mod_auth_basic.la
> mo
On Thu, Nov 27, 2003 at 03:27:51PM +, Gary V. Vaughan wrote:
> mod_auth_basic.a doesn't contain mod_auth_basic.o. Are you running with
> - --disable-static?
I was hoping to not create shared modules, but I can't actually see
relevant flags in the libtool invocation. The compile which uses
-pr
I am finding out the hard way about .la .lo etc files trying to compile
cvs httpd, with static modules, but I still haven't found the small
example to illustrate the problem. Essentially
libtool --mode=link gcc -export-dynamic -o httpd modules.lo
modules/aaa/mod_auth_basic.la
translates as
gcc -o
On Wed, Nov 26, 2003 at 11:41:30AM +, Gary V. Vaughan wrote:
I don't understand the above, but bootstraping libtool, I see:
> ~ 1: remove $prefix/share/aclocal/l(ibtoo|td)l.m4 of old releases at
> install
> ~ time
> ~ 2: keep copies of the latest versions only in $prefix/share/libtool/
On Sat, Nov 22, 2003 at 10:18:03PM +, Patrick Welche wrote:
> On Sat, Nov 22, 2003 at 10:41:15AM -0600, Bob Friesenhahn wrote:
> ..
> > Running configure still does not result in a libtool script so I get
> > this error:
> >
> > /home/bfriesen/src
On Sat, Nov 22, 2003 at 10:41:15AM -0600, Bob Friesenhahn wrote:
..
> Running configure still does not result in a libtool script so I get
> this error:
>
> /home/bfriesen/src/gnu/libtool'
> CONFIG_FILES= CONFIG_HEADERS= CONFIG_COMMANDS=libtool
> /usr/local/bin/bash ./config.status
> config.statu
Somehow during execution of configure, ac_aux_dir becomes unset (!)
To repeat, create this highly complex configure.ac:
AC_INIT([autoprob],[1.0])
AC_PROG_LIBTOOL
AC_OUTPUT
automake -a
cp /usr/local/share/automake/config.{sub,guess} .
libtoolize
aclocal
autoconf
Then apply something like the att
On Mon, Nov 17, 2003 at 02:15:51PM +, Patrick Welche wrote:
> Can you think of something which has changed in the last 3 weeks that could
> cause this? (It looks like top_builddir or something like that is no longer
> set, but I am not changing autoconf, just libtool.. (supplementary
I have yesterday's CVS autoconf, automake, apache httpd-2.0. Using
ltmain.sh (GNU libtool) 1.5a (1.1296 2003/10/21 15:03:52)
apache's buildconf does its thing, and my only problem is undefined module
symbols in the final link, however
ltmain.sh (GNU libtool) 1.5a (1.1331 2003/11/14 17:33:04)
With today's cvs libtool, I came across the following trying to autogen atk:
libtoolize: putting files in AC_CONFIG_AUX_DIR, `'.
so, it seems that auxdir is unset. I think this is strange, as I vaguely
remember the existence of a AC_CONFIG_AUX_DIR_DEFAULT ? I suppose normally
one wouldn't see t
With today's CVS, on NetBSD-current/i386, gmake 3.79.1 just 1 test failed:
% cd tests
% gmake MAKE=gmake TESTS="mdemo2-conf.test mdemo2-make.test" VERBOSE=-x check
...
gmake[2]: Leaving directory `/usr/src/local/libtool/tests/mdemo2'
= Configuring in mdemo2 (--prefix=/usr/src/local/libtool/tests/_
Self explanatory I hope! Cheers, Patrick
Index: libtoolize.in
===
RCS file: /cvsroot/libtool/libtool/libtoolize.in,v
retrieving revision 1.25
diff -u -r1.25 libtoolize.in
--- libtoolize.in 14 Oct 2003 22:52:57 - 1.25
++
Using cvs libtool from just now, which passed everything :-), I tried
bootstraping sasl, and found that the libtool generated died at
progname=`$echo "$0" | ${SED} 's%^.*/%%'`
modename="$progname"
because SED was empty - where should SED be defined? (Adding SED=sed just
before the above had it wo
> You have therefore been approved for a lump sum pay
> out of US$1,500,000.00 in cash credited to file REF
> NO. REF: WBL/67-B773524441. This is from total
As far as I remember, within the last ?month? a French court forced
a company who promised a prize of XXX to actually pay it. (Was one
of
On Thu, Sep 13, 2001 at 09:30:40PM +0100, Gary V. Vaughan wrote:
...
> HAVE_LIBDL is a misnomer, and should perhaps be renamed to
> HAVE_DLOPEN, since the additon of a library that contains dlopen is
> handled separately.
Good idea :)
Patrick
___
Lib
On Thu, Sep 13, 2001 at 08:07:48AM +0200, Assar Westerlund wrote:
> Nick Hudson <[EMAIL PROTECTED]> writes:
> > OK. I am now seeing the same thing and the reason is that the configure
> > stuff for libltdl doesn't expect dlopen to exist in libc - it is
> > expecting it in libdl or libsvld. Parts o
On Mon, Sep 10, 2001 at 08:29:17PM +0100, Nick Hudson wrote:
> On Monday 10 September 2001 18:59, Patrick Welche wrote:
> > I mumbled about mdemo-exec and friends failing a while back, but hopefully
> > this will make the problem a bit clearer:
>
> I already stated that th
On Tue, Sep 11, 2001 at 07:34:16PM +0100, Gary V. Vaughan wrote:
> On Mon, Sep 10, 2001 at 08:29:17PM +0100, Nick Hudson wrote:
> > On Monday 10 September 2001 18:59, Patrick Welche wrote:
> > > I mumbled about mdemo-exec and friends failing a while back, but hopefully
> &
On Tue, Sep 11, 2001 at 07:34:16PM +0100, Gary V. Vaughan wrote:
> On Mon, Sep 10, 2001 at 08:29:17PM +0100, Nick Hudson wrote:
> > On Monday 10 September 2001 18:59, Patrick Welche wrote:
> > > I mumbled about mdemo-exec and friends failing a while back, but hopefully
> &
I mumbled about mdemo-exec and friends failing a while back, but hopefully
this will make the problem a bit clearer:
Just adding the following to source of 6 September 14:36 GMT:
Index: ltdl.c
===
RCS file: /cvsroot/libtool/libtool/l
A quick look says that in ltdl.c, presym_open() if you get there with a call
to lt_dlopen(0), filename is null, so
if (!filename)
{
filename = "@PROGRAM@";
}
then later:
if (!syms->address && strcmp(syms->name, filename) == 0)
as address==0, we look for syms->name ==
On Mon, Jul 16, 2001 at 09:05:40PM +0100, Gary V. Vaughan wrote:
>
> I am using automake from the stable branch, and autoconf-2.50, so I can't
> vouch for how well things work with development versions... you might try
> that configuration before digging too much. I have received a lot of patc
PASS: mdemo-static.test
PASS: mdemo-make.test
PASS: mdemo-exec.test
PASS: mdemo-inst.test
PASS: mdemo-unst.test
PASS: mdemo-conf.test
PASS: mdemo-make.test
FAIL: mdemo-exec.test
FAIL: mdemo-inst.test
PASS: mdemo-unst.test
PASS: mdemo-shared.test
PASS: mdemo-make.test
FAIL: mdemo-exec.test
FAIL:
On Mon, Mar 12, 2001 at 03:09:54PM -0500, edward wrote:
...
> > On Monday 12 March 2001 7:08 pm, Patrick Welche wrote:
> > > Using source updated Mar 12 11:42 GMT on NetBSD-1.5S/i386 I have a few
> > > failed tests. In directory tests running demo-conf.test then
>
Using source updated Mar 12 11:42 GMT on NetBSD-1.5S/i386 I have a few
failed tests. In directory tests running demo-conf.test then demo-make.test
gives...
creating hell
/bin/sh ./libtool --mode=link gcc -g -O2 -o hell.static -static main.o libhello.la
gcc -g -O2 -o hell.static main.o ./.lib
ltmain.sh generates wrapper scripts with a relink_command defined. In my
case, said command correctly has -L/usr/local/lib -L/usr/X11R6/lib, but only
has -Wl,--rpath -Wl,/usr/local/lib, no X11R6. I was hoping that both the -L
part and the --rpath part would grab $deplibs ? but they are obviously
d
On Thu, Jul 06, 2000 at 10:02:57PM +0100, Nick Hudson wrote:
>
> I don't (yet) understand the logic here, but the attached patch fixes
> all the tests for the head branch for NetBSD-current (on i386 at least).
> I'm still trying to understand why this works and if its definitely the
> way to go.
As some of the depdemo tests are failing for me under NetBSD-1.5B/i386, I
just tried running
depdemo-shared.test
depdemo-make.test
depdemo-exec.test
I don't understand the last part of the output from depdemo-make.test:
/bin/sh ./libtool --mode=link gcc -g -O2 -o depdemo.static main.o
./l
On Tue, May 30, 2000 at 03:23:09PM +0200, Linus Nordberg wrote:
> Mocha <[EMAIL PROTECTED]> wrote
> Mon, 29 May 2000 23:29:15 -0500:
>
># make check | grep FAIL
>FAIL: demo-exec.test
>FAIL: demo-exec.test
>FAIL: demo-exec.test
>FAIL: hardcode.test
>FAIL: build-relink.test
92 matches
Mail list logo
