> Subject: Re: FYI & question: Linux-PAM modules on Solaris > Date: Fri, 25 May 2001 10:03:39 -0700 > From: Andrew Morgan <morgan@transmeta.com> > Reply-To: pam-list@redhat.com > Organization: Transmeta Corporation > To: pam-list@redhat.com > References: <3B0D7DFA.49451E79@sprintmail.com> > > Jonathan Sturges wrote: > > > 272,273c272,273 > > < LD_D="ld -G -z redlocsym" > > < LD_L="ld -G -z redlocsym" > > --- > > > LD_D="gcc -shared -Xlinker -x" > > > LD_L="$LD -x -shared" > > What does this look like as a 'diff -u' patch? (This gives me a little > more context.) > > Here is a diff against CVS top of trunk, it looks a little different to > yours, but does it work for you? > > Index: configure.in > =================================================================== > RCS file: /cvsroot/pam/Linux-PAM/configure.in,v > retrieving revision 1.16 > diff -u -r1.16 configure.in > --- configure.in 2001/05/08 05:02:50 1.16 > +++ configure.in 2001/05/25 17:01:45 > @@ -319,8 +319,8 @@ > PIC="-K pic" > DYNTYPE=so > LD=ld > - LD_D="cc -z text -G -R." > - LD_L="$LD_D" > + LD_D="ld -G -z redlocsym" > + LD_L="ld -G -z redlocsym" > RANLIB=ranlib > STRIP=strip > CC_STATIC= > > Thanks > > Andrew Andrew, Sorry for the delay, but Sun's diff doesn't support -u, so I had to go get GNU diffutils. The diff you sent me seems to be from a newer version of configure.in; maybe from a current development tree, not 0.75 release? At any rate, it would not apply (note: I'm using GNU patch v2.5.4). Anyway, here's GNU 'diff -u' output from my system: --- Linux-PAM-0.75-clean/configure.in Sun Mar 18 20:56:36 2001 +++ Linux-PAM-0.75-good/configure.in Wed May 23 15:48:04 2001 @@ -269,8 +269,8 @@ PIC="-fPIC" #can/should we use LD=gcc ??? LD=ld - LD_D="gcc -shared -Xlinker -x" - LD_L="$LD -x -shared" + LD_D="ld -G -z redlocsym" + LD_L="ld -G -z redlocsym" RANLIB=ranlib STRIP=strip CC_STATIC="-Xlinker -export-dynamic" Remember, however, that 'configure' seems to fail after applying this to configure.in. I don't know why. The way I originally did this was to reverse-engineer it: after running configure with a stock configure.in, I then patched LD_D and LD_L in Make.Rules by hand, and deduced that the LD_D and LD_L values came from configure.in. Therefore, if my process or assumptions are flawed, that may explain why it breaks configure. :) thanks, Jonathan
