> Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient
> CPU doesn't have an FPU? And we're talking about the i386 family here...
IIRC, there were a few folks running FreeBSD in an embedded
environment. Perhaps with 80386 FPU coprocessor-less systems?
Dan Eischen
[EMAIL
Richard Cownie wrote:
> On Sat, 21 Aug 1999, David O'Brien wrote:
> > Are you saying 4.17 is better than 4.18 for debugging C++? Or are you
> > saying you didn't know FreeBSD comes with gdb:
>
> gdb-4.18 is badly broken on all platforms (at least for C++). You can't
> call methods from the gdb c
Kip Macy <[EMAIL PROTECTED]> wrote:
> Sorry for sending this again but when I first sent it -current was
> embroiled in a flame war.
>
> I would like to use the latest threads source because my application does
> not work correctly with the signal handling bugs in 3.x's threads.
> However, it do
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
> 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, 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) wit
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
> 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
On Thu, 17 Feb 2000, Thimble Smith wrote:
> Hi. I recently updated from -stable to -current. I notice now that
> pthread.h relies on #defines that are in unistd.h; so in order to use
> pthread_attr_setscope you have to include unistd.h before pthread.h.
>
> Is this standard behaviour? I'm wor
On Fri, 18 Feb 2000, Bruce Evans wrote:
> On Thu, 17 Feb 2000, Daniel Eischen wrote:
>
> > On Thu, 17 Feb 2000, Thimble Smith wrote:
> >
> > > Hi. I recently updated from -stable to -current. I notice now that
> > > pthread.h relies on #defines that
> * When you mmap() with MAP_GUARDED|MAP_STACK, you get
> a guarded stack. The system will not create a
> growable stack, though, it pre-reserves the space
> (but, of course, does not allocate physical pages
> for things you haven't touched).
>
> The new semantics
On Fri, 18 Feb 2000, Matthew Dillon wrote:
> :Currently, the threads library only creates one guard page
> :at the top (or bottom depending on how you look at it) of
> :each threads stack (for stacks of default size). Thread
> :stacks are allocated in sequential zones, so they are always
> :plac
On Tue, 29 Feb 2000, John Polstra wrote:
> Either pthread_suspend_np() and pthread_resume_np() are broken in
> -current or I don't understand them. The attached program (cc
> -pthread suspend.c) starts two background threads. Each thread loops
> outputting a character ('1' or '2' according to w
On Tue, 29 Feb 2000, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Daniel Eischen <[EMAIL PROTECTED]> wrote:
> > On Tue, 29 Feb 2000, John Polstra wrote:
> >
> > > Shouldn't the test against PS_SUSPENDED be "==" inste
> Did anyone of you took care that you can build an aout gdb on an ELF
> FreeBSD system?
>
> I don't mean a gdb that is aout, but one that can debug aout binaries.
I thought the gdb in our base system could debug aout binaries. Or
am I sadly mistaken.
> That would be most useful to have as a p
Mike Pritchard wrote:
> I've noticed some odd syscons keyboard behaviour over the past
> month or so. Sometimes I get a vty that outputs PC graphics characters
> for all of my input. This is always at a "login:" prompt. I think
> I can duplicate this by typing a bunch of garbage at a login prom
Marcel Moolenaar wrote:
> So, to start with issue 2:
>
> To start with the beginning:
>
> 1. Should the ucontext_t changes be backed out, or is this the
>way we would like to go? (but only it better :-)
I think we want to keep the ucontext changes. SUSv2 requires them
when SA_SIGINFO is se
Soren Schmidt wrote:
> It seems Daniel M. Eischen wrote:
> >
> > More info on the kernel hang.
> >
> > Removing pnp from the kernel configuration will allow me to boot
> > and successfully detects my pnp modem. So the culprit seems to
> > be the new pnp code. Suggestions welcome.
>
> Hmm, I a
Marcel Moolenaar wrote:
> Dag-Erling Smorgrav wrote:
> >
> > How about this: early in make world, we check whether or not the
> > current kernel supports the new syscalls. If it does, good. If it
> > doesn't, we build and load a small module which installs syscalls
> > which translate the sigset_
Matthew N. Dodd wrote:
> On Sat, 2 Oct 1999, Daniel M. Eischen wrote:
> > What's the unknown0? Shouldn't that be sio2? Do we need the logical
> > device ID?
>
> Yes. Try adding 0x8024b04e to sio.c
OK, I originally did that to no avail, but I didn't make the change to
the correct file (sys/isa
Doug Rabson wrote:
> I looked at you pnpinfo again and I think this change might be better. It
> accepts the cards description instead of overriding it and adds another ID
> for SUP2080 which your card is compatible with. I also removed the bogus
> descriptions for the USR3031 since the pnpinfo fo
Kenneth Wayne Culver wrote:
> Speaking of libc_r, (this is unrelated sort of) I was wondering if anyone
> was planning on adding the pthread_setcancel and other pthread cancel
> stuff to -CURRENT. I was trying to use it the other day when I realized it
> wasn't there... :-) Just a question, I'm n
John Polstra wrote:
> I know now why it worked on the i386 but not on the Alpha. On the
> i386 a system call "read", for example, produces a strong (normal
> global) symbol "_read" and a weak alias "read". Because the symbols
> were weak, the linker didn't complain about the multiple definitions
John Birrell wrote:
> Weak symbols don't work too well _between_ libraries. If libc is linked
> before libpthread, any unresolved references when libc is searched will
> use the weak symbols from there, regardless of the fact that a strong
> symbol exists in libpthread. If libc is linked after lib
other week or so and
I can update them.
>
> *) Signal delivery fixes. I think Daniel Eischen has already taken care of
>this.
Yes, awaiting review by JB.
>
> *) Lacking interfaces, such as pthread_cancel() (mentioned specifically in
>PR bin/7587) need to be implemented.
> In message <[EMAIL PROTECTED]> Christopher Masto writes:
> : Right now, I have no sound (not detected), no USB (panic on removal),
> : can't use my sio pccard, can't eject my ed pccard, my IDE drives are
> : taking hours to dump and fsck, and my TV card is missing every other
> : line if I try t
> It seem this is relevant.
> Here is the output of "python test_select.py":
>
> Traceback (innermost last):
> File "test_select.py", line 63, in ?
> test()
> File "test_select.py", line 47, in test
> rfd, wfd, xfd = select.select([p], [], [], tout)
> select.error: (4, 'Interrupted sy
On Tue, 28 Dec 1999, Soren Schmidt wrote:
> It seems Kenneth Wayne Culver wrote:
> > I can't get the nist port to compile:
> > c++ -g -O2 -Wall -DDO_NIST -DPACKAGE=\"ac3dec\" -DVERSION=\"0.5.5\"
> > -I../../inc -c bitstream.c -o bitstream.o
> > In file included from decode.h:24,
> >
> They're in sys/unistd.h, which is included by unistd.h. That should be
> just fine, and that location appears to be consistent with our other POSIX
> macro definitions.
Ahh, good. I didn't have them because I wasn't up to date.
So the question is now, why wasn't the nist port picking them up
On Tue, 21 Mar 2000, Kenneth D. Merry wrote:
> On Tue, Mar 21, 2000 at 20:15:29 +, Mark Ovens wrote:
> > Since u/g to 4.0 I've had problems with audio CD players and my
> > Toshiba XM6201 SCSI CD drive, cdcontrol and xmcd. Re-MAKEDEV'ing all
> > the cd devices has got cdcontrol working but sti
On Tue, 21 Mar 2000, Arun Sharma wrote:
> On Tue, Sep 07, 1999 at 01:21:59PM +0200, Marcel Moolenaar wrote:
> > Peter Wemm wrote:
> > >
> > > Before getting too far here, can we consider some other standard interfaces?
> > >
> > > #include
> > >
> > > int getcontext(ucontext_t *ucp);
On Wed, 22 Mar 2000, Arun Sharma wrote:
> On Wed, Mar 22, 2000 at 08:04:37AM -0500, Daniel Eischen wrote:
> >
> > I had them implemented and working for i386, and even had a hacked up
> > libc_r that used them instead of setjmp/longjmp. This was a few months
> > ago
Matthew Dillon wrote:
> The answer is nobody knows yet :-).
>
> Interrupts will probably wind up running each in its own thread, and
> we will probably adopt the BSDI hybridized model (which runs an interrupt
> synchronously if possible and spools it to a thread otherwise) to
On Sun, 26 Mar 2000, Matthew Dillon wrote:
> :> with supervisor execution, and allow interrupt execution concurrent
> :> with other interrupts. For example, two different ethernet interrupts
> :> could be taken concurrently with only minor spinlock controls
> :> on the IF queue
On Mon, 27 Mar 2000, Matthew Dillon wrote:
>
> :
> :> :> *not* preempted except when being interrupted, so there are no
> :> :> 'priorities', per say. Or, rather, the relative priority is strictly
> :> :> that the interrupt takes priority over supervisor code except when
> :> :>
On Mon, 27 Mar 2000, Matthew Dillon wrote:
> :And would there still be areas of the kernel that disable multiple
> :interrupts, perhaps CAM or the network stack for instance? What do
> :all the splbio and splnet calls translate into in this new scheme?
> :
> :--
> :Dan Eischen
>
> The entir
> Hi all,
>
> What is the proper way for obtaining the signal mask from
> within the jmp_buf struct on 4.x or -current? Previously
> with the JDK port for < 3.x we did something like this:
>
> signalMask = jmpbuf[0]._sjb[6];
>
> This no longer works now that we support >32 signals. Is
Alexander Leidinger wrote:
> Hi,
>
> (14) netchild@ttyp2% uname -a
> FreeBSD Magelan.Leidinger.net 5.0-CURRENT FreeBSD 5.0-CURRENT #14: Fri Apr 21
>17:28:37 CEST 2000 root@:/big/usr/src/sys/compile/WORK i386
>
> I've an application which uses pthread_cond_{wait,broadcast}() and
> the debug
[ Followups to -current ]
On Thu, 8 Nov 2001, Loren James Rittle wrote:
> Hello all,
>
> I have ported the most recent version of boehm-gc (6.1-alpha) to
> FreeBSD/i386 under the auspice of the gcc project (it will be in Hans'
> 6.1 release and it is on the gcc mainline). I got one notable thi
Alfred Perlstein wrote:
>
> * Dan Eischen <[EMAIL PROTECTED]> [011204 06:26] wrote:
> >
> > There are already cancellation tests when resuming threads
> > whose contexts are not saved as a result of a signal interrupt
> > (ctxtype != CTX_UC). You shouldn't test for cancellation when
> > ctxtype =
Alfred Perlstein wrote:
>
> * Daniel Eischen <[EMAIL PROTECTED]> [011204 12:32] wrote:
> > Alfred Perlstein wrote:
> > >
> > > * Dan Eischen <[EMAIL PROTECTED]> [011204 06:26] wrote:
> > > >
> > > > There are already cancellatio
On Fri, 30 Nov 2001, Louis-Philippe Gagnon wrote:
> If at first you don't succeed...
>
> I've encountered a problem using pthread_cancel, pthread_join and
> pthread_setcanceltype, I'm hoping someone can shed some light.
>
> (in a nutshell : pthread_setcanceltype doesn't seem to work in FreeBSD
On Sun, 9 Dec 2001, Peter Wemm wrote:
> Mark Murray wrote:
> > Hi
> >
> > Now that I have your attention, please listen up, this may have some
> > far-reaching consequences.
> >
> > We currently have 2 telnet sources in the src/ tree; src/crypto/telnet
> > and the "base" telnet spread around in
libc_r seems to be broke on alpha and I'm trying to fix it.
We munge jmp_bufs to create new contexts for threads and for
the thread scheduler. It seems that sometime over the last
few weeks/months something broke that. It doesn't look like
_setjmp of _longjmp have changed at all, though.
Includ
On Sun, 10 Feb 2002, Kevin Day wrote:
>
> I'm the maintainer for ports/editors/joe, and just tried compiling it under
> -CURRENT.
>
> includes which includes ucontext.h
>
> > cc -O -pipe -c umath.c
> > In file included from b.h:6,
> > from bw.h:23,
> > from
On Mon, 11 Feb 2002, Bruce Evans wrote:
> On Sun, 10 Feb 2002, Daniel Eischen wrote:
>
> > Hmm, includes . I'm not sure why though.
> > bde might know.
>
> includes for the normal namespace
> pollution that was needed to use sigreturn(2) (except sigreturn(2)
On Mon, 11 Feb 2002, Garrett Wollman wrote:
> <<[EMAIL PROTECTED]> said:
>
> > How do you easily forward declare something that is a typedef?
>
> There is a reason style(9) says not to use such typedefs.
> Unfortunately, this one it written into a standard. Since We Are The
> Implementation, th
On Sun, 10 Feb 2002, Kevin Day wrote:
>
> I'm the maintainer for ports/editors/joe, and just tried compiling it under
> -CURRENT.
>
> includes which includes ucontext.h
>
> > cc -O -pipe -c umath.c
> > In file included from b.h:6,
> > from bw.h:23,
> > from
On Sun, 10 Feb 2002, Andrey A. Chernov wrote:
> On Sun, Feb 10, 2002 at 12:13:05 -0800, Gregory Neil Shapiro wrote:
> >
> > http://people.freebsd.org/~gshapiro/CURRENT-8.12.2
>
> --- lib/libmilter/Makefile~orig Sun Jan 20 13:58:03 2002
> +++ lib/libmilter/MakefileSun Jan 20 13:05:02 20
On Mon, 11 Feb 2002, Bruce Evans wrote:
> On Sun, 10 Feb 2002, Daniel Eischen wrote:
> > What do you recommend we do? Should we not include
> > from , or do what Solaris does, or just leave
> > everything as is?
>
> Don't include from , and fix whatever
>
On Sun, 10 Feb 2002, Kevin Day wrote:
>
> I'm the maintainer for ports/editors/joe, and just tried compiling it under
> -CURRENT.
>
> includes which includes ucontext.h
>
> > cc -O -pipe -c umath.c
> > In file included from b.h:6,
> > from bw.h:23,
> > from
And when is alpha buildworld going to work again? It's been
busted for well over a week. The following patch posted by
drew gets around the problem for now. If we want people to
test changes on on the alpha, then we should try and make
sure that world isn't broken for too long on it. I know t
On Thu, 21 Feb 2002, Greg Lehey wrote:
> On Wednesday, 20 February 2002 at 23:48:12 -0500, John Baldwin wrote:
> >
> >>> What John's patch does is spin while the lock owner is running on
> >>> another cpu. Spinning while there are no other processes on the run
> >>> queues as well makes sense but
On Mon, 19 Feb 2001, Matthew Jacob wrote:
> > In message <[EMAIL PROTECTED]> Matthew
>Jacob writes:
> > : One system got stuck in the current __sF bork... I'm not stuck with:
> >
> > : Any advice?
> >
> > Copy a pre Feb 10th libc.so.5 to this box. Alternatively, copy a Feb
> > 17 or later one.
On Sun, 25 Feb 2001, Martin Blapp wrote:
>
> Daniel,
>
> > I don't know, what port builds libGL.so.1?
> > Something has to link in the threads library...
>
> Yep, XFree86 libs should be linked against -lc_r,
> I got this working with this.
>
> It's still broken in FreeBSD ports, all GL depende
On Fri, 9 Mar 2001, James FitzGibbon wrote:
> I'm wondering if anyone has the time or inclination to take a look at a fix
> for PR bin/25110. We're having problems using a freshly-built 4.2-stable
> box (technically 4.3 rc at this point), and the bug is still present.
>
> I'm not sure how many p
I admit I haven't been able to read every -current and -commit message,
but a search of the mail archives doesn't yield anything either...
What's going on with telnet? Trying to telnet to localhost or `hostname`
yields:
bash-2.02$ telnet localhost
Trying ::1...
Connected to localhost.
E
On 22 Mar 2001 [EMAIL PROTECTED] wrote:
> Dan Eischen <[EMAIL PROTECTED]> writes:
> > This commit broke telnet (or perhaps exposed brokenness that was
> > already present and never noticed):
> >
> > $ cvs -R log -Nr1.6 main.c
> >
> > RCS file: /opt/b/CVS/src/crypto/telnet/telnet/main.c,v
> >
On 22 Mar 2001 [EMAIL PROTECTED] wrote:
> Daniel Eischen <[EMAIL PROTECTED]> writes:
> > As someone else has already posted, the following will reproduce
> > the behaviour on my system:
> >
> > bash-2.02$ telnet localhost
> > Trying ::1...
> > C
On 22 Mar 2001 [EMAIL PROTECTED] wrote:
> Daniel Eischen <[EMAIL PROTECTED]> writes:
> > I can test this later tonight, but if you say it works, I'm fine
> > with that. I'd say go ahead and commit it unless/until SRA can
> > be "fixed".
>
>
Why are %fs and %gs set back to default (_udata_sel) when posting
signals?
I am planning on using %fs for TSD/KSD and want it to be valid
in signal handlers.
A test program is at:
http://people.freebsd.org/~deischen/test_tsd.c
Compile it with -DDEBUG on an unpatched kernel to show more
detai
On Wed, 2 May 2001, Bruce Evans wrote:
> On Tue, 1 May 2001, Daniel Eischen wrote:
>
> > Why are %fs and %gs set back to default (_udata_sel) when posting
> > signals?
>
> All segment registers are set to a default state so that signal handlers
> have some chance of
On Fri, 4 May 2001, Bruce Evans wrote:
> On Wed, 2 May 2001, Daniel Eischen wrote:
> > On Wed, 2 May 2001, Bruce Evans wrote:
> > >
> > > There is also the osendsig() case, and corresponding code in several
> > > emulators.
> >
> > I don't t
On Sat, 5 May 2001, Andrew Gallatin wrote:
>
> Daniel Eischen writes:
> >
> > OK, thanks. Here's my guess at what should be changed for the Linux
> > emulator. If this looks correct, I'll commit it.
> >
> > Hmm, I wonder how linuxthread
On Mon, 7 May 2001, Bruce Evans wrote:
> On Sat, 5 May 2001, Daniel Eischen wrote:
>
> > On Sat, 5 May 2001, Andrew Gallatin wrote:
> > >
> > > Daniel Eischen writes:
> > > >
> > > > OK, thanks. Here's my guess at what should
On Mon, 7 May 2001, John Polstra wrote:
> In article
> <[EMAIL PROTECTED]>, Daniel
> Eischen <[EMAIL PROTECTED]> wrote:
>
> > I think the only reason we used %fs instead of %gs was WINE. I
> > think Linux uses %gs for TSD, so if WINE were to ever depend on
On Mon, 4 Jun 2001, Bruce Evans wrote:
> On Sat, 2 Jun 2001, Maxim Sobolev wrote:
>
> > It seems that something is wrong with sscanf(3) in -current - in
> > some cases it may cause SIGBUS. I failed to reproduce the
> > problem on 4-STABLE, so it is a -current specific bug. Attached
> > please fin
On Fri, 8 Jun 2001, Idea Receiver wrote:
> I dont know if this is cause by -current, I have not yet try on the
> -stable. However, I just write here, maybe someone can help me.. :P
>
> recently, I wrote a multithread network server for my work. what it does
> is to accept TCP connection from remo
On Mon, 2 Jul 2001, Julian Elischer wrote:
>
> The time has come (now that we have a design) to assign names to the
> various entities that will be created when we implement the
> (current name) KSE code.
>
> I have already done initial work on this and have a system running with
> the proc str
On Mon, 2 Jul 2001, Alfred Perlstein wrote:
> Scheduling control block. Remove 'Process' because as far as I
> understand it, it's not really a process, it's a group of threads.
SCB is SCSI Command Block.
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-
On Fri, 6 Jul 2001, Julian Elischer wrote:
> On Fri, 6 Jul 2001, John Baldwin wrote:
> > One other note. #2 is conceptually a related group of #4's, so I think it's
> > name should reflect that. (It's view as a group of #4's is more important than
> > as being a part of #1.) So, if you go with
On Fri, 6 Jul 2001, Peter Wemm wrote:
> Julian Elischer wrote:
> >
> >
> > On Fri, 6 Jul 2001, Daniel Eischen wrote:
> > >
> > ->proc->
> > > ->thrgrp->
> > > ->thr->
> > > ->thrctx->
> > &
On Tue, 17 Jul 2001, John W. De Boskey wrote:
> Hi,
>
>I have run into an issue with the difference between what
> happens when a signal handler returns from a program converted
> to use pthreads (vs non-pthreads).
>
>Basically, in the non-pthread case, a change made to the
> sc_eip elem
Were we going to do anything to get rid of:
#define stdin (&__sF[0])
#define stdout (&__sF[1])
#define stderr (&__sF[2])
for 5.0-release, or is the current fix the one we want to
go with. I don't know if we ever decided how it should be
properly fixed, or if it shoul
On Fri, 20 Jul 2001, Alfred Perlstein wrote:
> * Daniel Eischen <[EMAIL PROTECTED]> [010720 17:00] wrote:
> > Were we going to do anything to get rid of:
> >
> > #define stdin (&__sF[0])
> > #define stdout (&__sF[1])
> > #define std
On Mon, 6 Aug 2001, Julian Elischer wrote:
> I have pushed the thread pointers down through most of the code
> though there are still many many places that assume that there is only one
> thread per process. (no multithreading yet, but getting closer..)
Keep up the good progress :-)
> At this st
On Mon, 27 Aug 2001, Robert Watson wrote:
>
> On Mon, 27 Aug 2001, Bruce Evans wrote:
>
> > How much faster (or slower) will it be for threaded programs (for
> > various numbers of CPUs)? I don't see how it can be faster for a single
> > CPU (interrupt threads in the kernel show that using thre
On Mon, 27 Aug 2001, John Baldwin wrote:
> On 27-Aug-01 Julian Elischer wrote:
> > I am ready to do my megga-commit to add the first stage of KSE-threading
> > support
> > to
> > the kernel. If there is any argument as to the wisdom of this move,
> > then this is the time to speak up!
> >
> > At
I've just committed some changes to the threads library
and would appreciate feedback from anyone running threaded
applications. They include fixes that -stable could really
use.
This commit also implements zero system call thread context
switching in the threads library. Switching between thr
On Sat, 14 Oct 2000 [EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Daniel Eischen <[EMAIL PROTECTED]> wrote:
> > The range of valid priorities has also changed, perhaps
> > requiring a library version bump. The range of valid priorities
> > i
On Sat, 14 Oct 2000 [EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Daniel Eischen <[EMAIL PROTECTED]> wrote:
> > On Sat, 14 Oct 2000 [EMAIL PROTECTED] wrote:
> > >
> > > I thought you could get that information with sched_get_priority_min
On Sun, 15 Oct 2000, German Tischler wrote:
> Hi.
>
> After the recent thread changes trying to use plaympeg
> (smpeg-0.4.0 package) fails with the following message:
>
> Fatal error 'Thread has returned from sigreturn or longjmp'
> at line ? in file /usr/src/lib/libc_r/uthread/uthread_kern.c
On Sat, 21 Oct 2000, Blaz Zupan wrote:
> Just tried installing "ohphone" under FreeBSD-current. "ohphone" is a H323
> compatible phone that can be used for Voice over IP, it's available in the
> FreeBSD ports collection. Just starting the application produces the message
> "User signal 2". That's
On Sun, 22 Oct 2000, Andrey Rouskol wrote:
>
> Hi there !
>
> Some days ago I was tring to compile mysql at -current and found that
> ./configure freezes at 'checking for restartable system calls'. Here is a
> code witch is executed - if you compile it with '-lc_r -lm -lcrypt' it will
It shoul
On Sun, 22 Oct 2000, Andrey Rouskol wrote:
>
> Hi there !
>
> Some days ago I was tring to compile mysql at -current and found that
> ./configure freezes at 'checking for restartable system calls'. Here is a
> code witch is executed - if you compile it with '-lc_r -lm -lcrypt' it will
> freeze.
On Wed, 1 Nov 2000, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Maxim Sobolev <[EMAIL PROTECTED]> wrote:
> >
> > I'm not sure what exactly caused this behaviour (I can guess two potential
> > victims: O'Brien's changes in crt stuff and recent Polstra's changes in
> > libgcc_r), but i
On Tue, 14 Nov 2000, Roger Hardiman wrote:
> Hi
>
> Since cvsup'ing -current box, I've got a port which
> core dumps immediatly.
>
> When I tried to run a debug version of the program under
> GDB I just got this
>
>
> ptrace(PT_GETDBREGS) failed: Operation not permitted
> ptrace(PT_GETDBREGS)
POSIX says that getlogin_r should return an int, not a char *. Our
implementation is also broken; it will only work the first time.
Since we've already bumped libc version number, anyone mind if I
fix it?
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-
On Fri, 5 Jan 2001, The Hermit Hacker wrote:
>
> morning all ...
>
> running 5.0-CURRENT here, and found the other day that mcopidl
> started to segfault the other day in kdelibs (from CVS) ... this evening,
> someone brought up the possibility that its a threading issue, and
> suggested t
On Tue, 9 Jan 2001, Maxim Sobolev wrote:
> Hi,
>
> I wonder if anyone noticed that disappearance of libgcc_r will cause lot of
> ports to break. Therefore it would be nice if some form of compatibility shim
> is provided, for example symlink from /usr/lib/libgcc.a to /usr/lib/libgcc_r.a
> automat
On Tue, 9 Jan 2001, Peter Wemm wrote:
> Matt Dillon wrote:
> >
> > :On Tue, Jan 09, 2001 at 09:45:14AM -0800, Archie Cobbs wrote:
> > :
> > :> +if ( `basename $SHELL` == "tcsh" ) then
> > :> +bindkey ^W backward-delete-word
> > :> +endif
> > :
> > :I generally test
On Tue, 9 Jan 2001, Peter Wemm wrote:
> "David O'Brien" wrote:
> > On Tue, Jan 09, 2001 at 07:53:29PM +0200, Maxim Sobolev wrote:
> > > I wonder if anyone noticed that disappearance of libgcc_r will cause lot of
> > > ports to break. Therefore it would be nice if some form of compatibility sh
>
[ Followups to -arch only please ]
I've got some changes to libc and libc_r that I'd like reviewed.
These changes eliminate the _THREAD_SAFE macro and allow a libc
and libc_r that can be linked together via -lc_r. This also means
that -pthread and -D_THREAD_SAFE can be deprecated. Note that
lib
On Wed, 24 Jan 2001, Maxim Sobolev wrote:
> "Daniel M. Eischen" wrote:
>
> > As discussed a few days ago, I've just committed the changes to libc
> > and libc_r to allow them to be linked together via -lc_r. If you're
> > running -current and have any threaded apps built using libc_r.so.5,
> > y
On Wed, 24 Jan 2001, Alfred Perlstein wrote:
> * Daniel M. Eischen <[EMAIL PROTECTED]> [010124 05:26] wrote:
> > As discussed a few days ago, I've just committed the changes to libc
> > and libc_r to allow them to be linked together via -lc_r. If you're
> > running -current and have any threaded
On Wed, 24 Jan 2001, Jordan Hubbard wrote:
> > What's not clear ;-) Use -lc_r instead of -pthread.
> >
> > gcc -Wall -o foo foo.c -lc_r
> >
> > The old way was:
> >
> > gcc -Wall -D_THREAD_SAFE -o foo foo.c -pthread
>
> H. And does the -pthread argument do anything anymore? If n
On Wed, 24 Jan 2001, Dan Nelson wrote:
> In the last episode (Jan 24), Daniel Eischen said:
> > On Wed, 24 Jan 2001, Alfred Perlstein wrote:
> > > * Daniel M. Eischen <[EMAIL PROTECTED]> [010124 05:26] wrote:
> > > > As discussed a few days ago, I've just
On Mon, 29 Jan 2001, Manfred Antar wrote:
> libc_r won't compile since changes made last night.
> (libc_r)504}make
> cc -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc_r/../libc/include
>-DPTHREAD_KERNEL -D_THREAD_SAFE -I/usr/src/lib/libc_r/uthread
>-I/usr/src/lib/libc_r/../../include -D_L
On Wed, 31 Jan 2001, Andrey A. Chernov wrote:
> I have some questions about new threads way. Daniel says that new way is:
>
> > gcc -Wall -o foo foo.c -lc_r
Only in -current, in -stable continue to use -pthread instead of -lc_r.
> 1) What about libgcc_r.a? Is it picked automatically in this cas
On Sun, 11 Feb 2001, Daniel Eischen wrote:
> deischen2001/02/11 14:06:46 PST
>
> Modified files:
> include stdio.h
> Log:
> libc MT-safety, part 2.
>
> Add a lock to FILE and define an additional flag.
This commit caused some
1 - 100 of 439 matches
Mail list logo
