APR has been split out of Apache. net-www/apache-2.0.52-r3 (currently hardmasked) depends on dev-libs/apr-0.9.5 and dev-libs/apr-util-0.9.5. Apache currently has the keywords: ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sparc ~x86 apr and apr-util has keywords: ~x86 Archs, please test apr and apr-util. Thanks!
~sparc'd
Added ~ppc64 to KEYWORDS.
Stamped ~hppa.
AMD64 Arch Tester piolyte tested: dev-libs/apr-0.9.5 dev-libs/apr-util-0.9.5 net-www/apache-2.0.52-r3 And is happy that they install and work.
~amd64'd
ppc done.
We will be unmasking (hopefully) on Feb 12. Please KEYWORD before then. Any archs that haven't done this will have to be dropped from apache-2.0. Thanks!
~alpha keyworded.
Our unmask date was pushed forward slightly and we're now hoping to unleash our stuff this saturday (26th). arm, mips and s390 devs, please test and mark apr-0.9.5 and apr-util-0.9.5 testing. Thanks.
It's time to unmask, so we are removing the following KEYWORDS from Apache-2.0.52-r3: ~arm ~mips ~s390 Please feel free to fix apr and apr-util and then re-add the keywords to apache. Thanks!
If you insist on removing keywords, please make sure doing so doesn't break the tree before you commit anything.
This removal is to avoid breaking the tree by keeping said archs at a lower revision of apache until they are able to test apr and apr-util at which time they can re-add thier arch to the latest apache. Note that the latest apache and apr and apr-util are all currently package.mask-ed but will be shortly going into ~arch, that's why this is necessary.
I have an issue with apr and apr-util. During compilation of apr-util it uses the libtool (/usr/share/apr-0/build/libtool) installed by apr. libtool uses lockfiles and it creates the lockfiles by creating hardlinks of itself. But if the user keeps /usr and /var/tmp in separate filesystem the linking fails and libtool goes into an endless loop trying to create the link over and over again. Code from apr's libtool: > # Calculate the filename of the output object if compiler does > # not support -o with -c > if test "$compiler_c_o" = no; then > output_obj=`$echo "X$srcfile" | $Xsed -e 's%^.*/%%' -e 's%\.[^.]*$%%'`.${objext} > lockfile="$output_obj.lock" > removelist="$removelist $output_obj $lockfile" > trap "$run $rm $removelist; exit $EXIT_FAILURE" 1 2 15 > else > output_obj= > need_locks=no > lockfile= > fi > > # Lock this critical section if it is needed > # We use this script file to make the link, it avoids creating a new file > if test "$need_locks" = yes; then > until $run ln "$progpath" "$lockfile" 2>/dev/null; do > $show "Waiting for $lockfile to be removed" > sleep 2 > done > elif test "$need_locks" = warn; then need_locks is yes by default and set to no if compiler_c_o (compiler supports -c and -o at the same time) is yes, which is set to no at the top of the file. gcc supports -c and -o at the same time, I wonder why it's set to no.
I had the same problem reported by Sven. When PORTAGE_TMPDIR from make.conf points to a different partition than the one where /usr/share/apr-0/build/libtool resides then the hardlink will fail resulting in an infinite loop.
It's -Wl,-O1 in my CFLAGS that's causing libtool to think gcc doesn't support -c and -o at the same time. gcc prints a warning when using -c compiling with -Wl flags active and it gets recognized as an error by apr.
from the configure script portion that check -c -o arguments support: # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings
can we go off the test-request phase and mark it fixed? or do we still have some outstanding issues on this bug?
This bug can be closed when archs that were originally CCed remove themselves from it, indicating that they have addressed the issue. As it doesn't affect whether we move to stable on x86, there is no harm in leaving this bug open as a reminder to them. Though reviewing the comments, it looks like there may be some issues on these archs.
This needs to remain open until the issues brought up by Sven are fixed too. Apparently, an "elibtoolize" in the ebuild will fix it, but I have been two snowed under to make the change and test it on an older gcc. If someone wants to do this before I can, you'll want to read through the patches in gentoo-x86/eclass/ET-patches to double check that an elibtoolize won't break binary compatability. You'll also need a setup where /usr and /var are on different filesystems, too.
I have the same problem that Sven has. If you need a system where /usr and /var are on different partitions on which to test a fix, I have one, and am willing to help squash this bug...
I've just added an elibtoolize call to apr-0.9.5-r2 and apr-0.9.6-r2 (currently in package.mask) which I hear will fix this issue. I don't have an older gcc that causes this libtool bug, so if those that have been affected by this could unmask "dev-libs/apr" in /etc/portage/package.unmask and re-emerge and see if this fixes it, it'd be much appreciated. :)
Doesn't fix the issue. /usr/share/apr-0/build/libtool still contains: # Does compiler simultaneously support -c and -o options? compiler_c_o="no" And /usr/share/apr-0/build/libtool tries to hardlink itself into the build root when building apr-util.
Any word on apr-util getting fixed yet? all ~x86 systems I run are still breaking on this package. http://forums.gentoo.org/viewtopic-t-303851-highlight-aprutil.html Describes the symptoms. The ebuild "freezes" at this line: ########## /bin/sh /usr/share/apr-0/build/libtool --silent --mode=compile i686-pc-linux-gnu -gcc -pthread -O2 -mcpu=i686 -fomit-frame-pointer -D_FILE_OFFSET_BITS=64 -D_LAR GEFILE_SOURCE -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_XO PEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I/var/tmp/portage/a pr-util-0.9.6/work/apr-util-0.9.6/include -I/var/tmp/portage/apr-util-0.9.6/work /apr-util-0.9.6/include/private -I/usr/include/apr-0 -c apr_buckets_pool.c && touch apr_buckets_pool.lo I have /var and /usr on different partitions...but each is a similar filesystem (ext3). Cheers, -Chris
I'm still having the same problem merging apr-util-0.9.6-r1 with libtool from apr-0.9.6-r2. Maybe this is not a complete fix but at least I am able to emerge apr-util if I simply substitute a symlink for a hardlink: --- /usr/share/apr-0/build/libtool.orig 2005-04-14 15:05:45.000000000 -0700 +++ /usr/share/apr-0/build/libtool 2005-04-14 15:07:11.000000000 -0700 @@ -1161,7 +1161,7 @@ # Lock this critical section if it is needed # We use this script file to make the link, it avoids creating a new file if test "$need_locks" = yes; then - until $run ln "$progpath" "$lockfile" 2>/dev/null; do + until $run ln -s "$progpath" "$lockfile" 2>/dev/null; do $show "Waiting for $lockfile to be removed" sleep 2 done
Same here. Emerge seems to hang on this (apr-util-0.9.6-r1): /bin/sh /usr/share/apr-0/build/libtool --silent --mode=compile i686-pc-linux-gnu-gcc -pthread -march=pentium4 -pipe -Os -mcpu=i686 -fomit-frame-pointer -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I/var/tmp/portage/apr-util-0.9.6-r1/work/apr-util-0.9.6/include -I/var/tmp/portage/apr-util-0.9.6-r1/work/apr-util-0.9.6/include/private -I/usr/include/apr-0 -c apr_buckets_pool.c && touch apr_buckets_pool.lo Output from emerge --info: ortage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.4.20050125-r1, 2.6.9-gentoo-r1 i686) ================================================================= System uname: 2.6.9-gentoo-r1 i686 Intel(R) Pentium(R) 4 CPU 2.53GHz Gentoo Base System version 1.6.10 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Apr 18 2005, 15:41:03)] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -pipe -Os -mcpu=i686 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -pipe -Os -mcpu=i686 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.easynet.nl/mirror/gentoo/ http://gentoo.mirror.sdv.fr http://gentoo.tiscali.nl/gentoo/ ftp://ftp.solnet.ch/mirror/Gentoo" LANG="en_US.utf8" LC_ALL="en_US.utf8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 alsa apache2 apm bash-completion berkdb bitmap-fonts crypt cups emboss encode foomaticdb fortran gdbm gif gpm hardened imlib ipv6 jpeg libg++ libwww mad mikmod motif mp3 mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png python readline sasl sdl slang spell ssl svga tcpd truetype truetype-fonts type1-fonts unicode xml2 xmms xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Ouch, so sorry this has been neglected. This will be fixed later on today, one way or another.
arm/s390 are done
FWIW, I applied the patch as suggested in comment #24 and that worked for me.
Confirmed. I did use that patch (which I had to make the change by hand because of a strange error) and it did work for me. :-D
sorry...
were ready to go stable -> stable request is bug 105516
