I was looking for followups to this thread and have searched the archives
for more information without luck. I have a few questions. Has this
project furthered any and where can one get the diffs / source??? Is
there a website that goes in depth about the project.
JOHN
Following on the
On Fri, Aug 27, 1999 at 01:33:03PM -0500, John Sconiers wrote:
I was looking for followups to this thread and have searched the archives
for more information without luck. I have a few questions. Has this
project furthered any and where can one get the diffs / source??? Is
there a
I was looking for followups to this thread and have searched the archives
for more information without luck. I have a few questions. Has this
project furthered any and where can one get the diffs / source??? Is
there a website that goes in depth about the project.
JOHN
Following on the
On Fri, Aug 27, 1999 at 01:33:03PM -0500, John Sconiers wrote:
I was looking for followups to this thread and have searched the archives
for more information without luck. I have a few questions. Has this
project furthered any and where can one get the diffs / source??? Is
there a website
On Thu, 5 Aug 1999, John Polstra wrote:
In article [EMAIL PROTECTED],
Brian F. Feldman [EMAIL PROTECTED] wrote:
Mind pointing me to the technical reason why (I'm sure you've explained
it before) we can't use the dl* calls in any way without linking
against ld-elf.so.1? I mean, have
Mm-hmm. ld -Bshareable as opposed to ar rc.
This demonstrates a superficial understanding of the process, nothing
more.
I just think we're not seeing eye to eye.
I'd be more inclined to say that John simply understands this where
you don't. Go study up, then come back and engage the poor
On Thu, 5 Aug 1999, Jordan K. Hubbard wrote:
Mm-hmm. ld -Bshareable as opposed to ar rc.
This demonstrates a superficial understanding of the process, nothing
more.
I know exactly how an ar archive is made of all the non-PIC .o files and
a ranlib works. I know what happens when ld puts
Peter Jeremy wrote:
I apologize if I gave anyone the impression that you couldn't build
statically linked executables with libpam.
Sorry I was so prickly about it.
I recall having a similar static-vs-dynamic discussion with you a couple
of years ago.
Yow, your memory is better than mine.
On Thu, 5 Aug 1999, John Polstra wrote:
My position was (and still is) that for most purposes dynamic
linking is a definite advantage, but we should continue to permit
static linking for applications that want it (which Sun doesn't).
I generally agree, except I feel that when there are
In article pine.bsf.4.10.9908052127030.86114-100...@janus.syracuse.net,
Brian F. Feldman gr...@freebsd.org wrote:
Mind pointing me to the technical reason why (I'm sure you've explained
it before) we can't use the dl* calls in any way without linking
against ld-elf.so.1? I mean, have them in
On Thu, 5 Aug 1999, John Polstra wrote:
In article pine.bsf.4.10.9908052127030.86114-100...@janus.syracuse.net,
Brian F. Feldman gr...@freebsd.org wrote:
Mind pointing me to the technical reason why (I'm sure you've explained
it before) we can't use the dl* calls in any way without
Mm-hmm. ld -Bshareable as opposed to ar rc.
This demonstrates a superficial understanding of the process, nothing
more.
I just think we're not seeing eye to eye.
I'd be more inclined to say that John simply understands this where
you don't. Go study up, then come back and engage the poor guy
On Thu, 5 Aug 1999, Jordan K. Hubbard wrote:
Mm-hmm. ld -Bshareable as opposed to ar rc.
This demonstrates a superficial understanding of the process, nothing
more.
I know exactly how an ar archive is made of all the non-PIC .o files and
a ranlib works. I know what happens when ld puts
Peter Jeremy [EMAIL PROTECTED] writes:
We need to be able to build an application that has no dynamically
loaded code for recovery purposes (/stand and /sbin) as well as for
security.
Isn't that the same problem as with PAM?
/assar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
Assar Westerlund [EMAIL PROTECTED] wrote:
Peter Jeremy [EMAIL PROTECTED] writes:
We need to be able to build an application that has no dynamically
loaded code for recovery purposes (/stand and /sbin) as well as for
security.
Isn't that the same problem as with PAM?
Quite probably PAM has
John Polstra [EMAIL PROTECTED] wrote:
Peter Jeremy [EMAIL PROTECTED] wrote:
Assar Westerlund [EMAIL PROTECTED] wrote:
Peter Jeremy [EMAIL PROTECTED] writes:
We need to be able to build an application that has no dynamically
loaded code for recovery purposes (/stand and /sbin) as well as
hi, there!
On Tue, 3 Aug 1999, Oscar Bonilla wrote:
*Step One: I ported the NetBSD implementation of nsdispatch(3) as
implemented
by Luke Mewburn. See attached patch to libc and new header file. I'm also
attaching the man page for /etc/nsswitch.conf. Right now it compiles,
installs, and
On Wed, 4 Aug 1999, Peter Jeremy wrote:
Oscar Bonilla oboni...@fisicc-ufm.edu wrote:
If anyone has any comments, suggestions, etc. I would appreciate it.
Overall, I like the idea of NSS. But, having worked on Solaris 2.x
for some time, we need to avoid some of the blunders Sun made: The
Peter Jeremy jere...@gsmx07.alcatel.com.au writes:
We need to be able to build an application that has no dynamically
loaded code for recovery purposes (/stand and /sbin) as well as for
security.
Isn't that the same problem as with PAM?
/assar
To Unsubscribe: send mail to
Assar Westerlund as...@sics.se wrote:
Peter Jeremy jere...@gsmx07.alcatel.com.au writes:
We need to be able to build an application that has no dynamically
loaded code for recovery purposes (/stand and /sbin) as well as for
security.
Isn't that the same problem as with PAM?
Quite probably PAM
On Wed, 4 Aug 1999, Oscar Bonilla wrote:
[skip]
2. Make the C library nsdispatch aware. The dtab[] array will be
filled dynamicaly from the contents of /etc/nsswitch.conf.
I'm still not sure if this has to be done whithin the C library
or if nsdispatch should fill the dtab[] array
In article 99aug5.074611est.40...@border.alcanet.com.au,
Peter Jeremy jere...@gsmx07.alcatel.com.au wrote:
Assar Westerlund as...@sics.se wrote:
Peter Jeremy jere...@gsmx07.alcatel.com.au writes:
We need to be able to build an application that has no dynamically
loaded code for recovery
John Polstra j...@polstra.com wrote:
Peter Jeremy jere...@gsmx07.alcatel.com.au wrote:
Assar Westerlund as...@sics.se wrote:
Peter Jeremy jere...@gsmx07.alcatel.com.au writes:
We need to be able to build an application that has no dynamically
loaded code for recovery purposes (/stand and
On Tue, 3 Aug 1999, Oscar Bonilla wrote:
Following on the NSS (Name Service Switch):
*Step One: I ported the NetBSD implementation of nsdispatch(3) as implemented
by Luke Mewburn. See attached patch to libc and new header file. I'm also
attaching the man page for /etc/nsswitch.conf.
hi, there!
On Tue, 3 Aug 1999, Oscar Bonilla wrote:
*Step One: I ported the NetBSD implementation of nsdispatch(3) as implemented
by Luke Mewburn. See attached patch to libc and new header file. I'm also
attaching the man page for /etc/nsswitch.conf. Right now it compiles,
installs, and
On Tue, 3 Aug 1999, Oscar Bonilla wrote:
Following on the NSS (Name Service Switch):
*Step One: I ported the NetBSD implementation of nsdispatch(3) as
implemented
by Luke Mewburn. See attached patch to libc and new header file. I'm also
attaching the man page for /etc/nsswitch.conf.
Oscar Bonilla oboni...@fisicc-ufm.edu wrote:
If anyone has any comments, suggestions, etc. I would appreciate it.
Overall, I like the idea of NSS. But, having worked on Solaris 2.x
for some time, we need to avoid some of the blunders Sun made: The
biggest problem with Sun's NSS implementation is
27 matches
Mail list logo
