Wine dependency on attr/xattr.h is automagic

[James Le Cuirot]

It is important for distribution package managers to be able to produce consistent builds. Automagic dependencies that create different builds depending on the presence of certain files are an obstacle to this. They are also problematic for end-users of source-based distributions like Gentoo, though it's not so bad in this particular case because the dependency is solely on a header file and not on a library. In any case, here is a patch that adds a --with-xattr configure option to Wine. Apply this on top of the existing patches but you'll probably want to merge it into 0005 before submitting the change upstream.

[James Le Cuirot (chewi)]

Here's an updated patch against 1.7.4.

[Erich E. Hoover (ehoover)]

I'm sorry I ignored this bug for so long, I intended to reply to this and forgot to do it. I've merged this into the branch we're using to prepare for the next Wine release, so this should be fixed moving forward.

[Sebastian Lackner (slackner)]

Hi,

I'll just reopen this bug report since I think that the patch has not really the desired effect.

The original intention was to allow forcing XATTR, but if I understand the code correctly, it still doesn't abort when the XATTR header files are not present.

Could someone please confirm this? I'm not an autoconf expert, but the patch looks suspicious. This would probably also explain why some people still have the problems that XATTR is not included, like for example here:
https://bbs.archlinux.org/viewtopic.php?pid=1365948#p1365948

Sebastian

[Erich E. Hoover (ehoover)]

Hi Sebastian,

You are correct, if you want to force it to fail then it needs to be something like:
===
if test "x$with_xattr" != "xno"
then
  AC_CHECK_HEADERS(attr/xattr.h,,
    AC_MSG_ERROR([Extended file system attribute header file not found.])
  )
fi
===

Would you like me to add this?

[Sebastian Lackner (slackner)]

Hi,

I think something like this should definitely make it easier to figure out when something goes wrong.

Probably some error message like this would be more useful though:
AC_MSG_ERROR([XATTR will not be supported. Use --without-xattr if you don't need XATTR support.])

The only remaining question: Why does the detection not work sometimes / on some systems? Does attr/xattr.h expect some other headers to be included first? Or is it really random?

Sebastian

[James Le Cuirot (chewi)]

There is no strict rule about whether you should abort on failure when the feature is explicitly requested. Autoconf's AC_CHECK macros don't abort by default but pkg-config's PKG_CHECK_MODULES macro does. Many projects simply rely on the default behaviour. Other projects find aborting on failure to be more intuitive. I'm inclined to agree but I didn't apply that thinking here because Wine appears to have preferred the defaults. It is important to respect such decisions for the sake of consistency if nothing else.

Also, this behaviour generally isn't a problem for software installed through distribution package managers because the package manager will ensure that attr/xattr.h is present before configure is even run. The "automagic" problem I referred to above is different. It is important to be able to disable XATTR support even if attr/xattr.h is present.

I'm not sure about your last question. These macros are quite reliable. Sometimes configure will report that a header can be found but not used or vice-versa if the flags have gone a bit screwy but this shouldn't happen under regular circumstances. If you really did apply the patches properly and had attr/xattr.h present when you built Wine then only config.log will reveal why the feature was not enabled.

[Erich E. Hoover (ehoover)]

Ok guys, the latest version of wine-compholio (1.7.13) does what you want - just call configure with "--with-xattr" to explicitly require extended attributes. Without the flag configure will use the old behavior (it will succeed without xattr support), so it's important to set that flag if you want to make sure configure fails if xattr support is unavailable.