All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: Multiple issues building from dizzy or master
Date: Tue, 7 Oct 2014 11:21:06 -0500	[thread overview]
Message-ID: <543412F2.3050603@windriver.com> (raw)
In-Reply-To: <e777247650f44526919fb4737b79b0a6@CY1PR0301MB0700.namprd03.prod.outlook.com>

On 10/7/14, 10:24 AM, Lauren Post wrote:
> We've been trying for a few weeks to move all our builds to master (yesterday dizzy for poky which is the same) and been having random strange problems on multiple jenkins machines we do our daily builds on.  I talked to Otavio about it but wonder if we are missing something.    I'd appreciate any ideas.   We can build our kernel and uboot fine but when we try to build a more complex image with qt5 we have not succeeded any build since yesterday.
>
> As of today we are now getting errors in db compilation
> On both locally and on Jenkins we keep getting a db compile error as of today.
> ./db_cxx.h:59:22: fatal error: iostream.h: No such file or directory
>   #include <iostream.h>
>                        ^
> ---------------------------------------------------------------------
> For last week we've been battling random gcc_runtime configure errors only on Jenkins machines.
>
> This is the configure error.
> checking dynamic linker characteristics... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.

I hit this issue w/ Aarch64 builds, and the issue was that gcc linker definition 
did not match the installed library path definition.

In the aarch64 case, the ld.so lives in '/lib', and everything else in the 'oe 
libdir' (which if set to 'lib64') was causing issue.  I finally fixed it in my 
local build by symlinking ld.so into both places.

(I realize this isn't likely on the same architecture, but I suspect the same 
issue is possible here.  Basically the compiler and glibc are not synchronized 
and are looking in different locations for their components.)

> -------------------------------------------------------------------------------------------------------
> As of yesterday morning, we are also having many unpack errors on many files
> that are disappearing from our downloads before unpack. The fetch is working but
> then when it unpacks the package has disappeared from downloads. I've seen this
> on multiple components (libx11, xproto, inputproto, util-linux). Seems to happen
> more often with rm_work set but I've seen it without it set.

I don't use rm_work myself.  But a few of my coworkers do.  The only place 
they've hit an issue is on a specific CentOS based machine.  We've not been able 
to track it down, but rm_work appeared to run BEFORE the final staging...

> I'd appreciate any ideas. The only one I can reproduce locally is the db
> error  above but the others seem to only happen on Jenkins machines. We have 4
> different Jenkins machines all of which can't build on the master branch but
> have built fine for months on daisy and dora branches.

There was a recent bug found that affect systems with 64-bit inodes.  Check if 
you have that, you may need a 'pseudo' update... back porting from master should 
be fine for older versions.  (Master was updated yesterday?)

> By the way you can't set your gcc to 4.8.2 - liburcu breaks if you try to
> use  the older compiler. So not sure if any of the gcc runtime issues are related to
> the new gcc version. Not sure if we should keep gcc 4.8.2 in dizzy if it can't
> be used.
>
> Thanks for any ideas.  I've tried everything I can think of.
>
> Lauren Post
> i.MX Freescale
>



  reply	other threads:[~2014-10-07 16:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-07 15:24 Multiple issues building from dizzy or master Lauren Post
2014-10-07 16:21 ` Mark Hatle [this message]
2014-10-07 17:30 ` Martin Jansa
2014-10-08 12:51 ` Lauren Post
2014-10-09 15:50 ` Lauren Post
2014-10-09 15:57   ` Burton, Ross
2014-10-09 16:07   ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=543412F2.3050603@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.