This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Cannot build latest snapshot in maintainer-mode
- To: binutils at gcc dot gnu dot org
- Subject: Cannot build latest snapshot in maintainer-mode
- From: "Wolfe J.L." <jlw at sco dot com>
- Date: Thu, 28 Jun 2001 16:42:15 -0400
- Organization: SCO Inc.
I recently submitted a patch to config.guess that would standardive the
triplet
for UnixWare 7.x and Open Unix 8.0 systems to either
i?86-unknown-sysv5UnixWare7.1.1
i?86-unknown-sysv5OpenUNIX8.0.0
The "sysv5" prefix to the third segment is the critical portion.
I noticed in the binutils-latest-snapshot tree, the configure scripts,
as a result of
libtool.m4, have $host_os checks for "sysv5uw[78]*. This is incorrect
since
there never was or will be a UnixWare 8, and is more than needs to be
checked.
Likewise the "sysv5" (System 5- Release 5) is only applicable to
SCO/Caldera
Os's.
While I realize that a patch to libtool.m4 should probably be submitted
to the libtool
maintainers, I was attempting to check out the following patch with the
binutils-latest-snapshot.
*** libtool.m4.ORIG Sun May 20 15:02:54 2001
--- libtool.m4 Tue Jun 19 17:00:17 2001
***************
*** 636,646 ****
lt_cv_file_magic_test_file=/lib/libc.so
;;
! [sysv5uw[78]* | sysv4*uw2*)]
lt_cv_deplibs_check_method=pass_all
;;
! sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
case $host_vendor in
ncr)
lt_cv_deplibs_check_method=pass_all
--- 636,646 ----
lt_cv_file_magic_test_file=/lib/libc.so
;;
! [sysv5* | sysv4*uw2*)]
lt_cv_deplibs_check_method=pass_all
;;
! sysv4 | sysv4.2uw2* | sysv4.3*)
case $host_vendor in
ncr)
lt_cv_deplibs_check_method=pass_all
I cannot get the change to take effect in a build. I have:
- pulled down the special versions of automake, autoconf, gettext
and libtool
from ftp://sourceware.cygnus.com/pub/binutils as directed in
README-maintarer-mode; compiled and installed in my PATH
prior to other versions of the tools
- configured with --enable-maintainer-mode
When I do a "make clean", "make maintainer-clean" or simply a "make"
the
autoconf is failing building opcodes/configure with:
+ m4 -I/lfs/home4/NEWGNUTools/local/share/autoconf --reload autoconf.m4f
configure.in
configure.in:8: AC_TRY_COMPILE was called before AC_ISC_POSIX
configure.in:8: AC_TRY_RUN was called before AC_ISC_POSIX
pattern=AC_
status=0
+ grep ^[^#]*AC_ /tmp/acout.19907
+ echo autoconf: Undefined macros:
autoconf: Undefined macros:
+ sort -u
+ sed -n s/^[^#]*\(AC_[_A-Za-z0-9]*\).*/\1/p /tmp/acout.19907
+ read macro
+ grep -n ^[^#]*AC_FD_MSG configure.in /dev/null
+ test 1 -eq 1
+ echo ***BUG in Autoconf--please report*** AC_FD_MSG
***BUG in Autoconf--please report*** AC_FD_MSG
........
configure.in:107:AC_SUBST(cgendir)
configure.in:122:AC_SUBST(WIN32LDFLAGS)
configure.in:123:AC_SUBST(WIN32LIBADD)
configure.in:258:AC_SUBST(archdefs)
configure.in:259:AC_SUBST(BFD_MACHINES)
configure.in:30:AC_ARG_ENABLE(targets,
configure.in:38:AC_ARG_ENABLE(commonbfdlib,
configure.in:47:AC_ARG_ENABLE(build-warnings,
configure.in:65:AC_SUBST(WARN_CFLAGS)
configure.in:78:AC_PROG_CC
configure.in:85:AC_SUBST(HDEFINES)
configure.in:88:AC_CHECK_HEADERS(string.h strings.h stdlib.h)
configure.in:8:AC_ISC_POSIX
configure.in:93:AC_ARG_ENABLE(cgen-maint,
status=1
I have even gotten desparate and tried running autoconf by hand with
similar results.
Have I used the correct "special" versions of autoconf, automake,
gettext, and libtool?
I am beginning to suspect not:
1. the libtool components in the binutils snapshot appear to be 1.4a
based.
2. the libtool-000227.tar.bz2 appears to be 1.3.4 based.
3. libtool-1.4 has no references in it to an os_host with
"sysv5uw[78]*" in it.
When I hand tweak the various configure files, I get the same build and
test results
as I get with the unmodified binutils snapshot.
--
John Wolfe Caldera International, Inc. jlw at caldera dot com