Parse error freeradius-1.1.1

Wed Jun 21 22:06:02 CEST 2006

After looking more carefully at the make output, I noticed that the build
failed because the rlm_perl.lo had not been built, and the xarch=v8 was what
it complained about when it tried to build it.  I did some digging and ended
up replacing the "-xarch=v8" flag with "-mcpu=v8 -mtune=ultrasparc" in the
Makefile found in the directory of the component that was failing in the
build.

I had encountered a similar error on a previous Solaris/sparc compile and
used the same fix.  The build was successful after this change.  I will test
the server for functionality and drop one more note to confirm if all goes
well.

Regards,
Lin

On 6/21/06, Lin Richardson <lin at xmission.com> wrote:
>
> This was helpful!
>
> I progressed beyond the error noted previously by adding
> #undef HAVE_CLOSEFROM
> to the src/include/autoconf.h.in file.
>
> The build now ends in an error (under Solaris 10) that is similar to the
> error I hit with my attempts under Debian Sid.
>
> ...
> gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE
> -DNDEBUG -I/usr/home/lplricha/src/freeradius-1.1.2/src/include
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO
> -I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE -c rlm_perl.c -o rlm_perl.o
> >/dev/null 2>&1
> mv -f .libs/rlm_perl.lo rlm_perl.lo
> mv: cannot access .libs/rlm_perl.lo
> make[6]: *** [rlm_perl.lo] Error 2
> make[6]: Leaving directory `/usr/home/lplricha/src/freeradius-1.1.2
> /src/modules/rlm_perl'
>
>
> Also, I would be happy to do test compiles under different OS installs.  I
> can't really help with the coding much, but would be happy to contribute in
> other ways.  That may be off-topic for this list though.  :)
>
> Thanks,
> Lin
>
> On 6/21/06, Stephen Gran <steve at lobefin.net> wrote:
>
> > On Wed, Jun 21, 2006 at 10:28:12AM -0600, Lin Richardson said:
> > RE version 1.1.2
> >
> > I'm currious.  I have tried compiling 1.1.2 on Solaris 10, OpenBSD 3.9,
> and
> > Debian Sid.  The ONLY way I have been able to get it working is with the
> deb
> > packages.
> >
> > I have read exchanges regarding autoconf and libtool issues on the dev
> > list.  The most recent CVS snapshots progress further in the build, but
> > still result in errors.  Any news on when the issues may be resolved,
> > perhaps a 1.1.3 release?
> >
> > I'm not an uber compiler, so I admit I am a bit weak at resolving
> > compiletime issues.
> >
> > Under Solaris 10, my true target platform, I get the following final
> output
> > error from the build attempt
> > (I have already rebuilt the headers under Solaris 10 which is a common
> > problem when compiling under that OS.)
> > ...
> > In file included from dict.c:42:
> > ../include/libradius.h:316: error: conflicting types for `closefrom'
> > /usr/include/stdlib.h:193: error: previous declaration of `closefrom'
> > make[4]: *** [dict.lo] Error 1
> >
> > I am trying to move our enterprise RADIUS to freeradius from a comercial
> > product, but I need a documented install process that works well.  Any
> > ideas?
>
> <debian maintainer hat on>
>
> Take a look at debian/rules in the source package for debian.  It is
> the debian Makefile, and contains anything extra we do to make it
> build nicely.  The closefrom error sounds symptomatic of some of the
> autotools problems I have been looking at.  The relevant lines are:
> #ifndef HAVE_CLOSEFROM
> int             closefrom(int fd);
> #endif
> But clearly there is a system closefrom, so either the macro is
> undefined, or the configure test missed the system one.  Try adding
> #undef HAVE_CLOSEFROM
> to src/include/autoconf.h.in, and rerunning the build, at a guess.
>
> For this reason and others, I am looking at reworking a bunch of the
> auto* scripts, and hope they will be acceptable upstream.  They all need
> updating, and some of them can be considerably streamlined, but I don't
> know how invasive I/you want to be.  One of the first things I see is
> that there are multiple configure scripts in subdirectories, and this
> is usually not what you want - it's usualy easier to add the tests to
> the top level configure script and source the config.h from the top level.
>
> But again, I've just started looking - there may be reasons (historical
> or otherwise) for this that I'm not seeing yet.  Any tips or pointers
> greatly appreciated.
>
> Take care,
> --
> --------------------------------------------------------------------------
> |  Stephen Gran                  | Decision maker, n.:  The person in your
> |
> |  steve at lobefin.net             | office who was unable to form a
> task    |
> |  http://www.lobefin.net/~steve <http://www.lobefin.net/%7Esteve> |
> force  before the music stopped.        |
> --------------------------------------------------------------------------
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFEmX3pSYIMHOpZA44RAoo+AJ9j7vNr/JN8ZeHXNkhDw3en9TJe4gCfbVM0
> MhlhpOzCjYl9SN77VeIZP1w=
> =YYof
> -----END PGP SIGNATURE-----
>
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20060621/be1791c8/attachment.html>