HEADS UP: sigset_t changes committed
I just finished committing the sigset_t changes I worked on for the last 5 weeks. Before attempting to build world, you must make and install a new kernel. The new kernel will contain new syscalls that are needed during build world. doscmd is currently not being build because it needs fixing first. Alpha users are invited to test the changes since I've not been able to do that myself. I've done all I possibly could do to make this a success. I've attached the commit logs for everyone to see. Please report problems as soon as possible. Thanks, sigset_t change (part 1 of 5) - Rename sigaction, sigprocmask, sigpending and sigsuspend to osigaction, osigprocmask, osigpending and osigsuspend (resp) and add new syscalls for them to support the new sisgset_t without breaking existing binaries. Change the prototype of sigaltstack to use the typedef stack_t instead of struct sigaltstack to reflect that it is SUSv2 compliant. Also, rename sigreturn to osigreturn and add a new syscall to support the modified stackframe. The change is caused by sigreturn operating on ucontext_t now and the fact that siginfo_t has been updated to conform to SUSv2. sigset_t change (part 2 of 5) - The core of the signalling code has been rewritten to operate on the new sigset_t. No methodological changes have been made. Most references to a sigset_t object are through macros (see signalvar.h) to create a level of abstraction and to provide a basis for further improvements. The NSIG constant has not been changed to reflect the maximum number of signals possible. The reason is that it breaks programs (especially shells) which assume that all signals have a non-null name in sys_signame. See src/bin/sh/trap.c for an example. Instead _SIG_MAXSIG has been introduced to hold the maximum signal possible with the new sigset_t. struct sigprop has been moved from signalvar.h to kern_sig.c because a) it is only used there, and b) access must be done though function sigprop(). The latter because the table doesn't holds properties for all signals, but only for the first NSIG signals. signal.h has been reorganized to make reading easier and to add the new and/or modified structures. The "old" structures are moved to signalvar.h to prevent namespace polution. Especially the coda filesystem suffers from the change, because it contained lines like (p->p_sigmask == SIGIO), which is easy to do for integral types, but not for compound types. NOTE: kdump (and port linux_kdump) must be recompiled. Thanks to Garrett Wollman and Daniel Eischen for pressing the importance of changing sigreturn as well. sigset_t change (part 3 of 5) - By introducing a new sigframe so that the signal handler operates on the new siginfo_t and on ucontext_t instead of sigcontext, we now need two version of sendsig and sigreturn. A flag in struct proc determines whether the process expects an old sigframe or a new sigframe. The signal trampoline handles which sigreturn to call. It does this by testing for a magic cookie in the frame. The alpha uses osigreturn to implement longjmp. This means that osigreturn is not only used for compatibility with existing binaries. To handle the new sigset_t, setjmp saves it in sc_reserved (see NOTE). the struct sigframe has been moved from frame.h to sigframe.h to handle the complex header dependencies that was caused by the new sigframe. NOTE: For the i386, the size of jmp_buf has been increased to hold the new sigset_t. On the alpha this has been prevented by using sc_reserved in sigcontext. sigset_t change (part 4 of 5) - The compatibility code and/or emulators have been updated: iBCS2 now mostly uses the older syscalls. SVR4 now properly handles all signals. This has been achieved by using the new sigset_t throughout the emulator. The Linuxulator has been severely updated. Internally the new Linux sigset_t is made the default. These are then mapped to and from the new FreeBSD sigset_t. Also, rt_sigsuspend has been implemented in the Linuxulator. Implementing this syscall basicly caused all this sigset_t changing in the first place and the syscall has been used throughout the change as a means for testing. It basicly is too much work to undo the implementation so that it can later be added again. A special note on the use of sv_sigtbl and sv_sigsize in struct sysentvec: Every signal larger than sv_sigsize is not translated and is passed on to the signal handler unmodified. Signals in the range 1 upto and including sv_sigsize are translated. The rationale is that only the system defined signals need to be translated. The emulators also have been updated so that the translation tables are only indexed for valid (system defined) signals. This change also fixes the translation bug already in the SVR4 emulator. sigset_t change (part 5 of 5) - Most of the userland changes ar
Re: HEADS UP: sigset_t changes committed
> I just finished committing the sigset_t changes I worked on for the last > 5 weeks. Thanks Marcel, this was great, and the commit messages were outstanding (as well as humorous :). Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar wrote: > > These libraries either a) have one of the modified structures > visible in the interface, or b) use sigset_t internally and > may cause breakage if new binaries are used against libraries > that don't have the sigset_t change. This not an immediate > issue, but will be as soon as applications start using the > new range to its fullest. Without really wanting to get into this discussion, the version bumps if an old binary cannot use a new library, not the other way around. Alas, this is all I'll be saying. Interested parties can refer to the recent discussion+flame war on the subject. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] Rule 69: Do unto other's code as you'd have it do unto yours To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
In article <[EMAIL PROTECTED]>, Marcel Moolenaar <[EMAIL PROTECTED]> wrote:
>
> Alpha users are invited to test the changes since I've not been able to
> do that myself. I've done all I possibly could do to make this a
> success.
It looks like real bad news for the Alpha. :-( I built and
installed the kernel as instructed, and then started a make
buildworld. That died soon with this:
===> usr.bin
"/a/src/usr.bin/Makefile", line 223: Unclosed conditional/for loop
"/a/src/usr.bin/Makefile", line 223: Unclosed conditional/for loop
"/a/src/usr.bin/Makefile", line 223: 1 open conditional
"/a/src/usr.bin/Makefile", line 223: 1 open conditional
make: fatal errors encountered -- cannot continue
make: fatal errors encountered -- cannot continue
*** Error code 1
*** Error code 1
I suspect it's caused by the trailing backslash in the "doscmd" line
near the end:
.if ${MACHINE_ARCH} == "i386"
# Things that don't compile on alpha or are aout specific:
SUBDIR+=ar \
brandelf \
gcore \
gprof4 \
nm \
ranlib \
sasc \
size \
strings \
strip
# doscmd \
.endif
Anyway, when the make buildworld failed, I tried to do a "cvs
status" or some such thing, which caused amd to attempt to mount the
repository from a different machine. Wham, instant panic, and it
trashed out one of my filesystems _thoroughly_ -- 1000 files and 10
MB in lost+found. :-(
Once I got things patched up again with a little chewing gum, I was
able to get a core dump. It overflowed the kernel stack with
zillions of recursive calls to nfs_sigintr:
#37 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
#38 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
#39 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
#40 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
#41 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
#42 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
#43 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
#44 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
I haven't found the bottom of the stack yet (11000 frames and
counting ...). Let me know if you'd like some additional info.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"No matter how cynical I get, I just can't keep up."-- Nora Ephron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Wed, 29 Sep 1999, Marcel Moolenaar wrote: > I just finished committing the sigset_t changes I worked on for the last > 5 weeks. > > Before attempting to build world, you must make and install a new > kernel. The new kernel will contain new syscalls that are needed during > build world. doscmd is currently not being build because it needs fixing > first. Is there any way at all that we can change this process so that building the kernel first is not required? Those of us involved in educating users about the make world process spend a lot of time telling them not to do this. It's amazing how long and how tenaciously "one-time" exceptions like this stick in their minds. That said, I think that your commit messages were models of excellence, and this work looks like something that will benefit the project for a long time down the road. Thanks, Doug -- "Stop it, I'm gettin' misty." - Mel Gibson as Porter, "Payback" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John Polstra wrote: > > I suspect it's caused by the trailing backslash in the "doscmd" line > near the end: > > strip > # doscmd \ > .endif It doesn't give me any problems... > Anyway, when the make buildworld failed, I tried to do a "cvs > status" or some such thing, which caused amd to attempt to mount the > repository from a different machine. Wham, instant panic, and it > trashed out one of my filesystems _thoroughly_ -- 1000 files and 10 > MB in lost+found. :-( > Once I got things patched up again with a little chewing gum, I was > able to get a core dump. It overflowed the kernel stack with > zillions of recursive calls to nfs_sigintr: > > #37 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) > at ../../nfs/nfs_socket.c:1504 > #38 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) > at ../../nfs/nfs_socket.c:1504 > #39 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) > at ../../nfs/nfs_socket.c:1504 > #40 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) > at ../../nfs/nfs_socket.c:1504 > #41 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) > at ../../nfs/nfs_socket.c:1504 > #42 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) > at ../../nfs/nfs_socket.c:1504 > #43 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) > at ../../nfs/nfs_socket.c:1504 > #44 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) > at ../../nfs/nfs_socket.c:1504 > > I haven't found the bottom of the stack yet (11000 frames and > counting ...). Let me know if you'd like some additional info. Yes please. Looking at the code, it seems to me that nmp shouldn't be 0. What I like to know is, if sendsig/sigreturn is somehow involved. A bad stack can do all sorts of nasty things. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John Polstra wrote:
>
> Marcel Moolenaar wrote:
> > John Polstra wrote:
> >> strip
> >> # doscmd \
> >> .endif
> >
> > It doesn't give me any problems...
>
> Weird! It doesn't seem like the Alpha make should be different.
As a first "guess": Either sendsig/sigreturn or setjmp/longjmp caused
this...
> Yes, I agree. The old code also assumed it wouldn't be 0.
Ok, this should do it. If it looks good to you, I'll commit this...
Index: nfs_socket.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_socket.c,v
retrieving revision 1.55
diff -u -r1.55 nfs_socket.c
--- nfs_socket.c1999/09/29 15:03:47 1.55
+++ nfs_socket.c1999/09/29 18:58:13
@@ -1504,15 +1504,19 @@
{
sigset_t tmpset;
- tmpset = p->p_siglist;
- SIGSETNAND(tmpset, p->p_sigmask);
- SIGSETNAND(tmpset, p->p_sigignore);
if (rep && (rep->r_flags & R_SOFTTERM))
return (EINTR);
if (!(nmp->nm_flag & NFSMNT_INT))
+ return (0);
+ if (p == NULL)
return (0);
- if (p && SIGNOTEMPTY(p->p_siglist) && NFSINT_SIGMASK(tmpset))
+
+ tmpset = p->p_siglist;
+ SIGSETNAND(tmpset, p->p_sigmask);
+ SIGSETNAND(tmpset, p->p_sigignore);
+ if (SIGNOTEMPTY(p->p_siglist) && NFSINT_SIGMASK(tmpset))
return (EINTR);
+
return (0);
}
--
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar wrote: > John Polstra wrote: >> strip >> # doscmd \ >> .endif > > It doesn't give me any problems... Weird! It doesn't seem like the Alpha make should be different. >> I haven't found the bottom of the stack yet (11000 frames and >> counting ...). Let me know if you'd like some additional info. > > Yes please. Looking at the code, it seems to me that nmp shouldn't be 0. Yes, I agree. The old code also assumed it wouldn't be 0. > What I like to know is, if sendsig/sigreturn is somehow involved. A > bad stack can do all sorts of nasty things. GDB is still looking for the bottom of the stack. :-( I did a "bt -30" to try to find it. Do any of you know the address of the outermost frame of the kernel stack on the Alpha? If I knew that then I could probably find the region of interest faster than GDB. John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Following up on my previous mail regarding the panic on the Alpha,
I've been looking at the diff for the code in question, in
"src/sys/nfs/nfs_socket.c":
@@ -1501,14 +1502,16 @@
struct nfsreq *rep;
register struct proc *p;
{
+ sigset_t tmpset;
+ tmpset = p->p_siglist;
+ SIGSETNAND(tmpset, p->p_sigmask);
+ SIGSETNAND(tmpset, p->p_sigignore);
if (rep && (rep->r_flags & R_SOFTTERM))
return (EINTR);
if (!(nmp->nm_flag & NFSMNT_INT))
return (0);
- if (p && p->p_siglist &&
- (((p->p_siglist & ~p->p_sigmask) & ~p->p_sigignore) &
- NFSINT_SIGMASK))
+ if (p && SIGNOTEMPTY(p->p_siglist) && NFSINT_SIGMASK(tmpset))
return (EINTR);
return (0);
}
It looks like the old code was prepared for "p" to be NULL, but the
new code assumes it is non-NULL.
GDB is _still_ looking for the bottom of the stack. If it ever
finds it, I'll send that part of the backtrace. :-)
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"No matter how cynical I get, I just can't keep up."-- Nora Ephron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Nate Williams wrote:
>> Following up on my previous mail regarding the panic on the Alpha,
>> I've been looking at the diff for the code in question, in
>> "src/sys/nfs/nfs_socket.c":
>>
>> @@ -1501,14 +1502,16 @@
>> struct nfsreq *rep;
>> register struct proc *p;
>> {
>> + sigset_t tmpset;
>>
>> + tmpset = p->p_siglist;
>> + SIGSETNAND(tmpset, p->p_sigmask);
>> + SIGSETNAND(tmpset, p->p_sigignore);
>> if (rep && (rep->r_flags & R_SOFTTERM))
>> return (EINTR);
>> if (!(nmp->nm_flag & NFSMNT_INT))
>> return (0);
>> - if (p && p->p_siglist &&
>> - (((p->p_siglist & ~p->p_sigmask) & ~p->p_sigignore) &
>> - NFSINT_SIGMASK))
>> + if (p && SIGNOTEMPTY(p->p_siglist) && NFSINT_SIGMASK(tmpset))
>> return (EINTR);
>> return (0);
>> }
>>
>> It looks like the old code was prepared for "p" to be NULL, but the
>> new code assumes it is non-NULL.
>
> Am I missing something?
>
> - if (p && p->p_siglist &&
> - (((p->p_siglist & ~p->p_sigmask) & ~p->p_sigignore) &
> - NFSINT_SIGMASK))
> + if (p && SIGNOTEMPTY(p->p_siglist) && NFSINT_SIGMASK(tmpset))
>
> The
> if (p
>
> in both cases checks for an null p. Or, am I missing something?
You're missing the use of "p->p_siglist" that was added at the top
of the function.
John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar wrote: > > Ok, this should do it. If it looks good to you, I'll commit this... I'm running it now, and so far it seems to have solved the problem. Could you also please get rid of that "# doscmd \" line from usr.bin/Makefile? Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
> Following up on my previous mail regarding the panic on the Alpha,
> I've been looking at the diff for the code in question, in
> "src/sys/nfs/nfs_socket.c":
>
> @@ -1501,14 +1502,16 @@
> struct nfsreq *rep;
> register struct proc *p;
> {
> + sigset_t tmpset;
>
> + tmpset = p->p_siglist;
> + SIGSETNAND(tmpset, p->p_sigmask);
> + SIGSETNAND(tmpset, p->p_sigignore);
> if (rep && (rep->r_flags & R_SOFTTERM))
> return (EINTR);
> if (!(nmp->nm_flag & NFSMNT_INT))
> return (0);
> - if (p && p->p_siglist &&
> - (((p->p_siglist & ~p->p_sigmask) & ~p->p_sigignore) &
> - NFSINT_SIGMASK))
> + if (p && SIGNOTEMPTY(p->p_siglist) && NFSINT_SIGMASK(tmpset))
> return (EINTR);
> return (0);
> }
>
> It looks like the old code was prepared for "p" to be NULL, but the
> new code assumes it is non-NULL.
Am I missing something?
- if (p && p->p_siglist &&
- (((p->p_siglist & ~p->p_sigmask) & ~p->p_sigignore) &
- NFSINT_SIGMASK))
+ if (p && SIGNOTEMPTY(p->p_siglist) && NFSINT_SIGMASK(tmpset))
The
if (p
in both cases checks for an null p. Or, am I missing something?
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Doug wrote: > > On Wed, 29 Sep 1999, Marcel Moolenaar wrote: > > Is there any way at all that we can change this process so that > building the kernel first is not required? IIRC, you can use -DNOTOOLS. In that case the current tools are assumed to be sufficient for building world. But, you can't do an installworld as part of that, because eventually the new binaries that are installed get used by the install process (/bin/sh for example). In short: you need a new kernel for the newly compiled binaries to run. > Those of us involved in > educating users about the make world process spend a lot of time telling > them not to do this. It's amazing how long and how tenaciously "one-time" > exceptions like this stick in their minds. I understand, but the new syscalls simply need to be in the kernel before you can run the binaries that use them. Using -DNOTOOLS you can delay that moment until just before doing the installworld, but you can't avoid it. I hope and trust that users understand that this is an exception... > That said, I think that your commit messages were models of > excellence, and this work looks like something that will benefit the > project for a long time down the road. Thanks! -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John Polstra wrote:
>
> Following up on my previous mail regarding the panic on the Alpha,
> I've been looking at the diff for the code in question, in
> "src/sys/nfs/nfs_socket.c":
>
> @@ -1501,14 +1502,16 @@
> struct nfsreq *rep;
> register struct proc *p;
> {
> + sigset_t tmpset;
>
> + tmpset = p->p_siglist;
> + SIGSETNAND(tmpset, p->p_sigmask);
> + SIGSETNAND(tmpset, p->p_sigignore);
> if (rep && (rep->r_flags & R_SOFTTERM))
> return (EINTR);
> if (!(nmp->nm_flag & NFSMNT_INT))
> return (0);
> - if (p && p->p_siglist &&
> - (((p->p_siglist & ~p->p_sigmask) & ~p->p_sigignore) &
> - NFSINT_SIGMASK))
> + if (p && SIGNOTEMPTY(p->p_siglist) && NFSINT_SIGMASK(tmpset))
> return (EINTR);
> return (0);
> }
>
> It looks like the old code was prepared for "p" to be NULL, but the
> new code assumes it is non-NULL.
Thanks, I overlooked that one. I'll fix it right away.
--
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar wrote: > > Ok, this should do it. If it looks good to you, I'll commit this... Yes, it looks fine to me. You may not be able to commit it right away, though. It looks like freefall is down. Maybe they're putting in the new disk. I'll try the patch a little bit later today, after I finish some other things I have to do. I'm also going to add a panic if nmp==NULL in my local version, so that if it still fails I can get a reasonable stack trace. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
> Nate Williams wrote:
> >> Following up on my previous mail regarding the panic on the Alpha,
> >> I've been looking at the diff for the code in question, in
> >> "src/sys/nfs/nfs_socket.c":
> >>
> >> @@ -1501,14 +1502,16 @@
> >> struct nfsreq *rep;
> >> register struct proc *p;
> >> {
> >> + sigset_t tmpset;
> >>
> >> + tmpset = p->p_siglist;
> >> + SIGSETNAND(tmpset, p->p_sigmask);
> >> + SIGSETNAND(tmpset, p->p_sigignore);
> >> if (rep && (rep->r_flags & R_SOFTTERM))
> >> return (EINTR);
> >> if (!(nmp->nm_flag & NFSMNT_INT))
> >> return (0);
> >> - if (p && p->p_siglist &&
> >> - (((p->p_siglist & ~p->p_sigmask) & ~p->p_sigignore) &
> >> - NFSINT_SIGMASK))
> >> + if (p && SIGNOTEMPTY(p->p_siglist) && NFSINT_SIGMASK(tmpset))
> >> return (EINTR);
> >> return (0);
> >> }
> >>
> >> It looks like the old code was prepared for "p" to be NULL, but the
> >> new code assumes it is non-NULL.
> >
> > Am I missing something?
> >
> > - if (p && p->p_siglist &&
> > - (((p->p_siglist & ~p->p_sigmask) & ~p->p_sigignore) &
> > - NFSINT_SIGMASK))
> > + if (p && SIGNOTEMPTY(p->p_siglist) && NFSINT_SIGMASK(tmpset))
> >
> > The
> > if (p
> >
> > in both cases checks for an null p. Or, am I missing something?
>
> You're missing the use of "p->p_siglist" that was added at the top
> of the function.
Whoops, thanks for pointing that out.
Just call me 'mole-eyed Nate'. *sigh*
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Wed, Sep 29, 1999 at 11:55:23AM -0700, Doug wrote: > On Wed, 29 Sep 1999, Marcel Moolenaar wrote: > > > I just finished committing the sigset_t changes I worked on for the last > > 5 weeks. > > > > Before attempting to build world, you must make and install a new > > kernel. The new kernel will contain new syscalls that are needed during > > build world. doscmd is currently not being build because it needs fixing > > first. > > Is there any way at all that we can change this process so that > building the kernel first is not required? Those of us involved in > educating users about the make world process spend a lot of time telling > them not to do this. It's amazing how long and how tenaciously "one-time" > exceptions like this stick in their minds. > Those users shouldn't track (or run) -CURRENT. bye, Harold -- Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
As John Polstra wrote ... > In article <[EMAIL PROTECTED]>, Marcel Moolenaar <[EMAIL PROTECTED]> wrote: > > > > Alpha users are invited to test the changes since I've not been able to > > do that myself. I've done all I possibly could do to make this a > > success. > > It looks like real bad news for the Alpha. :-( I built and > installed the kernel as instructed, and then started a make > buildworld. That died soon with this: > > ===> usr.bin > "/a/src/usr.bin/Makefile", line 223: Unclosed conditional/for loop > "/a/src/usr.bin/Makefile", line 223: Unclosed conditional/for loop > "/a/src/usr.bin/Makefile", line 223: 1 open conditional > "/a/src/usr.bin/Makefile", line 223: 1 open conditional > make: fatal errors encountered -- cannot continue > make: fatal errors encountered -- cannot continue > *** Error code 1 > *** Error code 1 > Exactly the same thing here 10 minutes ago on my Alpine box. > Anyway, when the make buildworld failed, I tried to do a "cvs > status" or some such thing, which caused amd to attempt to mount the > repository from a different machine. Wham, instant panic, and it > trashed out one of my filesystems _thoroughly_ -- 1000 files and 10 > MB in lost+found. :-( Yikes. No panics here, but I don't have anything NFS mounted here. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Wed, 29 Sep 1999, Harold Gutch wrote: > On Wed, Sep 29, 1999 at 11:55:23AM -0700, Doug wrote: > > On Wed, 29 Sep 1999, Marcel Moolenaar wrote: > > > > > I just finished committing the sigset_t changes I worked on for the last > > > 5 weeks. > > > > > > Before attempting to build world, you must make and install a new > > > kernel. The new kernel will contain new syscalls that are needed during > > > build world. doscmd is currently not being build because it needs fixing > > > first. > > > > Is there any way at all that we can change this process so that > > building the kernel first is not required? Those of us involved in > > educating users about the make world process spend a lot of time telling > > them not to do this. It's amazing how long and how tenaciously "one-time" > > exceptions like this stick in their minds. > > > Those users shouldn't track (or run) -CURRENT. My, isn't that a clever solution. Problem is, in N number of months -Current will be -Stable. Not to mention that every time someone has to upgrade from -Stable to -Current from now on (for entirely legitimate reasons) they will have to do this unique procedure. This is really a much bigger problem than people seem to realize (however necessary it may ultimately turn out to be). Doug -- "Stop it, I'm gettin' misty." - Mel Gibson as Porter, "Payback" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
In article <[EMAIL PROTECTED]>,
Wilko Bulte <[EMAIL PROTECTED]> wrote:
> As John Polstra wrote ...
> >
> > ===> usr.bin
> > "/a/src/usr.bin/Makefile", line 223: Unclosed conditional/for loop
> > "/a/src/usr.bin/Makefile", line 223: Unclosed conditional/for loop
> > "/a/src/usr.bin/Makefile", line 223: 1 open conditional
> > "/a/src/usr.bin/Makefile", line 223: 1 open conditional
> > make: fatal errors encountered -- cannot continue
> > make: fatal errors encountered -- cannot continue
> > *** Error code 1
> > *** Error code 1
> >
>
> Exactly the same thing here 10 minutes ago on my Alpine box.
Marcel has committed the fix for that now. You can either grab it,
or remove the line "# doscmd \" from that Makefile.
You will also need to grab the latest version of
"src/lib/libc/alpha/gen/setjmp.S". I committed a fix for a typo in
that file a few minutes ago. ("addq" was misspelled as "add".)
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"No matter how cynical I get, I just can't keep up."-- Nora Ephron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Wed, Sep 29, 1999 at 02:04:27PM -0700, Doug wrote: > On Wed, 29 Sep 1999, Harold Gutch wrote: > > > On Wed, Sep 29, 1999 at 11:55:23AM -0700, Doug wrote: > > > On Wed, 29 Sep 1999, Marcel Moolenaar wrote: > > > > > > > I just finished committing the sigset_t changes I worked on for the last > > > > 5 weeks. > > > > > > > > Before attempting to build world, you must make and install a new > > > > kernel. The new kernel will contain new syscalls that are needed during > > > > build world. doscmd is currently not being build because it needs fixing > > > > first. > > > > > > Is there any way at all that we can change this process so that > > > building the kernel first is not required? Those of us involved in > > > educating users about the make world process spend a lot of time telling > > > them not to do this. It's amazing how long and how tenaciously "one-time" > > > exceptions like this stick in their minds. > > > > > Those users shouldn't track (or run) -CURRENT. > > My, isn't that a clever solution. Problem is, in N number of > months -Current will be -Stable. Not to mention that every time someone > has to upgrade from -Stable to -Current from now on (for entirely > legitimate reasons) they will have to do this unique procedure. This is > really a much bigger problem than people seem to realize (however > necessary it may ultimately turn out to be). > I interpreted the way of currently handling things (build the kernel first, then the userland) to be a _temporary_ solution, that Marcel was working on being fixed. If this is not the case, then I agree with you. bye, Harold -- Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Wed, 29 Sep 1999, Harold Gutch wrote: > I interpreted the way of currently handling things (build the > kernel first, then the userland) to be a _temporary_ solution, > that Marcel was working on being fixed. If this is not the case, > then I agree with you. If I understand correctly, it only needs to be done once per system, but it makes no difference whether it happens on a given system now or six months from now. -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Wed, Sep 29, 1999 at 04:17:29PM -0700, Doug wrote: > On Wed, 29 Sep 1999, Ben Rosengart wrote: > > > On Wed, 29 Sep 1999, Harold Gutch wrote: > > > > > I interpreted the way of currently handling things (build the > > > kernel first, then the userland) to be a _temporary_ solution, > > > that Marcel was working on being fixed. If this is not the case, > > > then I agree with you. > > > > If I understand correctly, it only needs to be done once per system, but > > it makes no difference whether it happens on a given system now or six > > months from now. > > Yes, if I understand Marcel correctly from this moment forward > everyone who upgrades from any version of freebsd prior to today's > -current will have to build the kernel first. > Uhm, that's the way I see it being _right now_ as well. What I was thinking of, was that things would go smoother if you wouldn't upgrade _right now_, but in [insert some time in the near future here], as things would perhaps be "fixed" by then. And yes, I'm thinking of an upgrade from the "classical kernel/userland" to the "new one", e.g. an upgrade from last week's kernel and userland to the one in two months time. Perhaps I silently just expected too much :). bye, Harold -- Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
> On Thu, 30 Sep 1999, Harold Gutch wrote: > > > Uhm, that's the way I see it being _right now_ as well. What I > > was thinking of, was that things would go smoother if you > > wouldn't upgrade _right now_, but in [insert some time in the > > near future here], as things would perhaps be "fixed" by then. > > There is no fix to make. If the binaries built by the current > sources cannot run unless the sigset_t stuff is in the kernel of the > machine that they are running on this problem will never be "fixed." Then the tools target is broken. The intent of the tools target it to build a running on the current system set of binaries that can build the FreeBSD tree, it the binaries in obj/tmp won't run on the current system something is broken. If it is broken, please back out the signal changes or fix the tools target. -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Wed, 29 Sep 1999, Ben Rosengart wrote: > On Wed, 29 Sep 1999, Harold Gutch wrote: > > > I interpreted the way of currently handling things (build the > > kernel first, then the userland) to be a _temporary_ solution, > > that Marcel was working on being fixed. If this is not the case, > > then I agree with you. > > If I understand correctly, it only needs to be done once per system, but > it makes no difference whether it happens on a given system now or six > months from now. Yes, if I understand Marcel correctly from this moment forward everyone who upgrades from any version of freebsd prior to today's -current will have to build the kernel first. Doug -- "Stop it, I'm gettin' misty." - Mel Gibson as Porter, "Payback" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Thu, 30 Sep 1999, Harold Gutch wrote: > Uhm, that's the way I see it being _right now_ as well. What I > was thinking of, was that things would go smoother if you > wouldn't upgrade _right now_, but in [insert some time in the > near future here], as things would perhaps be "fixed" by then. There is no fix to make. If the binaries built by the current sources cannot run unless the sigset_t stuff is in the kernel of the machine that they are running on this problem will never be "fixed." Doug -- "Stop it, I'm gettin' misty." - Mel Gibson as Porter, "Payback" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
> > Before attempting to build world, you must make and install a new > > kernel. The new kernel will contain new syscalls that are needed during > > build world. doscmd is currently not being build because it needs fixing > > first. > > Is there any way at all that we can change this process so that > building the kernel first is not required? No. > Those of us involved in > educating users about the make world process spend a lot of time telling > them not to do this. It's amazing how long and how tenaciously "one-time" > exceptions like this stick in their minds. The users are probably right in this case :-). New kernels normally don't break anything except utilities that grope in kmem. New kernels are about 1000 times easier to back out of than wrong worlds (just boot a backup kernel). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
< said: > I believe this must be fixed. There is no way it can be ``fixed''. That's Just The Way It Is. I'm sorry that you're having a problem with this. Nobody ever said keeping -current would be easy. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
I believe this must be fixed. At some point in time, there is going to be another change to the kernel such that some older version of the code cannot run on a new kernel. I believe this situation has occurred before. This will lead to a situation where a new kernel is required before the build and a new build is required before the new kernel is installed. We cannot have this paradox. Jim Bloom [EMAIL PROTECTED] Doug wrote: > > On Thu, 30 Sep 1999, Harold Gutch wrote: > > > Uhm, that's the way I see it being _right now_ as well. What I > > was thinking of, was that things would go smoother if you > > wouldn't upgrade _right now_, but in [insert some time in the > > near future here], as things would perhaps be "fixed" by then. > > There is no fix to make. If the binaries built by the current > sources cannot run unless the sigset_t stuff is in the kernel of the > machine that they are running on this problem will never be "fixed." > > Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
< said: > If I understand correctly, it only needs to be done once per system, but > it makes no difference whether it happens on a given system now or six > months from now. Surely. The thing we have to be careful about is making sure that the kernel does not grow new dependencies on software that now can't get built ahead of time. I tripped over one of these when I last upgraded my desktop: the kernel contained some __asm statements which were only valid in EGCS. This is a hard problem in general, but sometimes we just need to say ``screw it!'' and do what's necessary to advance the state of the art. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Ben Rosengart writes: > On Wed, 29 Sep 1999, Harold Gutch wrote: > > > I interpreted the way of currently handling things (build the > > kernel first, then the userland) to be a _temporary_ solution, > > that Marcel was working on being fixed. If this is not the case, > > then I agree with you. > > If I understand correctly, it only needs to be done once per system, but > it makes no difference whether it happens on a given system now or six > months from now. And if I'm running a version of 3.x or older version of -current that can't even build a working kernel because config is out of sync with the kernel sources? I agree with Rod Grimes, if you can't build it with make world, and you're not going to fix it so it can be, it should be backed out. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
< said: > If it is broken, please back out the signal changes or fix the tools > target. No, Rod, just Deal With It(tm). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Wed, 29 Sep 1999, Jim Bloom wrote: > I believe this must be fixed. At some point in time, there is going to be > another change to the kernel such that some older version of the code cannot run > on a new kernel. I believe this situation has occurred before. This will lead > to a situation where a new kernel is required before the build and a new build > is required before the new kernel is installed. We cannot have this paradox. FTPing a GENERIC kernel from somewhere would solve this, then just single user the box, make world. Build your kernel. Reboot. I have to side with the people who say that this being a problem for someone means that person shouldn't be running -current. Furthermore, for when 4.0 becomes a -R or -S, ftping in a compiled kernel shouldn't be that hard of a price to pay for going from 3.2. /stand/sysinstall based upgrades could easily seemlessly take care of this, too. I'm sure people are working on a fix for having to do this, but doing it just isn't this big of a deal. Maybe I'm missing something. - ( Adam Strohl ) - - UNIX Operations/Systems http://www.digitalspark.net - - adams (at) digitalspark.netxxx.xxx. x - - ( DigitalSpark.NET )--- - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Thu, Sep 30, 1999 at 08:17:16AM +1000, Adam Strohl wrote: >On Wed, 29 Sep 1999, Jim Bloom wrote: > >>I believe this must be fixed. At some point in time, there is going >>to be another change to the kernel such that some older version of the >>code cannot run on a new kernel. > >FTPing a GENERIC kernel from somewhere would solve this, then just >single user the box, make world. Build your kernel. Reboot. This assumes that your old world can work correctly with your new kernel (remembering that `make world' is seen as our standard system stress test). The whole justification for the `install the world then upgrade the kernel' approach has been that we _do_not_ guarantee this. >Furthermore, for when 4.0 becomes a -R or -S, ftping in a compiled kernel >shouldn't be that hard of a price to pay for going from 3.2. We've never required this before. I managed to convert from 2.2.6 to -current using `make upgrade'. Why should I need to FTP a kernel from another machine to go from 3.x to 4.x? Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
I got world built and installed OK on the alpha now, and things generally seem OK. However, amd dumped core with a SEGV immediately upon startup. I haven't had even a second to try to debug it yet. Just thought I'd let you know about it. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Thu, Sep 30, 1999 at 01:29:40AM +1000, Marcel Moolenaar wrote: >Before attempting to build world, you must make and install a new >kernel. The new kernel will contain new syscalls that are needed during >build world. doscmd is currently not being build because it needs fixing >first. I'd like to voice my concerns with this change as well. The `normal' upgrade procedure has always been to build and install a new world before the new kernel. The only exception I'm aware of has been the aout->elf transition (where a special build procedure was provided). This commit seems to create the same upgrade hurdle as existed with the conversion to ELF[1]. That conversion came with an extensive description of how to upgrade the system, as well as clear CVS tags delimiting it. This change has no tags and a single paragraph warning us to install a new kernel before building world. I can't configure or compile a -current kernel on a -stable system (and I have no idea whether I can run a -current kernel with a -stable world, but I suspect I can't). This makes it very difficult to convert a -stable system to -current. Whilst -current is for people who like battering their way around such hurdles, it's also the testbed for 4.0-RELEASE, and we will need a tested and documented upgrade procedure in place before then. That said, I think that backing out the changes at this stage will only make things worse. I would like to see a clear upgrade procedure that will enable someone to cross this hurdle when their running system can't build or run a current kernel. [1] Actually, in many ways this change is worse. Recent 2.2 kernels will happily execute many 3.x ELF programs as long as the shared libraries are present. This change makes any program that uses signals not backward compatible. Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Wed, 29 Sep 1999, Garrett Wollman wrote: > < said: > > > I believe this must be fixed. > > There is no way it can be ``fixed''. That's Just The Way It Is. I'm > sorry that you're having a problem with this. Nobody ever said > keeping -current would be easy. I have to agree with Rod that we need to fix the tools so that there is a transition. IMHO, it is unacceptable to expect EVERYONE to "jump" to the new scheme by installing a new kernel. There is nothing fundamental in the toolset which SHOULD care about the underlying kernel. Compilers, loaders, etc. are just programs that operate on the contents of files. Think of compiling the 4.0 system on a 3.3 system as a simpler case of cross compiling. I should be able to compile FreeBSD 4.0/alpha on a FreeBSD 3.3/i386 system. Someone compiled the new system on an old one. The tools that they used should be available as a "compatability" tool to make the transition. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
In message <[EMAIL PROTECTED]> Peter Jeremy writes: : We've never required this before. I managed to convert from 2.2.6 to : -current using `make upgrade'. Why should I need to FTP a kernel : from another machine to go from 3.x to 4.x? In keeping notes, what would need to happen would be that you'd have to build config as well as all the tools to build binaries. Sounds like a make upgrade proceedure would need to do through the lib-tools or build-tools targets, build the kernel, install it reboot. The current Makefile.upgrade would have to be massively gutted and rewritten since it deals with the aout -> elf transition, but it shouldn't be too horrible. This transition is a matter of building a kernel (which has the egcs problem to deal since 3.3-stable is gcc 2.7 based). I know there have been a fair number of make improvements, but I don't know if they are dependencies on them in the build procedure. I think that we need to do this upgrade proceedure. I wish I had more time than to just sketch out this outline... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Would it at least be possible to add a test to the make-world makefile, saying "if kernel_version < xyzzy then echo 'Sorry, install new kernel first' exit 9 fi" Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Thu, Sep 30, 1999 at 02:37:45PM +1000, Warner Losh wrote: >In keeping notes, what would need to happen would be that you'd have >to build config as well as all the tools to build binaries. We might be able to get away with temporarily replacing the i386/include/atomic.h[1] with the one from -stable and using gcc 2.7. At some stage, we need to confirm that a -current kernel will work with a -stable world - or add the incompatible bits to the list of things to build first. >The current Makefile.upgrade would have to be massively gutted and >rewritten since it deals with the aout -> elf transition, but it >shouldn't be too horrible. At least, no more horrible than the aout->elf procedure :-). >I think that we need to do this upgrade proceedure. I wish I had more >time than to just sketch out this outline... I think that a suitable upgrade procedure should have been thought through and implemented before the changes were committed. It would also have been nice to have a CVS tag. It's a bit late now though. [1] It's just occurred to me that the solution for atomic.h is to make the asm constraints dependent on the gcc version. Anyone willing to commit a change if I submit patches? Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
In message <[EMAIL PROTECTED]> Peter Jeremy writes: : I think that a suitable upgrade procedure should have been thought : through and implemented before the changes were committed. It would : also have been nice to have a CVS tag. It's a bit late now though. It is never too late to lay down a tag... : [1] It's just occurred to me that the solution for atomic.h is to : make the asm constraints dependent on the gcc version. Anyone : willing to commit a change if I submit patches? That's the sort of change I made, but I can't seem to find them now... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Garrett Wollman scribbled this message on Sep 29: > <<[EMAIL PROTECTED]> said: > > > If it is broken, please back out the signal changes or fix the tools > > target. > > No, Rod, just Deal With It(tm). actually, no, I would like this fixed... I will be unable to develope FreeBSD if the tools target doesn't work!! I do all of my compiles on a 3.0-R box (yes, that's right, 3.0-R) and it will basicly stop me from doing any of that... this is a VERY bad thing to happen to FreeBSD... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Hi, On Wed, Sep 29, 1999 at 10:07:07PM -0700, John-Mark Gurney wrote: > Garrett Wollman scribbled this message on Sep 29: > > <<[EMAIL PROTECTED]> said: > > > > > If it is broken, please back out the signal changes or fix the tools > > > target. > > > > No, Rod, just Deal With It(tm). > > actually, no, I would like this fixed... I will be unable to develope > FreeBSD if the tools target doesn't work!! I do all of my compiles on > a 3.0-R box (yes, that's right, 3.0-R) and it will basicly stop me from > doing any of that... > > this is a VERY bad thing to happen to FreeBSD... Is there no way for a new tool (especially through libc) to detect it is running on an old kernel, and do things the old way? The test would need to be done once per application, and could be conditionised so that it was only included in the tools built during a make world... Regards, -Jeremy (who hasn't looked at the code) -- | "Come home my prodigal son, come home and lets be one, --+-- don't want to see you cry, don't make me tell you why, |you've lived in a house with me, my blood has set you free, |in the world you'll surely die, nothing else will satisfy." -MIC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Harold Gutch wrote: > > I interpreted the way of currently handling things (build the > kernel first, then the userland) to be a _temporary_ solution, > that Marcel was working on being fixed. If this is not the case, > then I agree with you. I'm not working on changing the build/installworld. There's nothing "broken" about having to install the kernel first, IMO. I don't see how I can "fix" it then. The upgrading from -stable to -current is currently being tested by Bill Fumerola. I can imagine that some might be broken in that case. This I will attempt to fix, then... -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
BTW: I think that what you are doing is really great !! Hmm... I wonder if the volume in the list will increase with cool apps such as IBM's ViaVoice which needs your mods to work. Tnks ! -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John Polstra wrote: > > I got world built and installed OK on the alpha now, and things > generally seem OK. However, amd dumped core with a SEGV immediately > upon startup. I haven't had even a second to try to debug it yet. > Just thought I'd let you know about it. ...and there was much rejoicing... As for AMD, I don't use it. I'll dig into manpages, source code and whatsnot. If possible I'll reconfigure something here so that I can test it on a i386. BTW: I'm sorry, that a simple bug in the NFS code made your filesystem go south. I have been working hard to prevent that... -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
[cc list trimmed] John-Mark Gurney wrote: > actually, no, I would like this fixed... I will be unable to develope > FreeBSD if the tools target doesn't work!! I do all of my compiles on > a 3.0-R box (yes, that's right, 3.0-R) and it will basicly stop me from > doing any of that... I'm not sure how you are developing, but in general you don't depend on the tools target unless you are rebuilding the system. As long as you don't upgrade to -current for now, there's absolutely nothing to worry about. You can still develop on -stable. You binaries work on -current as well. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar scribbled this message on Sep 30: > [cc list trimmed] > > John-Mark Gurney wrote: > > > actually, no, I would like this fixed... I will be unable to develope > > FreeBSD if the tools target doesn't work!! I do all of my compiles on > > a 3.0-R box (yes, that's right, 3.0-R) and it will basicly stop me from > > doing any of that... > > I'm not sure how you are developing, but in general you don't depend on > the tools target unless you are rebuilding the system. As long as you > don't upgrade to -current for now, there's absolutely nothing to worry > about. You can still develop on -stable. You binaries work on -current > as well. but I'm developing for -current... I do a buildworld on my 3.0-R box and move it over to the box after it's complete... I'm not sure about you, but doing a buildworld over nfs w/ a processor that is sub p133 is not something that really works to well... I am planning on upgrading my 3.0-R to 3.3-R, but that won't fix anything that allows me to build -current on it... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Amancio Hasty scribbled this message on Sep 30: > BTW: I think that what you are doing is really great !! > > Hmm... I wonder if the volume in the list will increase with cool > apps such as IBM's ViaVoice which needs your mods to work. I happen to agree that this is a good move for FreeBSD, but it breaks the fundemental part of FreeBSD is that you can buildworld to w/o any dependancies on the target... I thought we were working to the point that we could build a mips world on an x86 box?? w/ this, it completely breaks it... the whole idea of a buildworld is that the tools can be build on ANY platform and run, (assuming the tools support it) and then be able to build the target... might as well say goodbye to ever getting freebsd's userland running under NetBSD which is how our nice Alpha port got started... this NEEDS to be fixed... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
I know this is not topic related, so appologies in advance ... Sometimes people deserve a pat on the back. This is the best thing since Chocolate Chip cookies :) We're running things like myth2_demo, and it opens the doors to a whole bunch of applications ... e.g. C++ Builder to follow next year (for Linux, but probably running in Linuxulator !!) thanks Reinier > BTW: I think that what you are doing is really great !! > > Hmm... I wonder if the volume in the list will increase with cool > apps such as IBM's ViaVoice which needs your mods to work. > > Tnks ! > > > -- > > Amancio Hasty > [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Without proper linux support we are dead . Now I have to get off my soap box and let the work continue 8) Best Regards -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Amancio Hasty wrote: > BTW: I think that what you are doing is really great !! Thanks! > Hmm... I wonder if the volume in the list will increase with cool > apps such as IBM's ViaVoice which needs your mods to work. Already Linux binaries have been tested and confirmed working with the new sigset_t that weren't working before. Luoqi's work to support libvga is also a great thing, BTW. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Richard Wackerbarth wrote: > > There is nothing fundamental in the toolset which SHOULD care about the > underlying kernel. Compilers, loaders, etc. are just programs that operate on > the contents of files. Think of compiling the 4.0 system on a 3.3 system as a > simpler case of cross compiling. I should be able to compile FreeBSD 4.0/alpha > on a FreeBSD 3.3/i386 system. Sigh.. Yes, but if you need the tools you just compiled in your cross-compilation for cross-compilation itself, you'll have a big problem. And that's almost exacly what happens when building world... Using -DNOTOOLS should allow you to build a -current world without installing a new kernel. Stay focussed people! -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John-Mark Gurney wrote: > > but I'm developing for -current... I do a buildworld on my 3.0-R box > and move it over to the box after it's complete... I'm not sure about > you, but doing a buildworld over nfs w/ a processor that is sub p133 > is not something that really works to well... Ah, now I understand your use of development. > I am planning on upgrading my 3.0-R to 3.3-R, but that won't fix anything > that allows me to build -current on it... Try -DNOTOOLS. I don't know if the -current sources depend specifically on -current tools (such as egcs). -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Thu, Sep 30, 1999 at 01:41:41PM +1000, Peter Jeremy wrote: > On Thu, Sep 30, 1999 at 01:29:40AM +1000, Marcel Moolenaar wrote: > >Before attempting to build world, you must make and install a new > >kernel. The new kernel will contain new syscalls that are needed during > >build world. doscmd is currently not being build because it needs fixing > >first. > > I'd like to voice my concerns with this change as well. The `normal' > upgrade procedure has always been to build and install a new world > before the new kernel. The only exception I'm aware of has been the > aout->elf transition (where a special build procedure was provided). Isn't this backwards? The kernel's the place that can (and must) have the backwards-compatability hooks, for the simple reason that even if you build the world, your ports and third-party applications have to keep running. Kernels are built and updated without corresponding buildworlds all the time. If you change something fairly fundamental about the interface specification for the userland-kernel interaction (say, going to 64-bit file offsets, for an equivelant example), then it seems pretty obvious to me that a program or library compiled to the new spec _cannot_ run on a kernel that doesn't implement it. How could it be otherwise? This seems to be a different argument to the one John-Mark is makeing: he isn't trying to _run_ his new world on his old kernel, just compile it. I agree that there are probably some curly issues regarding building a build-only set of tools. These are obviously going to be _different_ from the equivelant tools that you want built as part of the buildworld, being cross-compilers and so on. I don't know how close the build target is to that ideal. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
At 10:17 PM + 1999/9/29, Adam Strohl wrote: > Furthermore, for when 4.0 becomes a -R or -S, ftping in a compiled kernel > shouldn't be that hard of a price to pay for going from 3.2. > > /stand/sysinstall based upgrades could easily seemlessly take care of > this, too. I must confess ignorance (and I haven't exhaustively searched the mailing list archives, the Handbook, or the FAQ), but is this the recommended method of upgrading from a previous major release to the latest -STABLE major release (i.e., going from 2.x to 3.x today, or from 3.x to 4.x when the time comes)? I thought the official procedure was cvsup, or is that for updating only within a particular major release? Thanks! -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
As a fresh idea (probably stupid, but anyway): Why we can't load compile and small KLD with all necessary syscalls (even probably stubs) to build 4.0 world when someone trying to build it on top of 3.*? -Maxim -- "We believe in the Power and the Might!" (Manowar, 1996) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Maxim Sobolev wrote: > Why we can't load compile and small KLD with all necessary syscalls (even ^^^ I mean ".load and compile small". Cut and paste technology sometimes plays bad jokes with us.;) -Max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar wrote: > As for AMD, I don't use it. I'll dig into manpages, source code and > whatsnot. If possible I'll reconfigure something here so that I can test > it on a i386. Thanks. I'll try to get you a stack trace from it today if I can find time. > BTW: I'm sorry, that a simple bug in the NFS code made your > filesystem go south. I have been working hard to prevent that... I know you have, and there's absolutely no need to apologize. Your commit was a model of excellence in terms of the review process, the heads up message, the commit logs, etc. This machine is a scratch box and if I had to go all the way back to disklabel it wouldn't be much of a disaster. Besides, it appears I only lost files from "/usr/obj". :-) John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Kenneth Wayne Culver wrote: > commit. But even then I still ran into problems, although I'm not sure how > closely related they are to the changes made. My problems seem to be with > the Soren's ata drivers. I'm using Soren's ATA drivers myself without problems. Admitted, I'm only using it to play audio CDs :-) -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
I would have to agree with that. I have never seen such a well documented commit. But even then I still ran into problems, although I'm not sure how closely related they are to the changes made. My problems seem to be with the Soren's ata drivers. The good old "lost contact with device" messages are back and with a vengence. It seems that now (through a mistake of my own, in addition to this problem with the ata drivers) I have to go back to a snapshot of current, and reinstall all the tools, as well as a generic kernel. However, the pnp controller as of the latest snapshot still causes me to lock up hard before I ever get booted. Isn't there some way to disable to pnp0 controller, like in the userconfig part off the boot floppy? = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: AgRSkaterq | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Thu, 30 Sep 1999, John Polstra wrote: > Marcel Moolenaar wrote: > > > As for AMD, I don't use it. I'll dig into manpages, source code and > > whatsnot. If possible I'll reconfigure something here so that I can test > > it on a i386. > > Thanks. I'll try to get you a stack trace from it today if I can > find time. > > > BTW: I'm sorry, that a simple bug in the NFS code made your > > filesystem go south. I have been working hard to prevent that... > > I know you have, and there's absolutely no need to apologize. Your > commit was a model of excellence in terms of the review process, the > heads up message, the commit logs, etc. This machine is a scratch box > and if I had to go all the way back to disklabel it wouldn't be much > of a disaster. Besides, it appears I only lost files from "/usr/obj". > :-) > > John > --- > John Polstra [EMAIL PROTECTED] > John D. Polstra & Co., Inc.Seattle, Washington USA > "No matter how cynical I get, I just can't keep up."-- Nora Ephron > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Maxim Sobolev scribbled this message on Sep 30: [-- Warning: koi8-r is not compatible with your display.] > Maxim Sobolev wrote: > > > Why we can't load compile and small KLD with all necessary syscalls (even > > ^^^ > I mean ".load and compile small". Cut and paste technology sometimes > plays bad jokes with us.;) hmmm.. that might be an option of providing a kld that emulates the new syscalls on an older kernel... I would want the patch to be available for staticly linking into the kernel though.. I don't like LKM/KLD's on servers that are suppose to be rock solid... (at least not yet) -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar scribbled this message on Sep 30:
> Try -DNOTOOLS. I don't know if the -current sources depend specifically
> on -current tools (such as egcs).
well, this may work, but it still doesn't produce a "clean" system to
build with... I don't know the number of times that I've used the
following patch to Makefile.inc1:
+build-env:
+ @echo export PATH=${STRICTTMPPATH}
+ @echo export COMPILER_PATH=${WORLDTMP}/usr/libexec:${WORLDTMP}/usr/bin
+ @echo export GCC_EXEC_PREFIX=${WORLDTMP}/usr/lib/
+ @echo export LD_LIBRARY_PATH=${WORLDTMP}${SHLIBDIR}
+ @echo export LIBRARY_PATH=${WORLDTMP}${SHLIBDIR}:${WORLDTMP}/usr/lib
+ @echo export DESTDIR=${WORLDTMP}
+
.include
this allows me to do eval `make build-env`, and suddenly, my build
environment on my 3.0-R box becomes a standard -current world that allows
me to build kernels, programs and other things as if I WAS on a -current
box...
loosing this ability is a big problem for me... I'd even go w/ a simple
option that converts all the signal macros into functions which get
switched depending upon the kernel... and you only get the performance
penalty if you define the option, and it would allow everything to be
backwards compatible...
--
John-Mark Gurney Voice: +1 408 975 9651
Cu Networking
"The soul contains in itself the event that shall presently befall it.
The event is only the actualizing of its thought." -- Ralph Waldo Emerson
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Thu, 30 Sep 1999, Marcel Moolenaar wrote: > The upgrading from -stable to -current is currently being tested by Bill > Fumerola. I can imagine that some might be broken in that case. This I > will attempt to fix, then... As others have mentioned 3.3-STABLE right now cannot build 4.0-CURRENT kernels. Without the 4.0-CURRENT kernel, I can't build the 4.0 world to build the 4.0 kernel, and so on. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John-Mark Gurney wrote: [..] > might as well say goodbye to ever getting freebsd's userland running > under NetBSD which is how our nice Alpha port got started... this > NEEDS to be fixed... NetBSD have just done exactly the same sort of thing. And for that matter it makes no difference for that sort of thing as we used a different syscall set explicitly in that case. The only "problem" is that -current libc is tightly bound to the -current kernel. How about this as a cheap and robust "solution": - when building libc, have an option that allows sigaction etc to be *wrappers* that emulate their functionality through osigaction(). This means dropping sigaction etc from the assembler function list and use some C stubs instead. Call this (say) -DANCIENTTOOLS for the Makefiles. The objective would be to try not to generate a binary that requires syscalls that are not present on something like 2.2.x. - -DANCIENTTOOLS would be both a make define and a C define, so makefiles could use .if defined(ANCIENTTOOLS) ... to disable new stuff and C code could use #ifdef ANCIENTTOOLS or #ifndef etc. This would mean it would be a lot easier to build make(1) as well since it could avoid using stuff that is only in the latest systems. - this could be used on other libraries (eg: consumers of issetugid()) - what this buys us is we can build the static libraries and build tools with -DANCIENTTOOLS and they'll run on anything from 2.2 onwards. - this can also be used to do some workarounds for old gcc's etc for the build tools too. - this enables us to build the /usr/obj/tmp tree hosted for >= 2.2.x but they are -current tools for compiling the *rest* of the system including the real build tools. I think this would solve a lot of chicken/egg problems and would solve the signal syscall issue thing completely. So far we've been lucky. None of the 40-50 odd new syscalls we've added over the last few years have been used in building the tree, so folks have had it easy for a while. Marcel has done *nothing* wrong. This was bound to blow up sooner or later when we added a new syscall that was used during the build. So how about folks get off Marcel's back and stop running around like it's the end of the world and lets do a proper workaround. Rest assured, this will be resolved with a workaround of some sort or other and will be a 4.0-RELEASE requirement that 3.x-stable can do a source upgrade to 4.0. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Peter Wemm scribbled this message on Oct 1: > John-Mark Gurney wrote: > [..] > > might as well say goodbye to ever getting freebsd's userland running > > under NetBSD which is how our nice Alpha port got started... this > > NEEDS to be fixed... > > NetBSD have just done exactly the same sort of thing. And for that matter > it makes no difference for that sort of thing as we used a different syscall > set explicitly in that case. > > The only "problem" is that -current libc is tightly bound to the -current > kernel. > > How about this as a cheap and robust "solution": > - when building libc, have an option that allows sigaction etc to be > *wrappers* that emulate their functionality through osigaction(). This > means dropping sigaction etc from the assembler function list and use some > C stubs instead. Call this (say) -DANCIENTTOOLS for the Makefiles. > The objective would be to try not to generate a binary that requires syscalls > that are not present on something like 2.2.x. [...] I completely agree... this isn't a problem that takes much work to solve.. > So far we've been lucky. None of the 40-50 odd new syscalls we've added > over the last few years have been used in building the tree, so folks have yes, we have had it very easy, it's surprising that we have made it this long w/ the build system we have... > had it easy for a while. Marcel has done *nothing* wrong. This was bound > to blow up sooner or later when we added a new syscall that was used during > the build. > > So how about folks get off Marcel's back and stop running around like it's > the end of the world and lets do a proper workaround. Rest assured, this > will be resolved with a workaround of some sort or other and will be a > 4.0-RELEASE requirement that 3.x-stable can do a source upgrade to 4.0. the reason I was on Marcel's back was because of his statement that he WOULD NOT do ANYTHING to fix the problem, and that as far as he was considered, that's life and deal w/ it... if he had said, oh, I'll look for a solution to the problem, I wouldn't of been so hard on him... so, is Marcel going to do the work for this? or will this have to be passed to someone like you or myself? -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Thu, 30 Sep 1999, Brad Knowles wrote: > At 10:17 PM + 1999/9/29, Adam Strohl wrote: > > > Furthermore, for when 4.0 becomes a -R or -S, ftping in a compiled kernel > > shouldn't be that hard of a price to pay for going from 3.2. > > > > /stand/sysinstall based upgrades could easily seemlessly take care of > > this, too. > > I must confess ignorance (and I haven't exhaustively searched the > mailing list archives, the Handbook, or the FAQ), For future reference you will get better results if you don't explicitly state your failure to educate yourself on the topic you are posting about. > but is this the > recommended method of upgrading from a previous major release to the > latest -STABLE major release (i.e., going from 2.x to 3.x today, or > from 3.x to 4.x when the time comes)? I thought the official > procedure was cvsup, or is that for updating only within a particular > major release? There is no "official procedure." Like everything else in unix the "best" solution varies on the problem domain. If you have console access it is generally always better to use sysinstall since that method is almost always guaranteed to work. Many of us don't have console access to the machines we maintain, and although this is not an "officially supported" method of upgrading preventing chicken and egg problems in the upgrade from source process is a matter of good design, as well as a matter of great importance to the "fringe cases" that don't involve "simply" doing an upgrade. Doug -- "Stop it, I'm gettin' misty." - Mel Gibson as Porter, "Payback" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John-Mark Gurney wrote: > the reason I was on Marcel's back was because of his statement that he > WOULD NOT do ANYTHING to fix the problem, and that as far as he was > considered, that's life and deal w/ it... if he had said, oh, I'll look > for a solution to the problem, I wouldn't of been so hard on him... I said that for the -current case. I also said that an upgrade from -stable to -current will be fixed if it was broken. > so, is Marcel going to do the work for this? or will this have to be > passed to someone like you or myself? I'm not going to claim this. Everyone with a constructive opinions can join the club. It's so much easier for everyone if it's done by more than 1 person. Those that don't feel confortable solving this problem are encouraged to test solutions. As for me, I'm trying to define the problem as detailed and consise as possible. I already have some specific thoughts and ideas. I'm thinking large here: real cross-compilation capabilities and such (it may be handy for FreeBSD/IA64)... -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Sep 30, 11:24pm, Marcel Moolenaar wrote: } Subject: Re: HEADS UP: sigset_t changes committed } As for me, I'm trying to define the problem as detailed and consise as } possible. I already have some specific thoughts and ideas. I'm thinking } large here: real cross-compilation capabilities and such (it may be } handy for FreeBSD/IA64)... While proper cross-compilation would be really nice to have, it won't solve the "make world" problem. It would get you through "make buildworld", but "make installworld" will overwrite the system binaries with new versions that use the new signal syscalls that the currently running kernel doesn't support. It would even be possible to cross-compile a new kernel, but it still has to be installed and the system rebooted before installing userland. In this particular case, the only thing cross-compilation would buy us is the ability to build (but not install) 4.x binaries on a machine running 3.x. It sounds like some folks would be satisfied just having that. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Don Lewis scribbled this message on Sep 30:
> On Sep 30, 11:24pm, Marcel Moolenaar wrote:
> } Subject: Re: HEADS UP: sigset_t changes committed
>
> } As for me, I'm trying to define the problem as detailed and consise as
> } possible. I already have some specific thoughts and ideas. I'm thinking
> } large here: real cross-compilation capabilities and such (it may be
> } handy for FreeBSD/IA64)...
>
> While proper cross-compilation would be really nice to have, it won't solve
> the "make world" problem. It would get you through "make buildworld", but
> "make installworld" will overwrite the system binaries with new versions that
> use the new signal syscalls that the currently running kernel doesn't support.
> It would even be possible to cross-compile a new kernel, but it still has
> to be installed and the system rebooted before installing userland.
>
> In this particular case, the only thing cross-compilation would buy us
> is the ability to build (but not install) 4.x binaries on a machine
> running 3.x. It sounds like some folks would be satisfied just having
> that.
I'm sorry, this is easy to fix... have a set of tools you copy to /ibin
that are used for the install (all staticly compiled binaries hopefully)
and run the install world out of /ibin... maybe include some binaries
for system recovery to make sure...
if people are interested, I can take a look at it... it'd be interesting
to be able to do something like; make prep-installworld; rm -rf
/usr/{sbin,bin,lib} /{bin,sbin}; make installworld and have it
complete... :)
--
John-Mark Gurney Voice: +1 408 975 9651
Cu Networking
"The soul contains in itself the event that shall presently befall it.
The event is only the actualizing of its thought." -- Ralph Waldo Emerson
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar scribbled this message on Sep 30: > John-Mark Gurney wrote: > > > the reason I was on Marcel's back was because of his statement that he > > WOULD NOT do ANYTHING to fix the problem, and that as far as he was > > considered, that's life and deal w/ it... if he had said, oh, I'll look > > for a solution to the problem, I wouldn't of been so hard on him... > > I said that for the -current case. I also said that an upgrade from > -stable to -current will be fixed if it was broken. you don't under stand, we are NOT talking about upgrades, we are talking about how to make a buildable system on -stable... the make buildworld -DNOTOOLS does not work, and will not work for what I like to do.. I need tools from -current that RUN ON -stable... you completely cut the whole part of me agreeing w/ Peter about -DACIENTTOOLS... and so you know, (this is unrelated to the -current tools running on -stable), you can't do a buildworld w/ -DNOTOOLS and have it succeed: ===> libgcc echo '#include ' > config.h echo '#include ' >> config.h echo '#include "i386/xm-i386.h"' > tconfig.h echo '#include "i386/i386.h"' > tm.h echo '#include "i386/att.h"' >> tm.h echo '#include "i386/freebsd.h"' >> tm.h echo '#include "i386/perform.h"' >> tm.h cc -c -nostdinc -O -pipe -pipe -O -pipe -O -I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/a/home/johng/FreeBSD-checkout/40current/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c cc1: Invalid option `-fexceptions' *** Error code 1 it took me all of 21 minutes for the buildworld to fail.. considering I'm not running softupdates, it'd be even faster... > > so, is Marcel going to do the work for this? or will this have to be > > passed to someone like you or myself? > > I'm not going to claim this. Everyone with a constructive opinions can > join the club. It's so much easier for everyone if it's done by more > than 1 person. Those that don't feel confortable solving this problem > are encouraged to test solutions. so, I take this that you are uninterested in trying to solve the problem at hand? I vote for Peter's idea, which is something that I was thinking about before he sent the idea out... just in a different way... > As for me, I'm trying to define the problem as detailed and consise as > possible. I already have some specific thoughts and ideas. I'm thinking > large here: real cross-compilation capabilities and such (it may be > handy for FreeBSD/IA64)... ok, the problem is: a) -current tools are built w/ -current libc and friends b) -current libc and friends are NOW (they used to not be this way) unable to run on anything but -current because of the signal changes.. c) the problem is that the signal changes do not provide a way to continue to function in the case that the kernel doesn't support the new syscalls... we have a catch-22 in the build environment.. the tools need a -current libc and friends, and libc and friends needs a -current kernel, and a -current kernel needs the tools to be built... the solution is to make libc and friends be able to operate on a non-current system by wrapping the signal stuff in #ifdef's that will provide fall back support when requested and use the o* syscalls in this case... what we may want to do, is to leave the old signal code in, and simply add in the ability to "select" what signal code we want to include.. and make it a general system so that it just doesn't apply to the signal system... this way we can say, we are building under NetBSD, and they don't have getcwd as a syscall so we need to compile getcwd as a function using this code, instead of using FreeBSD's syscall... and as Bruce will point out... the fact that -current's libc even builds on -stable and has run is completely by chance... our build of libc and tools should detect the system that we are on (or be told the type of system) and react accordingly... before this time we have been lucky that it hasn't been needed, but now we need it... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
> you don't under stand, we are NOT talking about upgrades, we are talking > about how to make a buildable system on -stable... There are essentially the same problem. In order to do an upgrade, you have to be able to build on -stable. :) > ===> libgcc > echo '#include ' > config.h > echo '#include ' >> config.h > echo '#include "i386/xm-i386.h"' > tconfig.h > echo '#include "i386/i386.h"' > tm.h > echo '#include "i386/att.h"' >> tm.h > echo '#include "i386/freebsd.h"' >> tm.h > echo '#include "i386/perform.h"' >> tm.h > cc -c -nostdinc -O -pipe -pipe -O -pipe -O >-I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config > >-I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc > -I. -fexceptions -DIN_GCC >-I/usr/obj/a/home/johng/FreeBSD-checkout/40current/src/tmp/usr/include -DL_mulsi3 -o >_mulsi3.o >/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c > cc1: Invalid option `-fexceptions' This is unrelated to the signal code. Why are you jumping on Marcel for this? In any case, I believe there is work in progress as well as interest in making *something* work. Let's all quit yelling at one another and start working towards a solution, instead of pointing fingers and screaming 'he broke it and won't fix it'. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Sep 30, 4:14pm, John-Mark Gurney wrote: } Subject: Re: HEADS UP: sigset_t changes committed } > } > In this particular case, the only thing cross-compilation would buy us } > is the ability to build (but not install) 4.x binaries on a machine } > running 3.x. It sounds like some folks would be satisfied just having } > that. } } I'm sorry, this is easy to fix... have a set of tools you copy to /ibin } that are used for the install (all staticly compiled binaries hopefully) } and run the install world out of /ibin... maybe include some binaries } for system recovery to make sure... ... but as soon as you run the stuff in /ibin to install the new userland, you won't even be able to run a shell script, because the newly installed /bin/sh will be using the new signal syscalls. The install process will have to include installing a new kernel and will have to be followed by an immediate reboot. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Fri, Oct 01, 1999, you wrote: >On Sep 30, 4:14pm, John-Mark Gurney wrote: >} Subject: Re: HEADS UP: sigset_t changes committed >} > >} > In this particular case, the only thing cross-compilation would buy us >} > is the ability to build (but not install) 4.x binaries on a machine >} > running 3.x. It sounds like some folks would be satisfied just having >} > that. >} >} I'm sorry, this is easy to fix... have a set of tools you copy to /ibin >} that are used for the install (all staticly compiled binaries hopefully) >} and run the install world out of /ibin... maybe include some binaries >} for system recovery to make sure... > >... but as soon as you run the stuff in /ibin to install the new userland, >you won't even be able to run a shell script, because the newly installed >/bin/sh will be using the new signal syscalls. No, all it means is that the tools to install the new userland need to have special shellscripts with '#!/ibin/sh' or similar, or be explicitly invoked (eg /ibin/sh foo). I don't think this is a real problem. Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Don Lewis scribbled this message on Sep 30: > On Sep 30, 4:14pm, John-Mark Gurney wrote: > } Subject: Re: HEADS UP: sigset_t changes committed > } > > } > In this particular case, the only thing cross-compilation would buy us > } > is the ability to build (but not install) 4.x binaries on a machine > } > running 3.x. It sounds like some folks would be satisfied just having > } > that. > } > } I'm sorry, this is easy to fix... have a set of tools you copy to /ibin > } that are used for the install (all staticly compiled binaries hopefully) > } and run the install world out of /ibin... maybe include some binaries > } for system recovery to make sure... > > ... but as soon as you run the stuff in /ibin to install the new userland, > you won't even be able to run a shell script, because the newly installed > /bin/sh will be using the new signal syscalls. The install process will > have to include installing a new kernel and will have to be followed by > an immediate reboot. why are you trying to run a shell script instead of rebooting your computer after the installworld? you need to install a kernel+userland as a COMPLETE set... and the kernel needs to be build w/ the tools that were used to make all... it's that simple.. the hard part is making the tools work/build properly... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Nate Williams scribbled this message on Sep 30: > > you don't under stand, we are NOT talking about upgrades, we are talking > > about how to make a buildable system on -stable... > > There are essentially the same problem. In order to do an upgrade, you > have to be able to build on -stable. :) yes, they are the "same problem", but they are viewed differently.. w/ an upgrade, you can requre ANYTHING to happen, this includes having to install and reboot w/ 10 different kernels before you reach your destination... which makes the last part impossible... > > ===> libgcc > > echo '#include ' > config.h > > echo '#include ' >> config.h > > echo '#include "i386/xm-i386.h"' > tconfig.h > > echo '#include "i386/i386.h"' > tm.h > > echo '#include "i386/att.h"' >> tm.h > > echo '#include "i386/freebsd.h"' >> tm.h > > echo '#include "i386/perform.h"' >> tm.h > > cc -c -nostdinc -O -pipe -pipe -O -pipe -O >-I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config > >-I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc > -I. -fexceptions -DIN_GCC >-I/usr/obj/a/home/johng/FreeBSD-checkout/40current/src/tmp/usr/include -DL_mulsi3 -o >_mulsi3.o >/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c > > cc1: Invalid option `-fexceptions' > > This is unrelated to the signal code. Why are you jumping on Marcel for > this? this is what preceeded the above snip it in my original message that Nate deleted: > > and so you know, (this is unrelated to the -current > > tools running on -stable), you can't do a buildworld w/ -DNOTOOLS and > > have it succeed: he suggested that I try a make buildworld -DNOTOOLS to see if that would work, I was simply reporting that it failed to work... notice that I said: "this is unrelated to the -current tools running on -stable" part... > In any case, I believe there is work in progress as well as interest in > making *something* work. Let's all quit yelling at one another and > start working towards a solution, instead of pointing fingers and > screaming 'he broke it and won't fix it'. :) P.S. It is really hard for me to not make personal attacks against you after all of the above and completely ignoring the rest of my message. Simply pointing out behavior problems is not going to solve anything. So, why don't you read the last part of my message that you felt like ignoring, and provide input? The last part included a possible solution to the problem. since you seem to have completely ignored the last part of my message, here it is again: ok, the problem is: a) -current tools are built w/ -current libc and friends b) -current libc and friends are NOW (they used to not be this way) unable to run on anything but -current because of the signal changes.. c) the problem is that the signal changes do not provide a way to continue to function in the case that the kernel doesn't support the new syscalls... we have a catch-22 in the build environment.. the tools need a -current libc and friends, and libc and friends needs a -current kernel, and a -current kernel needs the tools to be built... the solution is to make libc and friends be able to operate on a non-current system by wrapping the signal stuff in #ifdef's that will provide fall back support when requested and use the o* syscalls in this case... what we may want to do, is to leave the old signal code in, and simply add in the ability to "select" what signal code we want to include.. and make it a general system so that it just doesn't apply to the signal system... this way we can say, we are building under NetBSD, and they don't have getcwd as a syscall so we need to compile getcwd as a function using this code, instead of using FreeBSD's syscall... and as Bruce will point out... the fact that -current's libc even builds on -stable and has run is completely by chance... our build of libc and tools should detect the system that we are on (or be told the type of system) and react accordingly... before this time we have been lucky that it hasn't been needed, but now we need it... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
> P.S. It is really hard for me to not make personal attacks against you > after all of the above and completely ignoring the rest of my message. No, I didn't. My statement was that your 'confrontational' style of email wasn't making things any better. Mellow it out, and instead of attacking first (thus putting folks on the defense) and then providing content, skip the first step. This is the same as you've done with the response to me, attack first and ask questions later. :( Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Nate Williams scribbled this message on Sep 30: > > P.S. It is really hard for me to not make personal attacks against you > > after all of the above and completely ignoring the rest of my message. > > No, I didn't. My statement was that your 'confrontational' style of > email wasn't making things any better. > > Mellow it out, and instead of attacking first (thus putting folks on the > defense) and then providing content, skip the first step. > > This is the same as you've done with the response to me, attack first > and ask questions later. :( this is just a notice, I am going to be taking a break from FreeBSD for a couple weeks... I will not be reading my freebsd.org email while I am on the break, my other email addresses will continue to work... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Don Lewis wrote: > > While proper cross-compilation would be really nice to have, it won't solve > the "make world" problem. It would get you through "make buildworld", but > "make installworld" will overwrite the system binaries with new versions that > use the new signal syscalls that the currently running kernel doesn't support. > It would even be possible to cross-compile a new kernel, but it still has > to be installed and the system rebooted before installing userland. Correct. If you want to be able to upgrade your -stable system to -current by simply typeing 'make upgrade', then building and installing the kernel should be part of that target. The installworld problem can then be solved like this (for example): 1) backup binaries that are needed by installworld 2) Install a new kernel 3) install world 4) reboot If installworld fails halfway through step 3, and leaves you with an unusable system, then rebooting should be able to solve that. > In this particular case, the only thing cross-compilation would buy us > is the ability to build (but not install) 4.x binaries on a machine > running 3.x. It sounds like some folks would be satisfied just having > that. Exactly, but done properly (or at all) installing may be possible as well. I think we should aim for that to happen and see where it leads us. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John-Mark Gurney wrote:
>
> if people are interested, I can take a look at it... it'd be interesting
> to be able to do something like; make prep-installworld; rm -rf
> /usr/{sbin,bin,lib} /{bin,sbin}; make installworld and have it
> complete... :)
Yes, please. Don't forget to install the newly built kernel as part of
an upgrade process. It may not be appropriate in a normal installworld,
though.
--
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John-Mark Gurney wrote: > > you don't under stand, we are NOT talking about upgrades, we are talking > about how to make a buildable system on -stable... the make buildworld > -DNOTOOLS does not work, and will not work for what I like to do.. I > need tools from -current that RUN ON -stable... I do understand. You would have known if you followed the other threads on this topic. > you completely cut the whole part of me agreeing w/ Peter about > -DACIENTTOOLS... and so you know, (this is unrelated to the -current > tools running on -stable), you can't do a buildworld w/ -DNOTOOLS and > have it succeed: I haven't had time to read is suggestion, contemplate and determine its strengths and weaknesses for myself. If everybody stopped whining for a minute ;-) > ===> libgcc > echo '#include ' > config.h > echo '#include ' >> config.h > echo '#include "i386/xm-i386.h"' > tconfig.h > echo '#include "i386/i386.h"' > tm.h > echo '#include "i386/att.h"' >> tm.h > echo '#include "i386/freebsd.h"' >> tm.h > echo '#include "i386/perform.h"' >> tm.h > cc -c -nostdinc -O -pipe -pipe -O -pipe -O >-I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config > >-I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc > -I. -fexceptions -DIN_GCC >-I/usr/obj/a/home/johng/FreeBSD-checkout/40current/src/tmp/usr/include -DL_mulsi3 -o >_mulsi3.o >/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c > cc1: Invalid option `-fexceptions' > *** Error code 1 Mine has stopped at exactly the same point. I started a make world yesterday (it finished tonight). > it took me all of 21 minutes for the buildworld to fail.. considering > I'm not running softupdates, it'd be even faster... Congratulations! > > As for me, I'm trying to define the problem as detailed and consise as > > possible. I already have some specific thoughts and ideas. I'm thinking > > large here: real cross-compilation capabilities and such (it may be > > handy for FreeBSD/IA64)... > > ok, the problem is: > a) -current tools are built w/ -current libc and friends Yes. This can't be done. > b) -current libc and friends are NOW (they used to not be this way) unable > to run on anything but -current because of the signal changes.. We have never supported running -current binaries (ie compiled against a -current environment) to run on -stable. If it worked in the past, nice. > c) the problem is that the signal changes do not provide a way to > continue to function in the case that the kernel doesn't support > the new syscalls... No that's not the real problem here. You're redefining the problem to match your solution. > we have a catch-22 in the build environment.. the tools need a -current > libc and friends, and libc and friends needs a -current kernel, and a > -current kernel needs the tools to be built... No, we don't have a catch-22. We're using the wrong sources for the wrong reasons. > the solution is to make libc and friends be able to operate on a > non-current system by wrapping the signal stuff in #ifdef's that will > provide fall back support when requested and use the o* syscalls in > this case... That may solve this problem, but doesn't leave you with cross-compilation. > what we may want to do, is to leave the old signal code in, and simply > add in the ability to "select" what signal code we want to include.. > and make it a general system so that it just doesn't apply to the signal > system... I can't parse this. The old sisgnal code hasn't been removed. We have to explicitly add support, because we need to transform the new sigset_t related calls onto the old. > this way we can say, we are building under NetBSD, and they don't have > getcwd as a syscall so we need to compile getcwd as a function using > this code, instead of using FreeBSD's syscall... What you are saying, is that libc must be used as a compatibility shell, right? > and as Bruce will point out... the fact that -current's libc even builds > on -stable and has run is completely by chance... Exactly. So are running binaries. > our build of libc and tools should detect the system that we are on (or > be told the type of system) and react accordingly... before this time > we have been lucky that it hasn't been needed, but now we need it... Exactly. This has been discussed in another thread with Rodney. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John-Mark Gurney wrote: > > hmmm.. that might be an option of providing a kld that emulates the new > syscalls on an older kernel... I would want the patch to be available > for staticly linking into the kernel though.. I don't like LKM/KLD's on > servers that are suppose to be rock solid... (at least not yet) It coulod be part of the TOOLS section of world. Install a kld for the purpose of buildworld and use it. It would prevent people from building world on machines with securelevel >= 2, though, and that's bad. Nevertheless, since this particular target would only be compiled to deal with this kind of nasty changes, and would not be required most of the time, it sounds reasonable to me. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] Rule 69: Do unto other's code as you'd have it do unto yours To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
> I'm not working on changing the build/installworld. There's nothing > "broken" about having to install the kernel first, IMO. I don't see how > I can "fix" it then. In fact for OpenBSD (and I'll assume NetBSD) their `build world' procedure is to first compile a new config(8), then build and install a new kernel & reboot. THEN build and install the rest. from /usr/src/Makefile: # 3) It is strongly recommended that you build and install a new kernel # before rebuilding your system. Some of the new programs may use new # functionality or depend on API changes that your old kernel doesn't # have. # # 4) If you are reasonably sure that things will compile OK, use the # "make build" target supplied here. Good luck. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
David O'Brien wrote: > > > I'm not working on changing the build/installworld. There's nothing > > "broken" about having to install the kernel first, IMO. I don't see how > > I can "fix" it then. > > In fact for OpenBSD (and I'll assume NetBSD) their `build world' > procedure is to first compile a new config(8), then build and install a > new kernel & reboot. THEN build and install the rest. I think Peter makes some good arguments inre building the kernel first, but as others have expressed I think that the chicken and egg problems are not yet solved. Perhaps what we need is a type of pre-world kernel target that will create a space somewhere in /usr/src/sys where it can build and install all the dependencies (gas, config, etc.) then build the new kernel with the new tools. So the "new" procedure would be something like: make kernel NAME Builds tools, builds new kernel, installs new kernel, (rebuilds libkvm & friends?) reboot (option to rebuild libkvm, et al here instead for those cases where world won't be built?) make world (insert things like rebuild kernel again to get sigset_t changes in) reboot Does this sound like the same things y'all are talking about? I realize that I haven't even addressed the cross platform problems, and I agree that it is necessary to solve those longstanding issues. However before we can start on those problems we need to come to agreement on the "best" method of performing the necessary steps, then hammer out the details. This has the potential to really go somewhere if people get behind it and commit to solving the problems with a long term view in mind. Excited, Doug -- "Stop it, I'm gettin' misty." - Mel Gibson as Porter, "Payback" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
In message <[EMAIL PROTECTED]> Marcel Moolenaar writes: : Yes, but if you need the tools you just compiled in your : cross-compilation for cross-compilation itself, you'll have a big : problem. And that's almost exacly what happens when building world... No. The cross build world takes care to build host runable binaries. It doesn't take sufficient care because your change highlights places where it doesn't. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
In message <[EMAIL PROTECTED]> John-Mark Gurney writes: : I thought we were working to the point that we could build a mips world : on an x86 box?? w/ this, it completely breaks it... the whole idea of : a buildworld is that the tools can be build on ANY platform and run, : (assuming the tools support it) and then be able to build the target... No. It won't built completely, but only through the first kernel files that are needed (at least in the checked in tree). I had things further, but lost them in a disk crash. I've not had the time to revisit it since then. I defintely will have to try this again after these changes. If it can't be made to work, this is a huge deal... However, the current build tree isn't careful enough to distinguish between host run programs and target programs, which is why we're having this problem. I suspect that making this work will make cross building easier (and vice versa). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
