| Summary: | sys-libs/libselinux-2.2.2-r1: broken -L/-I/LDFLAGS handling and force staticed linking of libsepol | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | SpanKY <vapier> |
| Component: | [OLD] Core system | Assignee: | SE Linux Bugs <selinux> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aranea |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
libselinux-2.2.2-build.patch
libselinux-2.2.2-r1.ebuild.patch |
||
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).
|
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