Re: Sporadic build failure of next

[Claudius Heine <claudius.heine.ext@siemens.com>]

On 20/08/2019 09.09, Jan Kiszka wrote:
> On 20.08.19 08:54, Claudius Heine wrote:
>> Hi Jan,
>>
>> On 20/08/2019 07.37, [ext] Jan Kiszka wrote:
>>> Hi,
>>>
>>> attached a build failure of 49895c62cdca. I ran that build 3 more 
>>> times, but it didn't trigger an issue again. Looks like some false 
>>> sharing, but I do not have an idea yet of what exactly.
>>
>> This is probably the important part of the log:
>>
>> | dpkg-shlibdeps: error: no dependency information found for 
>> /lib/arm-linux-gnueabihf/libc.so.6 (used by 
>> debian/libhello/usr/lib/arm-linux-gnueabihf/libhello.so.0.0.0)
>> | Hint: check if the library actually comes from a package.
>> | dh_shlibdeps: dpkg-shlibdeps -Tdebian/libhello.substvars 
>> debian/libhello/usr/lib/arm-linux-gnueabihf/libhello.so.0.0.0 returned 
>> exit code 2
>>
>> The manpage dpkg-shlibdeps(1) states:
>>
>>         no dependency information found for library-file (used by 
>> binary).
>>                The library needed by binary has been found by 
>> dpkg-shlibdeps in library-
>>                file but dpkg-shlibdeps has been unable to find any 
>> dependency information
>>                for that library. To find out the dependency, it  has 
>> tried  to map  the
>>                library  to  a Debian package with the help of dpkg -S 
>> library-file.  Then
>>                it   checked   the   corresponding   shlibs   and 
>> symbols files    in
>>                /var/lib/dpkg/info/,   and   in   the   various 
>> package's build  trees
>>                (debian/*/DEBIAN/).
>>
>>                This failure can be caused by a bad or missing shlibs 
>> or symbols file  in
>>                the  package  of the library. It might also happen if 
>> the library is built
>>                within the same source package and if the shlibs files 
>> has  not yet  been
>>                created  (in  which  case  you  must fix debian/rules 
>> to create the shlibs
>>                before calling dpkg-shlibdeps). Bad RPATH can also  
>> lead to  the library
>>                being      found      under     a     non-canonical 
>> name (example:
>>                /usr/lib/openoffice.org/../lib/libssl.so.0.9.8 
>> instead          of
>>                /usr/lib/libssl.so.0.9.8)   that's   not   associated 
>> to   any package,
>>                dpkg-shlibdeps tries to work around  this  by  trying  
>> to   fallback  on  a
>>                canonical  name  (using  realpath(3))  but  it might 
>> not always work. It's
>>                always best to clean up the RPATH of the binary to 
>> avoid problems.
>>
>>                Calling dpkg-shlibdeps  in  verbose  mode  (-v)  will 
>> provide much  more
>>                information  about where it tried to find the 
>> dependency information. This
>>                might be useful if you don't understand why it's giving 
>> you this error.
>>
>> Maybe inspection of the work space on the ci server when this error 
>> occurred will help.
> 
> Unfortunately, that is history already (disposed docker builds). But it 
> has to be something that destroyed the information because the later 
> builds got past this point.

Maybe its a issue with the libhello package? What I found odd was the 
path. libc6-armhf-cross contains the libc here:

     libc6-armhf-cross: /usr/arm-linux-gnueabihf/lib/libc.so.6

So a simple search (dpkg -S) for '/lib/arm-linux-gnueabihf/libc.so.6' 
will not give that result.

Maybe the rpath needs to be fixed? Maybe the rpath is sometimes fixed, 
and sometimes not? race?

regards,
Claudius

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de