Summary: | app-admin/setools-3.3.7-r3 fails to build | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Patrick Lauer <patrick> |
Component: | New packages | Assignee: | Sven Vermeulen (RETIRED) <swift> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | d.fedorov, selinux, xiangzhai83, yamadharma |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | selinux-utils | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 436338 | ||
Bug Blocks: |
Description
Patrick Lauer
2012-08-07 04:14:42 UTC
Just some feedback. One of the problems seen: """ typedef struct apol_vector {} apol_vector_t; %extend apol_vector_t { apol_vector_t() { return apol_vector_create(NULL); }; size_t get_size() { return apol_vector_get_size(self); }; ~apol_vector_t() { apol_vector_destroy(&self); }; """ Swig sees this as the "apol_vector" object, not "apol_vector_t", so it wants the constructor and destructor pair to be named similarly, like so: """ apol_vector() { return apol_vector_create(NULL); }; ~apol_vector() { return apol_vector_destry(&self); }; """ The problem now seems to be that the get_size() method is translated by swig to apol_vector_get_size(), which already exists (in the C-code that we want to swigify). In this particular case, I think I can just drop the definition and have it called directly (swig should be sufficiently intelligent, doesn't it?) but there are others where the declaration that swig generates is different from the one in the code. If that occurs, and I don't find a way to override this (perhaps namespaces, but that's a far stretch) then I'm even further away from home... Okay, %rename()'ing all functions (a little over 500 from the first count) and updating their wrappers... *sigh* Hopefully that really fixes things and doesn't just fix build (but fail at runtime). Got it to build again. Running regression tests against policycoreutils now (as those are the ones I know use the swig'ified interfaces of setools) and will then commit. *** Bug 432162 has been marked as a duplicate of this bug. *** setools-3.3.7-r5 in hardened-dev overlay *** Bug 433764 has been marked as a duplicate of this bug. *** In main tree, ~arch Some reports are that this was a swig error instead of a coding error. At least with swig-2.0.4-r1 setools-3.3.7-r3 seems to build just fine (again). Reopening ok, swig-2.0.8 still fails to build -r3 So, for future reference... swig-2.0.something started using the C++ standard for handling constructors/destructors. So in the following definition, "A" is the correct constructor: """ typedef struct A { A(); B(); } B; """ However, the swig code used in setools uses "B" as the constructor: """ typedef struct apol_vector { apol_vector_t() { ... }; } apol_vector_t; """ This causes the code to fail with recent enough swig. Attempts to correct this code gives failures all over the map: duplicate definitions (as the code is currently interwoven with wrappers) if you correct it to one way, or unmatching functions if you correct it the other way. Also, the various setools applications use the (wrong) names too, so there a lot of work would be needed as well. What I am going to do is to: (1.) force building with <swig-2.0 which doesn't exhibit this behavior (2.) force building with python-2.7 again as <swig-2.0 doesn't work with python 3.2. This is sad to say, but I cannot devote any more time on this matter until upstream resolves this properly. In hardened-dev overlay Moved to main tree Might I suggest this be reopened since it's broken and not fixed yet in stable? At the very least it will reduce the frequency of duplicate bug reports and make the cause more visible for those who wonder why their updates keep failing. We're using the following status to allow easier follow-up of bugs: RESOLVED:TEST-REQUEST - fix is in an overlay VERIFIED:TEST-REQUEST - fix is in main tree, ~arch VERIFIED:FIXED - fix is in main tree, stable I get a python error. I'm going to try a few things in a bit. I'll get back to you with the results shortly. r6 appears to work, r3 did not (r6 is still marked unstable, I updated today). I'll send you my logs, if I forget ping me on irc. @schmitt953: it is still marked unstable, hence the TEST-REQUEST part. It'll be marked as FIXED when it gets stable. Stabilized |