Re: Sporadic build failure of next

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

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.

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