Gstreamer and rpath

Gstreamer and rpath

[Koen Kooi]

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

Hi,

There were some report about gstreamer not finding plugins and Cliff Brake reported that
frobbing OE_LT_RPATH_ALLOW helped:

============================================================
- --- packages/gstreamer/gst-common.inc   27ceb74f764523f7d0708087bd16ae8a3627c39e
+++ packages/gstreamer/gst-common.inc   860249c91df6da7ad81a6dffba9d5529cc114c67
@@ -7,6 +7,9 @@ inherit autotools pkgconfig

 inherit autotools pkgconfig

+OE_LT_RPATH_ALLOW = "any"
+OE_LT_RPATH_ALLOW[export]="1"
+
 do_stage() {
     rm -rf ${STAGE_TEMP}
     mkdir -p ${STAGE_TEMP}
============================================================
- --- packages/gstreamer/gst-plugins.inc  6293327f294676ab88b8ec6b36906d0113b3566a
+++ packages/gstreamer/gst-plugins.inc  5dc5a74a21bc2ea4d9870acdac9615b821137cec
@@ -10,6 +10,9 @@ acpaths = "-I ${S}/common/m4 -I ${S}/m4"

 acpaths = "-I ${S}/common/m4 -I ${S}/m4"

+OE_LT_RPATH_ALLOW = "any"
+OE_LT_RPATH_ALLOW[export]="1"
+
 LIBV = "0.10"

 python populate_packages_prepend () {


Could someone more familiar with gstreamer and/or the OE_LT_RPATH_ALLOW syntax make this
more finegrained?

regards,

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

iD8DBQFGsXU9MkyGM64RGpERAuEwAJ9Su8/u9KTVGiUXZZBlV8d1jlXsbwCdEnjA
IiNAD5rXK8/ZHOqucqnBTKU=
=sHJu
-----END PGP SIGNATURE-----

Re: Gstreamer and rpath

[Michael Krelin]

I don't know much about gstreamer, but being inventor of
OE_LT_RPATH_ALLOW I felt obliged to look into gst-plugins.inc and I'm
guessing it should be:

OE_LT_RPATH_ALLOW=":${libdir}/gstreamer-${LIBV}:"

instead of "any".

Love,
H

Koen Kooi wrote:
> Hi,
> 
> There were some report about gstreamer not finding plugins and Cliff Brake reported that
> frobbing OE_LT_RPATH_ALLOW helped:
> 
> ============================================================
> --- packages/gstreamer/gst-common.inc   27ceb74f764523f7d0708087bd16ae8a3627c39e
> +++ packages/gstreamer/gst-common.inc   860249c91df6da7ad81a6dffba9d5529cc114c67
> @@ -7,6 +7,9 @@ inherit autotools pkgconfig
> 
>  inherit autotools pkgconfig
> 
> +OE_LT_RPATH_ALLOW = "any"
> +OE_LT_RPATH_ALLOW[export]="1"
> +
>  do_stage() {
>      rm -rf ${STAGE_TEMP}
>      mkdir -p ${STAGE_TEMP}
> ============================================================
> --- packages/gstreamer/gst-plugins.inc  6293327f294676ab88b8ec6b36906d0113b3566a
> +++ packages/gstreamer/gst-plugins.inc  5dc5a74a21bc2ea4d9870acdac9615b821137cec
> @@ -10,6 +10,9 @@ acpaths = "-I ${S}/common/m4 -I ${S}/m4"
> 
>  acpaths = "-I ${S}/common/m4 -I ${S}/m4"
> 
> +OE_LT_RPATH_ALLOW = "any"
> +OE_LT_RPATH_ALLOW[export]="1"
> +
>  LIBV = "0.10"
> 
>  python populate_packages_prepend () {
> 
> 
> Could someone more familiar with gstreamer and/or the OE_LT_RPATH_ALLOW syntax make this
> more finegrained?
> 
> regards,
> 
> Koen

_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Gstreamer and rpath

[Stanislav Brabec]

Michael Krelin wrote:
> I don't know much about gstreamer, but being inventor of
> OE_LT_RPATH_ALLOW I felt obliged to look into gst-plugins.inc and I'm
> guessing it should be:

Maybe it would be better to not break build environment and then work
around consequent errors by hacks like OE_LT_RPATH_ALLOW,
never-ever-do-rpath.patch etc.

gcc has --sysroot which can do required linking without any hacks.

To fix this overall see:

http://bugs.openembedded.org/show_bug.cgi?id=2713
get rid references to temporary directories on installed system

I failed to find proper place to change OE-wide values for cross- CC,
CC, CPP, CXX, LD,... Can anybody tell me, where they are defined?

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: Gstreamer and rpath

[Michael Krelin]

> Michael Krelin wrote:
>> I don't know much about gstreamer, but being inventor of
>> OE_LT_RPATH_ALLOW I felt obliged to look into gst-plugins.inc and I'm
>> guessing it should be:
> 
> Maybe it would be better to not break build environment and then work
> around consequent errors by hacks like OE_LT_RPATH_ALLOW,
> never-ever-do-rpath.patch etc.
> 
> gcc has --sysroot which can do required linking without any hacks.
> 

Generally, I tend to agree, but in practice I'm afraid that would amount
to rewriting the whole OE...


Love,
H

Re: Gstreamer and rpath

[Stanislav Brabec]

Michael Krelin wrote:
> > Michael Krelin wrote:
> >> I don't know much about gstreamer, but being inventor of
> >> OE_LT_RPATH_ALLOW I felt obliged to look into gst-plugins.inc and I'm
> >> guessing it should be:
> > 
> > Maybe it would be better to not break build environment and then work
> > around consequent errors by hacks like OE_LT_RPATH_ALLOW,
> > never-ever-do-rpath.patch etc.
> > 
> > gcc has --sysroot which can do required linking without any hacks.
> > 
> 
> Generally, I tend to agree, but in practice I'm afraid that would amount
> to rewriting the whole OE...

No.

1. and 2. and 4. should be change of about 20 lines (change xxxx_CC from
e. g. "arm-angstrom-linux-gnueabi-gcc" to e. g.
"arm-angstrom-linux-gnueabi-gcc --sysroot=/OE/build/tmp/staging/arm-angstrom-linux-gnueabi").
I only could not find correct lines.

If anybody tell me the correct location, I can do test bootstrap with
the new options.

5. is low priority, after 4. it will become NOP

6. Is already done, it should be enough to change check pattern in the
QA stuff.

3. and 7. break packages (e. g. findutils) not depending on CC
definition and has to be fixed manually anyway.

And if 8. will be done (in far future), most individual fixes in 7.
could be removed.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: Gstreamer and rpath

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

Stanislav Brabec wrote:
> Michael Krelin wrote:
>>> Michael Krelin wrote:
>>>> I don't know much about gstreamer, but being inventor of
>>>> OE_LT_RPATH_ALLOW I felt obliged to look into gst-plugins.inc and I'm
>>>> guessing it should be:
>>> Maybe it would be better to not break build environment and then work
>>> around consequent errors by hacks like OE_LT_RPATH_ALLOW,
>>> never-ever-do-rpath.patch etc.
>>>
>>> gcc has --sysroot which can do required linking without any hacks.
>>>
>> Generally, I tend to agree, but in practice I'm afraid that would amount
>> to rewriting the whole OE...

Is --sysroot present in all versions of gcc? If not, which version does 
it first appear?

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Gstreamer and rpath

[Michael Krelin]

I think starting with 3.4, another reason why this idea maybe not yet
viable...

Love,
H

> Is --sysroot present in all versions of gcc? If not, which version does
> it first appear?
> 
> Philip
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Gstreamer and rpath

[Stanislav Brabec]

Philip Balister wrote:

> Is --sysroot present in all versions of gcc? If not, which version does 
> it first appear?

3.3.3 has not it yet.

gcc/ChangeLog.2005:
2005-07-25  Mark Mitchell  <mark@codesourcery.com>

	* gcc.c (option_map): Add --sysroot.

Michael Krelin wrote:

> I think starting with 3.4, another reason why this idea maybe not yet
> viable...

I see no problem here: For cross compilation OE compiles its own
compiler, which already supports --sysroot, and for native compilation
--sysroot is not needed (--prefix=.../OE/... is correct there).

Michael Krelin wrote:

> staging doesn't resemble root filesystem, to begin with. So that would
> involve rearranging staging as well. Which is again a good idea, but
> would take longer that it sounds in pure theory.

Yes, I realized that. This step seems to be the most complicated work.
As a work-around it is possible to make symlink "usr" pointing to
staging root.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: Gstreamer and rpath

[Koen Kooi]

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

Stanislav Brabec schreef:
> Philip Balister wrote:
> 
>> Is --sysroot present in all versions of gcc? If not, which version does 
>> it first appear?
> 
> 3.3.3 has not it yet.
> 
> gcc/ChangeLog.2005:
> 2005-07-25  Mark Mitchell  <mark@codesourcery.com>
> 
> 	* gcc.c (option_map): Add --sysroot.
> 
> Michael Krelin wrote:
> 
>> I think starting with 3.4, another reason why this idea maybe not yet
>> viable...
> 
> I see no problem here: For cross compilation OE compiles its own
> compiler, which already supports --sysroot,

No. We have a gcc-cross_3.3.3.bb and 3.3.4

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

iD8DBQFGseBjMkyGM64RGpERApeSAKCN9M3ZOXHkQ4eZ4G5BFZdZ9FJItACcC0OS
K3d/zOAwdbQmNuLmTMOD0Q0=
=1Zuo
-----END PGP SIGNATURE-----

Re: Gstreamer and rpath

[Stanislav Brabec]

Koen Kooi wrote:

> > I see no problem here: For cross compilation OE compiles its own
> > compiler, which already supports --sysroot,
> 
> No. We have a gcc-cross_3.3.3.bb and 3.3.4

But Angstrom uses 4.1.2 as default, isn't it? And it compiles everything
correctly (except qemu).

oe:~> /OE/build/tmp/cross/arm-angstrom-linux-gnueabi/bin/gcc --version
gcc (GCC) 4.1.2

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: Gstreamer and rpath

[Koen Kooi]

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

Stanislav Brabec schreef:
> Koen Kooi wrote:
> 
>>> I see no problem here: For cross compilation OE compiles its own
>>> compiler, which already supports --sysroot,
>> No. We have a gcc-cross_3.3.3.bb and 3.3.4
> 
> But Angstrom uses 4.1.2 as default, isn't it? And it compiles everything
> correctly (except qemu).

OE != angstrom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGsegSMkyGM64RGpERAs9EAJ9aWZcVWuqab5/Ly4QVT2LIV4DXFQCgknlK
uclWnyqzCSbAMgHEl5+F4dQ=
=6QXr
-----END PGP SIGNATURE-----

Re: Gstreamer and rpath

[Stanislav Brabec]

Koen Kooi wrote:
 
> > But Angstrom uses 4.1.2 as default, isn't it? And it compiles everything
> > correctly (except qemu).
> 
> OE != angstrom

Yes. But it means, that !angstrom may also succeed with a newer gcc.

There are three chances for --sysroot:

- All OE projects will upgrade to gcc >= 3.4.

- Keep libtool hacks optional for distros using older gcc versions.

- Write wrappers on top of old gcc to implement the most important parts
  of --sysroot (rewriting of -L and -I paths and use of -nostdinc).
  (~15 lines in bash or sh+sed).

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: Gstreamer and rpath

[Michael Krelin]

>  
>>> But Angstrom uses 4.1.2 as default, isn't it? And it compiles everything
>>> correctly (except qemu).
>> OE != angstrom
> 
> Yes. But it means, that !angstrom may also succeed with a newer gcc.

You're not talking about gcc upgrade, but rather about different
approach to the whole crossbuild.

> There are three chances for --sysroot:
> 
> - All OE projects will upgrade to gcc >= 3.4.

Including sharprom compatible build, that requires 2.95 or something.

> - Keep libtool hacks optional for distros using older gcc versions.
> - Write wrappers on top of old gcc to implement the most important
> parts of --sysroot (rewriting of -L and -I paths and use of
> -nostdinc). (~15 lines in bash or sh+sed).

That may be possible even with rearranged staging, indeed, but again,
you agreed it's more complicated that it seemed to you at the first glance.

I'm not taking the symlink workaround seriously, because inventing one
workaround to get rid of the other isn't going to get us anywhere.

Love,
H

Re: Gstreamer and rpath

[Koen Kooi]

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

Michael Krelin schreef:

> I'm not taking the symlink workaround seriously, because inventing one
> workaround to get rid of the other isn't going to get us anywhere.

Packaged-staging v1 is using that symlink approach and it doesn't help a lot. Hence the
need for v2 :)

regards,

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

iD8DBQFGsfxgMkyGM64RGpERAswNAKCF4iODAbUdbkU2bkXoP62jOqNFOwCgjj1U
4FlEIEs3i7GiYX8rXig1rVA=
=qDhZ
-----END PGP SIGNATURE-----

Re: Gstreamer and rpath

[Michael Krelin]

> Michael Krelin schreef:
> 
>> I'm not taking the symlink workaround seriously, because inventing one
>> workaround to get rid of the other isn't going to get us anywhere.
> 
> Packaged-staging v1 is using that symlink approach and it doesn't help a lot. Hence the
> need for v2 :)

Just about time ;-)

No matter how soon we can move to sysroot approach, I think making
staging resemble filesystem is the right thing to do, anyway...


Love,
H

Re: Gstreamer and rpath

[Koen Kooi]

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

Michael Krelin schreef:
>> Michael Krelin schreef:
>>
>>> I'm not taking the symlink workaround seriously, because inventing one
>>> workaround to get rid of the other isn't going to get us anywhere.
>> Packaged-staging v1 is using that symlink approach and it doesn't help a lot. Hence the
>> need for v2 :)
> 
> Just about time ;-)
> 
> No matter how soon we can move to sysroot approach, I think making
> staging resemble filesystem is the right thing to do, anyway...

