[oe] QA issue with staging (workdir) for .la files in xmlrpc-c package

[Khem Raj]

On 12/23/2010 1:44 AM, Martin Panter wrote:
> On 23 December 2010 18:43, Frans Meulenbroeks
> <fransmeulenbroeks at gmail.com>  wrote:
>> 2010/12/23 Martin Panter<vadmium+floss at gmail.com>:
>>> Hi all
>>>
>>> I'm having trouble building "xmlrpc-c", which I think is required for
>>> rtorrent. It's failing at the "do_qa_staging" stage with the messages
>>> such as "QA Issue with staging: libxmlrpc.la failed sanity test
>>> (workdir)".
>>>
>>> I gather the issue is that my sysroots/*/usr/lib/libxmlrpc.la file has
>>> the following, which mentions the tmp/work/ directory:
>>>
>>> # Libraries that this one depends upon.
>>> dependency_libs=' -L.libs
>>> -L/media/disk/home/vadmium/proj/aegle/build/tmp/work/armv7a-angstrom-linux-gnueabi/xmlrpc-c-1.06.41-r1/xmlrpc-c-1.06.41/src/../lib/libutil/.libs
>>> -lxmlrpc_util -lxml2 -lz -lm'
>>>
>>> So looks like another Libtool issue. But I'm stuck this time so if
>>> anyone has any hints that would be awesome. For instance why does that
>>> -L. . ./tmp/work/. . . component get there, and perhaps is there some
>>> Libtool option to prevent or fix it?
>>>
>>> I think the xmlrpc-c packages has its own version of Libtool (1.3.4?).
>>> I tried coaxing the build process to use OE's Libtool version
>>> (EXTRA_OEMAKE = "LIBTOOL='${HOST_SYS}-libtool'", after the import
>>> line, in the recipe file), but this didn't seem to help.
>>>
>>> Previously I thought I had another "QA issue" with this xmlrpc-c
>>> package, something about a "hash style", which I thought I solved by
>>> passing LADD='${LDFLAGS}' to the Make command. But recently when I
>>> removed this change I am not getting the earlier "hash style QA
>>> issue"; only this newer "workdir" one. But I may be confused.
>>>
>>> -Martin
>>>
>>> These are the full messages taken straight from log.do_qa_staging file
>>> with awesome-long path names:
>>>
>>> ERROR: QA Issue with staging: libxmlrpc.la failed sanity test
>>> (workdir) in path
>>> /media/disk/home/vadmium/proj/aegle/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>>> ERROR: QA Issue with staging: libxmlrpc_server_abyss.la failed sanity
>>> test (workdir) in path
>>> /media/disk/home/vadmium/proj/aegle/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>>> ERROR: QA Issue with staging: libxmlrpc_server.la failed sanity test
>>> (workdir) in path
>>> /media/disk/home/vadmium/proj/aegle/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>>> ERROR: QA Issue with staging: libxmlrpc_server_cgi.la failed sanity
>>> test (workdir) in path
>>> /media/disk/home/vadmium/proj/aegle/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>>> ERROR: QA Issue with staging: libxmlrpc_client.la failed sanity test
>>> (workdir) in path
>>> /media/disk/home/vadmium/proj/aegle/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>>> FATAL: QA staging was broken by the package built above
>>
>> I *think* I've rebuild rtorrent yesterday. for beagleboard/minimal.
>> Didn't get the error. Can't verify things right now. Feel frree to
>> ping me this evening on irc (roughly 18.00-22.00 gmt) or tomorrow
>> during the day)
>> What libtool are you using? and is this on git head ?
>
> On 23/12/2010, Frans Meulenbroeks<fransmeulenbroeks at gmail.com>  wrote:
>> 2010/12/23 Martin Panter<vadmium+floss at gmail.com>:
>>> Hi all
>>>
>>> I'm having trouble building "xmlrpc-c", which I think is required for
>>> rtorrent. It's failing at the "do_qa_staging" stage with the messages
>>> such as "QA Issue with staging: libxmlrpc.la failed sanity test
>>> (workdir)".
>>>
>>> I gather the issue is that my sysroots/*/usr/lib/libxmlrpc.la file has
>>> the following, which mentions the tmp/work/ directory:
>>>
>>> # Libraries that this one depends upon.
>>> dependency_libs=' -L.libs
>>> -L/media/disk/home/vadmium/proj/aegle/build/tmp/work/armv7a-angstrom-linux-gnueabi/xmlrpc-c-1.06.41-r1/xmlrpc-c-1.06.41/src/../lib/libutil/.libs
>>> -lxmlrpc_util -lxml2 -lz -lm'
>>>
>>> So looks like another Libtool issue. But I'm stuck this time so if
>>> anyone has any hints that would be awesome. For instance why does that
>>> -L. . ./tmp/work/. . . component get there, and perhaps is there some
>>> Libtool option to prevent or fix it?


Yes it a mix of libtool and the xmlrpc-c build system combined issue. 
The patch you provided solved some part of the problem. I have committed 
a modified patch which fixes several problems along with this
one in xmlrpc-c recipe

-Khem