qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [Qemu-commits] [COMMIT 3f600fa] Revert "This files


From: Blue Swirl
Subject: Re: [Qemu-devel] Re: [Qemu-commits] [COMMIT 3f600fa] Revert "This files are compiled in libqemu.a now"
Date: Sun, 27 Sep 2009 16:37:24 +0300

On Sat, Sep 26, 2009 at 11:49 AM, Aurelien Jarno <address@hidden> wrote:
> On Sat, Sep 26, 2009 at 11:22:31AM +0300, Blue Swirl wrote:
>> On Sat, Sep 26, 2009 at 10:53 AM, Aurelien Jarno <address@hidden> wrote:
>> > On Sat, Sep 26, 2009 at 09:25:29AM +0200, Aurelien Jarno wrote:
>> >> On Sat, Sep 26, 2009 at 09:44:39AM +0300, Blue Swirl wrote:
>> >> > On Fri, Sep 25, 2009 at 11:23 PM, Aurelien Jarno <address@hidden> wrote:
>> >> > > On Fri, Sep 25, 2009 at 07:24:37PM -0000, Anthony Liguori wrote:
>> >> > >> From: Blue Swirl <address@hidden>
>> >> > >>
>> >> > >> This reverts commit fe6549dfd76c278dbcd788b3c15c5e6e5ed32190.
>> >> > >>
>> >> > >> tcg-runtime and host-utils are needed on 32 bit host and they are 
>> >> > >> not part
>> >> > >> of libqemu.a.
>> >> > >>
>> >> > >> Thanks to Stefan Weil for reporting.
>> >> > >>
>> >> > >
>> >> > > So what is the correct fix to the original problem? All the user-linux
>> >> > > targets are failing to build following commits
>> >> > > 96e132e24ee5a693069e83b6a981693588b088c1 and
>> >> > > c2b023b62707f5dc73497dc03f3764f145a29785:
>> >> > >
>> >> > > $ LC_ALL=C make
>> >> > >  LINK  i386-linux-user/qemu-i386
>> >> > > gcc: tcg-runtime.o: No such file or directory
>> >> > > gcc: host-utils.o: No such file or directory
>> >> > > make[1]: *** [qemu-i386] Error 1
>> >> > > make: *** [subdir-i386-linux-user] Error 2
>> >> >
>> >> > I can't reproduce the problem (i386 log below). Did you run make clean?
>> >> >
>> >>
>> >> Yes 'make clean' or even 'git clean -fdx' doesn't change anything, the
>> >> problem is still there.
>> >>
>> >
>> > OTOH, using configure --disable-system workarounds the problem.
>>
>> I've tried the following cases (both x86_64 + i386 host, x86_64 + i386 
>> targets):
>> * system targets before user targets
>> * user targets before system targets
>> * just user targets
>>
>
> Some people tried to reproduce the problem on IRC, and it seems the
> conditions are:
> - use in-tree building
> - build user targets after system targets

Okay, now I can reproduce this. I try to avoid in-tree building if possible.

Perhaps there should be a -user symlink hack similar to cutils.c and
cache-utils.c. It's getting a bit ugly, though.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]