unix-compat does not build because of strangeness in GHC's header files.

[rtvd]

I have build 7.0.3 from source and then tried building unix-compat library. The library failed to build because it could not find libutil.h.

Digging a bit deeper I found the following:

unix-compat includes among other things header files from GHC.

./libraries/unix/include/HsUnixConfig.h has this in it:

  /* Define to 1 if you have the <libutil.h> header file. */
  #define HAVE_LIBUTIL_H 0

However, ./libraries/unix/include/HsUnix.h has this:

  #ifdef HAVE_LIBUTIL_H
  #include <libutil.h>
  #endif

Naturally, it has tried to include the non-existing libutil.h. Even though HAVE_LIBUTIL_H is zero, it is still considered to be defined.

After removing this line:

  #define HAVE_LIBUTIL_H 0

unix-compat has been successfully built.

[simonmar]

I don't understand how you ended up with

  #define HAVE_LIBUTIL_H 0

Normally when a header file does not exist, autoconf generates a line that looks like

/* Define to 1 if you have the <wibble.h> header file. */
/* #undef HAVE_WIBBLE_H */

(I just tested this by adding a new header file test to configure.ac, as you can see).

Where did you get your GHC distribution, and what platform is this?

[rtvd]

My bad. Sorry. It is not reproducible any more on my PC. I should have filed this ticket while I still remembered everything clearly.

However:

1. if I build 7.0.3 from sources the header file does not have #define LIBUTIL_H . This is good.

2. but if I download 7.0.3 binary for Linux on x64 from here

http://www.haskell.org/ghc/download_ghc_7_0_3#x86_64linux

the header file has this

/* Define to 1 if you have the <libutil.h> header file. */ #define HAVE_LIBUTIL_H 1

Perhaps the release has been built on a Linux where libutil.h was present. And on mine (Ubuntu 10.04.2) this header file is absent.

[igloo]

To use a bindist your system needs to be "similar enough" to the system that built it.

Ubuntu probably has a libbsd-dev package including libutil.h.

[simonmar]

I think unix-compat should not need to #include "HsUnix.h", removing that would also fix the problem.

[byorgey]

Just as a point of reference for anyone finding this ticket after running into this issue, I also ran into this problem (sadly, it seems arch linux does not even have any packages providing libutil.h). Unfortunately, removing the #include "HsUnix.h" from include/HsUnixCompat.h gets me past the initial configuration stage but now I get a different error:

src/System/PosixCompat/Files.hsc:54:5:
    Ambiguous occurrence `setSymbolicLinkOwnerAndGroup'
    It could refer to either `System.PosixCompat.Files.setSymbolicLinkOwnerAndGroup',
                             defined at src/System/PosixCompat/Files.hsc:75:1
                          or `System.Posix.Files.setSymbolicLinkOwnerAndGroup',
                             imported from System.Posix.Files at src/System/PosixCompat/Files.hsc:69:1-25

One workaround that worked for me (although obviously not ideal) is to force the "portable" version of unix-compat with cabal install -fportable unix-compat.

[jystic]

I have uploaded a new version of unix-compat (0.2.1.2) to Hackage which does not include HsUnix.h.

Given the new information from byorgey though, there is still some issues.

The decision about whether setSymbolicLinkOwnerAndGroup is required is made in HsUnixCompat.h:

#define NEED_setSymbolicLinkOwnerAndGroup !HAVE_LCHOWN

And in the unix package, the decision is made like so:

#if HAVE_LCHOWN
    setSymbolicLinkOwnerAndGroup,
#endif

So definitely something strange going on, I wonder what HAVE_LCHOWN is defined as (or not defined as)

[jystic]

My 0.2.1.2 upload was a bit premature, I must have forgotten to cabal clean before I checked that everything still built properly. After doing a clean I get the same error as byorgey because HAVE_LCHOWN is not defined. It used to get included indirectly, HsUnix.h includes HsUnixConfig.h.

I have uploaded 0.2.1.3 which includes HsUnixConfig.h instead of HsUnix.h because HAVE_LCHOWN is the only thing required from the unix include files.

Unfortunately, this does not fix the original problem. HsUnixConfig.h really just needs to match the system configuration, that's the whole point.

[byorgey]

unix-compat-0.2.1.3 installs cleanly for me, thanks for the updated version.

[simonmar]

Replying to jystic:

Unfortunately, this does not fix the original problem. HsUnixConfig.h really just needs to match the system configuration, that's the whole point.

The right fix is to have a configure.ac for unix-compat and test the property at compile-time. Perhaps that would be a problem for Windows users though?

[jystic]

Replying to simonmar:

Replying to jystic:

Unfortunately, this does not fix the original problem. HsUnixConfig.h really just needs to match the system configuration, that's the whole point.

The right fix is to have a configure.ac for unix-compat and test the property at compile-time. Perhaps that would be a problem for Windows users though?

Can you describe how I would set that up? HsUnixCompat.h isn't used by the Windows compilation. If configure.ac could be executed conditionally or if we just ignored the result that would be fine.