Created attachment 369866 [details, diff] libselinux-2.2.2-build.patch the new libselinux-2.2.2-r1 ebuild suffers from a number of problems: - hardcodes -L/usr/lib - hardcodes -I/usr/include - hardcodes /usr/lib/libsepol.a - puts LDFLAGS in the wrong location (after the objects instead of before) - does not get libpcre cflags from pkg-config - hardcodes -lpcre instead of using pkg-config settings - overlinks libpcre with files that don't need it attached patch should fix things i think
Created attachment 369868 [details, diff] libselinux-2.2.2-r1.ebuild.patch
should be all set now in the tree; thanks for the report! Commit message: Clean up linking behavior http://sources.gentoo.org/sys-libs/libselinux/files/libselinux-2.2.2-build.patch?rev=1.1 http://sources.gentoo.org/sys-libs/libselinux/libselinux-2.2.2-r3.ebuild?rev=1.1
This change actually breaks things. Specifically, the part about linking libsepol dynamically instead of statically triggers the following semanage failure: # semanage permissive -l Traceback (most recent call last): File "/usr/lib/python-exec/python2.7/semanage", line 27, in <module> import seobject File "/usr/lib64/python2.7/site-packages/seobject.py", line 27, in <module> import sepolicy File "/usr/lib64/python2.7/site-packages/sepolicy/__init__.py", line 11, in <module> import sepolgen.interfaces as interfaces File "/usr/lib64/python2.7/site-packages/sepolgen/interfaces.py", line 24, in <module> import access File "/usr/lib64/python2.7/site-packages/sepolgen/access.py", line 35, in <module> from selinux import audit2why ImportError: /usr/lib64/python2.7/site-packages/selinux/audit2why.so: undefined symbol: sepol_set_policydb Sadly, I don't have the time to examine this further at the moment, and I'm in no mood to deal with linker madnesses anyway. SpanKY, as the author of the patch, could you please have a look at this?
I'll revert the libsepol static linkage as that is apparently by design by upstream (libselinux' audit2why uses hidden symbols, which are only accessible through static linking).
Reverted to statically linking libsepol.a again through bug #504832
except you reverted all the fixes and not just the static linking, so you've re-introduced problems i outlined in the summary
No, the newly generated patchbundle contains your fixes afaics: >>> Preparing source in /var/portage/portage/sys-libs/libselinux-2.2.2-r4/work/libselinux-2.2.2 ... * Applying libselinux patches ... * 0005-use-ruby-include-with-rubylibver.patch ... [ ok ] * 0006-build-related-fixes-bug-500674.patch ... [ ok ] * Done with patching Unless the patch didn't apply well, but from the build log I think it does. For instance, your patch contains: -override CFLAGS += -I../include -I$(INCLUDEDIR) -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 $(EMFLAGS) +override CFLAGS += -I../include $(PCRE_CFLAGS) -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 $(EMFLAGS) In the build log I see: x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -c -o mapping.o mapping.c So no hardcoded -I$(INCLUDEDIR) (which was in libselinux-2.2.2-r2).
