Message ID | 20200605114700.1052050-1-laurent@vivier.eu |
---|---|
State | New |
Headers | show |
On Fri, 5 Jun 2020 at 12:48, Laurent Vivier <laurent@vivier.eu> wrote: > > The following changes since commit ddc760832fa8cf5e93b9d9e6e854a5114ac63510: > > Merge remote-tracking branch 'remotes/gkurz/tags/9p-next-2020-05-26' into s= > taging (2020-05-26 14:05:53 +0100) > > are available in the Git repository at: > > git://github.com/vivier/qemu.git tags/linux-user-for-5.1-pull-request > > for you to fetch changes up to aa3d2045d4ca760bd8c22935a2d73ee4f3480bd5: > > stubs: Restrict ui/win32-kbd-hook to system-mode (2020-06-05 11:36:00 +0200) > > ---------------------------------------------------------------- > linux-user pull request 20200605 > > Implement F_OFD_ fcntl() command, /proc/cpuinfo for hppa > Fix socket(), prnctl() error codes, underflow in target_mremap, > epoll_create() strace, oldumount for alpha > User-mode build dependencies improvement > > ---------------------------------------------------------------- Hi; this failed to compile on s390 and ppc when building hppa-linux-user: /home/ubuntu/qemu/linux-user/syscall.c: In function ‘do_openat’: /home/ubuntu/qemu/linux-user/syscall.c:7484:42: error: ‘is_proc’ undeclared (first use in this function); did you mean ‘ is_error’? { "/proc/cpuinfo", open_cpuinfo, is_proc }, ^~~~~~~ is_error /home/ubuntu/qemu/linux-user/syscall.c:7484:42: note: each undeclared identifier is reported only once for each function it appears in /home/ubuntu/qemu/rules.mak:69: recipe for target 'linux-user/syscall.o' failed Looks like this is because the #if condition guarding the is_proc() definition doesn't line up with the uses (missing a check on TARGET_HPPA). thanks -- PMM
Le 05/06/2020 à 18:45, Peter Maydell a écrit : > On Fri, 5 Jun 2020 at 12:48, Laurent Vivier <laurent@vivier.eu> wrote: >> >> The following changes since commit ddc760832fa8cf5e93b9d9e6e854a5114ac63510: >> >> Merge remote-tracking branch 'remotes/gkurz/tags/9p-next-2020-05-26' into s= >> taging (2020-05-26 14:05:53 +0100) >> >> are available in the Git repository at: >> >> git://github.com/vivier/qemu.git tags/linux-user-for-5.1-pull-request >> >> for you to fetch changes up to aa3d2045d4ca760bd8c22935a2d73ee4f3480bd5: >> >> stubs: Restrict ui/win32-kbd-hook to system-mode (2020-06-05 11:36:00 +0200) >> >> ---------------------------------------------------------------- >> linux-user pull request 20200605 >> >> Implement F_OFD_ fcntl() command, /proc/cpuinfo for hppa >> Fix socket(), prnctl() error codes, underflow in target_mremap, >> epoll_create() strace, oldumount for alpha >> User-mode build dependencies improvement >> >> ---------------------------------------------------------------- > > Hi; this failed to compile on s390 and ppc when building hppa-linux-user: > > /home/ubuntu/qemu/linux-user/syscall.c: In function ‘do_openat’: > /home/ubuntu/qemu/linux-user/syscall.c:7484:42: error: ‘is_proc’ > undeclared (first use in this function); did you mean ‘ > is_error’? > { "/proc/cpuinfo", open_cpuinfo, is_proc }, > ^~~~~~~ > is_error > /home/ubuntu/qemu/linux-user/syscall.c:7484:42: note: each undeclared > identifier is reported only once for each function > it appears in > /home/ubuntu/qemu/rules.mak:69: recipe for target 'linux-user/syscall.o' failed > > Looks like this is because the #if condition guarding the > is_proc() definition doesn't line up with the uses (missing > a check on TARGET_HPPA). You're right. I was thinking this kind of problem would be detected by the travis-ci builds, but in fact ppc64 and s390 builds don't build other architecture linux-user targets. I update my PR. Thanks, Laurent
On Fri, 5 Jun 2020 at 20:20, Laurent Vivier <laurent@vivier.eu> wrote: > I was thinking this kind of problem would be detected by the travis-ci > builds, but in fact ppc64 and s390 builds don't build other architecture > linux-user targets. That's an unfortunate gap in the CI -- we should ideally cover the whole tree with at least one big-endian platform. thanks -- PMM
On 6/5/20 1:32 PM, Peter Maydell wrote: > On Fri, 5 Jun 2020 at 20:20, Laurent Vivier <laurent@vivier.eu> wrote: >> I was thinking this kind of problem would be detected by the travis-ci >> builds, but in fact ppc64 and s390 builds don't build other architecture >> linux-user targets. > > That's an unfortunate gap in the CI -- we should ideally cover > the whole tree with at least one big-endian platform. Indeed. Hopefully we can do this with our pending gitlab setup. For travis, IIRC we only build this restricted set because we had problems with timeouts on those machines. r~
On 05/06/2020 23.48, Richard Henderson wrote: > On 6/5/20 1:32 PM, Peter Maydell wrote: >> On Fri, 5 Jun 2020 at 20:20, Laurent Vivier <laurent@vivier.eu> wrote: >>> I was thinking this kind of problem would be detected by the travis-ci >>> builds, but in fact ppc64 and s390 builds don't build other architecture >>> linux-user targets. >> >> That's an unfortunate gap in the CI -- we should ideally cover >> the whole tree with at least one big-endian platform. > > Indeed. Hopefully we can do this with our pending gitlab setup. > > For travis, IIRC we only build this restricted set because we had problems with > timeouts on those machines. Right. But we could add one more tests with --target-list-exclude=${MAIN_SOFTMMU_TARGETS} --enable-user in Travis ... I'll have a look... Thomas