I have the following senerio -
We need to build the kernel and world for multiple platforms
architectures (amd64, mips, ppc, etc). Initially we had a set
of shell scripts for the following:
machine-kernel-toolchain.sh
machine-kernel64.sh
machine-world64.sh
machine-bldpkg.sh
on 23/06/2010 03:38 Hans Petter Selasky said the following:
Hi,
I'm creating a new thread on this issue.
On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote:
I saw similar behaviour a couple of years ago when I switched from
using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree
On Wednesday 23 June 2010 08:47:52 Andriy Gapon wrote:
on 23/06/2010 03:38 Hans Petter Selasky said the following:
Hi,
I'm creating a new thread on this issue.
On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote:
I saw similar behaviour a couple of years ago when I switched
on 23/06/2010 09:52 Hans Petter Selasky said the following:
On Wednesday 23 June 2010 08:47:52 Andriy Gapon wrote:
on 23/06/2010 03:38 Hans Petter Selasky said the following:
Hi,
I'm creating a new thread on this issue.
On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote:
I saw
on 23/06/2010 10:02 Andriy Gapon said the following:
I don't dispute that it is found broken in particular environments, I just
think
that the analysis could be incorrect.
Which also brings the question - what arch(s) is affected?
I tested on amd64.
--
Andriy Gapon
On Wednesday 23 June 2010 09:10:59 Andriy Gapon wrote:
on 23/06/2010 10:02 Andriy Gapon said the following:
I don't dispute that it is found broken in particular environments, I
just think that the analysis could be incorrect.
Ok.
Which also brings the question - what arch(s) is
Patrick Mahan ma...@mahan.org writes:
My issue is that if there is a build failure at any point, the
status does not seem to be propagated upward. For example, if
the kernel fails to build due to incorrect code, the script
machine-kernel64.sh stops (verifable by examining the logfile),
On 06/21/10 02:25, Garrett Cooper wrote:
For whatever reason my source tree wasn't prebuilt, so I reran
buildkernel and everything was fine once again.
So, do the tests pass now? :)
___
freebsd-hackers@freebsd.org mailing list
On Wed, Jun 23, 2010 at 10:10:59AM +0300, Andriy Gapon wrote:
on 23/06/2010 10:02 Andriy Gapon said the following:
I don't dispute that it is found broken in particular environments, I just
think
that the analysis could be incorrect.
Which also brings the question - what arch(s) is
On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon a...@icyb.net.ua wrote:
Which also brings the question - what arch(s) is affected?
I tested on amd64.
This should explain it. It looks to me like i386 uses kern/link_elf.c
as its linker, while amd64 uses kern/link_elf_obj.c. link_elf.c can
only
On Wed, Jun 23, 2010 at 2:56 AM, Ivan Voras ivo...@freebsd.org wrote:
On 06/21/10 02:25, Garrett Cooper wrote:
For whatever reason my source tree wasn't prebuilt, so I reran
buildkernel and everything was fine once again.
So, do the tests pass now? :)
Not 100%, but that might be a problem
on 23/06/2010 18:03 Ryan Stone said the following:
On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon a...@icyb.net.ua wrote:
Which also brings the question - what arch(s) is affected?
I tested on amd64.
This should explain it. It looks to me like i386 uses kern/link_elf.c
as its linker, while
On Wed, Jun 23, 2010 at 11:03:45AM -0400, Ryan Stone wrote:
I have to admit that I'm more than a little surprised that this
problem does not affect modules that in src, but maybe that's because
I don't know all that much about FreeBSD's build infrastructure. Are
the src modules being linked
I've escaped to loader prompt:
Current device is disk0s3a, from which this loader is running.
My USB stick is device1 and device1s2a is UFS /, on which I would like to
reach some file or simply list directory.
Syntax?
___
freebsd-hackers@freebsd.org
On 23.06.2010 23:03, rank1see...@gmail.com wrote:
I've escaped to loader prompt:
Current device is disk0s3a, from which this loader is running.
My USB stick is device1 and device1s2a is UFS /, on which I would like to
reach some file or simply list directory.
Syntax?
I guess, you have
You *should* be able to use device1s2a:/ as a syntax, but I noticed a bug in
our old loader code that parses devicenames like that where it wouldn't work
correctly with unit numbers. I don't know if that bug is still around, but
setting currdev did work around it.
/Andrew
-Original
On Wed, Jun 23, 2010 at 9:03 AM, rank1see...@gmail.com wrote:
I've escaped to loader prompt:
Current device is disk0s3a, from which this loader is running.
My USB stick is device1 and device1s2a is UFS /, on which I would like to
reach some file or simply list directory.
IIRC, there is no
2010/6/23 Eugene Grosbein eu...@grosbein.pp.ru:
On 23.06.2010 23:03, rank1see...@gmail.com wrote:
I've escaped to loader prompt:
Current device is disk0s3a, from which this loader is running.
My USB stick is device1 and device1s2a is UFS /, on which I would like to
reach some file or simply
Hi Kostik,
This patch seems to have faded out from memory. Is it possible to go
forward and commit it?
Thanks,
Regards.
On Sat, Jul 25, 2009 at 12:29:16AM +0300, Kostik Belousov wrote:
Below is the prototype that seems to work for me both with patched and
old rtld on i386. Patch also
On Wed, Jun 23, 2010 at 08:45:31AM -0700, Ted Faber wrote:
On Wed, Jun 23, 2010 at 11:03:45AM -0400, Ryan Stone wrote:
I have to admit that I'm more than a little surprised that this
problem does not affect modules that in src, but maybe that's because
I don't know all that much about
hi sorry for being late in reply but I had some problems in the last week. I
hope u still remeber what I was talking about :)
@chargen
Thanx for ur reply.
Embedded computer systems permeate all aspects of our daily lives.
Alarm clocks, coffee makers, digital watches, cell phones, and automobiles
21 matches
Mail list logo
