3.0 (master) build error
Hi, Not sure if this mail is better of freeradius-devel or -user. I'm posting it to -devel since 3.0 is not released yet. I'm trying to build master branch (last commit d1dfb80) on Ubuntu natty (gcc-4.5.2) with a simple ./configure && make, and the build failed with this error: CC listen.c listen.c: In function 'proxy_new_listener': listen.c:2403:21: error: 'buffer' undeclared (first use in this function) listen.c:2403:21: note: each undeclared identifier is reported only once for each function it appears in listen.c: In function 'listen_init': listen.c:2863:4: warning: passing argument 1 of 'cf_sectiontoitem' discards qualifiers from pointer target type /data/build/freeradius-server-3.0.0/src/freeradius-devel/conffile.h:101:12: note: expected 'struct CONF_SECTION *' but argument is of type 'const struct CONF_SECTION *' listen.c:2864:4: warning: passing argument 1 of 'cf_sectiontoitem' discards qualifiers from pointer target type /data/build/freeradius-server-3.0.0/src/freeradius-devel/conffile.h:101:12: note: expected 'struct CONF_SECTION *' but argument is of type 'const struct CONF_SECTION *' listen.c: At top level: listen.c:54:13: warning: 'print_packet' defined but not used make[4]: *** [listen.lo] Error 1 make[3]: *** [main] Error 2 make[2]: *** [all] Error 2 make[1]: *** [src] Error 2 make: *** [all] Error 2 Any known workaround for this? -- Fajar
Fajar A. Nugraha wrote:
Not sure if this mail is better of freeradius-devel or -user. I'm posting it to -devel since 3.0 is not released yet. I'm trying to build master branch (last commit d1dfb80) on Ubuntu natty (gcc-4.5.2) with a simple ./configure && make, and the build failed with this error:
I've pushed a tiny fix. Alan DeKok.
On Mon, Jan 9, 2012 at 4:59 PM, Alan DeKok <aland@deployingradius.com> wrote:
Fajar A. Nugraha wrote:
I'm trying to build master branch (last commit d1dfb80) on Ubuntu natty (gcc-4.5.2) with a simple ./configure && make, and the build failed with this error:
I've pushed a tiny fix.
Thanks. I kinda suspect it was something like that :D Some more observations (just curious, not important) - rlm_protocol_filter is now removed. No problem though, it's explained in git log - radeapclient is not built by default. There's a comment about it on git log, but no additional explanation. Is there a documentation on the reasoning somewhere? What IS important, is that I noticed sql.conf and eap.conf is now moved to modules/. AFAIK all files in modules/ is included and parsed by the server. This might be a problem in the following scenarios: - user install FR3 package (e.g. rpm/deb) - user modifies modules/sql or modules/eap - user upgrades FR3 package, and since the two files changed, new files will be created (e.g. modules/sql.rpmnew or modules/sql.dpkg-new) - both files (e.g. modules/sql and modules/sql.rpmnew) is included and parsed by the server, and both define the same module instance. This might mean the wrong instance is used, or at minimum create a confusion. What is the recommended way to solve this problem? Should packagers warn users "don't edit any file in modules/*, instead copy to a new file and assign new instance name"? -- Fajar
Hi,
by the server. This might be a problem in the following scenarios: - user install FR3 package (e.g. rpm/deb) - user modifies modules/sql or modules/eap - user upgrades FR3 package, and since the two files changed, new files will be created (e.g. modules/sql.rpmnew or modules/sql.dpkg-new) - both files (e.g. modules/sql and modules/sql.rpmnew) is included and parsed by the server, and both define the same module instance. This might mean the wrong instance is used, or at minimum create a confusion.
What is the recommended way to solve this problem? Should packagers warn users "don't edit any file in modules/*, instead copy to a new file and assign new instance name"?
Isn't that the exact same issue that all other modules/* files have, also now in 2.x? Say, I edited modules/detail.log because I don't like the default paths. Same thing is going to happen. IMHO, the creation of .rpmnew files is to blame in this case. RPM shouldn't do that. Not that I mind; installing from source is the way to go anyway :-) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
On Tue, Jan 10, 2012 at 1:49 PM, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
by the server. This might be a problem in the following scenarios: - user install FR3 package (e.g. rpm/deb) - user modifies modules/sql or modules/eap - user upgrades FR3 package, and since the two files changed, new files will be created (e.g. modules/sql.rpmnew or modules/sql.dpkg-new) - both files (e.g. modules/sql and modules/sql.rpmnew) is included and parsed by the server, and both define the same module instance. This might mean the wrong instance is used, or at minimum create a confusion.
What is the recommended way to solve this problem? Should packagers warn users "don't edit any file in modules/*, instead copy to a new file and assign new instance name"?
Isn't that the exact same issue that all other modules/* files have, also now in 2.x? Say, I edited modules/detail.log because I don't like the default paths.
Correct. However, in v2.x several commonly-edited modules was not located in modules/, but rather as files under raddb directly (e.g. eap.conf, sql.conf, sqlipool.conf). If they edit those files (which, most of the time they must, to get it to work), the extra .rpmnew/.dpkg-new files wont matter because they won't be read.
Same thing is going to happen. IMHO, the creation of .rpmnew files is to blame in this case. RPM shouldn't do that.
AFAIK neither rpm or deb has the option to say "this is a config file. If this file changed, don't write anything, not even a .*new file"
Not that I mind; installing from source is the way to go anyway :-)
Packages makes it easier to manage many servers :) I'm thinking one of these options would make sense: (1) Do it like sites-available and sites-enabled. That is, have a directory (e.g. modules-enabled) which simply contains symlinks to files in modules directory. Easy enough for packagers to implement by themselves without changing upstream source (2) Force users "don't edit any file in modules/*, instead copy to a new file and assign new instance name". (3) Modify FR code so that it blacklists several extensions, like logrotate does via "tabooext" directive. -- Fajar
Hi,
I'm thinking one of these options would make sense: (1) Do it like sites-available and sites-enabled. That is, have a directory (e.g. modules-enabled) which simply contains symlinks to files in modules directory. Easy enough for packagers to implement by themselves without changing upstream source
check the mailing list archive - we've already had this discussion :-) alan
On Tue, Jan 10, 2012 at 4:46 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
I'm thinking one of these options would make sense: (1) Do it like sites-available and sites-enabled. That is, have a directory (e.g. modules-enabled) which simply contains symlinks to files in modules directory. Easy enough for packagers to implement by themselves without changing upstream source
check the mailing list archive - we've already had this discussion :-)
Which one? This one? http://lists.cistron.nl/pipermail/freeradius-users/2008-December/msg00103.ht... If yes, I'll implement (1) anyway for my systems. While it's true that in general a sysadmin should pay attention on system updates (including any warning messages) and resolve it, if there's a solution that would make a sysadmin job easier then I'll take it. Especially if you have systems configured with automatic/unattended updates. If no, then please point to the relevant thread since my Google-foo obviously failed :) In any case, thanks for the responses. Playing with the dhcp server now ... -- Fajar
On Tue, Jan 10, 2012 at 5:48 PM, Alan DeKok <aland@deployingradius.com> wrote:
Fajar A. Nugraha wrote:
In any case, thanks for the responses. Playing with the dhcp server now ...
There are a bunch of fixes which need to be ported from v2.1.x to master branch. They make the DHCP server work in more circumstances.
Ah, OK. I was able to do some testing with DHCP in 3.x and it works, but looking at 2.x (the config file, at least) there are indeed improvements there. Will try 2.x later. So my build result with 3.x is basically like this: - simple ./configure && make works - using "./configure --enable-ltdl-install=no --with-system-libtool --with-system-libltdl && make" does NOT work, ‘lt_dladvise’ undeclared error. Editing src/include/modpriv.h to force #include "ltdl.h" made the compile process worked again. This breaks plain "./configure" though. I'm guessing commit ce27f4e from v2.1.x was not completely ported yet. - "dpkg-buildpackage -b" failed with "Patch sql_modules.diff does not exist". I was able to work around this by using Ubuntu's debian directory, and editing some parts manually. -- Fajar
Fajar A. Nugraha wrote:
Ah, OK. I was able to do some testing with DHCP in 3.x and it works, but looking at 2.x (the config file, at least) there are indeed improvements there. Will try 2.x later.
There are a number of code changes, too.
So my build result with 3.x is basically like this: - simple ./configure && make works - using "./configure --enable-ltdl-install=no --with-system-libtool --with-system-libltdl && make" does NOT work, ‘lt_dladvise’ undeclared error.
What it the *actual* error? lt_dladvise is a structure. The configure script checks for lt_dladvise_init(). If that function exists, so does lt_dladvise. So my question is *why* does it find lt_dladvise_init(), and *where* is it found?
Editing src/include/modpriv.h to force #include "ltdl.h" made the compile process worked again. This breaks plain "./configure" though. I'm guessing commit ce27f4e from v2.1.x was not completely ported yet.
No, that functionality was back-ported from 3.0 to v2.1.x. It exists in 3.0, in modpriv.h. You should have seen that when editing modpriv.h. If you didn't see it, it's because you have an old copy of the source.
- "dpkg-buildpackage -b" failed with "Patch sql_modules.diff does not exist".
The file is in debian/patches. If you don't see it, it's because you don't have 3.0. Alan DeKok.
On Wed, Jan 11, 2012 at 7:05 PM, Alan DeKok <aland@deployingradius.com> wrote:
Fajar A. Nugraha wrote:
Ah, OK. I was able to do some testing with DHCP in 3.x and it works, but looking at 2.x (the config file, at least) there are indeed improvements there. Will try 2.x later.
There are a number of code changes, too.
After some testing I'm finding it hard to get 2.x DHCP to work properly, while in 3.x at least a linux client using "dhclient" was able to get correct response. I'll post more about this in a separate thread. Would freeradius-user be more appropriate for this?
So my build result with 3.x is basically like this: - simple ./configure && make works - using "./configure --enable-ltdl-install=no --with-system-libtool --with-system-libltdl && make" does NOT work, ‘lt_dladvise’ undeclared error.
What it the *actual* error? lt_dladvise is a structure. The configure script checks for lt_dladvise_init(). If that function exists, so does lt_dladvise.
So my question is *why* does it find lt_dladvise_init(), and *where* is it found?
Sorry, I was trying several build scenarios and forgot to copy the exact message. Just retried it with ./configure --enable-ltdl-install=no --with-system-libtool --with-system-libltdl && make Last few lines of output: CC modules.c modules.c: In function ‘fr_dlopenext’: modules.c:252:2: error: ‘lt_dladvise’ undeclared (first use in this function) modules.c:252:2: note: each undeclared identifier is reported only once for each function it appears in modules.c:252:14: error: expected ‘;’ before ‘advise’ modules.c:254:2: warning: implicit declaration of function ‘lt_dladvise_init’ modules.c:254:26: error: ‘advise’ undeclared (first use in this function) modules.c:255:6: warning: implicit declaration of function ‘lt_dladvise_ext’ modules.c:256:6: warning: implicit declaration of function ‘lt_dladvise_global’ modules.c:257:3: warning: implicit declaration of function ‘lt_dlopenadvise’ modules.c:260:2: warning: implicit declaration of function ‘lt_dladvise_destroy’ make[4]: *** [modules.lo] Error 1 make[3]: *** [main] Error 2 make[2]: *** [all] Error 2 make[1]: *** [src] Error 2 make: *** [all] Error 2
Editing src/include/modpriv.h to force #include "ltdl.h" made the compile process worked again. This breaks plain "./configure" though. I'm guessing commit ce27f4e from v2.1.x was not completely ported yet.
No, that functionality was back-ported from 3.0 to v2.1.x. It exists in 3.0, in modpriv.h. You should have seen that when editing modpriv.h.
It's there, but enclosed in an #ifdef block. My change: https://github.com/fajarnugraha/freeradius-server/commit/2403743 Not good, but at least it builds. I'm guessing that somehow WITH_SYSTEM_LTDL was not defined in my original 3.x build. In case it matters, I use ubuntu natty with libltdl7 2.2.6b-2ubuntu3 and libltdl-dev 2.2.6b-2ubuntu3.
If you didn't see it, it's because you have an old copy of the source.
I cloned https://github.com/alandekok/freeradius-server.git, last commit was b575b38 : Always use buffer
- "dpkg-buildpackage -b" failed with "Patch sql_modules.diff does not exist".
The file is in debian/patches.
It's not on https://github.com/alandekok/freeradius-server/tree/master/debian/patches -- Fajar
Fajar A. Nugraha wrote:
After some testing I'm finding it hard to get 2.x DHCP to work properly, while in 3.x at least a linux client using "dhclient" was able to get correct response. I'll post more about this in a separate thread. Would freeradius-user be more appropriate for this?
No, -devel is OK.
Sorry, I was trying several build scenarios and forgot to copy the exact message. Just retried it with
./configure --enable-ltdl-install=no --with-system-libtool --with-system-libltdl && make
Last few lines of output: ... modules.c:254:2: warning: implicit declaration of function ‘lt_dladvise_init’
OK... I've committed a patch which should help. You'll have do re-do "configure"
- "dpkg-buildpackage -b" failed with "Patch sql_modules.diff does not exist". The file is in debian/patches.
It's not on https://github.com/alandekok/freeradius-server/tree/master/debian/patches
I've added it. It should be there now. I haven't tested the debian build. Alan DeKok.
On Wed, Jan 11, 2012 at 10:34 PM, Alan DeKok <aland@deployingradius.com> wrote:
./configure --enable-ltdl-install=no --with-system-libtool --with-system-libltdl && make
Last few lines of output: ... modules.c:254:2: warning: implicit declaration of function ‘lt_dladvise_init’
OK... I've committed a patch which should help. You'll have do re-do "configure"
Unfortunately it still failed. Pulled up to 4ea1acf: "Install the README, too", Still the same error Making all in src/main... CC modules.c modules.c: In function ‘fr_dlopenext’: modules.c:252:2: error: ‘lt_dladvise’ undeclared (first use in this function) modules.c:252:2: note: each undeclared identifier is reported only once for each function it appears in modules.c:252:14: error: expected ‘;’ before ‘advise’ modules.c:254:2: warning: implicit declaration of function ‘lt_dladvise_init’ modules.c:254:26: error: ‘advise’ undeclared (first use in this function) modules.c:255:6: warning: implicit declaration of function ‘lt_dladvise_ext’ modules.c:256:6: warning: implicit declaration of function ‘lt_dladvise_global’ modules.c:257:3: warning: implicit declaration of function ‘lt_dlopenadvise’ modules.c:260:2: warning: implicit declaration of function ‘lt_dladvise_destroy’ make[4]: *** [modules.lo] Error 1 make[3]: *** [main] Error 2 make[2]: *** [all] Error 2 make[1]: *** [src] Error 2 make: *** [all] Error 2
- "dpkg-buildpackage -b" failed with "Patch sql_modules.diff does not exist". The file is in debian/patches.
It's not on https://github.com/alandekok/freeradius-server/tree/master/debian/patches
I've added it. It should be there now. I haven't tested the debian build.
Yup, it's there now, but still failed to build as well. Applying patch radiusd-to-freeradius.diff patching file Make.inc.in patching file raddb/radiusd.conf.in Hunk #2 succeeded at 465 (offset 2 lines). Applying patch sql_modules.diff patching file raddb/modules/sql Hunk #1 FAILED at 103. 1 out of 1 hunk FAILED -- rejects in file raddb/modules/sql patching file raddb/modules/sqlippool Hunk #1 FAILED at 46. Hunk #2 FAILED at 63. 2 out of 2 hunks FAILED -- rejects in file raddb/modules/sqlippool Patch sql_modules.diff does not apply (enforce with -f) make: *** [debian/stamp-patched] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 This one seems easier to fix. However successful debian build would still also depend on libltdl problem fixed. -- Fajar
On Thu, Jan 12, 2012 at 2:47 PM, Alan DeKok <aland@deployingradius.com> wrote:
Fajar A. Nugraha wrote:
Unfortunately it still failed. Pulled up to 4ea1acf: "Install the README, too", Still the same error
OK, I did one last push (missed in the last commit)
Thanks, that last one did it. The debian package build still failed though due to two incorrect pacthes. The fix is trivial, I've sent a pull request on github for that. On a side note, I see that the bundled debian directory is somewhat different than what's in Ubuntu. For example, [modules|mods-available]/sql* is included in freeradius-mysql, while in Ubuntu all that is in freeradius, which makes more sense, since it should be driver-independent. Would you be interested in merging additional changes that would make upstream debian directory closer to ubuntu/debian's? -- Fajar
Fajar A. Nugraha wrote:
On a side note, I see that the bundled debian directory is somewhat different than what's in Ubuntu. For example, [modules|mods-available]/sql* is included in freeradius-mysql, while in Ubuntu all that is in freeradius, which makes more sense, since it should be driver-independent.
Sure. I'm a bit ambivalent about it. If the sql configuration is *also* part of freeradius-postgresql, etc. packages, then it's OK. Or, we could have a "virtual" freeradius-sql package which contains the configuration, and have the -mysql package depend on that. But a virtual package may be a bit of overkill.
Would you be interested in merging additional changes that would make upstream debian directory closer to ubuntu/debian's?
Yes. Alan DeKok.
On Thu, Jan 12, 2012 at 3:29 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
modules.c: In function ‘fr_dlopenext’: modules.c:252:2: error: ‘lt_dladvise’ undeclared (first use in this function)
does your system libltdl includes have the lt_dladvise function? or is it old?
It should, since 2.x build just fine with the same configure flag. Alan's latest commit also fixed the build for 3.x. -- Fajar
Fajar A. Nugraha wrote:
Some more observations (just curious, not important) - rlm_protocol_filter is now removed. No problem though, it's explained in git log
No one used it so far as I know.
- radeapclient is not built by default. There's a comment about it on git log, but no additional explanation. Is there a documentation on the reasoning somewhere?
radclient now does MS-CHAP. For other EAP tests, use eapol_test. It's better.
What IS important, is that I noticed sql.conf and eap.conf is now moved to modules/. AFAIK all files in modules/ is included and parsed .. What is the recommended way to solve this problem?
raddb/mods-available raddb/mods-enabled Like most other software. Alan DeKok.
participants (4)
-
Alan Buxey -
Alan DeKok -
Fajar A. Nugraha -
Stefan Winter