qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] libcacard: actually use the symbols file


From: Michael Tokarev
Subject: Re: [Qemu-devel] [PATCH] libcacard: actually use the symbols file
Date: Sun, 27 Apr 2014 12:10:25 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0

27.04.2014 12:05, Alon Levy wrote:
> On 04/21/2014 12:09 PM, Michael Tokarev wrote:
>> 21.04.2014 13:01, Michael Tokarev wrote:
>>> libtool has an argument for .syms file, which is -export-symbols.
>>> There's no argument `-export-syms', and it looks like at least on
>>> linux, -export-syms is just ignored.  Use the correct argument,
>>> -export-symbols, to actually get the right export list.
>>
>> Note: with this patch applied, linking vscclient fails due to the
>> following symbols missing:
>>
>> qemu_mutex_lock
>> qemu_mutex_unlock
>> qemu_cond_wait
>> qemu_cond_signal
>> qemu_thread_create
>> socket_init
>> qemu_socket
>> qemu_mutex_init
>> qemu_cond_init
>>
>> So it looks like a preparation patch is needed before this one, to
>> ensure bisectability.
>>
>> Should those symbols be exported by libcacard (hence listed in the
>> .syms file), or should vscclient link line use more objects?
> 
> They should not be exported by libcacard. I'm not sure what is happening
> here except to note that the list of objects being linked must satisfy
> all missing symbols since it results in a loadable and executable
> executable.

Well.   vscclient explicitly uses them in the code, but only links with
libcacard, not with other qemu objects.  So adding proper qemu objects
here should be fine.  I can take care of that.

On the other hand, some of those are mutexes, shouldn't the same objects
be used inside the library and inside the executable?  I don't know.

Thanks,

/mjt




reply via email to

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