Bugzilla Bug 77455

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