[ANN] Version 3.0.0-rc0
a.cudbardb at freeradius.org
Sat Jul 20 09:41:17 CEST 2013
On 20 Jul 2013, at 00:21, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:
> On 19 Jul 2013, at 23:17, John Dennis <jdennis at 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
>> 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.
More information about the Freeradius-Users