New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem with fdatasync when cross compiling to aarch64 on Mac OS X #37
Comments
I'm not sure what we can do here. We use AC_CHECK_FUNCS([getgrgid_r getgrnam_r getpwnam_r getpwuid_r getpwnam getpwuid])
AC_CHECK_FUNCS([getpwent getgrent])
AC_CHECK_FUNCS([lchown setenv sysconf unsetenv clearenv])
AC_CHECK_FUNCS([nanosleep])
AC_CHECK_FUNCS([ptsname])
AC_CHECK_FUNCS([setitimer])
AC_CHECK_FUNCS([readdir_r])
AC_CHECK_FUNCS([telldir seekdir])
AC_CHECK_FUNCS([execvpe])
AC_CHECK_FUNCS([utimensat futimens])
AC_CHECK_FUNCS([lutimes futimes])
AC_CHECK_FUNCS([mkstemps mkdtemp])
AC_CHECK_FUNCS([fsync fdatasync])
AC_CHECK_FUNCS([posix_fadvise posix_fallocate]) So we're definitely not cross-compile safe right now... :-/ |
Okay, I've found a work around. We just need to suppress the warning when we are using clang. Just add the following to configure.ac.
The reason I think this is okay is due to this discussion: Orc/discount#55 At the very least, I don't think this is going to hurt anything. I'll fork and send you a pull request right now. |
There should be no problem using AC_CHECK_FUNCS when cross-compiling: "When writing tests in This is what we want, since the libraries (like unix) are built to run on the host environment (the target of the stage1 (cross-)compiler, and the system on which the stage2 (native) compiler runs). (Yes, the autoconf terminology is terribly confusing.) We should figure out what's going on here. Is fdatasync actually provided by unistd.h on the arm64 iOS environment you are targeting? |
Some searching reveals that OS X has had problems with @sseefried Can you check pull request #42 and see if it solves your problem? |
Oh, interesting. I found this bug report for ruby, which seems to state the opposite of what you wrote, but it's a bit confusing:
If that last sentence is accurate, then things fall into place. I looked at what AC_CHECK_FUNCS generates and it defines its own prototype for the function being tested (I guess since it wouldn't know what kind of arguments to pass otherwise). So the configure check succeeded, since it successfully linked the test executable because the iOS libc actually does define an fdatasync function. Then when we tried to build the unix library with the C backend, we got an error about the missing prototype for fdatasync, and failed due to -Werror. If that is what's going on, then I would think that @argiopetech's patch would have the same problem, unless a missing prototype is an error by default for clang? Worth testing though since apparently it worked for beanstalkd. |
Yeah, it appears I've crossed my sources here. Not sure why #42 workes for beanstalkd. According to this issue in picoc, I'm trying to track down a copy of the iOS documentation to see if this is a viable alternative. I'm honestly not sure how much the iOS libraries mimic those of OS X. |
@argiopetech I have tried out #42 and found that the relevant part of
My previous patch is now obviously the wrong approach. Thank you everyone for thinking through this more clearly than I was. |
Okay, so it appears the beanstalkd patch works is that (as mentioned by @rwbarton) AC_CHECK_FUNCS includes a prototype when it tries to compile. The beanstalkd patch does not include a prototype. As such, the AC_CHECK_FUNCS file compiles (no missing prototypes) and is linked (wrongly) to the system call. Without the prototype it fails to compile. I'm going to go ahead and close this as fixed. It's going to throw exceptions on OS X (with warning at compile time, of course), but I'll open a new issue to implement the |
The error output is:
The bug is introduced in commit 98eced8.
The compiler I was using was LLVM 3.6's
clang
in a wrapper script calledaarch64-apple-darwin14-clang
. The contents of this file are:The problem is simply that you cannot use
AC_CHECK_FUNCS
inconfigure.ac
tocheck for the existence of a library function when cross-compiling.
This is detailed here
My work-around to the issue is to run
configure
manually and then editinclude/HsUnixConfig.h
manually and set:
The text was updated successfully, but these errors were encountered: