Linus Nordberg <[EMAIL PROTECTED]> wrote
26 May 2000 13:22:25 +0200:
The parsing of /usr/bin/nm output on AIX (at least 4.1.4.0 and
4.3.2.0) fails.
Sorry about that. I was using AC_CHECK_TOOL rather than AC_PROG_NM
(from Libtool) to find `nm' and didn't get the `-B' option.
What if on
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
that was on NetBSD-1.4Y/Alpha (ELF) and libtool 1.3.5. how can in find
o
On May 30, 2000, Mocha <[EMAIL PROTECTED]> wrote:
> how can in find out why the test failed and track down the errors.
Start with defining the environment variable VERBOSE, so that you get
more details about the errors.
This might be a symptom of a bug that was fixed yesterday in the CVS
tree,
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
On Mon, May 29, 2000 at 11:29:15PM -0500, Mocha wrote:
> # make check | grep FAIL
> FAIL: demo-exec.test
> FAIL: demo-exec.test
> FAIL: demo-exec.test
> FAIL: hardcode.test
> FAIL: build-relink.test
>
> that was on NetBSD-1.4Y/Alpha (ELF) and libtool 1.3.5. how can in find out
> why the test fai
On May 30, 2000, Linus Nordberg <[EMAIL PROTECTED]> wrote:
> Linus Nordberg <[EMAIL PROTECTED]> wrote
> 26 May 2000 13:22:25 +0200:
>The parsing of /usr/bin/nm output on AIX (at least 4.1.4.0 and
>4.3.2.0) fails.
> Sorry about that. I was using AC_CHECK_TOOL rather than AC_PROG_NM
>
Hi Linus,
Thanks for the report!
On Fri, May 26, 2000 at 01:22:25PM +0200, Linus Nordberg wrote:
> The parsing of /usr/bin/nm output on AIX (at least 4.1.4.0 and
> 4.3.2.0) fails.
>
> config.log:
>
> ltconfig:1871: eval "nm conftest.o | sed -n -e 's/^.*[ ]\([BCDT]\)[][
> ]*\(\)\([_A
Hi Kevin,
I've run through the libtool code again, and I think that I was wrong
about the ML branch bypassing the part of libtool that drops static
libs. AFAICT, the ML branch simply adds the libraries it detected
from the internal C++ compiler link commands, and adds them to the
list of librari
On Tue, 30 May 2000, Ossama Othman wrote:
> I've run through the libtool code again, and I think that I was wrong
> about the ML branch bypassing the part of libtool that drops static
> libs. AFAICT, the ML branch simply adds the libraries it detected
> from the internal C++ compiler link comman
Hi,
libtool --silent doesn't hide the
--
Libraries have been installed in:
XXXx
To link against installed libraries in a given directory, LIBDIR,
you must use the `-LLIBDIR' flag during linking.
You will
>>Makefile.am:
AUTOMAKE_OPTIONS = foreign
lib_LTLIBRARIES = libtest.la
libtest_la_SOURCES = test.cc
>>configure.in:
AC_INIT(test.cc)
AM_INIT_AUTOMAKE(test, 1.0)
AC_PROG_CXX
AC_LANG_CPLUSPLUS
AM_PROG_LIBTOOL
AC_LIBTOOL_CXX
AC_OUTPUT(Makefile)
>>test.cc:
#include
void foo() {
cout <<
Hi Kevin,
On Tue, May 30, 2000 at 05:37:59PM -0400, Kevin Atkinson wrote:
> On Tue, 30 May 2000, Ossama Othman wrote:
> > goes through. This means that libtool should be dropping the static
> > libs from the dependency list. Do you get a warning message from
> > Libtool such as:
>
> None: This
Hi Kevin,
Thanks for the simple test. I just need to find a Solaris system with
a busted libstdc++ installation, i.e. one that built without
"--enable-shared."
On Tue, May 30, 2000 at 08:43:17PM -0400, Kevin Atkinson wrote:
>
> AC_INIT(test.cc)
> AM_INIT_AUTOMAKE(test, 1.0)
>
> AC_PROG_CXX
>
On Tue, 30 May 2000, Ossama Othman wrote:
> Hi Kevin,
>
> Thanks for the simple test. I just need to find a Solaris system with
> a busted libstdc++ installation, i.e. one that built without
> "--enable-shared."
That should not be too difficult because that is the default option when
building
14 matches
Mail list logo
