Hello I am trying to cross compile freeradius-server-3.0.21. Until recently we used a 2.x series but upgrading to openssl 1.1.1 forced us to upgrade freeradius too (it is probably reasonable anyway). Now with freeradius 3.0.21 I am running into an impasse as configuration barfs at me: checking for __builtin_choose_expr support in compiler... configure: error: in `/home/mega/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius/freeradius-server-3.0.21': configure: error: cannot run test program while cross compiling configure reads Configured with: /home/mega/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/toolchain/gcc-8.4.0/configure --target=x86_64-unknown-linux-uclibc --with-sysroot=/home/mega/leaf/devel/master-new-openssl/staging/x86_64-unknown-linux-uclibc --includedir=/home/mega/leaf/devel/master-new-openssl/staging/x86_64-unknown-linux-uclibc/usr/include --prefix=/home/mega/leaf/devel/master-new-openssl/toolchain/x86_64-unknown-linux-uclibc --enable-shared --with-gnu-ld --with-gnu-as --disable-libmudflap --disable-libssp --disable-libmpx --disable-libquadmath --disable-libgomp --disable-multilib --enable-languages=c++ It appears that I have to disable parallel testing of the capabilities. Could anyone point me what to look at? Thank you ET -- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com
On Oct 15, 2020, at 4:46 AM, Erich Titl <erich.titl@think.ch> wrote:
I am trying to cross compile freeradius-server-3.0.21. Until recently we used a 2.x series but upgrading to openssl 1.1.1 forced us to upgrade freeradius too (it is probably reasonable anyway).
Yup. v2 has been end of life for quite a while now.
Now with freeradius 3.0.21 I am running into an impasse as configuration barfs at me:
checking for __builtin_choose_expr support in compiler... configure: error: in `/home/mega/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius/freeradius-server-3.0.21': configure: error: cannot run test program while cross compiling
Hmm... I suppose we could fix the configure check to not run programs. But that won't really help. The short answer is that you can edit the "configure" script to remove those checks. Just look for that error message, and remove all of the code which references "builtin_choose_expr". The configure script is just shell script (terrible, terrible shell script), but it's not too bad. You will likely have to do the same thing for other tests, too.
It appears that I have to disable parallel testing of the capabilities. Could anyone point me what to look at?
Arguably the "configure" checks should be set up to not run any local programs. Then cross compiling will be a lot easier. But in the end, we don't do a lot of cross compiling, so it's not a well-tested feature. If someone were to supply patches... we could add them, and then ensure that cross-compiling is supported for the future. Alan DeKok.
Hi Alan Am 15.10.2020 um 14:12 schrieb Alan DeKok:
On Oct 15, 2020, at 4:46 AM, Erich Titl <erich.titl@think.ch> wrote:
I am trying to cross compile freeradius-server-3.0.21. Until recently we used a 2.x series but upgrading to openssl 1.1.1 forced us to upgrade freeradius too (it is probably reasonable anyway).
Yup. v2 has been end of life for quite a while now.
Now with freeradius 3.0.21 I am running into an impasse as configuration barfs at me:
checking for __builtin_choose_expr support in compiler... configure: error: in `/home/mega/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius/freeradius-server-3.0.21': configure: error: cannot run test program while cross compiling
Hmm... I suppose we could fix the configure check to not run programs. But that won't really help.
The short answer is that you can edit the "configure" script to remove those checks. Just look for that error message, and remove all of the code which references "builtin_choose_expr".
The configure script is just shell script (terrible, terrible shell script), but it's not too bad.
Well the nested if constructs are not really easy to read.
You will likely have to do the same thing for other tests, too.
It appears that I have to disable parallel testing of the capabilities. Could anyone point me what to look at?
Arguably the "configure" checks should be set up to not run any local programs. Then cross compiling will be a lot easier.
I am afraid that by just disabling the checks lots of confdefs will just be omitted. I have no idea what will be the results in the compiled object if it compiles at all.
But in the end, we don't do a lot of cross compiling, so it's not a well-tested feature. If someone were to supply patches... we could add them, and then ensure that cross-compiling is supported for the future.
I understand that the compile script is built by autoconf, probably using m4, unfortunately I am not familiar with this tool. Thanks Erich -- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com
Hi Alan Am 15.10.2020 um 14:12 schrieb Alan DeKok:
On Oct 15, 2020, at 4:46 AM, Erich Titl <erich.titl@think.ch> wrote: ....
`/home/mega/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius/freeradius-server-3.0.21': configure: error: cannot run test program while cross compiling
Hmm... I suppose we could fix the configure check to not run programs. But that won't really help.
The short answer is that you can edit the "configure" script to remove those checks. Just look for that error message, and remove all of the code which references "builtin_choose_expr".
I got away with editing configure.ac and then run autogen.sh to create a new configure script without the tests. Here are the relevant lines dnl # dnl # check for some compiler features dnl # FR_TLS dnl FR_HAVE_BUILTIN_CHOOSE_EXPR dnl FR_HAVE_BUILTIN_TYPES_COMPATIBLE_P dnl FR_HAVE_BUILTIN_BSWAP64 dnl FR_HAVE_BOUNDED_ATTRIBUTE so it appears that configure is running, but now I see configure: creating ./config.status config.status: creating all.mk sed -i 's,need_relink=yes,need_relink=no,' freeradius-server-3.0.21/libtool sed: can't read freeradius-server-3.0.21/libtool: No such file or directory make: *** [buildtool.mk:21: freeradius-server-3.0.21/.configure] Error 2 make: Leaving directory '/home/mega/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius' It looks like config.status gets created and started but libtool needs to be created somewhere. Thanks ET -- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com
On Oct 15, 2020, at 1:15 PM, Erich Titl <erich.titl@think.ch> wrote:
I got away with editing configure.ac and then run autogen.sh to create a new configure script without the tests. Here are the relevant lines
You can just do "make reconfig" and it will work. You might need to do a "configure" first, but that doesn't have to be a cross-compile. You can always re-run "configure" later. Don't run autogen.sh. It will do all kinds of stupidities in order to
so it appears that configure is running, but now I see
configure: creating ./config.status config.status: creating all.mk sed -i 's,need_relink=yes,need_relink=no,' freeradius-server-3.0.21/libtool sed: can't read freeradius-server-3.0.21/libtool: No such file or directory make: *** [buildtool.mk:21: freeradius-server-3.0.21/.configure] Error 2 make: Leaving directory '/home/mega/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius'
It looks like config.status gets created and started but libtool needs to be created somewhere.
We don't use libtool. It's garbage. Just do "make reconfig", and the build process will Do the Right Thing. Alan DeKok.
Hi Alan Am 15.10.2020 um 19:23 schrieb Alan DeKok:
On Oct 15, 2020, at 1:15 PM, Erich Titl <erich.titl@think.ch> wrote:
I got away with editing configure.ac and then run autogen.sh to create a new configure script without the tests. Here are the relevant lines
You can just do "make reconfig" and it will work. You might need to do a "configure" first, but that doesn't have to be a cross-compile. You can always re-run "configure" later.
So you are telling me that after commenting the offending macros in configure.ac a make reconfig is the right thing to do?
Don't run autogen.sh. It will do all kinds of stupidities in order to
I read you and that worries me. Should it not be removed from the distibution?
so it appears that configure is running, but now I see
configure: creating ./config.status config.status: creating all.mk sed -i 's,need_relink=yes,need_relink=no,' freeradius-server-3.0.21/libtool sed: can't read freeradius-server-3.0.21/libtool: No such file or directory make: *** [buildtool.mk:21: freeradius-server-3.0.21/.configure] Error 2 make: Leaving directory '/home/mega/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius'
It looks like config.status gets created and started but libtool needs to be created somewhere.
We don't use libtool. It's garbage.
It appears to be put in config.status and that is created by configure AFAIK.
Just do "make reconfig", and the build process will Do the Right Thing.
Well, we have some kind of a standardised build process, grown over the years. Basically it ia a Makefile which prepares the package and then runs configure with predefined options and then a make using the generated configuration. I would like to streamline this and doubt I will easily throw all this infrastructure away. Maybe we are wrong to use cross compile but this is hard to foresee as we are supporting a number of different architectures, e.g. x486, x686, x86-64 and a few RPI versions. I can of course control what this makefile does. mega@leafbuilder:~/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius/freeradius-server-3.0.21$ make reconfig make: Nothing to be done for 'reconfig'. I then ran configure as before .... configure: creating ./config.status config.status: creating all.mk sed -i 's,need_relink=yes,need_relink=no,' freeradius-server-3.0.21/libtool sed: can't read freeradius-server-3.0.21/libtool: No such file or directory make: *** [buildtool.mk:21: freeradius-server-3.0.21/.configure] Error 2 make: Leaving directory '/home/mega/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius' ... This is what I read in configure # configure is writing to config.log, and then calls config.status. # config.status does its own redirection, appending to config.log. So it appears that configure is creating the offending sed invocation which fails because it is missing libtool in the distribution. There appears to be some code to build libtool in the scripts directory. mega@leafbuilder:~/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius$ tar tjf freeradius-server-3.0.21.tar.bz2 | grep libtool freeradius-server-3.0.21/scripts/jlibtool.c freeradius-server-3.0.21/scripts/libtool.mk Thanks ET -- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com
On Oct 15, 2020, at 6:08 PM, Erich Titl <erich.titl@think.ch> wrote:
So you are telling me that after commenting the offending macros in configure.ac a make reconfig is the right thing to do?
Yes. Maybe: ./configure edit configure.ac make reconfig Which will then regenerate configure.
Don't run autogen.sh. It will do all kinds of stupidities in order to
I read you and that worries me. Should it not be removed from the distibution?
Probably.
We don't use libtool. It's garbage.
It appears to be put in config.status and that is created by configure AFAIK.
libtool is a horrific 4K LoC shell script which is supposed to do cross-platform building. It's insane. We use a better faster tool
Well, we have some kind of a standardised build process, grown over the years. Basically it ia a Makefile which prepares the package and then runs configure with predefined options and then a make using the generated configuration. I would like to streamline this and doubt I will easily throw all this infrastructure away. Maybe we are wrong to use cross compile but this is hard to foresee as we are supporting a number of different architectures, e.g. x486, x686, x86-64 and a few RPI versions. I can of course control what this makefile does.
You can re-generate the "configure" script, and then use "git" to create your own repo.
mega@leafbuilder:~/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius/freeradius-server-3.0.21$ make reconfig make: Nothing to be done for 'reconfig'.
Then you didn't edit "configure.ac", I think. Or, you regenerated "configure" after editing "configure.ac"
There appears to be some code to build libtool in the scripts directory.
mega@leafbuilder:~/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius$ tar tjf freeradius-server-3.0.21.tar.bz2 | grep libtool freeradius-server-3.0.21/scripts/jlibtool.c freeradius-server-3.0.21/scripts/libtool.mk
jlibtool != libtool We don't use libtool. It's garbage. Alan DeKok.
Am 16.10.2020 um 00:12 schrieb Alan DeKok:
On Oct 15, 2020, at 6:08 PM, Erich Titl <erich.titl@think.ch> wrote:
So you are telling me that after commenting the offending macros in configure.ac a make reconfig is the right thing to do?
Yes. Maybe:
./configure
edit configure.ac
make reconfig
Which will then regenerate configure.
Don't run autogen.sh. It will do all kinds of stupidities in order to
I read you and that worries me. Should it not be removed from the distibution?
Probably.
We don't use libtool. It's garbage.
It appears to be put in config.status and that is created by configure AFAIK.
libtool is a horrific 4K LoC shell script which is supposed to do cross-platform building. It's insane.
So it is possible that it is invoked by the cross compile instructions
We use a better faster tool
Well, we have some kind of a standardised build process, grown over the years. Basically it ia a Makefile which prepares the package and then runs configure with predefined options and then a make using the generated configuration. I would like to streamline this and doubt I will easily throw all this infrastructure away. Maybe we are wrong to use cross compile but this is hard to foresee as we are supporting a number of different architectures, e.g. x486, x686, x86-64 and a few RPI versions. I can of course control what this makefile does.
You can re-generate the "configure" script, and then use "git" to create your own repo.
Oh sure I know how to handle this. But basically I don't want to mess around with the code provided by the freeradius project.
mega@leafbuilder:~/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius/freeradius-server-3.0.21$ make reconfig make: Nothing to be done for 'reconfig'.
Then you didn't edit "configure.ac", I think. Or, you regenerated "configure" after editing "configure.ac"
Indeed I did using autogen.sh, I will then start over with a virgin tarball.
There appears to be some code to build libtool in the scripts directory.
mega@leafbuilder:~/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius$ tar tjf freeradius-server-3.0.21.tar.bz2 | grep libtool freeradius-server-3.0.21/scripts/jlibtool.c freeradius-server-3.0.21/scripts/libtool.mk
jlibtool != libtool
We don't use libtool. It's garbage.
I got it, let me make a start over and report Thanks ET -- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com
On Oct 15, 2020, at 6:18 PM, Erich Titl <erich.titl@think.ch> wrote:
libtool is a horrific 4K LoC shell script which is supposed to do cross-platform building. It's insane.
So it is possible that it is invoked by the cross compile instructions
No. What I said was that FreeRADIUS doesn't use libtool. What I meant was "FreeRADIUS doesn't use libtool"
Oh sure I know how to handle this. But basically I don't want to mess around with the code provided by the freeradius project.
If you're editing a "configure" script to site-local changes, it's fine. That's part of the build process. We don't use "configure" when the server is running.
mega@leafbuilder:~/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius/freeradius-server-3.0.21$ make reconfig make: Nothing to be done for 'reconfig'.
Then you didn't edit "configure.ac", I think. Or, you regenerated "configure" after editing "configure.ac"
Indeed I did using autogen.sh, I will then start over with a virgin tarball.
As I said... don't use "autogen.sh". This doesn't mean "leave the output of autopen.sh alone, and try to do something on top of that". It means start over. Alan DeKok.
Hi Alan Am 16.10.2020 um 00:26 schrieb Alan DeKok:
On Oct 15, 2020, at 6:18 PM, Erich Titl <erich.titl@think.ch> wrote:
libtool is a horrific 4K LoC shell script which is supposed to do cross-platform building. It's insane.
So it is possible that it is invoked by the cross compile instructions
No. What I said was that FreeRADIUS doesn't use libtool. What I meant was "FreeRADIUS doesn't use libtool"
Oh sure I know how to handle this. But basically I don't want to mess around with the code provided by the freeradius project.
If you're editing a "configure" script to site-local changes, it's fine. That's part of the build process. We don't use "configure" when the server is running.
mega@leafbuilder:~/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius/freeradius-server-3.0.21$ make reconfig make: Nothing to be done for 'reconfig'.
Then you didn't edit "configure.ac", I think. Or, you regenerated "configure" after editing "configure.ac"
Indeed I did using autogen.sh, I will then start over with a virgin tarball.
As I said... don't use "autogen.sh". This doesn't mean "leave the output of autopen.sh alone, and try to do something on top of that". It means start over.
Yep....I did I restarted from scratch ./configure yields then checking for grep... (cached) /bin/grep checking for _talloc in -ltalloc... no checking for _talloc in -ltalloc in /usr/local/lib... no checking for _talloc in -ltalloc in /opt/lib... no configure: WARNING: talloc library not found. Use --with-talloc-lib-dir=<path>. configure: error: FreeRADIUS requires libtalloc OK it needs talloc stuff ./configure --with-talloc-include-dir=~/leaf/devel/master-new-openssl/staging/x86_64-unknown-linux-uclibc/usr/include/samba --with-talloc-lib-dir=~/leaf/devel/master-new-openssl/staging/x86_64-unknown-linux-uclibc/usr/lib checking for _talloc in -ltalloc in ~/leaf/devel/master-new-openssl/staging/x86_64-unknown-linux-uclibc/usr/lib... no checking for _talloc in -ltalloc... no checking for _talloc in -ltalloc in /usr/local/lib... no checking for _talloc in -ltalloc in /opt/lib... no configure: WARNING: talloc library not found. Use --with-talloc-lib-dir=<path>. configure: error: FreeRADIUS requires libtalloc despite ls ~/leaf/devel/master-new-openssl/staging/x86_64-unknown-linux-uclibc/usr/lib/libtalloc* /home/mega/leaf/devel/master-new-openssl/staging/x86_64-unknown-linux-uclibc/usr/lib/libtalloc.so /home/mega/leaf/devel/master-new-openssl/staging/x86_64-unknown-linux-uclibc/usr/lib/libtalloc.so.2 /home/mega/leaf/devel/master-new-openssl/staging/x86_64-unknown-linux-uclibc/usr/lib/libtalloc.so.2.0.5 So obviously there are talloc libraries present there. This error does not show up when I use the whole shebang of configuration options make: Entering directory '/home/mega/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius' ( cd freeradius-server-3.0.21 ; ./configure --prefix=/usr \ --sysconfdir=/etc \ --localstatedir=/var \ --host=x86_64-unknown-linux-uclibc \ --build=x86_64-linux-gnu \ --with-rlm_acctlog \ --with-rlm_acct_unique \ --with-rlm_always \ --with-rlm_attr_filter \ --with-rlm_attr_rewrite \ --with-rlm_chap \ --with-rlm_checkval \ --with-rlm_copy_packet \ --with-rlm_detail \ --with-rlm_digest \ --with-rlm_dynamic_clients \ --with-rlm_eap \ --with-rlm_eap_gtc \ --with-rlm_eap_leap \ --with-rlm_eap_md5 \ --with-rlm_eap_mschapv2 \ --with-lm_eap_peap \ --with-rlm_eap_sim \ --with-rlm_eap_tls \ --with-rlm_eap_ttls \ --with-rlm_exec \ --with-rlm_expiration \ --with-rlm_expr \ --with-rlm_fastusers \ --with-rlm_files \ --with-rlm_ldap \ --with-rlm_linelog \ --with-rlm_logintime \ --with-rlm_mschap \ --with-rlm_otp \ --with-rlm_pap \ --with-rlm_passwd \ --with-rlm_policy \ --with-rlm_preprocess \ --with-rlm_radutmp \ --with-rlm_realm \ --with-rlm_sql \ --with-rlm_sqlcounter \ --with-rlm_sqlippool \ --with-rlm_sql_log \ --with-rlm_unix \ --without-rlm_ippool \ --without-rlm_sql_unixodbc \ --without-rlm_counter \ --without-rlm_dbm \ --without-rlm_eap_tnc \ --without-rlm-krb5 \ --without-rlm-eap_ikev2 \ --without-rlm-perl \ --without-rlm-pam \ --without-rlm_sql_iodbc \ --without-rlm_python \ --without-rlm_sql_oracle \ --without-rlm_sql_postgresql \ --with-dhcp \ --with-talloc-include-dir=/home/mega/leaf/devel/master-new-openssl/staging/x86_64-unknown-linux-uclibc/usr/include/samba \ --with-talloc-lib-dir=/home/mega/leaf/devel/master-new-openssl/staging/x86_64-unknown-linux-uclibc/usr/lib \ --with-mysql-dir=/home/mega/leaf/devel/master-new-openssl/staging/x86_64-unknown-linux-uclibc/usr Now I commented out the offending macros and ran mega@leafbuilder:~/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius/freeradius-server-3.0.21$ make reconfig Makefile:38: *** Missing 'Make.inc' Run './configure [options]' and retry. Stop. OK so rerunning configure yields checking for __builtin_choose_expr support in compiler... configure: error: in `/home/mega/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius/freeradius-server-3.0.21': configure: error: cannot run test program while cross compiling See `config.log' for more details Obviously the modified configure.ac did not build a new configure script. Using autogen.sh before did. There must be a proper way to rebuild configure here. Thanks ET -- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com
Hi Alan Am 16.10.2020 um 00:26 schrieb Alan DeKok: ....
As I said... don't use "autogen.sh". This doesn't mean "leave the output of autopen.sh alone, and try to do something on top of that". It means start over.
I just started over again but instead of running autogen.sh I just ran autoconf. I found that it was our makefile which ran the incriminating sed on libtool, so now configure is built with the intended exceptions. So far so good, the first few modules are built but later on the make process tries to run jlibtool: LN-S raddb/mods-enabled/replicate LN-S raddb/mods-enabled/soh LN-S raddb/mods-enabled/sradutmp LN-S raddb/mods-enabled/unix LN-S raddb/mods-enabled/unpack LN-S raddb/mods-enabled/utf8 CC src/lib/cbuff.c CC src/lib/cursor.c CC src/lib/debug.c make[1]: /home/mega/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius/freeradius-server-3.0.21/build/make/jlibtool: Command not found The jlibtool binary is built but cannot be executed possibly because it is built for the target architecture. mega@leafbuilder:~/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius/freeradius-server-3.0.21/build/make$ ls jlibtool mega@leafbuilder:~/leaf/devel/master-new-openssl/source/x86_64-unknown-linux-uclibc/radius/freeradius-server-3.0.21/build/make$ ./jlibtool -bash: ./jlibtool: No such file or directory Do I need to find a way to build jlibtool for the host before trying to compile freeradius and if so where to begin. Thanks ET -- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com
On Oct 16, 2020, at 4:56 AM, Erich Titl <erich.titl@think.ch> wrote:
I just started over again but instead of running autogen.sh I just ran autoconf. I found that it was our makefile which ran the incriminating sed on libtool, so now configure is built with the intended exceptions.
That's better.
So far so good, the first few modules are built but later on the make process tries to run jlibtool: ..
Do I need to find a way to build jlibtool for the host before trying to compile freeradius and if so where to begin.
Yes. mkdir build/make gcc scripts/jlibtool.c -o build/make/jlibtool That's it. Alan DeKok.
Am 16.10.2020 um 14:15 schrieb Alan DeKok:
On Oct 16, 2020, at 4:56 AM, Erich Titl <erich.titl@think.ch> wrote:
I just started over again but instead of running autogen.sh I just ran autoconf. I found that it was our makefile which ran the incriminating sed on libtool, so now configure is built with the intended exceptions.
That's better.
So far so good, the first few modules are built but later on the make process tries to run jlibtool: ..
Do I need to find a way to build jlibtool for the host before trying to compile freeradius and if so where to begin.
Yes.
mkdir build/make gcc scripts/jlibtool.c -o build/make/jlibtool
I ran make from the main directory then make clean, obviously it left jlibtool. I could then run our variant of the makefile, the rest is history. Thanks a lot for your help and patience. ET -- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com
participants (2)
-
Alan DeKok -
Erich Titl