Claudio Fontana <cfont...@suse.de> writes:
> Hi all,
>
> and thanks for the help, after a lot of fiddling and applying your
> suggestions (and a reboot !?)
> now things work.
>
> The only thing I am left seeing (also on master) is with check-tcg:
>
>
> Remote 'g' packet reply is too long (expected 312 bytes, got 560 bytes):
> 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040008004310000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010063000000000001006340000000082009207000000000000000000000000000000000000000000000000
> Traceback (most recent call last):
> File "/home/claudio/git/qemu/tests/tcg/multiarch/gdbstub/sha1.py", line 68,
> in <module>
> if gdb.parse_and_eval('$pc') == 0:
> gdb.error: No registers.
>
>
> a number of times during the test.
Hmm that is a mismatch between a broken multiarch gdb and the test. It
is indeed harmless (that's what the $pc test is for) but unfortunately
very noisy on the build. All distros seem to package things differently
but you can either install gdb-multiarch which configure will prefer
when detecting or build your own gdb and point at it with configure
--gdb=/path/to/gdb
>
> Seems not to break anything, but I wonder if it is expected or it
> would need suppressing?
I'm open to a clean way of skipping these tests when we don't have all
the parts we need to run.
>
> Thanks again,
>
> Claudio
>
>
> On 11/25/20 6:02 PM, Alex Bennée wrote:
>>
>> Claudio Fontana <cfont...@suse.de> writes:
>>
>>> Hi Alex,
>>>
>>> On 11/25/20 10:42 AM, Alex Bennée wrote:
>>>>
>>>> Philippe Mathieu-Daudé <f4...@amsat.org> writes:
>>>>
>>>>> On 11/24/20 12:04 PM, Claudio Fontana wrote:
>>>>>> Hi Alex,
>>>>>>
>>>>>> I am seeing build failures with build-user and build-user-plugin:
>>>>>>
>>>>>> https://gitlab.com/hw-claudio/qemu/-/pipelines/220245998
>>>>>>
>>>>>> and I am trying to start investigating.
>>>>>>
>>>>>> How do I reproduce this locally?
>>>>>>
>>>>>> I am trying to run locally the check-tcg rule, but I cannot get it to
>>>>>> work.
>>>>>> I managed to work around the problem of static libraries (disabled them),
>>>>>>
>>>>>> but then I get:
>>>>>>
>>>>>> BUILD TCG tests for x86_64-linux-user
>>>>>> BUILD x86_64-linux-user guest-tests with cc
>>>>>> /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
>>>>>> /tmp/ccgqtAM9.o: in function `test_fops':
>>>>>> /dev/shm/cfontana/qemu/tests/tcg/i386/test-i386.c:759: undefined
>>>>>> reference to `fmod'
>>>>>> /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
>>>>>> /dev/shm/cfontana/qemu/tests/tcg/i386/test-i386.c:760: undefined
>>>>>> reference to `sqrt'
>>>>>> /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
>>>>>> /dev/shm/cfontana/qemu/tests/tcg/i386/test-i386.c:761: undefined
>>>>>> reference to `sin'
>>>>>> /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
>>>>>> /dev/shm/cfontana/qemu/tests/tcg/i386/test-i386.c:762: undefined
>>>>>> reference to `cos'
>>>>>>
>>>>>> Have you seen it before?
>>>>>> Any suggestions? I'm on OpenSUSE Leap 15 SP2.
>>>>>
>>>>> Related to 3fc1aad3864 ("configure: remove unnecessary libm test")
>>>>> + tcg tests still not ported to Meson?
>>>>
>>>> Hmm so we certainly need libm for the testcase but I guess this is>
>>>> failing with a local cross compiler rather than docker? I'm not sure the
>>>> global feature test should be relevant for testcases.
>>>>
>>>
>>> Probably it's my attempt to make it work with non-static libm that failed
>>> then,
>>>
>>> is it supposed to work?
>>>
>>> I see mention of BUILD_STATIC there, but it does not seem to actually work
>>> for me.
>>>
>>> If I use static libm, then it works.
>>> If I uninstall static libm, any attempt to build fails, regardless of
>>> whether I pass BUILD_STATIC='n' or so.
>>
>> All the test cases themselves should be built as static although I see
>> we fall back for the case of using a local cross compiler. That normally
>> only covers the case where the host compiler can also build for 32 bit
>> for testcases.
>>
>>>
>>> Ciao and thanks,
>>>
>>> CLaudio
>>
>>
--
Alex Bennée