Indeed. I suspect most of our packages could handle that (autotools, qmake and distutils
based ones) easily. The big question is:

  How are we going to do it?

Are we going to declare another ".dev is broken" period, a branch, a branch with a small
amount of packages like org.oe.packaged-staging?

regards,

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

iD8DBQFGsg2fMkyGM64RGpERAmKeAJwImUaWvpL8sXSgVOPoIeZ+NQ3wSQCfZjJX
Th2kgW3NxO8jQhjtryyD0z8=
=jaw3
-----END PGP SIGNATURE-----

Re: Gstreamer and rpath

[Michael Krelin]

>> No matter how soon we can move to sysroot approach, I think making
>> staging resemble filesystem is the right thing to do, anyway...
> 
> Indeed. I suspect most of our packages could handle that (autotools, qmake and distutils
> based ones) easily. The big question is:
> 
>   How are we going to do it?
> 
> Are we going to declare another ".dev is broken" period, a branch, a branch with a small
> amount of packages like org.oe.packaged-staging?

I think you are better acquainted with OE bowels to answer your
question. I'd think that the changes here are rather small (in terms of
files affected), actually and can do without a major breakage, but you
never know...

Love,
H

Re: Gstreamer and rpath

[Richard Purdie]

On Thu, 2007-08-02 at 19:00 +0200, Koen Kooi wrote:
> Michael Krelin schreef:
> >> Michael Krelin schreef:
> >>> I'm not taking the symlink workaround seriously, because inventing one
> >>> workaround to get rid of the other isn't going to get us anywhere.
> >> Packaged-staging v1 is using that symlink approach and it doesn't help a lot. Hence the
> >> need for v2 :)
> > 
> > Just about time ;-)
> > 
> > No matter how soon we can move to sysroot approach, I think making
> > staging resemble filesystem is the right thing to do, anyway...
> 
> Indeed. I suspect most of our packages could handle that (autotools, qmake and distutils
> based ones) easily. The big question is:
> 
>   How are we going to do it?
> 
> Are we going to declare another ".dev is broken" period, a branch, a branch with a small
> amount of packages like org.oe.packaged-staging?

