I am quite happy to report that what's on the current fork-kill branch on github libselinux builds on mac with no warnings. Also, we want the libsepol patches upstream to cleanse those warnings as well. All the smaller patches have been sent out and merged, with the exception of "libselinux: drop unused stdio_ext.h header file", which was just sent out. I don't expect an issue on that merge. This leaves: https://github.com/williamcroberts/selinux/commit/df022f0f4425498f8537cc2c73064b6bb37c6a05 will be whats needed upstream to close the gap. I think we might want to take a revertme patch that comments out all the libselinux build files, so when it's merged into aosp theirs no duplicate definitions of libselinux, and then once they can revert that commit, we can do the same. They will likely have a window where they can fetch upstream into external/selinux before killing external/libselinux and enabling the build files. This seems to be the approach last time with a blank toplevel Android.mk sds let me know how you want the afformentioned commit on the link above broken up if at all, or any other issues you have, and Ill prep the final patch series for the mailing list. Thanks all for the input provided, and Josh for your late night mac help! On Fri, Sep 23, 2016 at 1:44 PM, William Roberts <bill.c.roberts@xxxxxxxxx> wrote: > On Fri, Sep 23, 2016 at 1:24 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: >> On 09/23/2016 04:01 PM, Joshua Brindle wrote: >>> William Roberts wrote: >>>> On Fri, Sep 23, 2016 at 6:57 AM, Joshua Brindle >>>> <brindle@xxxxxxxxxxxxxxxxx> wrote: >>>>> William Roberts wrote: >>>>>> On Sep 22, 2016 9:18 PM, "Jeffrey Vander Stoep"<jeffv@xxxxxxxxxx> >>>>>> wrote: >>>>>>> Remember to test on the Mac build. About a year ago I moved the >>>>>>> host side >>>>>> tools over to upstream libselinux, but had to revert because it >>>>>> broke the >>>>>> Mac build in multiple places. Since then Richard Haines has done a >>>>>> lot of >>>>>> work to reduce the diff between upstream and the Android fork. >>>>>> Hopefully >>>>>> that will reduce your effort. >>>>>> >>>>>> Yeah I'm quite concerned about the Mac build, does anyone on here have >>>>>> access to a Mac for testing? >>>>> >>>>> I do, let me know when you have a branch you need looked at and I'll >>>>> try to >>>>> get to it. >>>> >>>> Feel free to test the fork-kill branch from my github, you should find >>>> the details >>>> below from a previous message in the thread. >>>> >>> >>> Sure, >>> >>> Mac uses llvm which seems to catch much more than gcc, I have to get rid >>> of Werror to even get partially through a build. First issues: >>> >>> genbools.c:71:9: warning: unused variable 'size' [-Wunused-variable] >>> size_t size = 0; >>> ^ >>> 1 warning generated. >>> cc -Wall -W -Wundef -Wshadow -Wmissing-format-attribute -O2 -I. >>> -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o genusers.o >>> genusers.c >>> genusers.c:39:9: warning: unused variable 'len' [-Wunused-variable] >>> size_t len = 0; >>> ^ >>> genusers.c:63:14: warning: variable 'nread' is uninitialized when used >>> here [-Wuninitialized] >>> if (buffer[nread - 1] == '\n') >>> ^~~~~ >>> genusers.c:40:15: note: initialize the variable 'nread' to silence this >>> warning >>> ssize_t nread; >>> ^ >>> = 0 >>> >>> but the .symver actually kills it altogether (I get a lot of these): >>> >>> <inline asm>:10:1: error: unknown directive >>> .symver cil_filecons_to_string_nopdb, cil_filecons_to_string@@LIBSEPOL_1.1 >>> ^ >> >> Are you building this in the context of Android? We disable the symver >> stuff automatically if ANDROID is defined. We only need to ensure that >> the portion of selinux userspace that is compiled for Android builds on >> MacOS X; it will never fully build there. >> > > All those files belong to libsepol, which I am pretty sure is building on Mac. > However, size is unused on __APPLE__ path, so I will prep patches for those > unused and uninitialized variables. > > I am mostly concerned about libselinux, which on Android we only use a subset > of the files. It would be possible to have a Makefile setup with the > files and defines > but it would only build the build host version and not the target. The > target would > be trickier as it links and builds against bionic. > > -- > Respectfully, > > William C Roberts -- Respectfully, William C Roberts _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
