I am trying to cross emerge packages on my desktop and laptop (both running Gentoo on virtual machines) in order to "speed up" the installation of software onto my Raspberry Pi, but I've run into a roadblock I'd prefer to demolish, so to speak, rather than to walk around it. The issue is that sed and binutils, when compiled on my amd64 virtual machines through a cross compiler made through crossdev (target: armv6zk-hardfloat-linux-gnueabihf), both exhibit the same configure time error:

Code:

configure: error: ACLs enabled but support not detected

To make sure this problem wasn't limited to arm cross compilers, I attempted to run the cross emerge with an i686-pc-linux-gnu crossdev setup, and lo and behold, the same error occurred. I found one mention of this in the Gentoo Bugzilla (https://bugs.gentoo.org/show_bug.cgi?id=476084), to which I also submitted some information. I've tried googling for this issue, and I've found that others have run into it in the past (such as here in the forums) but have solved it by removing the acl use flag. I'd rather figure out why this is happening. Any assistance or tips would be greatly appreciated and thanks in advance!

EDIT: Updated subject header to be more correct. This problem affects a lot more packages that use ACL.

EDIT2: Updated subject header to be more correct according to my recent findings. Any program that uses gnulibs m4/acl.m4 for autoconf since 2006 should be affected.

EDIT3&4: Fixed mistake, binutils is not the source of the problem, gnulib is.

Last edited by gemarcano on Wed Oct 16, 2013 2:39 pm; edited 5 times in total

Here's the config.log around the area where the config failed. I'm unsure whether the lines for statacl and aclsort matter, but I'm including them just in case. Let me know if you want more of the log. Sadly, the only lines that seem to relate to the error are the last two, and that isn't very helpful.

I did some digging in the configure script, and this is the code that calls the error:

Code:

if test "x$enable_acl$use_acl" = "xyes0"; then
as_fn_error $? "ACLs enabled but support not detected" "$LINENO" 5

I tried figuring out quickly why use_acl is false, but I wasn't able to do so at a glance... the configure script is a bit hard to read without fixing indentation levels (and it is very long).

Let me know if you need any more information from the config.log. In terms of my emerge --info for this cross compiler, I can include it here but I also put it in the bug report I mentioned in my first post. Let me know if you need it or anything else. Thanks!

I went ahead and indented the code for my own sanity. I can't guarantee line numbers weren't affected by my tinkering, but I'll see if I can get an unmodified configure script and put it up on pastebin soon. Anyhow, the code above is where I found a probably issue. Since this is a cross-compilation, the variable $cross_compiling is "yes", so gl_cv_func_working_acl_get_file is set to "cross-compiling" (which is reflected by this being printed out later in the config.log). The problem is a few lines down.

Code:

if test $gl_cv_func_working_acl_get_file = yes; then :
use_acl=1
fi

This test is explicitly checking to see if this variable is set to "yes", which is never the case in a cross-compilation. This, in turn, prevents use_acl=1 from being set.

Now, I'm not 100% sure this is the cause of the problem, since there are a lot more if statements involving the setting of use_acl=1, but seemingly every single one on my machine is failing. I am also admitedly not that great with BASH, so please, any input on what I've found would be greatly appreciated!

EDIT:
As an extra, I have also found the above code, practically verbatum, in the sed configure script as well. I have to check my emerge history to see which packages failed and I'll try to match those that failed cross-compilation due to ACL to this code above.

EDIT2:
I think this is the problem. I ran the configure as though I were going to build on my actual machine, and the branch that executes seems to be te else branch of the cross compile branch:

I believe this is the case because when I run the configure on my computer natively (no cross compilation), gl_cv_func_working_acl_get_file is set to "yes" , which would then make sure that use_acl is set to 1. This "yes" is reflected on the config.log line "checking for working acl_file_get... yes"

I seriously need input from someone that knows more about configure. As best as I can tell, by reviewing the code in the file, the snippit of code I have above is trying to determine if we are cross-compiling the application or not. If we are not, it tries to compile a test program and runs it to check for a specific bug or error condition. In a cross compiled run, there is no way that the test program can be run to check for this condition and is thus skipped, but by skipping this test the configure fails. This makes me wonder if this test wasn't thought through well for cross compilations? This check is essentially making it so that coreutils (and sed and others) can only be built on architectures that will be using it if acl is enabled.

