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
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
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, but I
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/libtool
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
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
but I can't
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
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
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:27:48PM -0700, Eric Blake wrote:
The general idiom
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 linear.
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 test
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 $rels
ub2/liba.la $relsub/a.lo' $linkargs
stderr:
usage: rm [-f|-i] [-dPRrvW] file ...
stdout:
libtool: link: rm -fr
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
were.
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
This one is different
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
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, with a different compile line to the one
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 shared library
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
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)
P.S. libtool --config tells me:
hardcode_automatic=no
inherit_rpath=no
link_all_deplibs=unknown
Patrick
___
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
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
On Fri, Sep 30, 2005 at 02:06:42PM +0200, Ralf Wildenhues wrote:
Hi Gary,
* Gary V. Vaughan wrote on Fri, Sep 30, 2005 at 12:23:03PM CEST:
Okay to commit?
Observe major nit below, then commit, please!
By the way, I believe Patrick meant a generic command line switch to
list the
`libtoolize'.
Reported by Patrick Welche [EMAIL PROTECTED].
On Thu, Sep 01, 2005 at 03:51:08PM +0200, Ralf Wildenhues wrote:
Even better: MAKE=gmake /bin/sh -vx ./bootstrap
You know my setup too well ;-)
One with a broken `make', and a `find' without `-path', I guess.
The rest should be followup failures.
My find claims to have -path, but I also
,
tests/fcdemo-static.test: Use. Do not fail gratuitously but
SKIP on compilers that look like they could be Fortran 77-only.
Reported by Patrick Welche [EMAIL PROTECTED].
Now I have:
PASS: tests/f77demo-static.test
PASS: tests/f77demo-make.test
PASS: tests/f77demo-exec.test
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 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 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_
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
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
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
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
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
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 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
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_subst`
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
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
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
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
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++
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 at 04:41:54PM +, Patrick Welche
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
, 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--r-- 1 root wheel 206060 Feb 26 14:55 /usr/local/share/libtool/m4/libtool.m4
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'
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
* 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=config.h -I. -I. -I.. -I.. -g -O2 -c -o ltdl.lo ltdl.c
mkdir .libs
gcc
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
mod_auth_basic.lo
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
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
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/m4
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.status:
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/gnu/libtool'
CONFIG_FILES= CONFIG_HEADERS
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
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 question
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
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
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
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
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
___
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
this will make the problem
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
this will make the problem
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 the problem lies in the fact
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 patches
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 ==
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:
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
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
demo-make.test
gives
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.
I
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
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
80 matches
Mail list logo