I'm actually semi against forcing staging to look like an image. The
fact gcc requires this for its sysroot option is a sign that they
haven't got this right yet.

With packaged staging we need to decide which way we go, separate
staging packages or use the same ones as we use for images.

My personal gut feeling is that separate ones will work better. They
also mean we can handle the extra staging files like pkgmaps and perhaps
handle multi machine easier.

I think if we try to make image packages fit, we'll end up having to
make hack after hack and end up with something less maintainable.

Note this doesn't mean we shouldn't try and simplify package staging
tasks. Ideally I'd like to see one do_install task working for both
staging and the normal packages.

Regards,

Richard

Re: Gstreamer and rpath

[Michael Krelin]

> 
> I'm actually semi against forcing staging to look like an image. The
> fact gcc requires this for its sysroot option is a sign that they
> haven't got this right yet.
> 

Why?

> With packaged staging we need to decide which way we go, separate
> staging packages or use the same ones as we use for images.
> 
> My personal gut feeling is that separate ones will work better. They

So is mine, but...

> also mean we can handle the extra staging files like pkgmaps and perhaps
> handle multi machine easier.
> 
> I think if we try to make image packages fit, we'll end up having to
> make hack after hack and end up with something less maintainable.

why?

Sorry for these vague questions, but it's absolutely unclear to me. I
don't want you to waste your time on elaborating too much on these, but
can you give a hint or two?

