> What we had before the _libc_XXX name additions would have worked
> as long as all internal uses of XXX inside libc were changed to
> _XXX, and, when building for libc_r, all renamed (hidden) system
> calls need _XXX defined as weak symbols to _thread_sys_XXX.
Actually, you don't even need to d
Jason Evans wrote:
> Doen't that method still have the problem of propagating cancellation
> points within the libc code? In another email I argued for the need for
> three names, and your response was that three names aren't needed in the
> context of the next-generation threads library, but it
On Wed, 19 Jan 2000, Jason Evans wrote:
> On Wed, Jan 19, 2000 at 12:21:50PM -0500, Daniel Eischen wrote:
> > I guess I'm confused as to why you can't do what you need with
> > _XXX (internally used, non-cancellable function) and XXX (weak
> > reference to _XXX) within libc. libc_r would provide
On Wed, Jan 19, 2000 at 12:21:50PM -0500, Daniel Eischen wrote:
> > No, I was just busy doing other things.
> >
> > There is potentially one good reason to leave these changes in place for
> > now: they allow proper thread cancellation in libc_r as it stands right
> > now. This seems to me like
> No, I was just busy doing other things.
>
> There is potentially one good reason to leave these changes in place for
> now: they allow proper thread cancellation in libc_r as it stands right
> now. This seems to me like a good enough reason to leave the changes as is
> until our grand new thre
On Wed, Jan 19, 2000 at 01:36:43AM -0800, David O'Brien wrote:
> On Thu, Jan 13, 2000 at 06:53:25AM -0500, Daniel Eischen wrote:
> > On Wed, 12 Jan 2000, David O'Brien wrote:
> > > I don't see why a plain function like mkstemp() should be written so
> > > specially. Couldn't all the hiding/changi
On Thu, Jan 13, 2000 at 06:53:25AM -0500, Daniel Eischen wrote:
> On Wed, 12 Jan 2000, David O'Brien wrote:
> > I don't see why a plain function like mkstemp() should be written so
> > specially. Couldn't all the hiding/changing done for threads be done
> > w/in open() itself? Neither HP-UX 10.3
On Wed, 12 Jan 2000, John Polstra wrote:
> Jason Evans <[EMAIL PROTECTED]> wrote:
>
> > 2) Make a separate copy of mktemp.c to remove the internal dependency.
>
> I think this is the best approach -- likewise for getobjformat.c,
I agree. egcs provided "mkstemp.c" to handle the problem, but t
In article <[EMAIL PROTECTED]>,
David O'Brien <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 12, 2000 at 07:00:01PM -0800, John Polstra wrote:
>
> > I _really_ don't like it when a program reaches waaay over into an
> > unrelated directory for its sources.
>
> We already do that all over the place
On Wed, 12 Jan 2000, David O'Brien wrote:
> On Wed, Jan 12, 2000 at 07:00:01PM -0800, John Polstra wrote:
> > > The buildworld problem that I introduced is due to cc_fbsd directly
> > > compiling and linking in src/lib/libc/stdio/mktemp.c. This is in my
> > > opinion a questionable practice, sin
On Wed, Jan 12, 2000 at 07:00:01PM -0800, John Polstra wrote:
> > The buildworld problem that I introduced is due to cc_fbsd directly
> > compiling and linking in src/lib/libc/stdio/mktemp.c. This is in my
> > opinion a questionable practice, since it adds dependencies to the
> > internals of the
In article <[EMAIL PROTECTED]>,
Jason Evans <[EMAIL PROTECTED]> wrote:
> The buildworld problem that I introduced is due to cc_fbsd directly
> compiling and linking in src/lib/libc/stdio/mktemp.c. This is in my
> opinion a questionable practice, since it adds dependencies to the
> internals of t
The buildworld problem that I introduced is due to cc_fbsd directly
compiling and linking in src/lib/libc/stdio/mktemp.c. This is in my
opinion a questionable practice, since it adds dependencies to the
internals of the libc code, which has just been proven to bite. =)
Aesthetics aside, I'm not
13 matches
Mail list logo
