Problems compiling Linux-PAM-0.66 (possible hassle with egcs or glibc)
CaT
cat@zip.com.au
Mon May 31 21:06:00 GMT 1999
Andreas Jaeger wrote the following:
>
> >>>>> CaT writes:
>
> CaT> I just sent the letter below (well that's the relevant bit ;) to the
> CaT> pam mailinglist. After a brief exchange it was said that either glibc
> CaT> or egcs might be the problem here. The include file involved is
> CaT> string.h and I could not find what was wrong with it, _pam.macros.h
> CaT> or pam_access.c that would cause this.
>
> CaT> As such I was wondering if either of you guys could help out here.
> CaT> I use glibc2.1 with egcs 1.1.2 and linux 2.2.7ac4. The pam source
> CaT> code was acquired from the 0.66 tarball that's on any of the linux
> CaT> mirrors.
>
> CaT> Any and all help would be greatly appreciated. I'd like to get this
> CaT> sucker to compile. :/
>
> Without seeing the code that has problems, I guess FAQ 3.8. applies
> (appended below).
Many thanks to both you and Franz Sirl for pointing me in the right
direction. This did indeed fix that compile problem. :)
Where is this FAQ btw?
I'm sending this to the pam list aswell as it'll be useful info there
incase someone else has the same problem (and this is the reason why the
rest of the msg is quoted below). Also, I have another hassle and am
unsure as to how to cure it. When I applied the debian patch a week or
so back in an attempt to cure the previous error (which it did. I just
didn't know how exactly) I got this one also.
gcc -O3 -fomit-frame-pointer -march=pentiumpro -pipe -DLINUX_PAM -ansi -D_POSIX_SOURCE -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wtraditional -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -pedantic -I/felix/src/Linux-PAM/include -fPIC -Dlinux -Di386 -DPAM_DYNAMIC -c pam_filter.c -o dynamic/pam_filter.o
pam_filter.c: In function `_pam_log':
pam_filter.c:71: warning: implicit declaration of function `vsyslog'
pam_filter.c: In function `set_filter':
pam_filter.c:337: `XCASE' undeclared (first use in this function)
pam_filter.c:337: (Each undeclared identifier is reported only once
pam_filter.c:337: for each function it appears in.)
make[2]: *** [dynamic/pam_filter.o] Error 1
make[2]: Leaving directory `/felix/src/Linux-PAM/modules/pam_filter'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/felix/src/Linux-PAM/modules'
-----------------
> 3.8. I've got errors compiling code that uses certain string
> functions. Why?
>
> {AJ} glibc 2.1 has special string functions that are faster than the normal
> library functions. Some of the functions are additionally implemented as
> inline functions and others as macros. This might lead to problems with
> existing codes but it is explicitly allowed by ISO C.
>
> The optimized string functions are only used when compiling with
> optimizations (-O1 or higher). The behavior can be changed with two feature
> macros:
>
> * __NO_STRING_INLINES: Don't do any string optimizations.
> * __USE_STRING_INLINES: Use assembly language inline functions (might
> increase code size dramatically).
>
> Since some of these string functions are now additionally defined as macros,
> code like "char *strncpy();" doesn't work anymore (and is unnecessary, since
> <string.h> has the necessary declarations). Either change your code or
> define __NO_STRING_INLINES.
>
> {UD} Another problem in this area is that gcc still has problems on machines
> with very few registers (e.g., ix86). The inline assembler code can require
> almost all the registers and the register allocator cannot always handle
> this situation.
>
> One can disable the string optimizations selectively. Instead of writing
>
> cp = strcpy (foo, "lkj");
>
> one can write
>
> cp = (strcpy) (foo, "lkj");
>
> This disables the optimization for that specific call.
--
CaT (cat@zip.net.au) URL: http://www.zip.com.au/dev/null
For a bad joke read:
http://www2.hunterlink.net.au/~ddhrg/censorship_legislation.html
More information about the Gcc-bugs
mailing list