Love,
H

Re: Gstreamer and rpath

[Richard Purdie]

On Fri, 2007-08-03 at 00:43 +0200, Michael Krelin wrote:
> > 
> > I'm actually semi against forcing staging to look like an image. The
> > fact gcc requires this for its sysroot option is a sign that they
> > haven't got this right yet.
> > 
> 
> Why?

Well, why should I put libs in a /usr/lib directory rather that /lib? I
know there are guidelines but guidelines are one thing, forcing layouts
is a different thing.

It was once hoped that by changing variables like libdir, bindir, prefix
in bitbake.conf you could change your system layout. People could then
customise their images that way. I realise there are difficulties with
that in practise as some things are hardcoded and it won't work straight
away at present but if we start using the sysroot option I doubt it will
ever work.

> > With packaged staging we need to decide which way we go, separate
> > staging packages or use the same ones as we use for images.
> > 
> > My personal gut feeling is that separate ones will work better. They
> 
> So is mine, but...
> 
> > also mean we can handle the extra staging files like pkgmaps and perhaps
> > handle multi machine easier.
> > 
> > I think if we try to make image packages fit, we'll end up having to
> > make hack after hack and end up with something less maintainable.
> 
> why?

If staging packages can be different to image ones then we won't mind
customising them. If they have to be the same the only way to adjust for
staging will be to do post install tweaking. That feels like a hack.

