Funny, configure's output seems to be fine: checking for pam_start in -lpam... yes checking security/pam_appl.h usability... yes checking security/pam_appl.h presence... yes checking for security/pam_appl.h... yes checking pam/pam_appl.h usability... yes checking pam/pam_appl.h presence... yes checking for pam/pam_appl.h... yes
Well, I solved by changing the module's code (rlm_pam.c), including always my pam header file (witch is placed at /usr/include/pam), without that configure directive. It's definitely not the best way to fix it, but it works. Thanks, On Mon, Nov 9, 2009 at 10:50 PM, John Dennis <[email protected]> wrote: > On 11/09/2009 03:54 PM, Chico Sokol wrote: >> >> Any ideas here? >> >> Somebody have ever built FreeRADIUS with pam module? >> >> On Fri, Nov 6, 2009 at 5:36 PM, Chico Sokol<[email protected]> wrote: >>>> >>>> Did you install these *after* running configure? If so you'll have to >>>> run configure again so it can find them>and set the right compiler flags. >>> >>> No I've ran configure after installing pam package. >>> >>> >>> On Fri, Nov 6, 2009 at 11:47 AM, Alan DeKok<[email protected]> >>> wrote: >>>> >>>> Chico Sokol wrote: >>>>> >>>>> Hum... I need development header files? I have pam installed, and the >>>>> header files does exist at /usr/include/pam: >>>> >>>> <shrug> Then the PAM module and header files are no longer >>>> compatible. I don't use PAM, so I'm not really sure what the underlying >>>> issue is. >>>> >>>> Alan DeKok. > > Beats me, it works perfectly here for the Red Hat packages. On our systems > (e.g. Fedora, RHEL, CentOS) you need to have the pam-devel package > installed. In the output of your configure step you should see something > like this: > > === configuring in src/modules/rlm_pam > checking for i686-pc-linux-gnu-gcc... no > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking how to run the C preprocessor... gcc -E > checking for dlopen in -ldl... yes > checking for pam_start in -lpam... yes > checking for egrep... grep -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking security/pam_appl.h usability... yes > checking security/pam_appl.h presence... yes > checking for security/pam_appl.h... yes > checking pam/pam_appl.h usability... no > checking pam/pam_appl.h presence... no > checking for pam/pam_appl.h... no > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > > > Notice how the configure script in rlm_pam checks for the header file in > both /usr/include/security and /usr/include/pam > > You said your files were installed in /usr/include/pam if I recall > correctly. Is that what your configure output shows? > > If they are and you're getting type errors from the compiler then you've got > bad pam header files. > > > -- > John Dennis <[email protected]> > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > -- Chico Sokol - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
