coreutils built without ACL support so that ls and cp don't have the following behaviors: 1. For files that have a default ACL or an access ACL that contains more than the three required ACL entries, the ls utility in the long form produced by ls -l displays a plus sign (+) after the permission string. e.g. -rw-rw-r--+ 1 root root 0 Aug 17 13:03 acl_file 2. If the -p flag is specified, the cp utility also preserves ACLs. If this is not possible, a warning is produced. configure logs: ================ checking sys/acl.h usability... yes checking sys/acl.h presence... yes checking for sys/acl.h... yes checking for library containing acl_get_file... -lacl checking for acl_get_file... yes checking for acl_get_fd... yes checking for acl_set_file... yes checking for acl_set_fd... yes checking for acl_free... yes checking for acl_from_mode... yes checking for acl_from_text... yes checking for acl_delete_def_file... yes checking for acl_extended_file... yes checking for acl_delete_fd_np... no checking for acl_delete_file_np... no checking for acl_copy_ext_native... no checking for acl_create_entry_np... no checking for acl_to_short_text... no checking for acl_free_text... no checking for working acl_get_file... cross-compiling checking for facl... no checking for getacl... no checking for aclv.h... no checking for aclx_get... no checking for statacl... no checking for aclsort... no configure: WARNING: libacl development library was not found or not usable. configure: WARNING: GNU coreutils will be built without ACL support.
Fixed: http://cgit.openembedded.org/openembedded-core/commit/?id=b30ef39cc26dd0b6ed08bd2b1a6394de6b540720
Verified in master branch 37c8597e7600385367257e8a513e003947ebef5b