Cheers,

Richard

Re: Gstreamer and rpath

[Michael Krelin]

>>> I'm actually semi against forcing staging to look like an image. The
>>> fact gcc requires this for its sysroot option is a sign that they
>>> haven't got this right yet.
>>>
>> Why?
> 
> Well, why should I put libs in a /usr/lib directory rather that /lib? I
> know there are guidelines but guidelines are one thing, forcing layouts
> is a different thing.

Good question, thought doesn't have much to do with sysroot facility.
You have exactly the same freedom like you would have with no sysroot,
you're free to install in /usr, in / or in /do-not-enforce-layout/
prefix. The only difference is that you don't have to adjust your paths
to take staging prefix into account and you are not likey to pick up
your host system stuff while compiling.

About getting 'sysroot' right... Doesn't the name imply using in sysroot
the same layout like you would otherwise?

> It was once hoped that by changing variables like libdir, bindir, prefix
> in bitbake.conf you could change your system layout. People could then
> customise their images that way. I realise there are difficulties with
> that in practise as some things are hardcoded and it won't work straight
> away at present but if we start using the sysroot option I doubt it will
> ever work.

And of course you still have your libdir/bindir/prefix, etc.

Love,
H

Re: Gstreamer and rpath

[Richard Purdie]

On Fri, 2007-08-03 at 11:34 +0200, Michael Krelin wrote:
> >>> I'm actually semi against forcing staging to look like an image. The
> >>> fact gcc requires this for its sysroot option is a sign that they
> >>> haven't got this right yet.
> >>>
> >> Why?
> > 
> > Well, why should I put libs in a /usr/lib directory rather that /lib? I
> > know there are guidelines but guidelines are one thing, forcing layouts
> > is a different thing.
> 
> Good question, thought doesn't have much to do with sysroot facility.
> You have exactly the same freedom like you would have with no sysroot,
> you're free to install in /usr, in / or in /do-not-enforce-layout/
> prefix. The only difference is that you don't have to adjust your paths
> to take staging prefix into account and you are not likey to pick up
> your host system stuff while compiling.
>
> About getting 'sysroot' right... Doesn't the name imply using in sysroot
> the same layout like you would otherwise?

No, as I understand it sysroot makes assumptions about where the files
live under it. It assumes "/lib" and "/usr/lib" and its those
assumptions which I dislike. I haven't seen a way to change them but I
could easily be missing something.

If gcc does change them based on the values of prefix, libdir etc when
compiled, that would be a bit better but its still hardcoding things
into the compiler which I don't think should be hardcoded there. Does
anyone know if it adapts to changes in prefix. libdir and friends?

Regards,

Richard

Re: Gstreamer and rpath

[Michael Krelin]

>> About getting 'sysroot' right... Doesn't the name imply using in sysroot
>> the same layout like you would otherwise?
> 
> No, as I understand it sysroot makes assumptions about where the files
> live under it. It assumes "/lib" and "/usr/lib" and its those
> assumptions which I dislike. I haven't seen a way to change them but I
> could easily be missing something.

I think it's not exactly what it assumes. It assumes that what would be
/usr/lib/ without sysroot would be ${sysroot}/usr/lib/

> If gcc does change them based on the values of prefix, libdir etc when
> compiled, that would be a bit better but its still hardcoding things
> into the compiler which I don't think should be hardcoded there. Does
> anyone know if it adapts to changes in prefix. libdir and friends?

I think if you compile it with /opt/gcc prefix it would look in
${sysroot}/opt/gcc for whatever he wants based on his prefix and if you
-I/i-hate-fhs/ it would look into ${sysroot}/i-hate-fhs/

Love,
H
> 
> Regards,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Gstreamer and rpath

[Stanislav Brabec]

Michael Krelin píše v Ne 05. 08. 2007 v 18:27 +0200:
> >> About getting 'sysroot' right... Doesn't the name imply using in sysroot
> >> the same layout like you would otherwise?
> > 
> > No, as I understand it sysroot makes assumptions about where the files
> > live under it. It assumes "/lib" and "/usr/lib" and its those
> > assumptions which I dislike. I haven't seen a way to change them but I
> > could easily be missing something.
> 
> I think it's not exactly what it assumes. It assumes that what would be
> /usr/lib/ without sysroot would be ${sysroot}/usr/lib/
> 
> > If gcc does change them based on the values of prefix, libdir etc when
> > compiled, that would be a bit better but its still hardcoding things
> > into the compiler which I don't think should be hardcoded there. Does
> > anyone know if it adapts to changes in prefix. libdir and friends?
> 
> I think if you compile it with /opt/gcc prefix it would look in
> ${sysroot}/opt/gcc for whatever he wants based on his prefix and if you
> -I/i-hate-fhs/ it would look into ${sysroot}/i-hate-fhs/

