Re: Openembedded-devel Digest, Vol 43, Issue 98

Re: Openembedded-devel Digest, Vol 43, Issue 98

[Jay Snyder]

>
>
> try the following:
> TARGET_CC_ARCH += "${LDFLAGS}"
> This should resolve your problems if you build your executable from
> within your OE buildsystem.
> In very rare cases (e.g. when you build some programs outside of OE
> but use OE to package all) it could be useful to use the following:
> INSANE_SKIP_objc = "True"
> AFAIK that sould not be commonly used, but it worked for me.
>
> majo
>

Updating my GCC recipe with a "git pull" worked (the INSANE_SKIP_obj 
line got added sometime recently).

The TARGET_CC_ARCH += "${LDFLAGS}"  fix is the first thing that I try 
when i get this problem, and usually fixes it, although there are some 
packages that required patching Makefile.ac files throughout the 
project.     As I just stated in another reply, when I get beyond the 
current project time crunch (coming up on a release deadline), I will 
submit my recipe patches for inclusion in the OE git repository.

Thanks,
Jay

reply to digest mails, was: Re: Openembedded-devel Digest, Vol 43, Issue 98

[Koen Kooi]

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

Hi,

When you receive a digest mail it tells you to change the subject line
to something non-bogus. Please do so in the future.

If it turns out tha that is too hard for people we can consider turning
off digests.


On 23-02-10 14:47, Jay Snyder wrote:
>>
>>
>> try the following:
>> TARGET_CC_ARCH += "${LDFLAGS}"
>> This should resolve your problems if you build your executable from
>> within your OE buildsystem.
>> In very rare cases (e.g. when you build some programs outside of OE
>> but use OE to package all) it could be useful to use the following:
>> INSANE_SKIP_objc = "True"
>> AFAIK that sould not be commonly used, but it worked for me.
>>
>> majo
>>
> 
> Updating my GCC recipe with a "git pull" worked (the INSANE_SKIP_obj
> line got added sometime recently).
> 
> The TARGET_CC_ARCH += "${LDFLAGS}"  fix is the first thing that I try
> when i get this problem, and usually fixes it, although there are some
> packages that required patching Makefile.ac files throughout the
> project.     As I just stated in another reply, when I get beyond the
> current project time crunch (coming up on a release deadline), I will
> submit my recipe patches for inclusion in the OE git repository.
> 
> Thanks,
> Jay

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

iD8DBQFLg+0vMkyGM64RGpERAoELAKCTgm09I1gjcpAGVfd4CcTpD6WE7wCfdJ/k
spNEAoXQJqueAMXjoPCgqS8=
=Kt9W
-----END PGP SIGNATURE-----

Re: reply to digest mails, was: Re: Openembedded-devel Digest, Vol 43, Issue 98

[Philip Balister]

On 02/23/2010 06:58 AM, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> When you receive a digest mail it tells you to change the subject line
> to something non-bogus. Please do so in the future.
>
> If it turns out tha that is too hard for people we can consider turning
> off digests.

I tend to delete emails with the subject only containing digest info. 
I'm sure there are a few people who need the digests and no sense making 
life harder for them because of the actions of a few people.

Philip


>
>
> On 23-02-10 14:47, Jay Snyder wrote:
>>>
>>>
>>> try the following:
>>> TARGET_CC_ARCH += "${LDFLAGS}"
>>> This should resolve your problems if you build your executable from
>>> within your OE buildsystem.
>>> In very rare cases (e.g. when you build some programs outside of OE
>>> but use OE to package all) it could be useful to use the following:
>>> INSANE_SKIP_objc = "True"
>>> AFAIK that sould not be commonly used, but it worked for me.
>>>
>>> majo
>>>
>>
>> Updating my GCC recipe with a "git pull" worked (the INSANE_SKIP_obj
>> line got added sometime recently).
>>
>> The TARGET_CC_ARCH += "${LDFLAGS}"  fix is the first thing that I try
>> when i get this problem, and usually fixes it, although there are some
>> packages that required patching Makefile.ac files throughout the
>> project.     As I just stated in another reply, when I get beyond the
>> current project time crunch (coming up on a release deadline), I will
>> submit my recipe patches for inclusion in the OE git repository.
>>
>> Thanks,
>> Jay
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFLg+0vMkyGM64RGpERAoELAKCTgm09I1gjcpAGVfd4CcTpD6WE7wCfdJ/k
> spNEAoXQJqueAMXjoPCgqS8=
> =Kt9W
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: reply to digest mails, was: Re: Openembedded-devel Digest, Vol 43, Issue 98

[Petr Štetiar]

Philip Balister <philip@balister.org> [2010-02-23 14:37:18]:

