On 20 Jul 2013, at 00:21, Arran Cudbard-Bell <a.cudba...@freeradius.org> wrote:
> > On 19 Jul 2013, at 23:17, John Dennis <jden...@redhat.com> wrote: > >> I've built on Fedora and the unreleased RHEL-7 >> >> On RHEL-7 I built on the following architectures: >> >> ppc, s390, x86_64, ppc64, i686, s390x >> >> All of those built successfully but when I run one of our analysis tools >> it reports some problems, mostly in the area of multilib (multilib is >> where you can have more than one set of libraries on a system, e.g. >> 32-bit and 64-bit). The main problem is the header files have a few >> 32-bit vs. 64-bit items in them. Header files are not supposed to be >> arch specific. Normally the header files get installed in a devel >> package so 3rd parties can built and link new modules if they want. But >> the header files aren't clean, which would prohibit us from producing a >> devel package. One possibility is for the spec file to delete the >> offending elements in the header files, but it would be better if the >> multilib issues were not present in the FR 3.0 release at all, that >> would be much cleaner. > > radpaths.h is probably also a good candidate for imacroisation, meaning it > won't > be installed, and is not included directly. > > It's still good to have the information accessible somehow though. We could > introduce > some small wrapper functions in the server library fr_default_libdir() et al > which just return the values defined in radpath.h at build time. > > That'd mean if you were linking against the 64bit library you'd get the 64bit > libpath, > and if you linked against the 32bit library you'd get the 32bit libpath. > > Of course if you're linking against libfreeradius-server you probably already > have > a pretty good idea of where the libraries are, but I guess it ensures > consistency > if you use the lib path value to search for the modules. > >> Oddly there seems to be a multilib issue in one >> of the example python files. > > Is it attempting to compile them or something, and then complaining there are > differences? > >> I have not dug into how to fix any of these >> yet, but I hope we can get the fixes in before 3.0 is frozen. >> >> Also there were a few other issues reported in conjunction with IPv6. I >> have not had time yet to go through and see if these are red herrings or >> not. > > OK. > >> I've attached the output of the analysis tool for review. Ok fix pushed for the headers issue. I'll look at the others later. -Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html