Yes, --sysroot prefixes all -I and -L and similar paths with sysroot
value. But it does not touch other paths, so -DUGLYPATH="/i-hate-fhs" or
-Wl,-rpath -Wl,/i-hate-fhs will remain untouched. It is what one should
expect - only compile-time paths are changes.


________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utxzaurus

Re: Gstreamer and rpath

[Stanislav Brabec]

Richard Purdie wrote:

> I'm actually semi against forcing staging to look like an image. The
> fact gcc requires this for its sysroot option is a sign that they
> haven't got this right yet.
> 
> With packaged staging we need to decide which way we go, separate
> staging packages or use the same ones as we use for images.
> 
> My personal gut feeling is that separate ones will work better. They
> also mean we can handle the extra staging files like pkgmaps and perhaps
> handle multi machine easier.

Well, the point of gcc --sysroot is a simplification of cross
compilation for those using complete sysroot environment.

Maybe we have a good reason to not use sysroot, but then we have to
invent a different solution.

Manual enabling/disabling rpath is a bad solution. Better solutions is a
compiler wrapper knowing our rewrite rules.

For example:
arm-angstrom-gueabi-gcc -I/usr/include/ssl -L/usr/lib/purple-2 -loscar -lm
may be rewritten for example to:
arm-angstrom-gueabi-gcc -nostdinc -nostdlib -L/path/to/staging/platform/lib -L/path/to/staging/model/lib -I/path/to/staging/noarch/include -I/path/to/staging/platform/include -L/path/to/staging/model/include -I/path/to/staging/platform/include/ssl -I/path/to/staging/model/include/ssl -L/path/to/staging/platform/lib/purple-2 -L/path/to/staging/model/lib/purple-2 -loscar -lm

Such wrapper must not modify rpath, -D and other arguments with paths.

But for example AC_CHECK_FILE modification to work with such structure
would be complicated.

But maybe there is possible to invent better method than the sysroot
design is.


A random idea:

Define TARGET_ROOT_MAP, which may use similar syntax like overlay
filesystems have. It will allow to construct sysroot by these
filesystems on fly as well, e. g. for use with emulators.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec@suse.cz
Lihovarská 1060/12                            tel: +420 284 028 966
190 00 Praha 9                                fax: +420 284 028 951
Czech Republic                                http://www.suse.cz/

Re: Gstreamer and rpath

[Richard Purdie]

On Fri, 2007-08-03 at 11:21 +0200, Stanislav Brabec wrote:
> Richard Purdie wrote:
> 
> > I'm actually semi against forcing staging to look like an image. The
> > fact gcc requires this for its sysroot option is a sign that they
> > haven't got this right yet.
> > 
> > With packaged staging we need to decide which way we go, separate
> > staging packages or use the same ones as we use for images.
> > 
> > My personal gut feeling is that separate ones will work better. They
> > also mean we can handle the extra staging files like pkgmaps and perhaps
> > handle multi machine easier.
> 
> Well, the point of gcc --sysroot is a simplification of cross
> compilation for those using complete sysroot environment.

Yes, I understand that and I appreciate it does solve a certain mount of
the problem! I just think it could be better and that it isn't a "solves
everything" solution for OE.

> But maybe there is possible to invent better method than the sysroot
> design is.
> 
> A random idea:
> 
> Define TARGET_ROOT_MAP, which may use similar syntax like overlay
> filesystems have. It will allow to construct sysroot by these
> filesystems on fly as well, e. g. for use with emulators.

That would be a much nicer solution. Staging could them have its own
mapping and it should solve most of the problems we see. Have you any
idea how difficult that would be to implement?

Regards,

Richard

Re: Gstreamer and rpath

[Stanislav Brabec]

Richard Purdie wrote: 

> > A random idea:
> > 
> > Define TARGET_ROOT_MAP, which may use similar syntax like overlay
> > filesystems have. It will allow to construct sysroot by these
> > filesystems on fly as well, e. g. for use with emulators.
> 
> That would be a much nicer solution. Staging could them have its own
> mapping and it should solve most of the problems we see. Have you any
> idea how difficult that would be to implement?

I guess that a short time solution would be a wrapper script on top of
gcc - applications will call this wrapper, it will rewrite command line
arguments and then call gcc. It could also work with older versions of
gcc without any backporting.

Long time solution would be implementing this upstream in gcc and all
automake checks.

