cross compiling freeradius

classic Classic list List threaded Threaded
13 messages Options
| Threaded
Open this post in threaded view
|

cross compiling freeradius

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

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: cross compiling freeradius

Alan DeKok-2
On Oct 15, 2020, at 4:46 AM, Erich Titl <[hidden email]> 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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: cross compiling freeradius

Erich Titl
Hi Alan

Am 15.10.2020 um 14:12 schrieb Alan DeKok:

> On Oct 15, 2020, at 4:46 AM, Erich Titl <[hidden email]> 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

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: cross compiling freeradius

Erich Titl
In reply to this post by Alan DeKok-2
Hi Alan

Am 15.10.2020 um 14:12 schrieb Alan DeKok:
> On Oct 15, 2020, at 4:46 AM, Erich Titl <[hidden email]> 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

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: cross compiling freeradius

Alan DeKok-2
On Oct 15, 2020, at 1:15 PM, Erich Titl <[hidden email]> 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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: cross compiling freeradius

Erich Titl
Hi Alan

Am 15.10.2020 um 19:23 schrieb Alan DeKok:
> On Oct 15, 2020, at 1:15 PM, Erich Titl <[hidden email]> 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

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: cross compiling freeradius

Alan DeKok-2
On Oct 15, 2020, at 6:08 PM, Erich Titl <[hidden email]> 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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: cross compiling freeradius

Erich Titl
Am 16.10.2020 um 00:12 schrieb Alan DeKok:

> On Oct 15, 2020, at 6:08 PM, Erich Titl <[hidden email]> 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


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: cross compiling freeradius

Alan DeKok-2
On Oct 15, 2020, at 6:18 PM, Erich Titl <[hidden email]> 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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: cross compiling freeradius

Erich Titl
Hi Alan

Am 16.10.2020 um 00:26 schrieb Alan DeKok:

> On Oct 15, 2020, at 6:18 PM, Erich Titl <[hidden email]> 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

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: cross compiling freeradius

Erich Titl
In reply to this post by Alan DeKok-2
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

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: cross compiling freeradius

Alan DeKok-2
On Oct 16, 2020, at 4:56 AM, Erich Titl <[hidden email]> 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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: cross compiling freeradius

Erich Titl
Am 16.10.2020 um 14:15 schrieb Alan DeKok:

> On Oct 16, 2020, at 4:56 AM, Erich Titl <[hidden email]> 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

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html