[ANN] Version 3.0.0-rc0

Arran Cudbard-Bell a.cudbardb at freeradius.org
Sat Jul 20 01:21:56 CEST 2013

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.


> I've attached the output of the analysis tool for review.



More information about the Freeradius-Users mailing list