[ANN] Version 3.0.0-rc0

[Arran Cudbard-Bell]

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
>> 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