> On 02/23/2010 06:58 AM, Koen Kooi wrote:
>>
>> If it turns out tha that is too hard for people we can consider turning
>> off digests.
>
> I tend to delete emails with the subject only containing digest info.  
> I'm sure there are a few people who need the digests and no sense making  
> life harder for them because of the actions of a few people.

Maybe it would be more friendly to learn mailman rejecting emails with
"Digest" in subject...

-- ynezz

Re: Openembedded-devel Digest, Vol 43, Issue 98

[Khem Raj]

On Tue, Feb 23, 2010 at 5:47 AM, Jay Snyder
<jay.snyder@tycoelectronics.com> wrote:
>>
>>
>> try the following:
>> TARGET_CC_ARCH += "${LDFLAGS}"
>> This should resolve your problems if you build your executable from
>> within your OE buildsystem.
>> In very rare cases (e.g. when you build some programs outside of OE
>> but use OE to package all) it could be useful to use the following:
>> INSANE_SKIP_objc = "True"
>> AFAIK that sould not be commonly used, but it worked for me.
>>
>> majo
>>
>
> Updating my GCC recipe with a "git pull" worked (the INSANE_SKIP_obj line
> got added sometime recently).
>
> The TARGET_CC_ARCH += "${LDFLAGS}"  fix is the first thing that I try when i
> get this problem, and usually fixes it, although there are some packages
> that required patching Makefile.ac files throughout the project.

if you have a list of packages that would be helpful. Generally
packages should respect
LDFLAGS if they dont then probably they should be fixed.

    As I
> just stated in another reply, when I get beyond the current project time
> crunch (coming up on a release deadline), I will submit my recipe patches
> for inclusion in the OE git repository.

Thats nice.

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

Re: Openembedded-devel Digest, Vol 43, Issue 98

[Chris Larson]

It's worth noting here that TARGET_CC_ARCH += "${LDFLAGS}" is a hack,
not an ideal solution.   The preferred way of solving this is
reviewing the buildsystem in question to determine how best to make it
obey all of our bitbake variables, rather than injecting one into
another that it happens to already obey.

On Tue, Feb 23, 2010 at 11:15 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, Feb 23, 2010 at 5:47 AM, Jay Snyder
> <jay.snyder@tycoelectronics.com> wrote:
>>>
>>>
>>> try the following:
>>> TARGET_CC_ARCH += "${LDFLAGS}"
>>> This should resolve your problems if you build your executable from
>>> within your OE buildsystem.
>>> In very rare cases (e.g. when you build some programs outside of OE
>>> but use OE to package all) it could be useful to use the following:
>>> INSANE_SKIP_objc = "True"
>>> AFAIK that sould not be commonly used, but it worked for me.
>>>
>>> majo
>>>
>>
>> Updating my GCC recipe with a "git pull" worked (the INSANE_SKIP_obj line
>> got added sometime recently).
>>
>> The TARGET_CC_ARCH += "${LDFLAGS}"  fix is the first thing that I try when i
>> get this problem, and usually fixes it, although there are some packages
>> that required patching Makefile.ac files throughout the project.
>
> if you have a list of packages that would be helpful. Generally
> packages should respect
> LDFLAGS if they dont then probably they should be fixed.
>
>     As I
>> just stated in another reply, when I get beyond the current project time
>> crunch (coming up on a release deadline), I will submit my recipe patches
>> for inclusion in the OE git repository.
>
> Thats nice.
>
>>
>> Thanks,
>> Jay
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: Openembedded-devel Digest, Vol 43, Issue 98

[Khem Raj]

On Tue, Feb 23, 2010 at 10:19 AM, Chris Larson <clarson@kergoth.com> wrote:
> It's worth noting here that TARGET_CC_ARCH += "${LDFLAGS}" is a hack,
> not an ideal solution.

right.

The preferred way of solving this is
> reviewing the buildsystem in question to determine how best to make it
> obey all of our bitbake variables, rather than injecting one into
> another that it happens to already obey.

We (OE) are the one's who will suffer this most because other
distributions force gcc to implicitly
emit this option while invoking linker so they bypass the problem in
bulk of packages.

Re: Openembedded-devel Digest, Vol 43, Issue 98

[Chris Larson]

On Tue, Feb 23, 2010 at 11:39 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, Feb 23, 2010 at 10:19 AM, Chris Larson <clarson@kergoth.com> wrote:
>> It's worth noting here that TARGET_CC_ARCH += "${LDFLAGS}" is a hack,
>> not an ideal solution.
>
> right.
>
> The preferred way of solving this is
>> reviewing the buildsystem in question to determine how best to make it
>> obey all of our bitbake variables, rather than injecting one into
>> another that it happens to already obey.
>
> We (OE) are the one's who will suffer this most because other
> distributions force gcc to implicitly
> emit this option while invoking linker so they bypass the problem in
> bulk of packages.

Ah, I didn't realize that, thanks for the info :)
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics