Well one mystery is solved. Folks experiencing build breakage likely have
installed python2.4, which deposits libuuid into /usr/local/lib, without
any corresponding header file.
We have only one election to use osuuid, and that is a bogus test for the lib.
The proper test must check that the uuid_t resolves, and generate_uuid can be
invoked without compile warnings, no matter if it is declared in uuid.h,
uuid/uuid.h, or somewhere in the bowels of unistd.h or other common system
header files.
Throwing the yes/no flag on the linkability of generate_uuid against -luuid
or the clib is pretty broken behavior.
Bill
Garrett Rooney wrote:
On 2/14/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
Garrett Rooney wrote:
On 11/2/05, Craig Rodrigues <[EMAIL PROTECTED]> wrote:
Hi,
I maintain the port of APR for the FreeBSD ports system.
I was assigned the following bug:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/88406
If e2fsprogs is installed on a FreeBSD 5.4 system,
compilation of APR fails, because types conflict
if <uuid.h> (from the system) and <uuid/uuid.h> (from e2fsprogs) are
both included.
<uuid.h> is a relatively recent addition to FreeBSD and
was added in the FreeBSD 5.x timeframe.
Is this patch acceptable for apr?
Looks good to me, committed in r355780.
Sorry for the delay, this has been sitting in my inbox forever and I
just got a chance to try it out.
Could this commit be the origin of breakage on Macintosh OS/X? Both 1.2.x
and trunk fail to compile on Darwin7.9.0 kernel at this moment.
AFAIK this patch was never merged into 1.2.x, so if you're having
trouble building 1.2.x it's probably something else.
-garrett