I guess that there is several use cases, where target-root-map would be
more flexible than sysroot: noarch<platform<model (used in OE) and
basesystem_root<addon_root.

I am not sure, whether libtool will require modifications or not.


________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: Gstreamer and rpath

[Michael Krelin]

>> A random idea:
>>
>> Define TARGET_ROOT_MAP, which may use similar syntax like overlay
>> filesystems have. It will allow to construct sysroot by these
>> filesystems on fly as well, e. g. for use with emulators.
> 
> That would be a much nicer solution. Staging could them have its own
> mapping and it should solve most of the problems we see. Have you any
> idea how difficult that would be to implement?

I don't see how this random idea could be easily implemented (well, I
have to admit I haven't really given it a thought), but it serves a
perfect explanation why we can't go for sysroot at the moment and
probably anytime soon... Unfortunately, I think I'm convinced.

Love,
H

Re: Gstreamer and rpath

[Stanislav Brabec]

Michael Krelin wrote:
> >> A random idea:
> >>
> >> Define TARGET_ROOT_MAP, which may use similar syntax like overlay
> >> filesystems have. It will allow to construct sysroot by these
> >> filesystems on fly as well, e. g. for use with emulators.
> > 
> > That would be a much nicer solution. Staging could them have its own
> > mapping and it should solve most of the problems we see. Have you any
> > idea how difficult that would be to implement?
> 
> I don't see how this random idea could be easily implemented (well, I
> have to admit I haven't really given it a thought), but it serves a
> perfect explanation why we can't go for sysroot at the moment and
> probably anytime soon... Unfortunately, I think I'm convinced.

Instead of defining
CC="my-platform-gcc"
we can define
CC="wrap-compile-time-paths my-platform-gcc"

All OE recipes already handle CC. We will only change cross-CC (and
similar) values. If recipes don't use buggy quoting, it will work out of
the box. Autoconf and friends handle CC string with spaces without any
problems.

Writing of wrap-compile-time-paths should be easy - I guess no more than
30 lines of bash code. Maybe I would prefer pure Bourne shell + sed or C
to make such code acceptable for upstream autoconf.

It looks like gcc implementation of sysroot does following things:
- Search some compiler stuff in sysroot.
- Add sysroot to all includes paths including default system paths
- Add sysroot to all library paths including default system paths
- Pass it to the linker, if it supports it.

Linker uses sysroot as well - it is able to strip it from certain paths.
Its use may be platform specific there.

I am still not sure, how correct will be binaries created by upper
mentioned wrappers, but it will be for sure better than the
libtool-level hack. And it's easy to catch remaining references by QA
scripts.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: Gstreamer and rpath

[Michael Krelin]

> I am still not sure, how correct will be binaries created by upper
> mentioned wrappers, but it will be for sure better than the
> libtool-level hack. And it's easy to catch remaining references by QA
> scripts.

You mostly make a lot of sense, but sometimes I'm puzzled by your
statements. You're not sure whether binaries will be correct, but for
sure better than correct ones made the way you personally (and for
reason) dislike?


Love,
H

Re: Gstreamer and rpath

[Stanislav Brabec]

Michael Krelin wrote:
> > I am still not sure, how correct will be binaries created by upper
> > mentioned wrappers, but it will be for sure better than the
> > libtool-level hack. And it's easy to catch remaining references by QA
> > scripts.
> 
> You mostly make a lot of sense, but sometimes I'm puzzled by your
> statements. You're not sure whether binaries will be correct, but for
> sure better than correct ones made the way you personally (and for
> reason) dislike?

To be exact:

I tried to create a binary + library loaded with use of rpath using
"libtool ...-gcc --sysroot ..." option instead of current approach.

Library was properly find and loaded after copying to my Zaurus.

I got some references into sysroot path in debug section, no reference
in stripped code, no reference in .la files.

After stripping binaries and library, there was no reference to sysroot
any more.

I did not do further research on references in debug section. It's
required to check, whether debug info is correct.

Overall, it looks like better result than the current solution.

I did not yet wrote the wrapper, so I don't know, whether the result
will be as good as gcc --sysroot.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: Gstreamer and rpath

[Dr. Michael Lauer]

Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> Stanislav Brabec schreef:
>> Philip Balister wrote:
>> 
>>> Is --sysroot present in all versions of gcc? If not, which version does 
>>> it first appear?
>> 
>> 3.3.3 has not it yet.
>> 
>> gcc/ChangeLog.2005:
>> 2005-07-25  Mark Mitchell  <mark@codesourcery.com>
>> 
>>       * gcc.c (option_map): Add --sysroot.
>> 
>> Michael Krelin wrote:
>> 
>>> I think starting with 3.4, another reason why this idea maybe not yet
>>> viable...
>> 
>> I see no problem here: For cross compilation OE compiles its own
>> compiler, which already supports --sysroot,

