Request for branch merge

Request for branch merge

[Richard Purdie]

I've been aware that Poky and OE have been diverging slightly and I'd
like to correct this. There are some patches that I've promised for a
while too such as the rename from do_populate_staging ->
do_populate_sysroot.

With some help from Joshua Lock, I have a branch I'd like to propose be
merged into OE.dev:

http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress

This branch:

* Renames do_populate_staging -> do_populate_sysroot as per previous 
  staging discussion emails and also the staging directory -> 
  sysroots. It should convert existing builds safely and insert a 
  compatibility symlink. This continues the process of improving our 
  "staging" concept into one focused around true sysroots.
* Adds some gettext class sanity checks. In Poky this error is fatal, 
  for OE this is just a note for now. The idea being if AM_GNU_GETTEXT 
  is in configure.ac and gettext in some form isn't in DEPENDS, 
  something is wrong.
* Added relocatable binary processing from Poky for -native binaries 
  using chrpath. This isn't enabled for -cross packages due to the 
  relative path length problems.
* Added packaged-staging fetching capabilities. This uses new mirror 
  handling abilities in bitbake master branch but should work with older
  bitbakes, just with less functionality.
* Started moving gcc dependency information into core gcc version 
  specific includes as part of the gcc cleanup.
* Converted gcc to use the new style staging
* Added EXTRA_OECONF_INITIAL and EXTRA_OECONF_INTERMEDIATE variables to 
  gcc as part of the gcc cleanup
* Converted binutils, modutils-cross, glibc and gdb to new style staging
* Cleaned up the gcc-cross do_install function a lot

Along with a small number of other tweaks spotted along the way.

I could post the patches individually and get Acked lines for each one
but I'm hoping to avoid that and get permission to merge the branch
directly. We have talked about most of these things in one form or
another.

Cheers,

Richard

Re: Request for branch merge

[Tom Rini]

On Thu, 2010-04-01 at 16:33 +0100, Richard Purdie wrote:

> * Added relocatable binary processing from Poky for -native binaries 
>   using chrpath. This isn't enabled for -cross packages due to the 
>   relative path length problems.

Is there a reason to not use $ORIGIN here instead?  The patch Chris
Larson posted ages ago does get this right (the hard part is
gcc/gdb/binutils due to the multi configure running).  And any path
length issues you hit with -cross you should be able to hit with
-native, no?

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: Request for branch merge

[Tom Rini]

On Thu, 2010-04-01 at 08:41 -0700, Tom Rini wrote:
> On Thu, 2010-04-01 at 16:33 +0100, Richard Purdie wrote:
> 
> > * Added relocatable binary processing from Poky for -native binaries 
> >   using chrpath. This isn't enabled for -cross packages due to the 
> >   relative path length problems.
> 
> Is there a reason to not use $ORIGIN here instead?  The patch Chris
> Larson posted ages ago does get this right (the hard part is
> gcc/gdb/binutils due to the multi configure running).  And any path
> length issues you hit with -cross you should be able to hit with
> -native, no?

For reference it's just doing:
export RELATIVERPATH = "${@base_path_relative(d.getVar('bindir', 1),
d.getVar('STAGING_LIBDIR_NATIVE', 1))}"
export BUILD_LDFLAGS = "-L${STAGING_LIBDIR_NATIVE} \
                        -Wl,-rpath,\\\$\$ORIGIN/${RELATIVERPATH} -Wl,-O1
\
                        -Wl,-rpath,${STAGING_LIBDIR_NATIVE} -Wl,-O1 \
                        "

In bitbake.conf (extra variable for dealing with the hard packages
later).

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: Request for branch merge

[Khem Raj]

On Thu, Apr 1, 2010 at 8:33 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
> I've been aware that Poky and OE have been diverging slightly and I'd
> like to correct this. There are some patches that I've promised for a
> while too such as the rename from do_populate_staging ->
> do_populate_sysroot.
>
> With some help from Joshua Lock, I have a branch I'd like to propose be
> merged into OE.dev:
>
> http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress
>
> This branch:
>
> * Renames do_populate_staging -> do_populate_sysroot as per previous
>  staging discussion emails and also the staging directory ->
>  sysroots. It should convert existing builds safely and insert a
>  compatibility symlink. This continues the process of improving our
>  "staging" concept into one focused around true sysroots.
> * Adds some gettext class sanity checks. In Poky this error is fatal,
>  for OE this is just a note for now. The idea being if AM_GNU_GETTEXT
>  is in configure.ac and gettext in some form isn't in DEPENDS,
>  something is wrong.
> * Added relocatable binary processing from Poky for -native binaries
>  using chrpath. This isn't enabled for -cross packages due to the
>  relative path length problems.
> * Added packaged-staging fetching capabilities. This uses new mirror
>  handling abilities in bitbake master branch but should work with older
>  bitbakes, just with less functionality.
> * Started moving gcc dependency information into core gcc version
>  specific includes as part of the gcc cleanup.
> * Converted gcc to use the new style staging
> * Added EXTRA_OECONF_INITIAL and EXTRA_OECONF_INTERMEDIATE variables to
>  gcc as part of the gcc cleanup
> * Converted binutils, modutils-cross, glibc and gdb to new style staging
> * Cleaned up the gcc-cross do_install function a lot
>
> Along with a small number of other tweaks spotted along the way.
>
> I could post the patches individually and get Acked lines for each one
> but I'm hoping to avoid that and get permission to merge the branch
> directly. We have talked about most of these things in one form or
> another.
>

Looks good stuff.
I would have preferred to have eglibc also converted to new style
staging if possible but can be done afterwards too.

Re: Request for branch merge

[Richard Purdie]

On Thu, 2010-04-01 at 08:41 -0700, Tom Rini wrote:
> On Thu, 2010-04-01 at 16:33 +0100, Richard Purdie wrote:
> 
> > * Added relocatable binary processing from Poky for -native binaries 
> >   using chrpath. This isn't enabled for -cross packages due to the 
> >   relative path length problems.
> 
> Is there a reason to not use $ORIGIN here instead?

This *is* using $$ORIGIN. We're just postprocessing to do the injection.

>   The patch Chris
> Larson posted ages ago does get this right (the hard part is
> gcc/gdb/binutils due to the multi configure running).

This class automatically handles all that without having all those
horrible escaped strings that are likely to break each time we change
versions or add new packages.

>   And any path
> length issues you hit with -cross you should be able to hit with
> -native, no?

No, since -native binaries just need to go up to the root of the
staging/ directory as a maximum but the cross directory crosses the
cross/ to staging/ boundary which is a level further.

If we move cross/ into staging/ as is planned, this problem goes away at
that point.

Cheers,

Richard

Re: Request for branch merge

[Richard Purdie]

On Thu, 2010-04-01 at 08:43 -0700, Tom Rini wrote:
> On Thu, 2010-04-01 at 08:41 -0700, Tom Rini wrote:
> > On Thu, 2010-04-01 at 16:33 +0100, Richard Purdie wrote:
> > 
> > > * Added relocatable binary processing from Poky for -native binaries 
> > >   using chrpath. This isn't enabled for -cross packages due to the 
> > >   relative path length problems.
> > 
> > Is there a reason to not use $ORIGIN here instead?  The patch Chris
> > Larson posted ages ago does get this right (the hard part is
> > gcc/gdb/binutils due to the multi configure running).  And any path
> > length issues you hit with -cross you should be able to hit with
> > -native, no?
> 
> For reference it's just doing:
> export RELATIVERPATH = "${@base_path_relative(d.getVar('bindir', 1),
> d.getVar('STAGING_LIBDIR_NATIVE', 1))}"
> export BUILD_LDFLAGS = "-L${STAGING_LIBDIR_NATIVE} \
>                         -Wl,-rpath,\\\$\$ORIGIN/${RELATIVERPATH} -Wl,-O1
> \
>                         -Wl,-rpath,${STAGING_LIBDIR_NATIVE} -Wl,-O1 \
>                         "
> 
> In bitbake.conf (extra variable for dealing with the hard packages
> later).

I really much prefer the post processing approach as it "just works" and
doesn't need exceptions for hard packages, nor does it have horrible
quoting.

Cheers,

Richard

Re: Request for branch merge

[Richard Purdie]

On Thu, 2010-04-01 at 08:46 -0700, Khem Raj wrote:
> On Thu, Apr 1, 2010 at 8:33 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
> > I've been aware that Poky and OE have been diverging slightly and I'd
> > like to correct this. There are some patches that I've promised for a
> > while too such as the rename from do_populate_staging ->
> > do_populate_sysroot.
> >
> > With some help from Joshua Lock, I have a branch I'd like to propose be
> > merged into OE.dev:
> >
> > http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress
> >
> > This branch:
> >
> > * Renames do_populate_staging -> do_populate_sysroot as per previous
> >  staging discussion emails and also the staging directory ->
> >  sysroots. It should convert existing builds safely and insert a
> >  compatibility symlink. This continues the process of improving our
> >  "staging" concept into one focused around true sysroots.
> > * Adds some gettext class sanity checks. In Poky this error is fatal,
> >  for OE this is just a note for now. The idea being if AM_GNU_GETTEXT
> >  is in configure.ac and gettext in some form isn't in DEPENDS,
> >  something is wrong.
> > * Added relocatable binary processing from Poky for -native binaries
> >  using chrpath. This isn't enabled for -cross packages due to the
> >  relative path length problems.
> > * Added packaged-staging fetching capabilities. This uses new mirror
> >  handling abilities in bitbake master branch but should work with older
> >  bitbakes, just with less functionality.
> > * Started moving gcc dependency information into core gcc version
> >  specific includes as part of the gcc cleanup.
> > * Converted gcc to use the new style staging
> > * Added EXTRA_OECONF_INITIAL and EXTRA_OECONF_INTERMEDIATE variables to
> >  gcc as part of the gcc cleanup
> > * Converted binutils, modutils-cross, glibc and gdb to new style staging
> > * Cleaned up the gcc-cross do_install function a lot
> >
> > Along with a small number of other tweaks spotted along the way.
> >
> > I could post the patches individually and get Acked lines for each one
> > but I'm hoping to avoid that and get permission to merge the branch
> > directly. We have talked about most of these things in one form or
> > another.
> >
> 
> Looks good stuff.
> I would have preferred to have eglibc also converted to new style
> staging if possible but can be done afterwards too.

