You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "Wesley W. Garland" <we...@page.ca> on 2006/04/19 16:29:00 UTC

UUID requirements for APR 1.2.? increase SunOS version dependency

Hey, All;

I did a quick search of my APR mail folder and didn't see this issue
discussed explicitly, so I thought I should document my findings in case it
impacts someone else in the future, and/or the APR considers
Solaris-without-bleeding-edge-patches-support important.

I tried to build apr-1.2.7 this morning on a SunOS 5.8 Generic_108528-15
sun4u sparc machine.  The previous APR built on that machine was apr-1.0.1,
which built cleanly.

Here is (roughly) my configuration command for both versions:

CFLAGS="-g -O0 -mcpu=ultrasparc -mtune=ultrasparc -m32"
export CFLAGS

./configure \
--with-devrandom=/dev/random --with-pic --enable-threads
--enable-nonportable-atomics --enable-static \
--enable-shared --enable-dso=dlfcn --enable-debug

This failed to build due to a missing header file -- uuid/uuid.h -- when
building rand.c.

Upon further investigation, it appears that uuid functionality did not ship
with the original Solaris 8 or 9 releases (although it is entirely possible
it's now shipping with 8 and it's default shipping with later versions of 9
[checked an unpatched SunOS 5.9 Generic_118559-1 i386 i86pc box; Sep/05
release IIRC].

It seems Sun has issued BugID 4622990: "Solaris should provide a complete
UUID mechanism" to provide the functionality APR is looking for. This is
addressed in several patches (thank you, Sun Solve) -- the base patches seem
to have been aggregated into support for multi-terabyte disk support and
what have you.

Adding patch #115831-01 solved my problem under Solaris 8. This patch did
not require a reboot.
Patch #115832-01 is listed as the equivalent under Solaris 8 x86.

These patches provide uuid/uuid.h, which includes sys/uuid.h (for types), as
well as libuuid.so.1.

The best way to add this support under Solaris 9 (sparc) appears to be patch
ID 114129-??. -01 is marked OBSOLETE, and -02 is marked "Install in single
user mode; reboot after install".  This means that if you want to follow
Sun's directions for patch installation, you must either install an obsolete
patch, or reboot your box in order to build APR 1.2.x or run applications
using APR 1.2.x's UUID mechanisms.

An alternative for the desperate SunOS 5.9 sysadmin may be to install
114129-02 (if he does not already have 114129-01) and ignore Sun's caution
to install in single user mode and reboot after install. I suspect the
reason for the caution is that when -01 is loaded, sd and other drivers may
use it, and they don't want two versions of the DSO floating around in a
running box -- I can certainly a possibility of a kernel panic in any driver
paging in/out the UUID DSO and finding different code than it expected...

Is there an option I have missed?  Is there a possibility of rolling the
apr-util uuid code into apr itself, to avoid operating system version
dependencies?   Having to potentially reboot a SunOS 5.9 box to install a
"portable runtime" seems like it may be problematic down the road,
particularly if Apache httpd decides to kick up to apr-1.

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

Re: UUID requirements for APR 1.2.? increase SunOS version dependency

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Wesley W. Garland wrote:
> Hey, All;
> 
> I did a quick search of my APR mail folder and didn't see this issue 
> discussed explicitly

Wes, thanks for your report... in this case you also want to trawl through
http://issues.apache.org/bugzilla/ ... apr library product, apr component,
and look for uuid reports.

There's something *very* odd about your machine.  APR 1.2.7 does exactly the
autodetection you asked for about sendfile and uuid.  I'd be very interested
in seeing your config.log results of your configure command.  (You can spare
the list the extra bandwidth and direct that to me).  With uuid, it actually
forces a test compile/link - right down to including the appropriate header
files.  I presume you reconfigured/reinstalled apr-util after configuring & 
installing apr, first?  Also, you built in a clean directory, and didn't try
to unpack apr 1.2.7 on top of an older release?