Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 31 Oct 2019 12:32:38 +0100
From: Szabolcs Nagy <>
Subject: Re: Cross-compiling test flow for libc-test

* Ruinland ChuanTzu Tsai <> [2019-10-31 14:04:06 +0800]:
> Hi,
> sorry for sending this email out of the blue.
> I'm wondering whether there are any (official) guides about how to do
> cross-compiling tests for libc-test ?
> If I understand the Makefile of libc-test correctly, it will compile
> test units and then execute those tests on _host_ platform right away.
> Somehow, whilst I was cross-testing glibc, there's a script,
>, which could be used with `test-wrapper` hook to ex-
> ecute those freshly compiled test units on a hetero-architecture platf-
> orm via ssh connections.
> If there's no such mechanism for libc-test at this time being, then I'm
> willing to develope one.

i think you can override the RUN_TEST or RUN_WRAP make
variables in your config.mak to run things under qemu
or via ssh (you can introduce similar hook there in
the makefile if it's not enough)

> That being said, I'm curious about how's the attitude which maintainers
> take toward this kind of testing flow.
> Aside from cross-testing, I also wonder the status of testing reports
> for releases on currently supported CPU architectures.
> As I was running libc-test on x86_64, some of functional and regression
> tests fail.
> Is there a validating rule (e.g. funcional/xxx and regression/yyy must 
> pass) for code checking-in which I can enforce locally before
> submitting patches here ?

yes libc test is not in a great shape, some of the
reported errors are real just not high priority,
i think currently you can run it on x86_64 and
compare the results you get on whatever other
platform to that.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.