I just looked and the eglibc do_stage function can most likely just be
deleted and for the -initial version, rename do_stage to do_install and
drop the empty do_install. I didn't make that change as its not
something I've tested.

Cheers,

Richard

Re: Request for branch merge

[Andrea Adami]

>I just looked and the eglib
-- sorry for jumping in --

RP, while you're there, pls look at klibc.

do_stage() {
        oe_runmake  install
        cp '${STAGING_DIR_TARGET}/bin/klcc'
'${CROSS_DIR}/bin/${TARGET_PREFIX}klcc'
}

How to properly install klcc ?

Regards

Andrea

Re: Request for branch merge

[Richard Purdie]

On Thu, 2010-04-01 at 18:18 +0200, Andrea Adami wrote:
> >I just looked and the eglib
> -- sorry for jumping in --
> 
> RP, while you're there, pls look at klibc.
> 
> do_stage() {
>         oe_runmake  install
>         cp '${STAGING_DIR_TARGET}/bin/klcc'
> '${CROSS_DIR}/bin/${TARGET_PREFIX}klcc'
> }
> 
> How to properly install klcc ?

The closest analogy is what binconfig.bbclass ends up doing or in poky
see the gtk+.inc file and its sysroot postprocessing function.

You will be pleased to know I have plans to simplify this massively by
moving STAGING_BINDIR_CROSS to be a directory under ${D}${bindir}, I've
just not got to that yet. This is part of the gradual removal of the
cross directory in favour of the sysroots.

Cheers,

Richard

Re: Request for branch merge

[Gary Thomas]

On 04/01/2010 09:33 AM, Richard Purdie wrote:
> I've been aware that Poky and OE have been diverging slightly and I'd
> like to correct this. There are some patches that I've promised for a
> while too such as the rename from do_populate_staging ->
> do_populate_sysroot.
>
> With some help from Joshua Lock, I have a branch I'd like to propose be
> merged into OE.dev:
>
> http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress

Not much luck with this I'm afraid.
   MACHINE=efika
   DISTRO="angstrom-2008.1"

ERROR: '/local/Angstrom_BeagleBoard/openembedded/recipes/shasum/shasum-native.bb' failed
NOTE: package shasum-native-1.0-r1: task do_qa_configure: Started
ERROR: Error in executing python function in: /local/Angstrom_BeagleBoard/openembedded/recipes/shasum/shasum-native.bb
ERROR: Exception:<type 'exceptions.NameError'> Message:global name 'configs' is not defined
ERROR: Printing the environment of the function
ERROR:  0021:       else:
ERROR:  0022:          gt = "gettext"
ERROR:  0023:       deps = bb.utils.explode_deps(bb.data.getVar('DEPENDS', d, True) or "")
ERROR:  0024:       if gt not in deps:
ERROR:  0025:          for config in configs:
ERROR:  0026:              gnu = "grep \"^[[:space:]]*AM_GNU_GETTEXT\" %s >/dev/null" % config
ERROR:  0027:              if os.system(gnu) == 0:
ERROR:  0028:                 bb.note("""Gettext required but not in DEPENDS for file %s.
ERROR:  0029:Missing inherit gettext?""" % config)
ERROR: Function do_qa_configure failed
NOTE: Task failed: ('function do_qa_configure failed', '/local/Angstrom_BeagleBoard/tmp/work/i686-linux/shasum-native-1.0-r1/temp/log.do_qa_configure.24200')
ERROR: Logfile of failure stored in: /local/Angstrom_BeagleBoard/tmp/work/i686-linux/shasum-native-1.0-r1/temp/log.do_qa_configure.24200
Log data follows:
| ERROR: Error in executing python function in: /local/Angstrom_BeagleBoard/openembedded/recipes/shasum/shasum-native.bb
| ERROR: Exception:<type 'exceptions.NameError'> Message:global name 'configs' is not defined
| ERROR: Printing the environment of the function
| ERROR:        0021:       else:
| ERROR:        0022:          gt = "gettext"
| ERROR:        0023:       deps = bb.utils.explode_deps(bb.data.getVar('DEPENDS', d, True) or "")
| ERROR:        0024:       if gt not in deps:
| ERROR:        0025:          for config in configs:
| ERROR:        0026:              gnu = "grep \"^[[:space:]]*AM_GNU_GETTEXT\" %s >/dev/null" % config
| ERROR:        0027:              if os.system(gnu) == 0:
| ERROR:        0028:                 bb.note("""Gettext required but not in DEPENDS for file %s.
| ERROR:        0029:Missing inherit gettext?""" % config)
| ERROR: Function do_qa_configure failed
NOTE: package shasum-native-1.0-r1: task do_qa_configure: Failed
ERROR: TaskFailed event exception, aborting

I tried this with bitbake-1.8.18 and the version from Poky mainline.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Request for branch merge

[Tom Rini]

On Thu, 2010-04-01 at 17:07 +0100, Richard Purdie wrote:
> On Thu, 2010-04-01 at 08:43 -0700, Tom Rini wrote:
> > On Thu, 2010-04-01 at 08:41 -0700, Tom Rini wrote:
> > > On Thu, 2010-04-01 at 16:33 +0100, Richard Purdie wrote:
> > > 
> > > > * Added relocatable binary processing from Poky for -native binaries 
> > > >   using chrpath. This isn't enabled for -cross packages due to the 
> > > >   relative path length problems.
> > > 
> > > Is there a reason to not use $ORIGIN here instead?  The patch Chris
> > > Larson posted ages ago does get this right (the hard part is
> > > gcc/gdb/binutils due to the multi configure running).  And any path
> > > length issues you hit with -cross you should be able to hit with
> > > -native, no?
> > 
> > For reference it's just doing:
> > export RELATIVERPATH = "${@base_path_relative(d.getVar('bindir', 1),
> > d.getVar('STAGING_LIBDIR_NATIVE', 1))}"
> > export BUILD_LDFLAGS = "-L${STAGING_LIBDIR_NATIVE} \
> >                         -Wl,-rpath,\\\$\$ORIGIN/${RELATIVERPATH} -Wl,-O1
> > \
> >                         -Wl,-rpath,${STAGING_LIBDIR_NATIVE} -Wl,-O1 \
> >                         "
> > 
> > In bitbake.conf (extra variable for dealing with the hard packages
> > later).
> 
> I really much prefer the post processing approach as it "just works" and
> doesn't need exceptions for hard packages, nor does it have horrible
> quoting.

There's two uglies here.  Ugly one, above.  Quoting isn't nice to read
and gdb/gcc/binutils are special.  It does however, work from the
get-go.  And the only cases it doesn't get right, right off the bat are
some perl (and possibly python) module cases where we aren't giving the
right relative path there, but we can always figure it out and fix that
up per recipe.  Ugly two, the chrpath way.  Depends on having a big
enough RPATH in the initial binary to patch over.  Doesn't work if the
RPATH isn't long enough as you say, which is why you can't do it on
-cross.  $ORIGIN linking works on everything every time.

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: Request for branch merge

[Tom Rini]

On Thu, 2010-04-01 at 17:05 +0100, Richard Purdie wrote:
> On Thu, 2010-04-01 at 08:41 -0700, Tom Rini wrote:
> > On Thu, 2010-04-01 at 16:33 +0100, Richard Purdie wrote:
> > 
> > > * Added relocatable binary processing from Poky for -native binaries 
> > >   using chrpath. This isn't enabled for -cross packages due to the 
> > >   relative path length problems.
> > 
> > Is there a reason to not use $ORIGIN here instead?
> 
> This *is* using $$ORIGIN. We're just postprocessing to do the injection.
> 
> >   The patch Chris
> > Larson posted ages ago does get this right (the hard part is
> > gcc/gdb/binutils due to the multi configure running).
> 
> This class automatically handles all that without having all those
> horrible escaped strings that are likely to break each time we change
> versions or add new packages.

FWIW, the patch I use to make gcc/gdb/binutils work is actually
identical between these three packages.  I don't think it breaking from
version to version is a concern.

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: Request for branch merge

[Joshua Lock]

On Thu, 2010-04-01 at 10:37 -0600, Gary Thomas wrote:
> On 04/01/2010 09:33 AM, Richard Purdie wrote:
> > I've been aware that Poky and OE have been diverging slightly and I'd
> > like to correct this. There are some patches that I've promised for a
> > while too such as the rename from do_populate_staging ->
> > do_populate_sysroot.
> >
> > With some help from Joshua Lock, I have a branch I'd like to propose be
> > merged into OE.dev:
> >
> > http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress
> 
> Not much luck with this I'm afraid.

