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
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
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
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
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
[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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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 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
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
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
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 i386/xm-i386.h' config.h
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
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
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
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. :)
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
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
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
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
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
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
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
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
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
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 =
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
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 =
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
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
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,
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
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,
then I agree
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 21:17:48 -0400, Jim Bloom [EMAIL PROTECTED] 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.
On Wed, 29 Sep 1999 16:51:37 -0700 (PDT), "Rodney W. Grimes"
[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).
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current"
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
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
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
Hi,
On Wed, Sep 29, 1999 at 10:07:07PM -0700, John-Mark Gurney wrote:
Garrett Wollman scribbled this message on Sep 29:
On Wed, 29 Sep 1999 16:51:37 -0700 (PDT), "Rodney W. Grimes"
[EMAIL PROTECTED] said:
If it is broken, please back out the signal changes or fix the tools
target.
58 matches
Mail list logo
