Hi all, I try to compile freeradius-1.1.1 on a Suse Linux 8 Enterprise Server with gcc-3.2.2 and get the following error message: In file included from eap_peap.h:25, from rlm_eap_peap.c:24: ../../libeap/eap_tls.h:138: parse error before "SSL" ./../libeap/eap_tls.h:138: warning: no semicolon at end of struct or union ./../libeap/eap_tls.h:141: parse error before '*' token .... ... What could be wrong? Best regards Margit Meyer
Margit Meyer wrote:
I try to compile freeradius-1.1.1 on a Suse Linux 8 Enterprise Server with gcc-3.2.2 and get the following error message:
In file included from eap_peap.h:25, from rlm_eap_peap.c:24: ../../libeap/eap_tls.h:138: parse error before "SSL" ./../libeap/eap_tls.h:138: warning: no semicolon at end of struct or union ./../libeap/eap_tls.h:141: parse error before '*' token .... ...
What could be wrong?
There is a few problems in the autoconf tests in version 1.1.1. Please try 1.1.2. -- Nicolas Baradakis
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? Thanks, Lin On 6/21/06, Nicolas Baradakis <nbk@sitadelle.com> wrote:
Margit Meyer wrote:
I try to compile freeradius-1.1.1 on a Suse Linux 8 Enterprise Server with gcc-3.2.2 and get the following error message:
In file included from eap_peap.h:25, from rlm_eap_peap.c:24: ../../libeap/eap_tls.h:138: parse error before "SSL" ./../libeap/eap_tls.h:138: warning: no semicolon at end of struct or union ./../libeap/eap_tls.h:141: parse error before '*' token .... ...
What could be wrong?
There is a few problems in the autoconf tests in version 1.1.1. Please try 1.1.2.
-- Nicolas Baradakis
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
"Lin Richardson" <lin@xmission.com> wrote:
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.
The Debian people actively maintain updated packages for FreeRADIUS. Plus, it's difficult for open source projects to compile & test the project on many platforms, because they may not have access to many platforms.
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'
Add the following line at the top of libradius.h, and the build should succeed: #define HAVE_CLOSEFROM 1 Alan DeKok.
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@lobefin.net | office who was unable to form a task | | http://www.lobefin.net/~steve | force before the music stopped. | --------------------------------------------------------------------------
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@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@lobefin.net | office who was unable to form a task | | http://www.lobefin.net/~steve | 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
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@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@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@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
On Wed, Jun 21, 2006 at 02:06:02PM -0600, Lin Richardson said:
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.
Thank you for this point of information. This sounds like more libtool/autoconf breakage, at first glance. When (if!) I/we can port the current autotools build system to a newer version, do you mind testing it? Thanks, -- -------------------------------------------------------------------------- | Stephen Gran | Having nothing, nothing can he lose. | | steve@lobefin.net | -- William Shakespeare, "Henry VI" | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
Everything looks good so far. Thanks for the help. You are welcome to send me testing needs and I'll accommodate as I can. May not be same day service, but I'd be happy to do it. Regards, Lin On 6/21/06, Stephen Gran <steve@lobefin.net> wrote:
On Wed, Jun 21, 2006 at 02:06:02PM -0600, Lin Richardson said:
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.
Thank you for this point of information. This sounds like more libtool/autoconf breakage, at first glance. When (if!) I/we can port the current autotools build system to a newer version, do you mind testing it?
Thanks, -- -------------------------------------------------------------------------- | Stephen Gran | Having nothing, nothing can he lose. | | steve@lobefin.net | -- William Shakespeare, "Henry VI" | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFEme5NSYIMHOpZA44RAmzFAJ9Nyj69f9WIiJ7JTnQ1Sx41tP2pqwCeL9S9 OMlFkjpvzKYF/gHB811q8OY= =2cxc -----END PGP SIGNATURE-----
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Lin Richardson wrote:
You are welcome to send me testing needs and I'll accommodate as I can. May not be same day service, but I'd be happy to do it.
Thanks for the help. Could you try please the autotools upgrade in the CVS? $ cvs -d :pserver:anoncvs@cvs.freeradius.org:/source login CVS password: anoncvs $ cvs -d :pserver:anoncvs@cvs.freeradius.org:/source checkout -r branch_1_1 radiusd -- Nicolas Baradakis
I think this is probably a topic for the dev list... Anyway, I finally got back to the office after a few days off... access to some Solaris boxen. I assume you meant for me to test this build on solaris10? I grabbed the CVS branch referenced below and did the standard ./configure make output was as follows: Making all in rlm_detail... make[6]: Entering directory `/usr/home/lplricha/src/radiusd/src/modules/rlm_detail' /usr/home/lplricha/src/radiusd/libtool --mode=compile gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -g -Wshadow-Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs-W -Wredundant-decls -Wundef -I/usr/home/lplricha/src/radiusd/src/include -c rlm_detail.c mkdir .libs gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -g -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -W -Wredundant-decls -Wundef -I/usr/home/lplricha/src/radiusd/src/include -c rlm_detail.c -fPIC -DPIC -o .libs/rlm_detail.o rlm_detail.c: In function `detail_instantiate': rlm_detail.c:133: error: too few arguments to function `lrad_hash_table_create' rlm_detail.c:158: warning: passing arg 2 of `lrad_hash_table_insert' makes pointer from integer without a cast rlm_detail.c:158: error: too many arguments to function `lrad_hash_table_insert' rlm_detail.c: In function `do_detail': rlm_detail.c:344: warning: passing arg 2 of `lrad_hash_table_finddata' makes pointer from integer without a cast make[6]: *** [rlm_detail.lo] Error 1 make[6]: Leaving directory `/usr/home/lplricha/src/radiusd/src/modules/rlm_detail' make[5]: *** [common] Error 2 make[5]: Leaving directory `/usr/home/lplricha/src/radiusd/src/modules' make[4]: *** [all] Error 2 make[4]: Leaving directory `/usr/home/lplricha/src/radiusd/src/modules' make[3]: *** [common] Error 2 make[3]: Leaving directory `/usr/home/lplricha/src/radiusd/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/home/lplricha/src/radiusd/src' make[1]: *** [common] Error 2 make[1]: Leaving directory `/usr/home/lplricha/src/radiusd' make: *** [all] Error 2 -bash-3.00$ I hope that helps. Happy to test some other platforms if you have requests. regards, Lin On 6/23/06, Nicolas Baradakis <nbk@sitadelle.com> wrote:
Lin Richardson wrote:
You are welcome to send me testing needs and I'll accommodate as I can. May not be same day service, but I'd be happy to do it.
Thanks for the help. Could you try please the autotools upgrade in the CVS?
$ cvs -d :pserver:anoncvs@cvs.freeradius.org:/source login CVS password: anoncvs $ cvs -d :pserver:anoncvs@cvs.freeradius.org:/source checkout -r branch_1_1 radiusd
-- Nicolas Baradakis
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi all,
There is a few problems in the autoconf tests in version 1.1.1. Please try 1.1.2.
thanks for your tips. Now I managed to compile version 1.1.2. Here is the configure call I used: CFLAGS="$CFLAGS -DHEIMDAL_KRB5 -I/usr/include/heimdal" ./configure --with-snmp=no --includedir=/usr/include/heimdal Perhaps this will be useful for someone else. Regards Margit Meyer
participants (5)
-
Alan DeKok -
Lin Richardson -
Margit Meyer -
Nicolas Baradakis -
Stephen Gran