Whoops, good old fashioned copy and paste error. The test build I ran
didn't trigger this... Sorry.

I just force pushed an amended tree.

Cheers,
Joshua 

>    MACHINE=efika
>    DISTRO="angstrom-2008.1"
> 
> ERROR: '/local/Angstrom_BeagleBoard/openembedded/recipes/shasum/shasum-native.bb' failed
> NOTE: package shasum-native-1.0-r1: task do_qa_configure: Started
> ERROR: Error in executing python function in: /local/Angstrom_BeagleBoard/openembedded/recipes/shasum/shasum-native.bb
> ERROR: Exception:<type 'exceptions.NameError'> Message:global name 'configs' is not defined
> ERROR: Printing the environment of the function
> ERROR:  0021:       else:
> ERROR:  0022:          gt = "gettext"
> ERROR:  0023:       deps = bb.utils.explode_deps(bb.data.getVar('DEPENDS', d, True) or "")
> ERROR:  0024:       if gt not in deps:
> ERROR:  0025:          for config in configs:
> ERROR:  0026:              gnu = "grep \"^[[:space:]]*AM_GNU_GETTEXT\" %s >/dev/null" % config
> ERROR:  0027:              if os.system(gnu) == 0:
> ERROR:  0028:                 bb.note("""Gettext required but not in DEPENDS for file %s.
> ERROR:  0029:Missing inherit gettext?""" % config)
> ERROR: Function do_qa_configure failed
> NOTE: Task failed: ('function do_qa_configure failed', '/local/Angstrom_BeagleBoard/tmp/work/i686-linux/shasum-native-1.0-r1/temp/log.do_qa_configure.24200')
> ERROR: Logfile of failure stored in: /local/Angstrom_BeagleBoard/tmp/work/i686-linux/shasum-native-1.0-r1/temp/log.do_qa_configure.24200
> Log data follows:
> | ERROR: Error in executing python function in: /local/Angstrom_BeagleBoard/openembedded/recipes/shasum/shasum-native.bb
> | ERROR: Exception:<type 'exceptions.NameError'> Message:global name 'configs' is not defined
> | ERROR: Printing the environment of the function
> | ERROR:        0021:       else:
> | ERROR:        0022:          gt = "gettext"
> | ERROR:        0023:       deps = bb.utils.explode_deps(bb.data.getVar('DEPENDS', d, True) or "")
> | ERROR:        0024:       if gt not in deps:
> | ERROR:        0025:          for config in configs:
> | ERROR:        0026:              gnu = "grep \"^[[:space:]]*AM_GNU_GETTEXT\" %s >/dev/null" % config
> | ERROR:        0027:              if os.system(gnu) == 0:
> | ERROR:        0028:                 bb.note("""Gettext required but not in DEPENDS for file %s.
> | ERROR:        0029:Missing inherit gettext?""" % config)
> | ERROR: Function do_qa_configure failed
> NOTE: package shasum-native-1.0-r1: task do_qa_configure: Failed
> ERROR: TaskFailed event exception, aborting
> 
> I tried this with bitbake-1.8.18 and the version from Poky mainline.
> 

-- 
Joshua Lock
        Intel Open Source Technology Centre

Re: Request for branch merge

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01-04-10 17:33, Richard Purdie wrote:

> I could post the patches individually and get Acked lines for each one
> but I'm hoping to avoid that and get permission to merge the branch
> directly. We have talked about most of these things in one form or
> another.

I don't think this will get serious review people other than Tom, Khem
and Chris, so if they don't have huge objections, merge it and we'll
deal with the fallout together if needed.

And you just had to do this to fill the TSC meeting agenda for tonight,
right? :p

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLtN36MkyGM64RGpERAjhsAKC4hgH7uwCe/9+94Z7bjjxbYKF+HQCfSOxW
xurPnqe3FntdoS6zTwrNj5Q=
=7o0f
-----END PGP SIGNATURE-----

Re: Request for branch merge

[Richard Purdie]

On Thu, 2010-04-01 at 09:45 -0700, Tom Rini wrote:
> There's two uglies here.  Ugly one, above.  Quoting isn't nice to read
> and gdb/gcc/binutils are special.  It does however, work from the
> get-go.  And the only cases it doesn't get right, right off the bat are
> some perl (and possibly python) module cases where we aren't giving the
> right relative path there, but we can always figure it out and fix that
> up per recipe.  Ugly two, the chrpath way.  Depends on having a big
> enough RPATH in the initial binary to patch over.  Doesn't work if the
> RPATH isn't long enough as you say, which is why you can't do it on
> -cross.  

I've done the maths and it will always work within the sysroots/staging
directory as there is always enough length available. Since we want rid
of /cross/ for various reasons anyway I don't think this is a reason
against this approach.

Cheers,

Richard

Re: Request for branch merge

[Richard Purdie]

On Thu, 2010-04-01 at 19:55 +0200, Koen Kooi wrote:
> On 01-04-10 17:33, Richard Purdie wrote:
> 
> > I could post the patches individually and get Acked lines for each one
> > but I'm hoping to avoid that and get permission to merge the branch
> > directly. We have talked about most of these things in one form or
> > another.
> 
> I don't think this will get serious review people other than Tom, Khem
> and Chris, so if they don't have huge objections, merge it and we'll
> deal with the fallout together if needed.
> 
> And you just had to do this to fill the TSC meeting agenda for tonight,
> right? :p

I did chuckle when I realised the timing :)

Cheers,

Richard

Re: Request for branch merge

[Tom Rini]

On Thu, 2010-04-01 at 19:09 +0100, Richard Purdie wrote:
> On Thu, 2010-04-01 at 09:45 -0700, Tom Rini wrote:
> > There's two uglies here.  Ugly one, above.  Quoting isn't nice to read
> > and gdb/gcc/binutils are special.  It does however, work from the
> > get-go.  And the only cases it doesn't get right, right off the bat are
> > some perl (and possibly python) module cases where we aren't giving the
> > right relative path there, but we can always figure it out and fix that
> > up per recipe.  Ugly two, the chrpath way.  Depends on having a big
> > enough RPATH in the initial binary to patch over.  Doesn't work if the
> > RPATH isn't long enough as you say, which is why you can't do it on
> > -cross.  
> 
> I've done the maths and it will always work within the sysroots/staging
> directory as there is always enough length available. Since we want rid
> of /cross/ for various reasons anyway I don't think this is a reason
> against this approach.

What do you want to do on nativesdk ?  That's where this gets real
important as well.

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: Request for branch merge

[Richard Purdie]

On Thu, 2010-04-01 at 11:33 -0700, Tom Rini wrote:
> On Thu, 2010-04-01 at 19:09 +0100, Richard Purdie wrote:
> > On Thu, 2010-04-01 at 09:45 -0700, Tom Rini wrote:
> > > There's two uglies here.  Ugly one, above.  Quoting isn't nice to read
> > > and gdb/gcc/binutils are special.  It does however, work from the
> > > get-go.  And the only cases it doesn't get right, right off the bat are
> > > some perl (and possibly python) module cases where we aren't giving the
> > > right relative path there, but we can always figure it out and fix that
> > > up per recipe.  Ugly two, the chrpath way.  Depends on having a big
> > > enough RPATH in the initial binary to patch over.  Doesn't work if the
> > > RPATH isn't long enough as you say, which is why you can't do it on
> > > -cross.  
> > 
> > I've done the maths and it will always work within the sysroots/staging
> > directory as there is always enough length available. Since we want rid
> > of /cross/ for various reasons anyway I don't think this is a reason
> > against this approach.
> 
> What do you want to do on nativesdk ?  That's where this gets real
> important as well.

I'd argue for the same approach. We'd just have to ensure the base path
used for the SDK is long enough to accommodate this but again, thats not
difficult to arrange.

Cheers,

Richard

Re: Request for branch merge

[Chris Larson]

On Thu, Apr 1, 2010 at 10:55 AM, Koen Kooi <k.kooi@student.utwente.nl>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01-04-10 17:33, Richard Purdie wrote:
>
> > I could post the patches individually and get Acked lines for each one
> > but I'm hoping to avoid that and get permission to merge the branch
> > directly. We have talked about most of these things in one form or
> > another.
>
> I don't think this will get serious review people other than Tom, Khem
> and Chris, so if they don't have huge objections, merge it and we'll
> deal with the fallout together if needed.


I agree with Koen on this, it's a definite improvement. Let's get it merged
and deal with any fallout from there.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: Request for branch merge

[Tom Rini]

On Thu, 2010-04-01 at 13:03 -0700, Chris Larson wrote:
> On Thu, Apr 1, 2010 at 10:55 AM, Koen Kooi <k.kooi@student.utwente.nl>wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 01-04-10 17:33, Richard Purdie wrote:
> >
> > > I could post the patches individually and get Acked lines for each one
> > > but I'm hoping to avoid that and get permission to merge the branch
> > > directly. We have talked about most of these things in one form or
> > > another.
> >
> > I don't think this will get serious review people other than Tom, Khem
> > and Chris, so if they don't have huge objections, merge it and we'll
> > deal with the fallout together if needed.
> 
> 
> I agree with Koen on this, it's a definite improvement. Let's get it merged
> and deal with any fallout from there.

