Re: Sporadic build failure of next

[Jan Kiszka <jan.kiszka@siemens.com>]

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.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux