I'd say split this into the respective commits, so they are
self-contained.
Thanks for all that!
Samuel
Luca Dariz, le jeu. 28 déc. 2023 20:43:01 +0100, a ecrit:
> ---
> tests/user-qemu.mk | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/tests/user-qemu.mk b/t
---
tests/user-qemu.mk | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tests/user-qemu.mk b/tests/user-qemu.mk
index 50b04736..669eb77a 100644
--- a/tests/user-qemu.mk
+++ b/tests/user-qemu.mk
@@ -178,7 +178,15 @@ clean-test-%:
USER_TESTS := \
- tests/test-
Hey folks,
I'm checking make check output now. My log is here:
http://www2.bddebian.com:8000/hurd/glibc/glibc25_tls/make_check1.log
I trimmed out just a list of the errors here:
http://www2.bddebian.com:8000/hurd/glibc/glibc25_tls/make_check1_errors.log
I'll see if my dum
On Mon, Nov 25, 2002 at 05:06:22PM -0800, Roland McGrath wrote:
> > init_first.c now fails to compile with the following errors:
> Oops, my bad. I think and are what it needs.
> Can you test that?
That appears to fix it. Thanks!
Tks,
Jeff Bailey
__
> init_first.c now fails to compile with the following errors:
Oops, my bad. I think and are what it needs.
Can you test that?
> ../sysdeps/mach/hurd/i386/init-first.c: In function `posixland_init':
> ../sysdeps/mach/hurd/i386/init-first.c:68: `_dl_starting_up' undeclared (first use
>this fun
On Thu, Nov 21, 2002 at 08:24:21PM -0800, Roland McGrath wrote:
> > math/test-fpucw.out
> >
> > control word is 0x23f but should be 0x33f.
> I imagine this explains the other math results, which otherwise
> should not differ from Linux/x86. I put in a change to init-first.c
> that might fix i
On Thu, 2002-11-21 at 23:24, Roland McGrath wrote:
> > assert/test-assert-perr.out
> >
> > Blank file
>
> It's always empty. Do you mean it exitted with nonzero?
Yes, it exitted with 1.
--
When you get to the heart,
use a knife and fork.
- From instructions on how to eat an artichoke.
s
> assert/test-assert-perr.out
>
> Blank file
It's always empty. Do you mean it exitted with nonzero?
> math/test-fenv.out
>
> Test: after fesetenv (FE_NOMASK_ENV) processes will abort
> when feraiseexcept (FE_INVALID) is called.
> Fail: Process didn't receive signal and exited
FYI, I've just run make check on glibc for the Hurd (2.3.1 with various
Debian patches)
I'm pleased that all of the locales stuff appears to pass (I last ran
make check when we still used stdio)
This post is mostly informational and in case some brave hacker feels
like figuring the
On Fri, May 10, 2002 at 08:55:47AM -0700, Jeff Bailey wrote:
> On Fri, May 10, 2002 at 05:42:19PM +0200, Marcus Brinkmann wrote:
> > BTW, Jeroen might be interested in monitoring the build logs etc.
>
> That would be cool. But I'll let him volunteer before I give him
> work. ;)
Yes, I can monit
On Fri, May 10, 2002 at 08:55:47AM -0700, Jeff Bailey wrote:
> On Fri, May 10, 2002 at 05:42:19PM +0200, Marcus Brinkmann wrote:
>
> > > I remember you mentioning on IRC that `make check' for gcc won't
> > > work on the Hurd. Was that a stdio-related problem
On Fri, May 10, 2002 at 05:42:19PM +0200, Marcus Brinkmann wrote:
> > I remember you mentioning on IRC that `make check' for gcc won't
> > work on the Hurd. Was that a stdio-related problem, or other?
> If it is what I have in mind, it is a not having ulimit that
On Fri, May 10, 2002 at 08:38:32AM -0700, Jeff Bailey wrote:
> Marcus,
>
> I remember you mentioning on IRC that `make check' for gcc won't work
> on the Hurd. Was that a stdio-related problem, or other?
If it is what I have in mind, it is a not having ulimit that w
Marcus,
I remember you mentioning on IRC that `make check' for gcc won't work
on the Hurd. Was that a stdio-related problem, or other?
Having *just* caught a MAXPATHLEN bug in gcc-3.1 (ada front end), I'd
like to try and implement a compile farm of some sort so we can catch
th
That hard-coded default is as it's supposed to be. The I18NPATH=. in the
environment should make it find what it's looking for before it gets to
where it would look in /share. So probably a fopen is failing that should
be succeeding.
___
Bug-hurd mail
is so my
notes are here. It appears that there's a hardcoded path in the make
check. I'll try and hack this so that it refers to the not-installed
copy.
Generating locale de_DE.ISO-8859-1: this might take a while...
++ echo ISO-8859-1
++ sed -e s/SJIS/SHIFT_JIS/
+ generate_locale ISO
That definitely looks suspect. Both the file name "." in the error
messages and the errors themselves should not be happening. That is
running a script that runs localedef. Take that dag burn @ off the command
line using gen-locale.sh in localedata/Makefile, then repeat its command
line with sh
just that the whole system is getting more stable.
> So I figured I would run `make check', which died partway through. Is
> it too early to be interested in this?
IMHO we should always fix bugs.
> Note that this glibc is from a couple days ago, with the 'const'
> rem
First to note, that the libio stuff seems more stable to me. I don't
think I've ever completed a glibc build without a crash before.
So I figured I would run `make check', which died partway through. Is
it too early to be interested in this?
Note that this glibc is from a
On Sun, Mar 24, 2002 at 07:52:08AM -0800, James Morrison wrote:
> I'm curious what types of checks would be in a make check target for the
> hurd.
> Would have to be run in a sub-hurd to test all the hurd translators and libc
> functions? Should the test programs be compiled
On Sun, Mar 24, 2002 at 07:52:08AM -0800, James Morrison wrote:
> I'm curious what types of checks would be in a make check target
> for the hurd. Would have to be run in a sub-hurd to test all the
> hurd translators and libc functions? Should the test programs be
> compiled
Hi,
I'm curious what types of checks would be in a make check target for the
hurd.
Would have to be run in a sub-hurd to test all the hurd translators and libc
functions? Should the test programs be compiled within that test sub-hurd?
=
James Morrison
University of Wat
22 matches
Mail list logo