The issue at hand seems to be the detection of whether ACL is supported or not. Is there any way to know this while cross compiling? What ways can it be checked? Is checking for the existence of ACL functions enought without running them? The current script checks for some but not the ones that are normally found in GNU/Linux systems (as far as I can tell). Is it good enough to override use_acl when cross compiling (that seems rash)? At this point, any input would be greatly appreciated. I'll try to figure out how these configure scripts are made (autotools?) and see if I can encounter any documentation on this particular portion of the program.

I seriously need input from someone that knows more about configure
.. At this point, any input would be greatly appreciated. I'll try to figure out how these configure scripts are made (autotools?) and see if I can encounter any documentation on this particular portion of the program.

##workingset on IRC: chat.freenode.net is your best bet for help. I try to stay away from autoconf, but wrt acl, if you're using Linux I'd set it to available (so it uses the relevant headers) and let it possibly fail at runtime with ENOSYS. Alternatively set the cache var to zero if you're never going to use acl on the ARM board.
But truly, ##workingset are the best people: loads of autotools experts in there.

The proper test for ACL support, whether native compiling or cross-compiling, is to try to compile and link a test program which uses one or more functions that are presumed to be present only when the full program will build correctly. It is not necessary, and in some cases undesirable, to run the test program. In a cross-compilation environment, your cross-compiler will pull in libraries specific to the cross-compiled host, so the test will pass if you have the right cross headers and libraries for the feature and fail otherwise. Generally, the configure test is supposed to mimic the requirements of the underlying program, so that you can get a graceful error message up front if the underlying program is guaranteed to fail.

Cross compilation support is often neglected, when it exists at all, so it would not surprise me if optional features do not cross-test correctly, even on a popular package.

Thank you for your input. I'll be looking into getting in contact with ##workingset on IRC one of these days when I have more time. I'm admittedly new to IRC (so far in my Gentoo experience and programming so far I have not had to go to IRCs for help), although it's about time that changes. I know how to work around the issue, but since this impacts more than just coreutils, I'd much rather not have to patch the configure script for all of the affected packages, so I'm going to try to address the actual problem with what may be autoconf.

@ Hu

That's what I thought in terms of configure testing. This specific test tries to run some code to test for a bug and disable ACL if found... not sure how kosher that is. I'll try to determine if this bug it's covering for is still a problem or if it could be a problem... that may help determine what the best way to counter this problem.

--

I found a project online, openembedded (git commit here), that essentially tackled this problem I'm working on by forcing the check to yes. I guess that's a work-around, but again, that's just a work-around. If possible, I'd like to figure out a more permanent solution. I'll keep updating this forum thread with information as I find it. Thanks again for the input!

I traced the problem file to something in gnulib. The file is "m4/acl.m4", and the code in question is at the very bottom of the file, where the AC function is made to check for the bug. Specifically, this code seems to work around an old bug found in Darwin 8.7.0 (Wikipedia says Darwin is at version 14 now). I actually found the patch that applied this code for this bug filed "way back" in 2006. I've been studying how to handle this issue properly. The best way to do it would be to explicitly check the host (where the resulting binary will run) is or will be Darwin 8.7.0. and disable acl in that specific case, enable otherwise. I'm not sure how to do this exactly... from my reading of the autoconf documentation, host_alias may be able to give me the architecture name, but not the version. I'm not sure it is possible to infer the version from any information available to autoconf.

The other solution is the more general (and probably less safe), but it goes in line with what the documetation for autoconf says on the subject (found here):

Quote:

...If the optional shell commands action-if-cross-compiling are given, those commands are run instead; typically these commands provide pessimistic defaults that allow cross-compilation to work even if the guess was wrong. ...

Question: am I interpreting that sentence from the documentation correctly (specifically the pessimistic default bit)?

Assuming my interpretation is correct, I wrote up the following patch for gnulibs:

Essentially, if cross-compilation is detected, just assume that the system doesn't have the bug. This will work great on just about every cross-compilation scenario, unless the target system (the host that will run the binary) is Darwin 8.7.0, in which case the bug will manifest itself.

Does anyone know if it is possible to check for the architecture generically for autoconf? I'm going to keep reading up on whether this is possible, but if someone knows and is willing to impart the knowledge, I would greatly appreciate it! This would help with implementing the first of the two solutions for this issue, and is possibly the more robust of the two.

Since this issue impacts anything that borrows from m4/acl.m4 from gnulib, I think, I'm going to modify the subject of the thread to reflect this uncertainty.

If I'm understading this correctly, this code only executes when the tool chain is a cross compiler and when the CHOST of the target machine is some linux CHOST (in my case, armv6zk-hardfloat-linux-gnueabihf). I tried running this modified ebuild, and it worked, so for Gentoo this may be a good alternative for the time being, but similar additions would be required by sed and other programs that are currently failing in a similar manner... a more general solution, I think, would be best, and as such I'll keep looking for one. If I have time tomorrow I'll try to get in contact with the gnulib folks and see what they have to say on the matter...