Generally yes, and just a few things to hash out over the weekend I
think.

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: Request for branch merge

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01-04-10 22:34, Tom Rini wrote:
> On Thu, 2010-04-01 at 13:03 -0700, Chris Larson wrote:
>> On Thu, Apr 1, 2010 at 10:55 AM, Koen Kooi <k.kooi@student.utwente.nl>wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 01-04-10 17:33, Richard Purdie wrote:
>>>
>>>> I could post the patches individually and get Acked lines for each one
>>>> but I'm hoping to avoid that and get permission to merge the branch
>>>> directly. We have talked about most of these things in one form or
>>>> another.
>>>
>>> I don't think this will get serious review people other than Tom, Khem
>>> and Chris, so if they don't have huge objections, merge it and we'll
>>> deal with the fallout together if needed.
>>
>>
>> I agree with Koen on this, it's a definite improvement. Let's get it merged
>> and deal with any fallout from there.
> 
> Generally yes, and just a few things to hash out over the weekend I
> think.

I'm going to steal Chris' thunder a bit, but during the TSC meeting we
agreed that "after the weekend" would be a better time to merge it than
"now". Dealing with the fallout required lots of attention, which boils
down to "office hours" for most of the involved.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLtQtIMkyGM64RGpERAlNGAJsGhBaNRG6MrYu9b22xQ/u2gHixEQCgqfbK
yFuD52fo3laqE1HJU/qpktI=
=ShXS
-----END PGP SIGNATURE-----

Re: Request for branch merge

[Tom Rini]

On Thu, 2010-04-01 at 23:08 +0200, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01-04-10 22:34, Tom Rini wrote:
> > On Thu, 2010-04-01 at 13:03 -0700, Chris Larson wrote:
> >> On Thu, Apr 1, 2010 at 10:55 AM, Koen Kooi <k.kooi@student.utwente.nl>wrote:
> >>
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>>
> >>> On 01-04-10 17:33, Richard Purdie wrote:
> >>>
> >>>> I could post the patches individually and get Acked lines for each one
> >>>> but I'm hoping to avoid that and get permission to merge the branch
> >>>> directly. We have talked about most of these things in one form or
> >>>> another.
> >>>
> >>> I don't think this will get serious review people other than Tom, Khem
> >>> and Chris, so if they don't have huge objections, merge it and we'll
> >>> deal with the fallout together if needed.
> >>
> >>
> >> I agree with Koen on this, it's a definite improvement. Let's get it merged
> >> and deal with any fallout from there.
> > 
> > Generally yes, and just a few things to hash out over the weekend I
> > think.
> 
> I'm going to steal Chris' thunder a bit, but during the TSC meeting we
> agreed that "after the weekend" would be a better time to merge it than
> "now". Dealing with the fallout required lots of attention, which boils
> down to "office hours" for most of the involved.

Sounds good.  And I meant discuss and modify hashing out (with maybe
some step back and rethink for me) :)

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: Request for branch merge

[Philip Balister]

On 04/01/2010 05:08 PM, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01-04-10 22:34, Tom Rini wrote:
>> On Thu, 2010-04-01 at 13:03 -0700, Chris Larson wrote:
>>> On Thu, Apr 1, 2010 at 10:55 AM, Koen Kooi<k.kooi@student.utwente.nl>wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 01-04-10 17:33, Richard Purdie wrote:
>>>>
>>>>> I could post the patches individually and get Acked lines for each one
>>>>> but I'm hoping to avoid that and get permission to merge the branch
>>>>> directly. We have talked about most of these things in one form or
>>>>> another.
>>>>
>>>> I don't think this will get serious review people other than Tom, Khem
>>>> and Chris, so if they don't have huge objections, merge it and we'll
>>>> deal with the fallout together if needed.
>>>
>>>
>>> I agree with Koen on this, it's a definite improvement. Let's get it merged
>>> and deal with any fallout from there.
>>
>> Generally yes, and just a few things to hash out over the weekend I
>> think.
>
> I'm going to steal Chris' thunder a bit, but during the TSC meeting we
> agreed that "after the weekend" would be a better time to merge it than
> "now". Dealing with the fallout required lots of attention, which boils
> down to "office hours" for most of the involved.

Thanks. I know the people who do work on OE over the weekends appreciate 
this.

Philip

Re: Request for branch merge

[Tom Rini]

On Thu, 2010-04-01 at 13:34 -0700, Tom Rini wrote:
> On Thu, 2010-04-01 at 13:03 -0700, Chris Larson wrote:
> > On Thu, Apr 1, 2010 at 10:55 AM, Koen Kooi <k.kooi@student.utwente.nl>wrote:
> > 
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > On 01-04-10 17:33, Richard Purdie wrote:
> > >
> > > > I could post the patches individually and get Acked lines for each one
> > > > but I'm hoping to avoid that and get permission to merge the branch
> > > > directly. We have talked about most of these things in one form or
> > > > another.
> > >
> > > I don't think this will get serious review people other than Tom, Khem
> > > and Chris, so if they don't have huge objections, merge it and we'll
> > > deal with the fallout together if needed.
> > 
> > 
> > I agree with Koen on this, it's a definite improvement. Let's get it merged
> > and deal with any fallout from there.
> 
> Generally yes, and just a few things to hash out over the weekend I
> think.

With my non-blocking questions now, I think I'm good enough with this to
go in Monday.  I'll see about following up, after, with an alternative
way of relocation.

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: Request for branch merge

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01-04-10 17:33, Richard Purdie wrote:
> I've been aware that Poky and OE have been diverging slightly and I'd
> like to correct this. There are some patches that I've promised for a
> while too such as the rename from do_populate_staging ->
> do_populate_sysroot.
> 
> With some help from Joshua Lock, I have a branch I'd like to propose be
> merged into OE.dev:
> 
> http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress

While testing (rebased on top of this mornings OE, bitbake master) I'm
getting messages like this:

//OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so:
RPATH=/OE/angstrom-dev/sysroots/x86_64-linux/usr/lib
//OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so:
new RPATH: $ORIGIN/../../../../usr/lib
open: Permission denied
elf_open: Invalid argument

Are those messages from chrpath and can they be ignored?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLtfPaMkyGM64RGpERAoCOAKChBgWclw4D9dqIU9xwrBYYRuxtjQCghSRn
W07JDSPjVUcbSFDD50dCKgY=
=EC6F
-----END PGP SIGNATURE-----

Re: Request for branch merge

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02-04-10 15:40, Koen Kooi wrote:
> On 01-04-10 17:33, Richard Purdie wrote:
>> I've been aware that Poky and OE have been diverging slightly and I'd
>> like to correct this. There are some patches that I've promised for a
>> while too such as the rename from do_populate_staging ->
>> do_populate_sysroot.
> 
>> With some help from Joshua Lock, I have a branch I'd like to propose be
>> merged into OE.dev:
> 
>> http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress
> 
> While testing (rebased on top of this mornings OE, bitbake master) I'm
> getting messages like this:
> 
> //OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so:
> RPATH=/OE/angstrom-dev/sysroots/x86_64-linux/usr/lib
> //OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so:
> new RPATH: $ORIGIN/../../../../usr/lib
> open: Permission denied
> elf_open: Invalid argument
> 
> Are those messages from chrpath and can they be ignored?

And lots of:

: QA Issue with staging: libssp_nonshared.la failed sanity test
(installed) in path
/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLtgCdMkyGM64RGpERAv7sAJ9oScH3UmWw11aExUJRBxdnGDdoGACaA6jh
AmUQ3TfIfL5trAenmYXjmeo=
=u1oE
-----END PGP SIGNATURE-----

Re: Request for branch merge

[Richard Purdie]

On Fri, 2010-04-02 at 15:40 +0200, Koen Kooi wrote:
> While testing (rebased on top of this mornings OE, bitbake master) I'm
> getting messages like this:
> 
> //OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so:
> RPATH=/OE/angstrom-dev/sysroots/x86_64-linux/usr/lib
> //OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so:
> new RPATH: $ORIGIN/../../../../usr/lib
> open: Permission denied
> elf_open: Invalid argument
> 
> Are those messages from chrpath and can they be ignored?

The first messages are from the class and are safe to ignore. The
permission denied suggests something was added to staging that was
readonly? Can you check the permissions
on //OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so and see if that is the case. It would make sense for that code to check for read only and handle that case, restoring the permissions afterwards.

I won't get to it this weekend but I will make sure its fixed on Tuesday
if you can confirm that is the problem.

Cheers,

Richard

Re: Request for branch merge

[Richard Purdie]

On Fri, 2010-04-02 at 16:35 +0200, Koen Kooi wrote:
> And lots of:
> 
> : QA Issue with staging: libssp_nonshared.la failed sanity test
> (installed) in path
> /OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib

This one I can guess the reason for, we're missing the lamangler
function helper for cross packages. At the bottom of cross.bbclass, try
changing:

