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 s
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 b
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
> 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 ins
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... (a
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...
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
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 curr
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 thin
> 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 fi
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. :
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 in
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
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
> 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 '#in
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
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
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 capabi
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
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 seemle
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
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 tha
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
k
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
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"
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
a
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 pl
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 b
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
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)
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
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 i
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
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.
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 si
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
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 ye
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, bu
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
[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
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 rejo
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 "u
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. T
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).
>
> actu
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 ta
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
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 -s
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
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 y
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 w
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
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
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 GENER
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
< 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
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
< 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
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
< 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
> > 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 proce
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.
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,
> > the
> 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"
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
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
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
>
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.bi
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 m
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 ne
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 wi
> 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;
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, a
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
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,
> 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;
>
> +
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
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;
>> {
>> +
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_siglis
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 ...). Le
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 o
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
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
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
insta
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
> 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 mes
85 matches
Mail list logo