@mario18
Sure, USE="-acl" is a solution if one doesn't need access control lists for your system, but what if for some reason one really needs that feature? I mean, one could compile it natively on the target device (on my case the Raspberry Pi) and not have this issue, but when I have a computer with an i7-3770K that can compile coreutils in under a minute (compared to close to 10 or more on the Pi), I'd rather be able to cross-compile stuff. Personally, I don't really have a need for ACL, but being a young programmer with enough knowledge to contribute, hey, it's about time I give back to the community for my use of Linux these last seven years.

The pessimistic assumption would be to assume that untestable systems do have the bug, since you want to avoid letting anyone wander into it by accident. That obviously conflicts with what you want to do. A middle ground, given your discovery about the issue being related to Darwin, would be for cross-compilation to assume success if the host is not Darwin and assume failure if the host is Darwin. This is in line with your ebuild change, and makes --enable-acl work for cross-compile users who do not use Darwin, which is a step up over having --enable-acl not work for any cross-compile users.

@Hu
Ah, OK. Thanks for the clarification about the pessimistic assumption. The ebuild solution is an OK middle ground for us Gentoo folk. As you mention, the check should be if the host is not Darwin, skip the test-- right now it's if the system is Linux, skip the test. I'll fix that in a bit. I appreciate the input!

--
For what it's worth, I've also modified the sed ebuild with the same modification that I wrote for the coreutils ebuild, and the cross compilation succeeded. I'm still looking into how this host check may be able to be done at configure time and not by the ebuild... hopefully I can come up with something.

That looks like a good change for the ebuild. As you say, it would be nice to get this into the gnulib code that feeds the configure script so that other Linux distributions get correct cross-compilation behavior too.

Essentially, if I'm doing this right, what this code is doing is to pass the test if acl_get_file works or if the architecture being cross-compiled isn't Darwin. The substring matching is done via POSIX substring parameter matching, as demonstrated here at Stack Overflow. Does this make sense? I've tried this modification after copying my m4/acl.m4 file to my working copy of coreuilts-8.21/m4/acl.m4, and then running:

@Hu
Seeing that on my system doing the autoreconf and executing configure did not lead to problems in execution, I think it's valid syntax. I think that in the AC_IF so long as it's a valid sh expression it will run correctly.

I've submitted a summary of my work along with the patch for m4/acl.m4 upstream. Hopefully I hear something from them soon.

@steveL
Ah, yes, I had forgotten about the parentheses making a subshell. I'm not exactly fluent in SH or BASH, so thanks for catching that. I assumed parentheses would work like in C or C++.

Quote:

So how come --enable-acl is set on darwin cross-compile?

The --enable-acl is there to demonstrate that having it enabled will cause the configure to fail. It fails with the message:

Code:

configure: error: ACLs enabled but support not detected

This is the expected behavior when acl_get_file is found to be buggy. In this modification I made when cross-compiling it just guesses that the bug exists if the target host has darwin in its architecture name. The other configure run with the armv6zk host completes successfully with my modification, which is an improvement since the old code just assumed the error was present for cross-compilation. Does that make sense or am I messing up my logic somewhere?

The --enable-acl is there to demonstrate that having it enabled will cause the configure to fail. It fails with the message:

Code:

configure: error: ACLs enabled but support not detected

This is the expected behavior when acl_get_file is found to be buggy. In this modification I made when cross-compiling it just guesses that the bug exists if the target host has darwin in its architecture name. The other configure run with the armv6zk host completes successfully with my modification, which is an improvement since the old code just assumed the error was present for cross-compilation. Does that make sense or am I messing up my logic somewhere?

No, that makes sense: I just hadn't seen the other part of it, only the --enable-acl (and I'm not following it that closely.)

Though personally I'm not sure I'd bother with that for darwin, since it applies to such an old system. If I were upstream, I'd simply tell people to set the cachevar to no, if they were cross-compiling for such an old darwin (which is pretty unlikely imo.)

@steveL
Yeah, I agree. I just heard back from upstream and they applied a similar fix to what you suggested. Essentially now the m4/acl.m4 file is set up so that if the program will be cross-compiled, assume that there is no bug, else run the check.

I tested the upstream fix and it worked on my system (as expected), so I think this can be marked as solved? Except for the fact that sed and coreutils both still fail since they still include the old version of m4/acl.m4. I'll edit the subject header soon.