building debian package - rlm_sql is not portable
Hi, I'm trying to build debian package with fakeroot dpkg-buildpackage -b -uc for freeradius 2.2.3 on ubuntu 13.10 64 bit (3.11.0-15-generic) but i have this error: if [ "xrlm_sqlcounter" != "x" ]; then \ /home/ntt/freeradius-server-2.2.3/libtool --mode=install /home/ntt/freeradius-server-2.2.3/install-sh -c -c \ rlm_sqlcounter.la/home/ntt/freeradius-server-2.2.3/debian/tmp//usr/local/lib/ rlm_sqlcounter.la || exit $?; \ rm -f /home/ntt/freeradius-server-2.2.3/debian/tmp//usr/local/lib/ rlm_sqlcounter-2.2.3.la; \ ln -s rlm_sqlcounter.la/home/ntt/freeradius-server-2.2.3/debian/tmp//usr/local/lib/ rlm_sqlcounter-2.2.3.la || exit $?; \ fi libtool: install: warning: relinking `rlm_sqlcounter.la' (cd /home/ntt/freeradius-server-2.2.3/src/modules/rlm_sqlcounter; /bin/bash /home/ntt/freeradius-server-2.2.3/libtool --mode=relink gcc -release 2.2.3 -module -export-dynamic -o rlm_sqlcounter.la -rpath /usr/local/lib rlm_sqlcounter.lo rlm_sqlcounter.c /home/ntt/freeradius-server-2.2.3/src/lib/libfreeradius-radius.la/home/ntt/freeradius-server-2.2.3/src/modules/rlm_sql/.libs/ rlm_sql.la -lcrypto -lssl -lcrypto -lcrypto -lnsl -lresolv -pthread -inst-prefix-dir /home/ntt/freeradius-server-2.2.3/debian/tmp/) *** Warning: Linking the shared library rlm_sqlcounter.la against the loadable module *** rlm_sql.so is not portable! gcc -shared .libs/rlm_sqlcounter.o -L/home/ntt/freeradius-server-2.2.3/debian/tmp//usr/local/lib -L/usr/local/lib -lfreeradius-radius -lrlm_sql -lssl -lcrypto -lnsl -lresolv -pthread -Wl,-soname -Wl,rlm_sqlcounter-2.2.3.so -o .libs/ rlm_sqlcounter-2.2.3.so /usr/bin/ld: cannot find -lrlm_sql collect2: error: ld returned 1 exit status libtool: install: error: relink `rlm_sqlcounter.la' with the above command before installing it make[8]: *** [install] Error 1 If i try to compile (with ./configure and make) it works. Where i'm wrong? Thanks
Marco Marino wrote:
I'm trying to build debian package with fakeroot dpkg-buildpackage -b -uc
for freeradius 2.2.3 on ubuntu 13.10 64 bit (3.11.0-15-generic)
It should work...
... /home/ntt/freeradius-server-2.2.3/src/modules/rlm_sql/.libs/rlm_sql.la
Which means "link that specific file"
-L/home/ntt/freeradius-server-2.2.3/debian/tmp//usr/local/lib -L/usr/local/lib -lfreeradius-radius -lrlm_sql
And libtool turns that into "link to librlm_sql.so", which doesn't exist. <sigh> There's a reason we deleted libtool in the v3 branch. Libtool claims to make things easier. All it does is screw things up worse.
If i try to compile (with ./configure and make) it works. Where i'm wrong?
libtool is a horrible piece of software. Just do "./configure;make;make install" for now. Or, run v3. Alan DeKok.
Ok, I understand. I compile (and build debian packages of) freeradius3 without any problems. I need debian package of my own freeradius because i wrote a custom version of rlm_counter module. Some features: 1) Differentiated counters per Realm or per NAS-Identifier (Using some custom parameters in the modules/counter configuration file) 2) Possibility of saving daily (or monthly, but not yet tested) expired gdbm databases 3) Differentiated values of reply and check attributes per Realm ( or per NAS-Identifier) My patch works well with my use-case. I don't known if this patch can be useful because i don't have an enhanced knowledge of freeradius. I ask: Are these features useful? Should i post my modified version of rlm_counter module? If I should, i can upgrade my modules for freeradius 3 compatibility and post some code in about on month (sorry, i'm really overloaded of work) By the way, i will use freeradius3 instead of freeradius 2.2.3. Compile is really easy. Thanks 2014-02-12 14:50 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
Marco Marino wrote:
I'm trying to build debian package with fakeroot dpkg-buildpackage -b -uc
for freeradius 2.2.3 on ubuntu 13.10 64 bit (3.11.0-15-generic)
It should work...
... /home/ntt/freeradius-server-2.2.3/src/modules/rlm_sql/.libs/rlm_sql.la
Which means "link that specific file"
-L/home/ntt/freeradius-server-2.2.3/debian/tmp//usr/local/lib -L/usr/local/lib -lfreeradius-radius -lrlm_sql
And libtool turns that into "link to librlm_sql.so", which doesn't exist.
<sigh> There's a reason we deleted libtool in the v3 branch. Libtool claims to make things easier. All it does is screw things up worse.
If i try to compile (with ./configure and make) it works. Where i'm wrong?
libtool is a horrible piece of software.
Just do "./configure;make;make install" for now.
Or, run v3.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 12 Feb 2014, at 18:40, Marco Marino <marino.mrc@gmail.com> wrote:
Ok, I understand. I compile (and build debian packages of) freeradius3 without any problems. I need debian package of my own freeradius because i wrote a custom version of rlm_counter module. Some features: 1) Differentiated counters per Realm or per NAS-Identifier (Using some custom parameters in the modules/counter configuration file) 2) Possibility of saving daily (or monthly, but not yet tested) expired gdbm databases 3) Differentiated values of reply and check attributes per Realm ( or per NAS-Identifier)
My patch works well with my use-case. I don't known if this patch can be useful because i don't have an enhanced knowledge of freeradius. I ask: Are these features useful? Should i post my modified version of rlm_counter module? If I should, i can upgrade my modules for freeradius 3 compatibility and post some code in about on month (sorry, i'm really overloaded of work)
Post the patch as is, we'll see if it's useful and let you know.
By the way, i will use freeradius3 instead of freeradius 2.2.3. Compile is really easy.
Yes, a great deal of effort was put into fixing the build system and configure scripts for 3.x.x. Almost every Makefile in the server was rewritten. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Ok, this is my version of rlm_counter (and an example of the configuration file i'm using). Pay attention please: Code is really sketchy!!! I just need to known if these features can be useful. If the case, i give you a more stable (and precise) code. In this version saving expired gdbm databases is not possible. Furthermore, there are some conceptual errors. e.g.: i'm using a concatenated list for saving realms or nas-identifiers. This is wrong (search complexity is O(n) ). Hash table is better (O(1)).... but we can discuss it later. Thanks 2014-02-12 19:56 GMT+01:00 Arran Cudbard-Bell <a.cudbardb@freeradius.org>:
On 12 Feb 2014, at 18:40, Marco Marino <marino.mrc@gmail.com> wrote:
Ok, I understand. I compile (and build debian packages of) freeradius3 without any problems. I need debian package of my own freeradius because i wrote a custom version of rlm_counter module. Some features: 1) Differentiated counters per Realm or per NAS-Identifier (Using some custom parameters in the modules/counter configuration file) 2) Possibility of saving daily (or monthly, but not yet tested) expired gdbm databases 3) Differentiated values of reply and check attributes per Realm ( or per NAS-Identifier)
My patch works well with my use-case. I don't known if this patch can be useful because i don't have an enhanced knowledge of freeradius. I ask: Are these features useful? Should i post my modified version of rlm_counter module? If I should, i can upgrade my modules for freeradius 3 compatibility and post some code in about on month (sorry, i'm really overloaded of work)
Post the patch as is, we'll see if it's useful and let you know.
By the way, i will use freeradius3 instead of freeradius 2.2.3. Compile is really easy.
Yes, a great deal of effort was put into fixing the build system and configure scripts for 3.x.x. Almost every Makefile in the server was rewritten.
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Marco Marino