Open GoogleCodeExporter opened 8 years ago
If someone with 10.5 can test or look into this, that'd be great. I do not
currently
have access to 10.5.
Original comment by bbraun
on 14 Dec 2007 at 1:59
It looks like the configure script fails to set HAVE_SYS_ACL_H. Running
"locate acl.h" on my system gives me
/usr/include/sys/acl.h
(Note: I'm actually relaying this bug report from a backup-bouncer user so I'm
not doing the digging myself. I
have, however, verified the report myself.)
Original comment by n8gray@gmail.com
on 14 Dec 2007 at 7:29
Great, that's something to go on.
The sys/acl.h detection is a little odd because it tries to verify a working
acl_t as
well. Here is the autoconf test currently used:
AC_TRY_COMPILE([#include <sys/types.h> #include <sys/acl.h>], [acl_t a],
[AC_DEFINE([HAVE_SYS_ACL_H],[1], [define if you have sys/acl.h and it has a
working
acl_t type])])
Original comment by bbraun
on 14 Dec 2007 at 8:07
I believe the problem is in the configure test and no newline between #include
<sys/types.h> and #include <sys/acl.h>. A newline has been inserted and
checked into
subversion. If you (or the backup-bouncer user) could give it another shot,
that'd
be great.
Original comment by bbraun
on 14 Dec 2007 at 8:33
Ok, looking at config.log it appears that your test is trying to link to -lacl,
but in Leopard there is no libacl. The
acl man page indicates that the acl functions are part of libc.
Original comment by n8gray@gmail.com
on 14 Dec 2007 at 8:55
That's fine, it just won't use -lacl on osx. That's expected and not erroneous.
Original comment by bbraun
on 14 Dec 2007 at 8:59
Ok, well here's the output:
configure:7577: checking for acl_get_file in -lacl
configure:7612: gcc -o conftest -Wall -g conftest.c -lacl >&5
ld: library not found for -lacl
collect2: ld returned 1 exit status
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "Xar"
| #define PACKAGE_TARNAME "xar"
...
| #define DEV_CAST (uint32_t)
| /* end confdefs.h. */
|
| /* Override any GCC internal prototype to avoid an error.
| Use char because int might match the return type of a GCC
| builtin and then its argument prototype would still apply. */
| #ifdef __cplusplus
| extern "C"
| #endif
| char acl_get_file ();
| int
| main ()
| {
| return acl_get_file ();
| ;
| return 0;
| }
And here's the relevant declaration in acl.h:
extern acl_t acl_get_file(const char *path_p, acl_type_t type);
Original comment by n8gray@gmail.com
on 14 Dec 2007 at 9:13
That should be fine. If the -lacl test fails, it's not a big deal.
Are you testing with r201 from subversion? I committed that configure.ac
change earlier.
Original comment by bbraun
on 14 Dec 2007 at 9:27
Yes, I'm testing 201. I did an svn up followed by autogen.sh and configure.
Is there something else I need to
do?
Original comment by n8gray@gmail.com
on 14 Dec 2007 at 9:57
That should detect sys/acl.h and define HAVE_SYS_ACL_H in include/config.h,
which
will address the initial problem of sys/acl.h detection.
Original comment by bbraun
on 14 Dec 2007 at 10:24
OK, looks like you're right and the issue is fixed. Thanks!
Original comment by n8gray@gmail.com
on 20 Dec 2007 at 2:41
Original issue reported on code.google.com by
n8gray@gmail.com
on 14 Dec 2007 at 12:58