> No. We have a gcc-cross_3.3.3.bb and 3.3.4

I wouldn't mind deprecating these two.

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: Gstreamer and rpath

[Mike (mwester)]

----- Original Message ----- 
From: "Dr. Michael Lauer" <mickey@vanille-media.de>
To: <openembedded-devel@lists.openembedded.org>
Sent: Sunday, August 05, 2007 12:55 AM
Subject: Re: [oe] Gstreamer and rpath


>  > No. We have a gcc-cross_3.3.3.bb and 3.3.4
> 
> I wouldn't mind deprecating these two.

3.3.4 is still in use, if only in a maintenance mode.

Mike (mwester)

Re: Gstreamer and rpath

[Dr. Michael Lauer]

Mike (mwester) wrote:
> ----- Original Message ----- 
> From: "Dr. Michael Lauer" <mickey@vanille-media.de>
> To: <openembedded-devel@lists.openembedded.org>
> Sent: Sunday, August 05, 2007 12:55 AM
> Subject: Re: [oe] Gstreamer and rpath


>>  > No. We have a gcc-cross_3.3.3.bb and 3.3.4
>> 
>> I wouldn't mind deprecating these two.

> 3.3.4 is still in use, if only in a maintenance mode.

Can't we backport the sysroot patch?

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: Gstreamer and rpath

[Michael Krelin]

> Michael Krelin wrote:
>>> Michael Krelin wrote:
>>>> I don't know much about gstreamer, but being inventor of
>>>> OE_LT_RPATH_ALLOW I felt obliged to look into gst-plugins.inc and I'm
>>>> guessing it should be:
>>> Maybe it would be better to not break build environment and then work
>>> around consequent errors by hacks like OE_LT_RPATH_ALLOW,
>>> never-ever-do-rpath.patch etc.
>>>
>>> gcc has --sysroot which can do required linking without any hacks.
>>>
>> Generally, I tend to agree, but in practice I'm afraid that would amount
>> to rewriting the whole OE...
> 
> No.
> 
> 1. and 2. and 4. should be change of about 20 lines (change xxxx_CC from
> e. g. "arm-angstrom-linux-gnueabi-gcc" to e. g.
> "arm-angstrom-linux-gnueabi-gcc --sysroot=/OE/build/tmp/staging/arm-angstrom-linux-gnueabi").
> I only could not find correct lines.

staging doesn't resemble root filesystem, to begin with. So that would
involve rearranging staging as well. Which is again a good idea, but
would take longer that it sounds in pure theory.

Love,
H

> 
> If anybody tell me the correct location, I can do test bootstrap with
> the new options.
> 
> 5. is low priority, after 4. it will become NOP
> 
> 6. Is already done, it should be enough to change check pattern in the
> QA stuff.
> 
> 3. and 7. break packages (e. g. findutils) not depending on CC
> definition and has to be fixed manually anyway.
> 
> And if 8. will be done (in far future), most individual fixes in 7.
> could be removed.
> 

Re: Gstreamer and rpath

[Koen Kooi]

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

Michael Krelin schreef:
>> Michael Krelin wrote:
>>>> Michael Krelin wrote:
>>>>> I don't know much about gstreamer, but being inventor of
>>>>> OE_LT_RPATH_ALLOW I felt obliged to look into gst-plugins.inc and I'm
>>>>> guessing it should be:
>>>> Maybe it would be better to not break build environment and then work
>>>> around consequent errors by hacks like OE_LT_RPATH_ALLOW,
>>>> never-ever-do-rpath.patch etc.
>>>>
>>>> gcc has --sysroot which can do required linking without any hacks.
>>>>
>>> Generally, I tend to agree, but in practice I'm afraid that would amount
>>> to rewriting the whole OE...
>> No.
>>
>> 1. and 2. and 4. should be change of about 20 lines (change xxxx_CC from
>> e. g. "arm-angstrom-linux-gnueabi-gcc" to e. g.
>> "arm-angstrom-linux-gnueabi-gcc --sysroot=/OE/build/tmp/staging/arm-angstrom-linux-gnueabi").
>> I only could not find correct lines.
> 
> staging doesn't resemble root filesystem, to begin with. So that would
> involve rearranging staging as well. Which is again a good idea, but
> would take longer that it sounds in pure theory.

May I direct everybodies attention to
http://lists.linuxtogo.org/pipermail/openembedded-devel/2007-July/002636.html ?

regards,

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

iD8DBQFGsdbCMkyGM64RGpERAqEKAKCtBJWjsmvC1SVtbT1uXAkzyDydxQCgsKoL
zkZowRtburFE4qiXELz5h+Q=
=Ij7y
-----END PGP SIGNATURE-----