mv ${SYSROOT_DESTDIR}${target_base_libdir}/* ${SYSROOT_DESTDIR}${STAGING_DIR_TARGET}${target_base_libdir}/ || true
mv ${SYSROOT_DESTDIR}${target_libdir}/* ${SYSROOT_DESTDIR}${STAGING_DIR_TARGET}${target_libdir}/ || true

to become

rm -rf ${SYSROOT_DESTDIR}${target_base_libdir}/
rm -rf ${SYSROOT_DESTDIR}${target_libdir}/
sysroot_stage_libdir ${D}${target_base_libdir} ${SYSROOT_DESTDIR}${STAGING_DIR_TARGET}${target_base_libdir}
sysroot_stage_libdir ${D}${target_libdir} ${SYSROOT_DESTDIR}${STAGING_DIR_TARGET}${target_libdir}

which should mean the mangling happens correctly. Sorry I can't
test/push this right at the moment.

Cheers,

Richard

Re: Request for branch merge

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02-04-10 23:41, Richard Purdie wrote:
> On Fri, 2010-04-02 at 16:35 +0200, Koen Kooi wrote:
>> And lots of:
>>
>> : QA Issue with staging: libssp_nonshared.la failed sanity test
>> (installed) in path
>> /OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
> 
> This one I can guess the reason for, we're missing the lamangler
> function helper for cross packages. At the bottom of cross.bbclass, try
> changing:
> 
> mv ${SYSROOT_DESTDIR}${target_base_libdir}/* ${SYSROOT_DESTDIR}${STAGING_DIR_TARGET}${target_base_libdir}/ || true
> mv ${SYSROOT_DESTDIR}${target_libdir}/* ${SYSROOT_DESTDIR}${STAGING_DIR_TARGET}${target_libdir}/ || true
> 
> to become
> 
> rm -rf ${SYSROOT_DESTDIR}${target_base_libdir}/
> rm -rf ${SYSROOT_DESTDIR}${target_libdir}/
> sysroot_stage_libdir ${D}${target_base_libdir} ${SYSROOT_DESTDIR}${STAGING_DIR_TARGET}${target_base_libdir}
> sysroot_stage_libdir ${D}${target_libdir} ${SYSROOT_DESTDIR}${STAGING_DIR_TARGET}${target_libdir}
> 
> which should mean the mangling happens correctly. Sorry I can't
> test/push this right at the moment.

I pushed that to
http://gitorious.org/angstrom/openembedded/commits/koen/rpurdie-wip-rebased

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLtuxwMkyGM64RGpERAoeZAKCEnMZNc1/LwWLkfKAPFT8oFVqrfACbBm04
G8xIY0k4bvzPyLHPUJEhgB4=
=jHZ6
-----END PGP SIGNATURE-----

Re: Request for branch merge

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02-04-10 23:29, Richard Purdie wrote:
> On Fri, 2010-04-02 at 15:40 +0200, Koen Kooi wrote:
>> While testing (rebased on top of this mornings OE, bitbake master) I'm
>> getting messages like this:
>>
>> //OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so:
>> RPATH=/OE/angstrom-dev/sysroots/x86_64-linux/usr/lib
>> //OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so:
>> new RPATH: $ORIGIN/../../../../usr/lib
>> open: Permission denied
>> elf_open: Invalid argument
>>
>> Are those messages from chrpath and can they be ignored?
> 
> The first messages are from the class and are safe to ignore. The
> permission denied suggests something was added to staging that was
> readonly? Can you check the permissions
> on //OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so and see if that is the case. It would make sense for that code to check for read only and handle that case, restoring the permissions afterwards.
>

koen@dominion:/OE/org.openembedded.dev$ ls -la
/OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so

- -rwxr-xr-x 1 koen koen 70455 Apr  2 15:38
/OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so*


> I won't get to it this weekend but I will make sure its fixed on Tuesday
> if you can confirm that is the problem.

It builds a working 'console-image' for beagleboard and hawkboard, so
the basics are OK.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLtuzTMkyGM64RGpERAjRoAKCzYmyRXb96lzCtuW1PPSXK/MTGDgCgi6OJ
Hcseox1gKJSsztDFk//7i+4=
=aR2s
-----END PGP SIGNATURE-----

Re: Request for branch merge

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02-04-10 23:29, Richard Purdie wrote:
> On Fri, 2010-04-02 at 15:40 +0200, Koen Kooi wrote:
>> While testing (rebased on top of this mornings OE, bitbake master) I'm
>> getting messages like this:
>>
>> //OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so:
>> RPATH=/OE/angstrom-dev/sysroots/x86_64-linux/usr/lib
>> //OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so:
>> new RPATH: $ORIGIN/../../../../usr/lib
>> open: Permission denied
>> elf_open: Invalid argument
>>
>> Are those messages from chrpath and can they be ignored?
> 
> The first messages are from the class and are safe to ignore. The
> permission denied suggests something was added to staging that was
> readonly? Can you check the permissions
> on //OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so and see if that is the case. It would make sense for that code to check for read only and handle that case, restoring the permissions afterwards.
> 
> I won't get to it this weekend but I will make sure its fixed on Tuesday
> if you can confirm that is the problem.

With that patch I get:

NOTE: Task failed: ('function sysroot_stage_all failed',
'/OE/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/binutils-cross-2.18.50.0.7-r7.1/temp/log.sysroot_stage_all.7491')
ERROR: Logfile of failure stored in:
/OE/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/binutils-cross-2.18.50.0.7-r7.1/temp/log.sysroot_stage_all.7491
Log data follows:
|
/OE/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/binutils-cross-2.18.50.0.7-r7.1/temp/run.sysroot_stage_all.7491:
line 372: cd:
/OE/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/binutils-cross-2.18.50.0.7-r7.1/image/lib:
No such file or directory
| ERROR: Function sysroot_stage_all failed


regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLt0GYMkyGM64RGpERAo1jAJ9ZkzNdv2uefjQhFiszydtay99o7wCfWUtI
ndju9T002woZjh8HWfBKj+8=
=gBLB
-----END PGP SIGNATURE-----

Re: Request for branch merge

[Joshua Lock]

On Sat, 2010-04-03 at 09:23 +0200, Koen Kooi wrote: 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 02-04-10 23:29, Richard Purdie wrote:
> > On Fri, 2010-04-02 at 15:40 +0200, Koen Kooi wrote:
> >> While testing (rebased on top of this mornings OE, bitbake master) I'm
> >> getting messages like this:
> >>
> >> //OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so:
> >> RPATH=/OE/angstrom-dev/sysroots/x86_64-linux/usr/lib
> >> //OE/angstrom-dev/sysroots/x86_64-linux/usr/lib/python2.6/lib-dynload/strop.so:
> >> new RPATH: $ORIGIN/../../../../usr/lib
> >> open: Permission denied
> >> elf_open: Invalid argument

This looks like we're calling chrpath -l against a non-readable file, as
Richard suggested. Unfortunately it's not the echoed path which is the
problem, the path for which the open/elf_open warnings are triggered is
not echoed...

I've a patch to test the access to the file and temporarily set read and
write permissions on it if needed.

I'm just running this updated tree over a build of console-image now.

Cheers,
Joshua
-- 
Joshua Lock
        Intel Open Source Technology Centre

Re: Request for branch merge

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01-04-10 17:33, Richard Purdie wrote:
> I've been aware that Poky and OE have been diverging slightly and I'd
> like to correct this. There are some patches that I've promised for a
> while too such as the rename from do_populate_staging ->
> do_populate_sysroot.
> 
> With some help from Joshua Lock, I have a branch I'd like to propose be
> merged into OE.dev:
> 
> http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress

Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and
my issue with chrpath, which only leaves the cross staging lamangler
stuff to get fixed.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLwtvQMkyGM64RGpERAlkTAJ9OgPD4AlWVQk7E0fSH80USdap4SgCfdS+X
HSSYMh5iRIPDePeGRVVrnvk=
=UsoG
-----END PGP SIGNATURE-----

Re: Request for branch merge

[Tom Rini]

On Mon, 2010-04-12 at 10:37 +0200, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01-04-10 17:33, Richard Purdie wrote:
> > I've been aware that Poky and OE have been diverging slightly and I'd
> > like to correct this. There are some patches that I've promised for a
> > while too such as the rename from do_populate_staging ->
> > do_populate_sysroot.
> > 
> > With some help from Joshua Lock, I have a branch I'd like to propose be
> > merged into OE.dev:
> > 
> > http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress
> 
> Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and
> my issue with chrpath, which only leaves the cross staging lamangler
> stuff to get fixed.

Actually (and I'm OK with binconfig stuff being broken in the first
merge) the problem with binconfig junk isn't the file contents, but the
file location.  staging-target-pkg will contain
staging/<host>/usr/bin/<target>/foo-config.  Which means using pstaging
for a target pkg built on 32bit Linux fails when used on 64bit Linux.
Not that I wouldn't mind seeing the binconfig stuff die, just saying
it's a problem today :)

> 
> regards,
> 
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
> 
> iD8DBQFLwtvQMkyGM64RGpERAlkTAJ9OgPD4AlWVQk7E0fSH80USdap4SgCfdS+X
> HSSYMh5iRIPDePeGRVVrnvk=
> =UsoG
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel


-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: Request for branch merge

[Joshua Lock]

On Mon, 2010-04-12 at 10:37 +0200, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01-04-10 17:33, Richard Purdie wrote:
> > I've been aware that Poky and OE have been diverging slightly and I'd
> > like to correct this. There are some patches that I've promised for a
> > while too such as the rename from do_populate_staging ->
> > do_populate_sysroot.
> > 
> > With some help from Joshua Lock, I have a branch I'd like to propose be
> > merged into OE.dev:
> > 
> > http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress
> 
> Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and
> my issue with chrpath, which only leaves the cross staging lamangler
> stuff to get fixed.

I've just pushed an updated version of the tree with the recent Poky
changes you have observed and a merge of the autotools.bbclass to get
the lamangler stuff.

It builds a console-image fine here but the testing hasn't been
stringent as of yet.

Cheers,
Joshua
-- 
Joshua Lock
        Intel Open Source Technology Centre

Re: Request for branch merge

[Joshua Lock]

On Mon, 2010-04-12 at 08:59 -0700, Tom Rini wrote:
> On Mon, 2010-04-12 at 10:37 +0200, Koen Kooi wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 01-04-10 17:33, Richard Purdie wrote:
> > > I've been aware that Poky and OE have been diverging slightly and I'd
> > > like to correct this. There are some patches that I've promised for a
> > > while too such as the rename from do_populate_staging ->
> > > do_populate_sysroot.
> > > 
> > > With some help from Joshua Lock, I have a branch I'd like to propose be
> > > merged into OE.dev:
> > > 
> > > http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress
> > 
> > Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and
> > my issue with chrpath, which only leaves the cross staging lamangler
> > stuff to get fixed.
> 
> Actually (and I'm OK with binconfig stuff being broken in the first
> merge) the problem with binconfig junk isn't the file contents, but the
> file location.  staging-target-pkg will contain
> staging/<host>/usr/bin/<target>/foo-config.  Which means using pstaging
> for a target pkg built on 32bit Linux fails when used on 64bit Linux.
> Not that I wouldn't mind seeing the binconfig stuff die, just saying
> it's a problem today :)

Ah, hmm... yes. That is a problem.

FWIW I don't think you'll get any arguments from the Poky team where the
binconfig stuff to suffer an untimely demise!

Cheers,
Joshua
-- 
Joshua Lock
        Intel Open Source Technology Centre

Re: Request for branch merge

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12-04-10 18:45, Joshua Lock wrote:
> On Mon, 2010-04-12 at 10:37 +0200, Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 01-04-10 17:33, Richard Purdie wrote:
>>> I've been aware that Poky and OE have been diverging slightly and I'd
>>> like to correct this. There are some patches that I've promised for a
>>> while too such as the rename from do_populate_staging ->
>>> do_populate_sysroot.
>>>
>>> With some help from Joshua Lock, I have a branch I'd like to propose be
>>> merged into OE.dev:
>>>
>>> http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress
>>
>> Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and
>> my issue with chrpath, which only leaves the cross staging lamangler
>> stuff to get fixed.
> 
> I've just pushed an updated version of the tree with the recent Poky
> changes you have observed and a merge of the autotools.bbclass to get
> the lamangler stuff.

Thanks! I also like the CONFIGUREOPTS change you snuck in :)

> It builds a console-image fine here but the testing hasn't been
> stringent as of yet.

IIRC 'abiword' break if the cross lamangler isn't working, going to try
that now.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLw1yrMkyGM64RGpERAmH0AJ9tOYlZcBrCx6pHfZ+FDoLdRxhPvgCeK4VD
eujM8p1Ip0kO8Ldi3lZRHJQ=
=86n7
-----END PGP SIGNATURE-----

Re: Request for branch merge

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12-04-10 18:45, Joshua Lock wrote:
> On Mon, 2010-04-12 at 10:37 +0200, Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 01-04-10 17:33, Richard Purdie wrote:
>>> I've been aware that Poky and OE have been diverging slightly and I'd
>>> like to correct this. There are some patches that I've promised for a
>>> while too such as the rename from do_populate_staging ->
>>> do_populate_sysroot.
>>>
>>> With some help from Joshua Lock, I have a branch I'd like to propose be
>>> merged into OE.dev:
>>>
>>> http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress
>>
>> Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and
>> my issue with chrpath, which only leaves the cross staging lamangler
>> stuff to get fixed.
> 
> I've just pushed an updated version of the tree with the recent Poky
> changes you have observed and a merge of the autotools.bbclass to get
> the lamangler stuff.
> 
> It builds a console-image fine here but the testing hasn't been
> stringent as of yet.

I rebased your branch on top of 8e889754b1bdb261b85ac7de1c1f929ad597c09
(the checksum thing after than makes git puke) and I still get:

ERROR: QA Issue with staging: libgfortran.la failed sanity test
(installed) in path
/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
ERROR: QA Issue with staging: libssp_nonshared.la failed sanity test
(installed) in path
/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
ERROR: QA Issue with staging: libssp.la failed sanity test (installed)
in path /OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
ERROR: QA Issue with staging: libstdc++.la failed sanity test
(installed) in path
/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
ERROR: QA Issue with staging: libsupc++.la failed sanity test
(installed) in path
/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib

So the lamangler is still missing those by the looks of it.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLw4jGMkyGM64RGpERAswOAJ0Sxvzo46Fzm513uHjB8N/Eg3NyagCfVJgK
C5gVm3pr1zyAkeTkbRHjuIo=
=TEpD
-----END PGP SIGNATURE-----

Re: Request for branch merge

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12-04-10 18:45, Joshua Lock wrote:
> On Mon, 2010-04-12 at 10:37 +0200, Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 01-04-10 17:33, Richard Purdie wrote:
>>> I've been aware that Poky and OE have been diverging slightly and I'd
>>> like to correct this. There are some patches that I've promised for a
>>> while too such as the rename from do_populate_staging ->
>>> do_populate_sysroot.
>>>
>>> With some help from Joshua Lock, I have a branch I'd like to propose be
>>> merged into OE.dev:
>>>
>>> http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress
>>
>> Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and
>> my issue with chrpath, which only leaves the cross staging lamangler
>> stuff to get fixed.
> 
> I've just pushed an updated version of the tree with the recent Poky
> changes you have observed and a merge of the autotools.bbclass to get
> the lamangler stuff.
> 
> It builds a console-image fine here but the testing hasn't been
> stringent as of yet.

OK, I reproduced the abiword failure, it's in enchant:

| /bin/sh ../../arm-angstrom-linux-gnueabi-libtool --tag=CC
- --mode=link ccache arm-angstrom-linux-gnueabi-gcc -march=armv7-a
- -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
-
-isystem/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include
- -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2
- -ggdb3 -module -avoid-version -no-undefined
- -L/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
-
-Wl,-rpath-link,/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
- -Wl,-O1 -Wl,--hash-style=gnu -o libenchant_aspell.la -rpath
/usr/lib/enchant aspell_provider.lo -Wl,--export-dynamic -pthread
- -lgmodule-2.0 -lrt -lglib-2.0
- -L/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
- -laspell ../../src/libenchant.la
| /bin/grep:
/OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la:
No such file or directory
| /bin/sed: can't read
/OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la:
No such file or directory
| arm-angstrom-linux-gnueabi-libtool: link:
`/OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la'
is not a valid libtool archive

The file referenced
(/OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la)
doesn't exist since it is located in
/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/libstdc++.la
instead.

Any clues in which direction I should look to debug this?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLw5yNMkyGM64RGpERAiy6AJ9gkciNcKUwUJhSmRmRRGpzuEl8wwCgguCI
U0/KNvdOafbnrJeqhOz6Zt0=
=mlkL
-----END PGP SIGNATURE-----

Re: Request for branch merge

[Richard Purdie]

On Tue, 2010-04-13 at 00:19 +0200, Koen Kooi wrote:
> OK, I reproduced the abiword failure, it's in enchant:
> 
> | /bin/sh ../../arm-angstrom-linux-gnueabi-libtool --tag=CC
> - --mode=link ccache arm-angstrom-linux-gnueabi-gcc -march=armv7-a
> - -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
> -
> -isystem/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include
> - -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2
> - -ggdb3 -module -avoid-version -no-undefined
> - -L/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
> -
> -Wl,-rpath-link,/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
> - -Wl,-O1 -Wl,--hash-style=gnu -o libenchant_aspell.la -rpath
> /usr/lib/enchant aspell_provider.lo -Wl,--export-dynamic -pthread
> - -lgmodule-2.0 -lrt -lglib-2.0
> - -L/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
> - -laspell ../../src/libenchant.la
> | /bin/grep:
> /OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la:
> No such file or directory
> | /bin/sed: can't read
> /OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la:
> No such file or directory
> | arm-angstrom-linux-gnueabi-libtool: link:
> `/OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la'
> is not a valid libtool archive
> 
> The file referenced
> (/OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la)
> doesn't exist since it is located in
> /OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/libstdc++.la
> instead.
> 
> Any clues in which direction I should look to debug this?

Sorry I've not been able to spend the time I'd like on this stuff, work
and travel have got in the way and are probably going to tie me up for a
while yet if I'm realistic. Anyone at ELC should say hello btw! :) 

Jet lag prevents me thinking too clearly at the moment but whats
happening above is that the sysroot is starting to look more like the
real target filesystem and libstdc++ is moving to what I would say is
the correct place for it. This is good but it seems something, probably
a .la file has the incorrect path? Is this a build from scratch or an
old build? I suspect it would work with a build from scratch but if this
was one, there is some more subtle problem :/.

Alternatively, the lamangler may be causing this by leaving incorrect
paths in the .la files as I saw that issue isn't addressed yet.

Cheers,

Richard

Re: Request for branch merge

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13-04-10 05:46, Richard Purdie wrote:
> On Tue, 2010-04-13 at 00:19 +0200, Koen Kooi wrote:
>> OK, I reproduced the abiword failure, it's in enchant:
>>
>> | /bin/sh ../../arm-angstrom-linux-gnueabi-libtool --tag=CC
>> - --mode=link ccache arm-angstrom-linux-gnueabi-gcc -march=armv7-a
>> - -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
>> -
>> -isystem/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include
>> - -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2
>> - -ggdb3 -module -avoid-version -no-undefined
>> - -L/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>> -
>> -Wl,-rpath-link,/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>> - -Wl,-O1 -Wl,--hash-style=gnu -o libenchant_aspell.la -rpath
>> /usr/lib/enchant aspell_provider.lo -Wl,--export-dynamic -pthread
>> - -lgmodule-2.0 -lrt -lglib-2.0
>> - -L/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>> - -laspell ../../src/libenchant.la
>> | /bin/grep:
>> /OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la:
>> No such file or directory
>> | /bin/sed: can't read
>> /OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la:
>> No such file or directory
>> | arm-angstrom-linux-gnueabi-libtool: link:
>> `/OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la'
>> is not a valid libtool archive
>>
>> The file referenced
>> (/OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la)
>> doesn't exist since it is located in
>> /OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/libstdc++.la
>> instead.
>>
>> Any clues in which direction I should look to debug this?
> 
> Sorry I've not been able to spend the time I'd like on this stuff, work
> and travel have got in the way and are probably going to tie me up for a
> while yet if I'm realistic. Anyone at ELC should say hello btw! :) 


> Jet lag prevents me thinking too clearly at the moment but whats
> happening above is that the sysroot is starting to look more like the
> real target filesystem and libstdc++ is moving to what I would say is
> the correct place for it. This is good but it seems something, probably
> a .la file has the incorrect path? Is this a build from scratch or an
> old build? I suspect it would work with a build from scratch but if this
> was one, there is some more subtle problem :/.

It's a complete build from scratch (rm tmp -rf ; bitbake abiword).

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLxBfsMkyGM64RGpERAiykAJwNRGHh69Gq4cO+ey3U/+MiPqo+tQCfeKzS
G2KKVQZabSMFEkaoC/9CIXs=
=eBAr
-----END PGP SIGNATURE-----

Re: Request for branch merge

[Richard Purdie]

On Tue, 2010-04-13 at 09:06 +0200, Koen Kooi wrote:
> On 13-04-10 05:46, Richard Purdie wrote:
> > On Tue, 2010-04-13 at 00:19 +0200, Koen Kooi wrote:
> >> OK, I reproduced the abiword failure, it's in enchant:
> >>
> >> | /bin/sh ../../arm-angstrom-linux-gnueabi-libtool --tag=CC
> >> - --mode=link ccache arm-angstrom-linux-gnueabi-gcc -march=armv7-a
> >> - -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
> >> -
> >> -isystem/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include
> >> - -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2
> >> - -ggdb3 -module -avoid-version -no-undefined
> >> - -L/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
> >> -
> >> -Wl,-rpath-link,/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
> >> - -Wl,-O1 -Wl,--hash-style=gnu -o libenchant_aspell.la -rpath
> >> /usr/lib/enchant aspell_provider.lo -Wl,--export-dynamic -pthread
> >> - -lgmodule-2.0 -lrt -lglib-2.0
> >> - -L/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
> >> - -laspell ../../src/libenchant.la
> >> | /bin/grep:
> >> /OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la:
> >> No such file or directory
> >> | /bin/sed: can't read
> >> /OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la:
> >> No such file or directory
> >> | arm-angstrom-linux-gnueabi-libtool: link:
> >> `/OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la'
> >> is not a valid libtool archive
> >>
> >> The file referenced
> >> (/OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la)
> >> doesn't exist since it is located in
> >> /OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/libstdc++.la
> >> instead.
> >>
> >> Any clues in which direction I should look to debug this?
> > 
> > Sorry I've not been able to spend the time I'd like on this stuff, work
> > and travel have got in the way and are probably going to tie me up for a
> > while yet if I'm realistic. Anyone at ELC should say hello btw! :) 
> 
> 
> > Jet lag prevents me thinking too clearly at the moment but whats
> > happening above is that the sysroot is starting to look more like the
> > real target filesystem and libstdc++ is moving to what I would say is
> > the correct place for it. This is good but it seems something, probably
> > a .la file has the incorrect path? Is this a build from scratch or an
> > old build? I suspect it would work with a build from scratch but if this
> > was one, there is some more subtle problem :/.
> 
> It's a complete build from scratch (rm tmp -rf ; bitbake abiword).

Sorry about the delay, this commit should fix it (reproduced and tested
locally):

http://git.openembedded.net/cgit.cgi/openembedded/commit/?h=rpurdie/work-in-progress&id=bb53e48f79dab0877c8b8ce487a051d29cae31e3

Cheers,

Richard

Re: Request for branch merge

[Richard Purdie]

On Mon, 2010-04-12 at 17:46 +0100, Joshua Lock wrote:
> On Mon, 2010-04-12 at 08:59 -0700, Tom Rini wrote:
> > On Mon, 2010-04-12 at 10:37 +0200, Koen Kooi wrote:
>  > Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and
> > > my issue with chrpath, which only leaves the cross staging lamangler
> > > stuff to get fixed.
> > 
> > Actually (and I'm OK with binconfig stuff being broken in the first
> > merge) the problem with binconfig junk isn't the file contents, but the
> > file location.  staging-target-pkg will contain
> > staging/<host>/usr/bin/<target>/foo-config.  Which means using pstaging
> > for a target pkg built on 32bit Linux fails when used on 64bit Linux.
> > Not that I wouldn't mind seeing the binconfig stuff die, just saying
> > it's a problem today :)
> 
> Ah, hmm... yes. That is a problem.
> 
> FWIW I don't think you'll get any arguments from the Poky team where the
> binconfig stuff to suffer an untimely demise!

FWIW, Poky has had some interesting commits recently that address Tom's
issue above from Josh.

Cheers,

Richard

Re: Request for branch merge

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02-05-10 01:28, Richard Purdie wrote:
> On Tue, 2010-04-13 at 09:06 +0200, Koen Kooi wrote:
>> On 13-04-10 05:46, Richard Purdie wrote:
>>> On Tue, 2010-04-13 at 00:19 +0200, Koen Kooi wrote:
>>>> OK, I reproduced the abiword failure, it's in enchant:
>>>>
>>>> | /bin/sh ../../arm-angstrom-linux-gnueabi-libtool --tag=CC
>>>> - --mode=link ccache arm-angstrom-linux-gnueabi-gcc -march=armv7-a
>>>> - -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
>>>> -
>>>> -isystem/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include
>>>> - -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2
>>>> - -ggdb3 -module -avoid-version -no-undefined
>>>> - -L/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>>>> -
>>>> -Wl,-rpath-link,/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>>>> - -Wl,-O1 -Wl,--hash-style=gnu -o libenchant_aspell.la -rpath
>>>> /usr/lib/enchant aspell_provider.lo -Wl,--export-dynamic -pthread
>>>> - -lgmodule-2.0 -lrt -lglib-2.0
>>>> - -L/OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>>>> - -laspell ../../src/libenchant.la
>>>> | /bin/grep:
>>>> /OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la:
>>>> No such file or directory
>>>> | /bin/sed: can't read
>>>> /OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la:
>>>> No such file or directory
>>>> | arm-angstrom-linux-gnueabi-libtool: link:
>>>> `/OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la'
>>>> is not a valid libtool archive
>>>>
>>>> The file referenced
>>>> (/OE/angstrom-dev/cross/armv7a/arm-angstrom-linux-gnueabi/lib/libstdc++.la)
>>>> doesn't exist since it is located in
>>>> /OE/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/libstdc++.la
>>>> instead.
>>>>
>>>> Any clues in which direction I should look to debug this?
>>>
>>> Sorry I've not been able to spend the time I'd like on this stuff, work
>>> and travel have got in the way and are probably going to tie me up for a
>>> while yet if I'm realistic. Anyone at ELC should say hello btw! :) 
>>
>>
>>> Jet lag prevents me thinking too clearly at the moment but whats
>>> happening above is that the sysroot is starting to look more like the
>>> real target filesystem and libstdc++ is moving to what I would say is
>>> the correct place for it. This is good but it seems something, probably
>>> a .la file has the incorrect path? Is this a build from scratch or an
>>> old build? I suspect it would work with a build from scratch but if this
>>> was one, there is some more subtle problem :/.
>>
>> It's a complete build from scratch (rm tmp -rf ; bitbake abiword).
> 
> Sorry about the delay, this commit should fix it (reproduced and tested
> locally):
> 
> http://git.openembedded.net/cgit.cgi/openembedded/commit/?h=rpurdie/work-in-progress&id=bb53e48f79dab0877c8b8ce487a051d29cae31e3

Awesome, that removes the last of my concerns, please merge it :) I have
time next week to deal with possible fallout.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFL3YiSMkyGM64RGpERAh93AJ4+VaaUA5ZjK4FTck/X23LiPYPOKQCglzfg
O4zXrxxiRVfcsJ1ULnrxbZs=
=K19A
-----END PGP SIGNATURE-----

Re: Request for branch merge

[Tom Rini]

On Sun, 2010-05-02 at 00:29 +0100, Richard Purdie wrote:
> On Mon, 2010-04-12 at 17:46 +0100, Joshua Lock wrote:
> > On Mon, 2010-04-12 at 08:59 -0700, Tom Rini wrote:
> > > On Mon, 2010-04-12 at 10:37 +0200, Koen Kooi wrote:
> >  > Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and
> > > > my issue with chrpath, which only leaves the cross staging lamangler
> > > > stuff to get fixed.
> > > 
> > > Actually (and I'm OK with binconfig stuff being broken in the first
> > > merge) the problem with binconfig junk isn't the file contents, but the
> > > file location.  staging-target-pkg will contain
> > > staging/<host>/usr/bin/<target>/foo-config.  Which means using pstaging
> > > for a target pkg built on 32bit Linux fails when used on 64bit Linux.
> > > Not that I wouldn't mind seeing the binconfig stuff die, just saying
> > > it's a problem today :)
> > 
> > Ah, hmm... yes. That is a problem.
> > 
> > FWIW I don't think you'll get any arguments from the Poky team where the
> > binconfig stuff to suffer an untimely demise!
> 
> FWIW, Poky has had some interesting commits recently that address Tom's
> issue above from Josh.

Interesting.  When you killed CROSS_*, did you rework stuff so that gcc
& co's sysroot stuff works automatically or no?  Can't tell off-hand.
Thanks.

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: Request for branch merge

[Richard Purdie]

On Mon, 2010-05-03 at 09:46 -0700, Tom Rini wrote:
> On Sun, 2010-05-02 at 00:29 +0100, Richard Purdie wrote:
> > On Mon, 2010-04-12 at 17:46 +0100, Joshua Lock wrote:
> > > On Mon, 2010-04-12 at 08:59 -0700, Tom Rini wrote:
> > > > On Mon, 2010-04-12 at 10:37 +0200, Koen Kooi wrote:
> > >  > Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and
> > > > > my issue with chrpath, which only leaves the cross staging lamangler
> > > > > stuff to get fixed.
> > > > 
> > > > Actually (and I'm OK with binconfig stuff being broken in the first
> > > > merge) the problem with binconfig junk isn't the file contents, but the
> > > > file location.  staging-target-pkg will contain
> > > > staging/<host>/usr/bin/<target>/foo-config.  Which means using pstaging
> > > > for a target pkg built on 32bit Linux fails when used on 64bit Linux.
> > > > Not that I wouldn't mind seeing the binconfig stuff die, just saying
> > > > it's a problem today :)
> > > 
> > > Ah, hmm... yes. That is a problem.
> > > 
> > > FWIW I don't think you'll get any arguments from the Poky team where the
> > > binconfig stuff to suffer an untimely demise!
> > 
> > FWIW, Poky has had some interesting commits recently that address Tom's
> > issue above from Josh.
> 
> Interesting.  When you killed CROSS_*, did you rework stuff so that gcc
> & co's sysroot stuff works automatically or no?  Can't tell off-hand.

What do you mean by "works automatically"?

Cheers,

Richard

Re: Request for branch merge

[Tom Rini]

On Tue, 2010-05-04 at 19:10 +0100, Richard Purdie wrote:
> On Mon, 2010-05-03 at 09:46 -0700, Tom Rini wrote:
> > On Sun, 2010-05-02 at 00:29 +0100, Richard Purdie wrote:
> > > On Mon, 2010-04-12 at 17:46 +0100, Joshua Lock wrote:
> > > > On Mon, 2010-04-12 at 08:59 -0700, Tom Rini wrote:
> > > > > On Mon, 2010-04-12 at 10:37 +0200, Koen Kooi wrote:
> > > >  > Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and
> > > > > > my issue with chrpath, which only leaves the cross staging lamangler
> > > > > > stuff to get fixed.
> > > > > 
> > > > > Actually (and I'm OK with binconfig stuff being broken in the first
> > > > > merge) the problem with binconfig junk isn't the file contents, but the
> > > > > file location.  staging-target-pkg will contain
> > > > > staging/<host>/usr/bin/<target>/foo-config.  Which means using pstaging
> > > > > for a target pkg built on 32bit Linux fails when used on 64bit Linux.
> > > > > Not that I wouldn't mind seeing the binconfig stuff die, just saying
> > > > > it's a problem today :)
> > > > 
> > > > Ah, hmm... yes. That is a problem.
> > > > 
> > > > FWIW I don't think you'll get any arguments from the Poky team where the
> > > > binconfig stuff to suffer an untimely demise!
> > > 
> > > FWIW, Poky has had some interesting commits recently that address Tom's
> > > issue above from Josh.
> > 
> > Interesting.  When you killed CROSS_*, did you rework stuff so that gcc
> > & co's sysroot stuff works automatically or no?  Can't tell off-hand.
> 
> What do you mean by "works automatically"?

gcc & co have certain paths that they look in by default, relative to
their location (see meta-toolchain.bb, that's not a hard-coded search,
that's a relocatable one).  The current oe.dev layout of things doesn't
fit here so we have to pass in --sysroot=... at a minimum and often have
-isystem for "legacy" reasons.


-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: Request for branch merge

[Richard Purdie]

On Tue, 2010-05-04 at 11:55 -0700, Tom Rini wrote:
> On Tue, 2010-05-04 at 19:10 +0100, Richard Purdie wrote:
> > On Mon, 2010-05-03 at 09:46 -0700, Tom Rini wrote:
> > > On Sun, 2010-05-02 at 00:29 +0100, Richard Purdie wrote:
> > > > On Mon, 2010-04-12 at 17:46 +0100, Joshua Lock wrote:
> > > > > On Mon, 2010-04-12 at 08:59 -0700, Tom Rini wrote:
> > > > > > On Mon, 2010-04-12 at 10:37 +0200, Koen Kooi wrote:
> > > > >  > Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and
> > > > > > > my issue with chrpath, which only leaves the cross staging lamangler
> > > > > > > stuff to get fixed.
> > > > > > 
> > > > > > Actually (and I'm OK with binconfig stuff being broken in the first
> > > > > > merge) the problem with binconfig junk isn't the file contents, but the
> > > > > > file location.  staging-target-pkg will contain
> > > > > > staging/<host>/usr/bin/<target>/foo-config.  Which means using pstaging
> > > > > > for a target pkg built on 32bit Linux fails when used on 64bit Linux.
> > > > > > Not that I wouldn't mind seeing the binconfig stuff die, just saying
> > > > > > it's a problem today :)
> > > > > 
> > > > > Ah, hmm... yes. That is a problem.
> > > > > 
> > > > > FWIW I don't think you'll get any arguments from the Poky team where the
> > > > > binconfig stuff to suffer an untimely demise!
> > > > 
> > > > FWIW, Poky has had some interesting commits recently that address Tom's
> > > > issue above from Josh.
> > > 
> > > Interesting.  When you killed CROSS_*, did you rework stuff so that gcc
> > > & co's sysroot stuff works automatically or no?  Can't tell off-hand.
> > 
> > What do you mean by "works automatically"?
> 
> gcc & co have certain paths that they look in by default, relative to
> their location (see meta-toolchain.bb, that's not a hard-coded search,
> that's a relocatable one).  The current oe.dev layout of things doesn't
> fit here so we have to pass in --sysroot=... at a minimum and often have
> -isystem for "legacy" reasons.

Ah, right. I haven't attempted this, no. It would really depend on what
the "certain paths" that are hardcoded are and whether we can influence
them at all. Would be worth looking at in due course though.

Cheers,

Richard

Re: Request for branch merge

[Tom Rini]

On Thu, 2010-05-06 at 00:22 +0100, Richard Purdie wrote:
> On Tue, 2010-05-04 at 11:55 -0700, Tom Rini wrote:
> > On Tue, 2010-05-04 at 19:10 +0100, Richard Purdie wrote:
> > > On Mon, 2010-05-03 at 09:46 -0700, Tom Rini wrote:
> > > > On Sun, 2010-05-02 at 00:29 +0100, Richard Purdie wrote:
> > > > > On Mon, 2010-04-12 at 17:46 +0100, Joshua Lock wrote:
> > > > > > On Mon, 2010-04-12 at 08:59 -0700, Tom Rini wrote:
> > > > > > > On Mon, 2010-04-12 at 10:37 +0200, Koen Kooi wrote:
> > > > > >  > Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and
> > > > > > > > my issue with chrpath, which only leaves the cross staging lamangler
> > > > > > > > stuff to get fixed.
> > > > > > > 
> > > > > > > Actually (and I'm OK with binconfig stuff being broken in the first
> > > > > > > merge) the problem with binconfig junk isn't the file contents, but the
> > > > > > > file location.  staging-target-pkg will contain
> > > > > > > staging/<host>/usr/bin/<target>/foo-config.  Which means using pstaging
> > > > > > > for a target pkg built on 32bit Linux fails when used on 64bit Linux.
> > > > > > > Not that I wouldn't mind seeing the binconfig stuff die, just saying
> > > > > > > it's a problem today :)
> > > > > > 
> > > > > > Ah, hmm... yes. That is a problem.
> > > > > > 
> > > > > > FWIW I don't think you'll get any arguments from the Poky team where the
> > > > > > binconfig stuff to suffer an untimely demise!
> > > > > 
> > > > > FWIW, Poky has had some interesting commits recently that address Tom's
> > > > > issue above from Josh.
> > > > 
> > > > Interesting.  When you killed CROSS_*, did you rework stuff so that gcc
> > > > & co's sysroot stuff works automatically or no?  Can't tell off-hand.
> > > 
> > > What do you mean by "works automatically"?
> > 
> > gcc & co have certain paths that they look in by default, relative to
> > their location (see meta-toolchain.bb, that's not a hard-coded search,
> > that's a relocatable one).  The current oe.dev layout of things doesn't
> > fit here so we have to pass in --sysroot=... at a minimum and often have
> > -isystem for "legacy" reasons.
> 
> Ah, right. I haven't attempted this, no. It would really depend on what
> the "certain paths" that are hardcoded are and whether we can influence
> them at all. Would be worth looking at in due course though.

I'd really like to see us do this at the same time we kill off cross.
That, really, is the hard part of the equation and you've tackled it
already.  We just need <some name>/<target>/<std layout> and <some
name>/bin,lib,etc.

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation