Bug 137843
| Summary: | Cannot compile devel/apr (version 1.3.8.1.3.9) on AMD64 | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Troy <troy> |
| Component: | Individual Port(s) | Assignee: | Philip M. Gollucci <pgollucci> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-amd64->pgollucci make this a ports PR and assign. Check to see if you have /usr/local/bin/libtool15 /usr/local/bin/libtoolize15 /usr/local/share/libtool15 I found I had those files/directories even after upgrading the libtool 1.5 package to the latest one in ports. Deleting them let the apr build complete. It wasn't on amd64, but the error is similar or the same Gary, That was it. I deleted those two files and the directory below and it was able to build. Consider this bug closed. -Troy Gary Palmer wrote: > Check to see if you have > > /usr/local/bin/libtool15 > /usr/local/bin/libtoolize15 > /usr/local/share/libtool15 > > I found I had those files/directories even after upgrading the libtool > 1.5 package to the latest one in ports. Deleting them let the apr > build complete. It wasn't on amd64, but the error is similar or the same Same for me, on i386. Removing the listed leftover libtool15/libltdl15
files/directories let the devel/apr build succeed, where it would fail
before.
Given that the devel/libtool15 port is gone:
1. Can we have a pkg-install script that purges the obsolete libtool15
stuff (as listed, but substituting ${PKG_PREFIX} for /usr/local) post a
successful libtool22 install? Apparently the older pkg-plist were
incomplete, so that libtool15 didn't get completely removed on uninstall,
and a libtool22/libltdl22 post-installation cleanup of libtool15 seems the
natural way to solve.
2. Alternatively, please mention in /usr/ports/UPDATING that
libtool15/libltdl15 cruft needs to be purged manually (file list as above).
Thank you.
--
Matthias Andree
On Fri, 21 Aug 2009 07:16:57 -0500, Matthias Andree <matthias.andree@gmx.de> wrote: > Same for me, on i386. Removing the listed leftover libtool15/libltdl15 > files/directories let the devel/apr build succeed, where it would fail > before. > > Given that the devel/libtool15 port is gone: > > 1. Can we have a pkg-install script that purges the obsolete libtool15 > stuff (as listed, but substituting ${PKG_PREFIX} for /usr/local) post a > successful libtool22 install? Apparently the older pkg-plist were > incomplete, so that libtool15 didn't get completely removed on > uninstall, and a libtool22/libltdl22 post-installation cleanup of > libtool15 seems the natural way to solve. No need to, the /usr/local/bin/libtool15 wasn't in libtool15 for over three yeaers. It looks like you use FORCE_PKG_REGISTER that force overwrite and that libtool15 was never remove correct. > 2. Alternatively, please mention in /usr/ports/UPDATING that > libtool15/libltdl15 cruft needs to be purged manually (file list as > above). It's more like user's fault or something. Cheers, Mezz > Thank you. -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org Am 21.08.2009, 14:28 Uhr, schrieb Jeremy Messenger <mezz7@cox.net>: > On Fri, 21 Aug 2009 07:16:57 -0500, Matthias Andree > <matthias.andree@gmx.de> wrote: > >> Same for me, on i386. Removing the listed leftover libtool15/libltdl15 >> files/directories let the devel/apr build succeed, where it would fail >> before. >> >> Given that the devel/libtool15 port is gone: >> >> 1. Can we have a pkg-install script that purges the obsolete libtool15 >> stuff (as listed, but substituting ${PKG_PREFIX} for /usr/local) post a >> successful libtool22 install? Apparently the older pkg-plist were >> incomplete, so that libtool15 didn't get completely removed on >> uninstall, and a libtool22/libltdl22 post-installation cleanup of >> libtool15 seems the natural way to solve. > > No need to, the /usr/local/bin/libtool15 wasn't in libtool15 for over > three yeaers. It looks like you use FORCE_PKG_REGISTER that force > overwrite and that libtool15 was never remove correct. I don't use FORCE_PKG_REGISTER, and I've had a full ports upgrade earlier this year; so something must have left these cruft files behind when libtool15 got removed. >> 2. Alternatively, please mention in /usr/ports/UPDATING that >> libtool15/libltdl15 cruft needs to be purged manually (file list as >> above). > > It's more like user's fault or something. It's still worth mention as it saves valuable time. It's not as though 3 - 4 more lines in the libtool22 section of /usr/ports/UPDATING would hurt... -- Matthias Andree on 21/08/2009 15:28 Jeremy Messenger said the following:
> On Fri, 21 Aug 2009 07:16:57 -0500, Matthias Andree
> <matthias.andree@gmx.de> wrote:
>
>> Same for me, on i386. Removing the listed leftover libtool15/libltdl15
>> files/directories let the devel/apr build succeed, where it would fail
>> before.
>>
>> Given that the devel/libtool15 port is gone:
>>
>> 1. Can we have a pkg-install script that purges the obsolete libtool15
>> stuff (as listed, but substituting ${PKG_PREFIX} for /usr/local) post
>> a successful libtool22 install? Apparently the older pkg-plist were
>> incomplete, so that libtool15 didn't get completely removed on
>> uninstall, and a libtool22/libltdl22 post-installation cleanup of
>> libtool15 seems the natural way to solve.
>
> No need to, the /usr/local/bin/libtool15 wasn't in libtool15 for over
> three yeaers. It looks like you use FORCE_PKG_REGISTER that force
> overwrite and that libtool15 was never remove correct.
Maybe it looks so, but it is not so.
I never used FORCE_PKG_REGISTER and I performed
portupgrade -o devel/libtool22 libtool-1.5\*
portupgrade -o devel/libltdl22 libltdl-1.5\*
exactly as UPDATING suggested.
The date on the offending files was 26 Dec 2005.
This system is quite old and was continuously incrementally updated, so the files
must have been installed by some older version of libtool and never properly
cleaned up.
--
Andriy Gapon
Similar file dates here. It's futile tracing this, but from two independently maintained systems showing this behaviour: at some point in time the pkg-plist may have been wrong so that the bin/libtool15 file got installed without being recorded, and so it didn't get properly uninstalled. Why can't we just deal with this rather than raise objections until the death of the project? What's so fundamentally wrong about cleaning these files? If that is unacceptable (POLA violation), we could at least check for their existence and print a warning that these may need to be cleaned manually, and include instructions to check and possibly remove these files to UPDATING. Please. The devel/apr non-buildability was/is a critical issue, as it stops the port-based security update of subversion on affected systems. This isn't your random unmaintained crap port, but mainstream software... -- Matthias Andree Andriy Gapon wrote: > on 21/08/2009 15:28 Jeremy Messenger said the following: > >> On Fri, 21 Aug 2009 07:16:57 -0500, Matthias Andree >> <matthias.andree@gmx.de> wrote: >> >> >>> Same for me, on i386. Removing the listed leftover libtool15/libltdl15 >>> files/directories let the devel/apr build succeed, where it would fail >>> before. >>> >>> Given that the devel/libtool15 port is gone: >>> >>> 1. Can we have a pkg-install script that purges the obsolete libtool15 >>> stuff (as listed, but substituting ${PKG_PREFIX} for /usr/local) post >>> a successful libtool22 install? Apparently the older pkg-plist were >>> incomplete, so that libtool15 didn't get completely removed on >>> uninstall, and a libtool22/libltdl22 post-installation cleanup of >>> libtool15 seems the natural way to solve. >>> >> No need to, the /usr/local/bin/libtool15 wasn't in libtool15 for over >> three yeaers. It looks like you use FORCE_PKG_REGISTER that force >> overwrite and that libtool15 was never remove correct. >> > > Maybe it looks so, but it is not so. > I never used FORCE_PKG_REGISTER and I performed > portupgrade -o devel/libtool22 libtool-1.5\* > portupgrade -o devel/libltdl22 libltdl-1.5\* > exactly as UPDATING suggested. > > The date on the offending files was 26 Dec 2005. > This system is quite old and was continuously incrementally updated, so the files > must have been installed by some older version of libtool and never properly > cleaned up. > > > This bug was filed by me originally and I also never used FORCE_PKG_REGISTER. I think putting a blurb in UPDATING as well as fixing the installer would be good. I was lucky that the person who gave me this answer read the bug because I was stumped as to why the apr install was failing. State Changed From-To: open->closed I've builit with over 20 permutations in over 50 tb builds I've got these stale file/directories laying around as well. My system has= been updated since 4.x though, so I'm always battling cruft. The interest= ing thing is that my file dates were from Nov 10 2005. Since I do a forced= rebuild of everything on every release, this means that it was lost to the= +CONTENTS during the Great Rebuild of 6.0-RELEASE. =20 The main reason I'm following up though is that all of the files from the o= ld pkg-plist are still around on my system... (refer to here http://www.fre= ebsd.org/cgi/cvsweb.cgi/ports/devel/libtool15/Attic/pkg-plist?rev=3D1.12;co= ntent-type=3Dtext%2Fplain) =20 So, you also want to delete /usr/local/libexec/libtool15/, /usr/local/share= /aclocal/libtool15.m4, and share/aclocal/ltdl15.m4 =20 Apparently, I had ran into problems with the aclocal files before, and I re= named them to .old, but they were still there. =20 Stephen Hurd Senior Engineering Technician 3 Broadcom Corporation 949-926-8039 shurd@broadcom.com=20 |
Cannot compile devel/apr. I run into the following error. I'm also pasting the 9750-9759 lines from /usr/local/shar/libtool/libltdl/configure below the output of build failure. /usr/ports/devel/apr# make ===> apr-gdbm-db42-1.3.8.1.3.9 depends on file: /usr/local/bin/python2.6 - found ===> apr-gdbm-db42-1.3.8.1.3.9 depends on file: /usr/local/bin/perl5.8.9 - found ===> apr-gdbm-db42-1.3.8.1.3.9 depends on file: /usr/local/bin/automake-1.9 - found ===> apr-gdbm-db42-1.3.8.1.3.9 depends on file: /usr/local/bin/autoconf-2.62 - found ===> apr-gdbm-db42-1.3.8.1.3.9 depends on file: /usr/local/bin/libtool - found ===> apr-gdbm-db42-1.3.8.1.3.9 depends on shared library: expat.6 - found ===> apr-gdbm-db42-1.3.8.1.3.9 depends on shared library: gdbm.3 - found ===> apr-gdbm-db42-1.3.8.1.3.9 depends on shared library: iconv.3 - found ===> apr-gdbm-db42-1.3.8.1.3.9 depends on shared library: db-4.2.2 - found ===> Configuring for apr-gdbm-db42-1.3.8.1.3.9 cd /usr/ports/devel/apr/work/apr-1.3.8 ; /usr/bin/env CC="cc" CFLAGS="-O2 -fno-strict-aliasing -pipe" PYTHON="/usr/local/bin/python2.6" SHELL=/bin/sh CONFIG_SHELL=/bin/sh ACLOCAL=/usr/local/bin/aclocal-1.9 AUTOMAKE=/usr/local/bin/automake-1.9 AUTOMAKE_VERSION=19 AUTOCONF=/usr/local/bin/autoconf-2.62 AUTOHEADER=/usr/local/bin/autoheader-2.62 AUTOIFNAMES=/usr/local/bin/ifnames-2.62 AUTOM4TE=/usr/local/bin/autom4te-2.62 AUTORECONF=/usr/local/bin/autoreconf-2.62 AUTOSCAN=/usr/local/bin/autoscan-2.62 AUTOUPDATE=/usr/local/bin/autoupdate-2.62 AUTOCONF_VERSION=262 LIBTOOL=/usr/local/bin/libtool LIBTOOLIZE=/usr/local/bin/libtoolize LIBTOOL_M4=/usr/local/share/aclocal/libtool.m4 lt_cv_sys_max_cmd_len=262144 /bin/sh ./buildconf buildconf: checking installation... buildconf: python version 2.6.2 (ok) buildconf: autoconf version 2.62 (ok) buildconf: libtool version 2.2.6 (ok) Copying libtool helper files ... buildconf: Using libtool.m4 at /usr/local/share/aclocal/libtool.m4. Creating include/arch/unix/apr_private.h.in ... configure.in:190: warning: LTOPTIONS_VERSION is m4_require'd but not m4_defun'd build/libtool.m4:67: LT_INIT is expanded from... build/libtool.m4:102: AC_PROG_LIBTOOL is expanded from... configure.in:190: the top level configure.in:190: warning: LTSUGAR_VERSION is m4_require'd but not m4_defun'd configure.in:190: warning: LTVERSION_VERSION is m4_require'd but not m4_defun'd configure.in:190: warning: LTOBSOLETE_VERSION is m4_require'd but not m4_defun'd Creating configure ... configure.in:190: warning: LTOPTIONS_VERSION is m4_require'd but not m4_defun'd build/libtool.m4:67: LT_INIT is expanded from... build/libtool.m4:102: AC_PROG_LIBTOOL is expanded from... configure.in:190: the top level configure.in:190: warning: LTSUGAR_VERSION is m4_require'd but not m4_defun'd configure.in:190: warning: LTVERSION_VERSION is m4_require'd but not m4_defun'd configure.in:190: warning: LTOBSOLETE_VERSION is m4_require'd but not m4_defun'd configure:9755: error: possibly undefined macro: m4_ifval If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure:12392: error: possibly undefined macro: _LT_SET_OPTIONS configure:12392: error: possibly undefined macro: LT_INIT Generating 'make' outputs ... rebuilding rpm spec file cd /usr/ports/devel/apr/work/apr-util-1.3.9 ; /bin/rm -fr xml/expat cd /usr/ports/devel/apr/work/apr-util-1.3.9 ; /usr/bin/env CC="cc" CFLAGS="-O2 -fno-strict-aliasing -pipe" PYTHON="/usr/local/bin/python2.6" SHELL=/bin/sh CONFIG_SHELL=/bin/sh ACLOCAL=/usr/local/bin/aclocal-1.9 AUTOMAKE=/usr/local/bin/automake-1.9 AUTOMAKE_VERSION=19 AUTOCONF=/usr/local/bin/autoconf-2.62 AUTOHEADER=/usr/local/bin/autoheader-2.62 AUTOIFNAMES=/usr/local/bin/ifnames-2.62 AUTOM4TE=/usr/local/bin/autom4te-2.62 AUTORECONF=/usr/local/bin/autoreconf-2.62 AUTOSCAN=/usr/local/bin/autoscan-2.62 AUTOUPDATE=/usr/local/bin/autoupdate-2.62 AUTOCONF_VERSION=262 LIBTOOL=/usr/local/bin/libtool LIBTOOLIZE=/usr/local/bin/libtoolize LIBTOOL_M4=/usr/local/share/aclocal/libtool.m4 lt_cv_sys_max_cmd_len=262144 /bin/sh ./buildconf --with-apr=/usr/ports/devel/apr/work/apr-1.3.8 Looking for apr source in /usr/ports/devel/apr/work/apr-1.3.8 Creating include/private/apu_config.h ... Creating configure ... Generating 'make' outputs ... rebuilding rpm spec file cd /usr/ports/devel/apr/work/apr-1.3.8; /usr/bin/env CC="cc" CFLAGS="-O2 -fno-strict-aliasing -pipe" PYTHON="/usr/local/bin/python2.6" SHELL=/bin/sh CONFIG_SHELL=/bin/sh ACLOCAL=/usr/local/bin/aclocal-1.9 AUTOMAKE=/usr/local/bin/automake-1.9 AUTOMAKE_VERSION=19 AUTOCONF=/usr/local/bin/autoconf-2.62 AUTOHEADER=/usr/local/bin/autoheader-2.62 AUTOIFNAMES=/usr/local/bin/ifnames-2.62 AUTOM4TE=/usr/local/bin/autom4te-2.62 AUTORECONF=/usr/local/bin/autoreconf-2.62 AUTOSCAN=/usr/local/bin/autoscan-2.62 AUTOUPDATE=/usr/local/bin/autoupdate-2.62 AUTOCONF_VERSION=262 LIBTOOL=/usr/local/bin/libtool LIBTOOLIZE=/usr/local/bin/libtoolize LIBTOOL_M4=/usr/local/share/aclocal/libtool.m4 lt_cv_sys_max_cmd_len=262144 /bin/sh ./configure --prefix=/usr/local ${_LATE_CONFIGURE_ARGS} --with-installbuilddir=/usr/local/share/apr/build-1 --enable-threads --disable-ipv6 checking build system type... x86_64-unknown-freebsd7.2 checking host system type... x86_64-unknown-freebsd7.2 checking target system type... x86_64-unknown-freebsd7.2 Configuring APR library Platform: x86_64-unknown-freebsd7.2 checking for working mkdir -p... yes APR Version: 1.3.8 checking for chosen layout... apr checking for gcc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed Applying APR hints file rules for x86_64-unknown-freebsd7.2 setting apr_lock_method to "USE_FLOCK_SERIALIZE" (Default will be unix) checking whether make sets $(MAKE)... yes checking how to run the C preprocessor... cc -E checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether ln -s works... yes checking for ranlib... ranlib checking for a BSD-compatible install... /usr/bin/install -c checking for rm... rm checking for as... as checking for cpp... cpp checking for ar... ar checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for library containing strerror... none required checking whether system uses EBCDIC... no performing libtool configuration... ./configure: 9753: Syntax error: word unexpected (expecting ")") *** Error code 2 Stop in /usr/ports/devel/apr. *** Error code 1 Stop in /usr/ports/devel/apr. The following output are the lines 9750-9766 from: /usr/local/share/libtool/libltdl/configure 9750 # AIX (on Power*) has no versioning support, so currently we can not hardcode correct 9751 # soname into executable. Probably we can add versioning support to 9752 # collect2, so additional links can be useful in future. 9753 if test "$aix_use_runtimelinking" = yes; then 9754 # If using run time linking (on AIX 4.2 or later) use lib<name>.so 9755 # instead of lib<name>.a to let people know that these are not 9756 # typical AIX shared libraries. 9757 library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $li bname${shared_ext}' 9758 else 9759 # We preserve .a as extension for shared libraries through AIX4.2 9760 # and later when we are not doing run time linking. 9761 library_names_spec='${libname}${release}.a $libname.a' 9762 soname_spec='${libname}${release}${shared_ext}$major' 9763 fi 9764 shlibpath_var=LIBPATH 9765 fi 9766 ;; How-To-Repeat: just going into /usr/ports/devel/apr and type make