That's testing for offline installation. If $D is not set, it's running on the
target.
p.
On 25 August 2021 22:12:22 BST, "Robert P. J. Day"
wrote:
>
>Quoting Alexander Kanavin :
>
>> If you show the confusing examples, we could try to figure it out.
>>
>> Alex
>>
>> On Wed, 25 Aug 2021 at
On Mon, Jun 28, 2021 at 02:10:39PM -0700, Khem Raj wrote:
> well, if we can beat the compiler to not complain about using neon on a
> non-neon system then yes, but changing float ABI to make compiler happy
> seems a bit iffy, since compiler will generate code expecting VFP and that
> could trip
On Mon, Jun 28, 2021 at 12:42:55PM -0700, Khem Raj wrote:
> On Mon, Jun 28, 2021 at 12:10 PM Phil Blundell wrote:
> >
> > On Mon, Jun 28, 2021 at 11:46:08AM -0700, Khem Raj wrote:
> > > I still hope that if we can add a proper neon detection patch to meson
> > > they would be ok to accept it.
> >
On Mon, Jun 28, 2021 at 11:46:08AM -0700, Khem Raj wrote:
> I still hope that if we can add a proper neon detection patch to meson
> they would be ok to accept it.
Why doesn't the runtime detection work in the way that upstream clearly
think it ought to?
p.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You
Wouldn't it be easier to just force -fPIE on for those users for whom this is a
problem? Or force -fPIE off for native everywhere. I'm not sure that doing
something based on GCC version is obviously the right plan.
p.
On 7 June 2021 22:25:58 BST, bkyleruss...@gmail.com wrote:
>By having
On Thu, Feb 11, 2021 at 01:05:20PM +0100, Martin Jansa wrote:
> Or you can read it as that it makes sense to build mesa recipe only when
> DISTRO supports opengl or vulkan or opengles,
It's never been the intent of DISTRO_FEATURES to determine which recipes
it "makes sense" to build, above and
On Fri, Dec 04, 2020 at 08:30:01AM -0500, Sinan Kaya wrote:
> +Richard,
>
> On 12/4/2020 6:01 AM, Phil Blundell via lists.openembedded.org wrote:
> > On Thu, Dec 03, 2020 at 11:28:24PM +, Sinan Kaya wrote:
> >> This subclass allows us to easily split a reci
On Thu, Dec 03, 2020 at 11:28:24PM +, Sinan Kaya wrote:
> This subclass allows us to easily split a recipe into
> subpackages.
"lib_subpackage" seems a slightly odd name for something that isn't
dealing with libraries. What's the etymology of that?
> +d.appendVar("PACKAGES", " " + "
On Thu, Dec 03, 2020 at 05:35:23PM -0500, Trevor Woerner wrote:
> On Thu, Dec 3, 2020 at 5:25 PM Phil Blundell wrote:
>
> > If we're talking about OpenGLES applications, wouldn't you already have
> > opengl in DISTRO_FEATURES?
> >
>
> Not necessarily.
>
> Adding opengl to DISTRO_FEATURES
If we're talking about OpenGLES applications, wouldn't you already have opengl
in DISTRO_FEATURES?
I'm not sure it makes a lot of sense to introduce a check for dispmanx to
oe-core if nothing in oe-core ever defines that feature.
p.
On 3 December 2020 13:35:26 GMT, Trevor Woerner wrote:
On Thu, Jun 04, 2020 at 01:05:30PM -0700, Andre McCurdy wrote:
> The fix being proposed is simply to always leave the config file in
> the rootfs, so it's always there when ldconfig is run at build time.
> Doing so seems safe enough. Since the config file is only parsed by
> ldconfig, there's no
On Tue, Jun 02, 2020 at 09:17:44PM +0100, Richard Purdie wrote:
> I understand the concern, I am a little torn on this as adding in too
> many different controls and options complicates the test matrix and
> makes things harder for users.
>
> You're effectively suggesting a new DISTRO_FEATURE to
On Tue, Jun 02, 2020 at 02:17:22PM +0200, Rasmus Villemoes wrote:
> In case of a read-only rootfs, one could add some logic to remove them
> if one really wants to shave those few dozens of bytes off.
Note that there's also a slight runtime performance penalty associated
with having these files
On Tue, Jun 02, 2020 at 09:43:45PM +0200, Gregor Zatko wrote:
> - if you take a look at
> http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/tree/update-alternatives
> you'll simply see it's a shellscript; if we wanted to have it without
> bash we'd need a C++
> implementation, am I right?
No,
On Tue, Jun 02, 2020 at 09:09:25PM +0200, Gregor Zatko wrote:
> In some cases there is a need for update-alternatives script which gets built
> within opkg-utils recipe into a standalone package. However, this causes to
> many unnecessary dependencies, including Python, bc, OpenSSL etc. to be
On Thu, May 28, 2020 at 10:38:15AM -0700, Andre McCurdy wrote:
> And where does it leave OLDEST_KERNEL (currently set to 3.2.0)? If
> even kernel 4.1 is too old to be used with OE master then
> OLDEST_KERNEL looks like it should be updated to avoid giving users
> with older kernels false hope.
On Thu, May 28, 2020 at 12:30:13PM -0700, Andre McCurdy wrote:
> What I was trying to get at is why you felt that bringing up the fact
> the kernel 4.1 was released at around the time gcc 5 was current is
> important?
Agreed, I think this is a red herring. One of my current targets is
in fact
On Wed, May 27, 2020 at 05:02:00PM -0700, Khem Raj wrote:
> https://github.com/torvalds/linux/commit/052876f8e5aec887d22c4d06e54aa5531ffcec75
>
> this change e.g. in userspace checks for UINPUT_VERSION and decides to
> use one method
> or legacy to setup the device but this is really not gonna
On Wed, May 27, 2020 at 02:46:24PM -0700, Khem Raj wrote:
> and building userspace against way newer kernel-headers with older
> kernel underneath has unintended
> consequences.
Can you be more specific? If this doesn't work, it's just a bug and
should be fixed. What problems are you having?
On Mon, May 18, 2020 at 02:12:43PM +0200, Rasmus Villemoes wrote:
> I'm certainly open to other ways of solving this. But can we agree that
> it is a bug that the ldconfig done at build-time does not take
> /etc/ld.so.conf.d/* into account, and that that should not depend on
> whether one has
20 matches
Mail list logo
