* Re: sstate_clean() overzealous?
From: Khem Raj @ 2011-10-03 21:18 UTC (permalink / raw)
To: McClintock Matthew-B29882,
Patches and discussions about the oe-core layer
In-Reply-To: <CAEsOVNcZbs3TBQiBYnpzk4UgbfSwFYNHfkChhjN3FOcjnp4qUw@mail.gmail.com>
On 10/3/2011 2:11 PM, McClintock Matthew-B29882 wrote:
> On Mon, Oct 3, 2011 at 11:47 AM, Phil Blundell<philb@gnu.org> wrote:
>> The sstate_clean() function in sstate.bbclass is doing (inter alia):
>>
>> stfile = d.getVar("STAMP", True) + ".do_" + ss['task']
>> [...]
>> oe.path.remove(stfile + ".*")
>> oe.path.remove(stfile + "_setscene" + ".*")
>>
>> which means that, for tasks which set the stamp-extra-info flag to
>> ${MACHINE}, it ends up blowing away the stamps for all machines rather
>> than just the current one. The net effect of this seems to be that
>> there is no way to have the setscene stamps populated for more than one
>> MACHINE at any time, and hence all those tasks get rerun every time you
>> change MACHINE even if nothing else has been altered.
>>
>> Is this behaviour deliberate? It is certainly a little bit annoying but
>> I don't understand the internals of sstate well enough to judge what
>> exactly that glob is trying to accomplish.
>
> I've noticed that changing the MACHINE will also invalidate the
> -native stuff as well.
hmmm so we can not share sstate parts for two machines in same tmpdir ?
>
> -M
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [PATCH v2 10/16] Fix mdadm for powerpc64
From: Khem Raj @ 2011-10-03 21:17 UTC (permalink / raw)
To: McClintock Matthew-B29882,
Patches and discussions about the oe-core layer
In-Reply-To: <CAEsOVNcvCgboed7tx68aT_CemeN_pVd_k0JM_cWVDiMtRrCG0w@mail.gmail.com>
On 10/3/2011 2:14 PM, McClintock Matthew-B29882 wrote:
> On Mon, Oct 3, 2011 at 2:22 PM, Khem Raj<raj.khem@gmail.com> wrote:
>>> -PR = "r0"
>>> +PR = "r1"
>>>
>>> SRC_URI =
>>> "${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.bz2"
>>>
>>> @@ -16,6 +16,7 @@ SRC_URI[md5sum] = "12ee2fbf3beddb60601fb7a4c4905651"
>>> SRC_URI[sha256sum] =
>>> "0d1a04e688b082bc88846e3f524abd50bc782b6ffc06123140f7d358c8f9b906"
>>>
>>> CFLAGS += "-fno-strict-aliasing"
>>> +EXTRA_OEMAKE_append_powerpc64 = "CXFLAGS=-Wno-error=format"
>>>
>>> inherit autotools
>>>
>>
>> what kind of errors do you get ? and I wonder why they dont show up on
>> x86_64. It may be something to fix in the madadm code.
>
> I can't find a log of this anywhere, it's probably the default
> compiler warnings for our platform are different?
It would be handy to understand them since I dont see gcc
differentiating formats between ppc64 and x86_64 which both are 64bit
hosts. But obviously there is something missing.
>
> You could try enabling those errors and see if your build fails:
If I had a ppc64 build around
>
> EXTRA_OEMAKE_append_x86-64 = "CXFLAGS=-Werror=format"
>
> -M
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: sstate_clean() overzealous?
From: McClintock Matthew-B29882 @ 2011-10-03 21:11 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317660469.13337.16.camel@phil-desktop>
On Mon, Oct 3, 2011 at 11:47 AM, Phil Blundell <philb@gnu.org> wrote:
> The sstate_clean() function in sstate.bbclass is doing (inter alia):
>
> stfile = d.getVar("STAMP", True) + ".do_" + ss['task']
> [...]
> oe.path.remove(stfile + ".*")
> oe.path.remove(stfile + "_setscene" + ".*")
>
> which means that, for tasks which set the stamp-extra-info flag to
> ${MACHINE}, it ends up blowing away the stamps for all machines rather
> than just the current one. The net effect of this seems to be that
> there is no way to have the setscene stamps populated for more than one
> MACHINE at any time, and hence all those tasks get rerun every time you
> change MACHINE even if nothing else has been altered.
>
> Is this behaviour deliberate? It is certainly a little bit annoying but
> I don't understand the internals of sstate well enough to judge what
> exactly that glob is trying to accomplish.
I've noticed that changing the MACHINE will also invalidate the
-native stuff as well.
-M
^ permalink raw reply
* Re: [PATCH v2 10/16] Fix mdadm for powerpc64
From: McClintock Matthew-B29882 @ 2011-10-03 21:14 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E8A0B81.1080507@gmail.com>
On Mon, Oct 3, 2011 at 2:22 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> -PR = "r0"
>> +PR = "r1"
>>
>> SRC_URI =
>> "${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.bz2"
>>
>> @@ -16,6 +16,7 @@ SRC_URI[md5sum] = "12ee2fbf3beddb60601fb7a4c4905651"
>> SRC_URI[sha256sum] =
>> "0d1a04e688b082bc88846e3f524abd50bc782b6ffc06123140f7d358c8f9b906"
>>
>> CFLAGS += "-fno-strict-aliasing"
>> +EXTRA_OEMAKE_append_powerpc64 = "CXFLAGS=-Wno-error=format"
>>
>> inherit autotools
>>
>
> what kind of errors do you get ? and I wonder why they dont show up on
> x86_64. It may be something to fix in the madadm code.
I can't find a log of this anywhere, it's probably the default
compiler warnings for our platform are different?
You could try enabling those errors and see if your build fails:
EXTRA_OEMAKE_append_x86-64 = "CXFLAGS=-Werror=format"
-M
^ permalink raw reply
* Re: [RFC] .la files cleanup
From: Khem Raj @ 2011-10-03 20:28 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1317653702.13337.4.camel@phil-desktop>
On 10/3/2011 7:55 AM, Phil Blundell wrote:
> On Mon, 2011-10-03 at 14:58 +0400, Dmitry Eremin-Solenikov wrote:
>> My proposal would be to include a special task or a
>> do_install_append() part that
>> will remove specified .la files. (like ${libdir}/xorg/modules/*/.la,
>> ${libdir}/matchbox-panel/*.la, etc.). I see this usually done in
>> do_install or in special do_install_append
>> parts, but I think it would be better to handle this globally.
>
> I guess the ideal solution would be to find a way to stop libtool from
> installing these things in the first place. It isn't totally obvious to
> me that the .la files are a net benefit even for real shared libraries,
> and for plugins I think they are probably a net loss in most/all cases.
>
I also have this opinion. I think we need to experiment by not
installing .la at all and see what breaks. I would guess very little
> When this issue last came up it seemed that Richard's preferred fix was
> to just ship the .la files in FILES_${PN}-dev, and I guess that approach
> does at least have the merit of simplicity. See:
>
> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-July/005533.html
>
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [PATCH 02/13] xserver-xf86-dri-lite: remove COMPATIBLE_HOST
From: Khem Raj @ 2011-10-03 20:10 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <c341f97c3102144d6ae36e6669c69905ac9de240.1317367429.git.Martin.Jansa@gmail.com>
On 9/30/2011 12:27 AM, Martin Jansa wrote:
> * ie om-gta02 has mesa-dri module too
>
> Signed-off-by: Martin Jansa<Martin.Jansa@gmail.com>
> ---
> .../xorg-xserver/xserver-xf86-dri-lite.inc | 3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc b/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc
> index 093e049..2e35917 100644
> --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc
> +++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc
> @@ -10,6 +10,3 @@ EXTRA_OECONF += "\
> --with-pic \
> --with-int10=x86emu \
> "
> -
> -# Due to mesa-dri
> -COMPATIBLE_HOST = '(i.86.*-linux|x86_64.*-linux)'
how about powerpc and mips ? they will also become supported with this
change have you tested that
^ permalink raw reply
* Re: [PATCH] eglibc-2.14: add patch to fix libdl crash
From: Khem Raj @ 2011-10-03 19:47 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1317634209-3154-1-git-send-email-mokml@mnet-online.de>
On 10/3/2011 2:30 AM, mokml@mnet-online.de wrote:
> From: Klaus Kurzmann<mok@fluxnetz.de>
>
> * Without this patch programs using alsa-lib crash (alsamixer for example).
> * This patch is taken verbatim from ArchLinux.
>
can you add appropriate header for this?
secondly this reverts the license year text
from 2011 to 2010 that should not be needed.
> Signed-off-by: Klaus Kurzmann<mok@fluxnetz.de>
> ---
> .../eglibc-2.14/glibc-2.14-libdl-crash.patch | 132 ++++++++++++++++++++
> meta/recipes-core/eglibc/eglibc_2.14.bb | 3 +-
> 2 files changed, 134 insertions(+), 1 deletions(-)
> create mode 100644 meta/recipes-core/eglibc/eglibc-2.14/glibc-2.14-libdl-crash.patch
>
> diff --git a/meta/recipes-core/eglibc/eglibc-2.14/glibc-2.14-libdl-crash.patch b/meta/recipes-core/eglibc/eglibc-2.14/glibc-2.14-libdl-crash.patch
> new file mode 100644
> index 0000000..ee29f8c
> --- /dev/null
> +++ b/meta/recipes-core/eglibc/eglibc-2.14/glibc-2.14-libdl-crash.patch
> @@ -0,0 +1,132 @@
> +diff --git a/elf/dl-close.c b/elf/dl-close.c
> +index 73b2a2f..9bd91e3 100644
> +--- a/elf/dl-close.c
> ++++ b/elf/dl-close.c
> +@@ -1,5 +1,5 @@
> + /* Close a shared object opened by `_dl_open'.
> +- Copyright (C) 1996-2007, 2009, 2010, 2011 Free Software Foundation, Inc.
> ++ Copyright (C) 1996-2007, 2009, 2010 Free Software Foundation, Inc.
> + This file is part of the GNU C Library.
> +
> + The GNU C Library is free software; you can redistribute it and/or
> +@@ -119,17 +119,8 @@ _dl_close_worker (struct link_map *map)
> + if (map->l_direct_opencount> 0 || map->l_type != lt_loaded
> + || dl_close_state != not_pending)
> + {
> +- if (map->l_direct_opencount == 0)
> +- {
> +- if (map->l_type == lt_loaded)
> +- dl_close_state = rerun;
> +- else if (map->l_type == lt_library)
> +- {
> +- struct link_map **oldp = map->l_initfini;
> +- map->l_initfini = map->l_orig_initfini;
> +- _dl_scope_free (oldp);
> +- }
> +- }
> ++ if (map->l_direct_opencount == 0&& map->l_type == lt_loaded)
> ++ dl_close_state = rerun;
> +
> + /* There are still references to this object. Do nothing more. */
> + if (__builtin_expect (GLRO(dl_debug_mask)& DL_DEBUG_FILES, 0))
> +diff --git a/elf/dl-deps.c b/elf/dl-deps.c
> +index 9e30594..3890d00 100644
> +--- a/elf/dl-deps.c
> ++++ b/elf/dl-deps.c
> +@@ -478,6 +478,7 @@ _dl_map_object_deps (struct link_map *map,
> + nneeded * sizeof needed[0]);
> + atomic_write_barrier ();
> + l->l_initfini = l_initfini;
> ++ l->l_free_initfini = 1;
> + }
> +
> + /* If we have no auxiliary objects just go on to the next map. */
> +@@ -681,6 +682,7 @@ Filters not supported with LD_TRACE_PRELINKING"));
> + l_initfini[nlist] = NULL;
> + atomic_write_barrier ();
> + map->l_initfini = l_initfini;
> ++ map->l_free_initfini = 1;
> + if (l_reldeps != NULL)
> + {
> + atomic_write_barrier ();
> +@@ -689,5 +691,5 @@ Filters not supported with LD_TRACE_PRELINKING"));
> + _dl_scope_free (old_l_reldeps);
> + }
> + if (old_l_initfini != NULL)
> +- map->l_orig_initfini = old_l_initfini;
> ++ _dl_scope_free (old_l_initfini);
> + }
> +diff --git a/elf/dl-libc.c b/elf/dl-libc.c
> +index 7be9483..a13fce3 100644
> +--- a/elf/dl-libc.c
> ++++ b/elf/dl-libc.c
> +@@ -265,13 +265,13 @@ libc_freeres_fn (free_mem)
> +
> + for (Lmid_t ns = 0; ns< GL(dl_nns); ++ns)
> + {
> +- /* Remove all additional names added to the objects. */
> + for (l = GL(dl_ns)[ns]._ns_loaded; l != NULL; l = l->l_next)
> + {
> + struct libname_list *lnp = l->l_libname->next;
> +
> + l->l_libname->next = NULL;
> +
> ++ /* Remove all additional names added to the objects. */
> + while (lnp != NULL)
> + {
> + struct libname_list *old = lnp;
> +@@ -279,6 +279,10 @@ libc_freeres_fn (free_mem)
> + if (! old->dont_free)
> + free (old);
> + }
> ++
> ++ /* Free the initfini dependency list. */
> ++ if (l->l_free_initfini)
> ++ free (l->l_initfini);
> + }
> +
> + if (__builtin_expect (GL(dl_ns)[ns]._ns_global_scope_alloc, 0) != 0
> +diff --git a/elf/rtld.c b/elf/rtld.c
> +index 4a9109e..617e30e 100644
> +--- a/elf/rtld.c
> ++++ b/elf/rtld.c
> +@@ -2251,6 +2251,7 @@ ERROR: ld.so: object '%s' cannot be loaded as audit interface: %s; ignored.\n",
> + lnp->dont_free = 1;
> + lnp = lnp->next;
> + }
> ++ l->l_free_initfini = 0;
> +
> + if (l !=&GL(dl_rtld_map))
> + _dl_relocate_object (l, l->l_scope, GLRO(dl_lazy) ? RTLD_LAZY : 0,
> +diff --git a/include/link.h b/include/link.h
> +index e877104..051b99a 100644
> +--- a/include/link.h
> ++++ b/include/link.h
> +@@ -1,6 +1,6 @@
> + /* Data structure for communication from the run-time dynamic linker for
> + loaded ELF shared objects.
> +- Copyright (C) 1995-2006, 2007, 2009, 2010, 2011 Free Software Foundation, Inc.
> ++ Copyright (C) 1995-2006, 2007, 2009, 2010 Free Software Foundation, Inc.
> + This file is part of the GNU C Library.
> +
> + The GNU C Library is free software; you can redistribute it and/or
> +@@ -192,6 +192,9 @@ struct link_map
> + during LD_TRACE_PRELINKING=1
> + contains any DT_SYMBOLIC
> + libraries. */
> ++ unsigned int l_free_initfini:1; /* Nonzero if l_initfini can be
> ++ freed, ie. not allocated with
> ++ the dummy malloc in ld.so. */
> +
> + /* Collected information about own RPATH directories. */
> + struct r_search_path_struct l_rpath_dirs;
> +@@ -240,9 +243,6 @@ struct link_map
> +
> + /* List of object in order of the init and fini calls. */
> + struct link_map **l_initfini;
> +- /* The init and fini list generated at startup, saved when the
> +- object is also loaded dynamically. */
> +- struct link_map **l_orig_initfini;
> +
> + /* List of the dependencies introduced through symbol binding. */
> + struct link_map_reldeps
> diff --git a/meta/recipes-core/eglibc/eglibc_2.14.bb b/meta/recipes-core/eglibc/eglibc_2.14.bb
> index b2821db..4129947 100644
> --- a/meta/recipes-core/eglibc/eglibc_2.14.bb
> +++ b/meta/recipes-core/eglibc/eglibc_2.14.bb
> @@ -3,7 +3,7 @@ require eglibc.inc
> SRCREV = "15225"
>
> DEPENDS += "gperf-native"
> -PR = "r0"
> +PR = "r1"
> PR_append = "+svnr${SRCPV}"
>
> EGLIBC_BRANCH="eglibc-2_14"
> @@ -19,6 +19,7 @@ SRC_URI = "svn://www.eglibc.org/svn/branches/;module=${EGLIBC_BRANCH};proto=http
> file://ppc-sqrt.patch \
> file://multilib_readlib.patch \
> file://eglibc-rpc-export-again.patch \
> + file://glibc-2.14-libdl-crash.patch \
> "
> LIC_FILES_CHKSUM = "file://LICENSES;md5=98a1128c4b58120182cbea3b1752d8b9 \
> file://COPYING;md5=393a5ca445f6965873eca0259a17f833 \
^ permalink raw reply
* MINUTES: OE-TSC meeting 1-Sep-2011
From: Jeff Osier-Mixon @ 2011-10-03 19:37 UTC (permalink / raw)
To: openembedded-core, openembedded-devel, tsc
[-- Attachment #1: Type: text/plain, Size: 12725 bytes --]
My apologies for the delay on posting this one. This should complete the
set. Again, all minutes are now available at
http://www.openembedded.org/wiki/TSC
MINUTES: OE-TSC meeting 1-Sep-2011
Attending: Mark, Richard, Khem, Koen
Apologies: Tom
Notes: Jefro (not present)
--------------------------------------------------------
Agenda
1. pick a moderator
2. agenda items
a. Yocto update
b. oe-core release numbering
3. status on open subjects
a. oe-core
b. elections
--------------------------------------------------------
Results
1. Jefro
2. a. steering hard to bug fixing and stabilisation, branching shortly
enabling free form user contrib repos on git.yp.org in 1-2 weeks
b. oe-core to be 2011.<something> (poky is "edison")
3. a. hitting critical mass on features, people starting to use it & file
bugs
ti somewhat confused about layers vs different repos for poky/yocto
b. RP volunteered; alphabetical election order (Khem, Koen, Mark, Tom)
--------------------------------------------------------
Raw Transcript
(21:07:07) RP__: So I believe we have two agenda items plus the usual
rolling one
(21:07:17) RP__: Do we have anything on the rolling agenda we have a
pressing need to cover?
(21:10:37) RP__: so, since everyone is quiet I assume everyone doesn't have
much to talk about
(21:10:58) RP__: Yocto wise, we're steering hard to bug fixing and
stabilisation atm
(21:11:16) RP__: I think we'll want to branch shortly
(21:11:26) RP__: which leads into my open of what to call the branch in
oe-core
(21:12:00) RP__: The poky branch will be "edison" for this release
(21:12:23) koen: are we going to use the year.month like OE classic has?
(21:13:19) koen: I'm not terribly fond of it, but it beats plain numbers or
names
(21:14:31) RP__: I know people who hate year.month too
(21:14:35) RP__: so I doubt we can win
(21:15:10) khem [~khem@99-57-141-118.lightspeed.sntcca.sbcglobal.net]
entered the room.
(21:15:11) mode (+v khem) by ChanServ
(21:15:24) RP__: Is that branch going to be useful to people outside Yocto?
(21:15:30) RP__: I'm hoping the answer is yes?
(21:15:32) RP__: hi khem
(21:15:36) khem: hello
(21:16:02) koen: the oe-core branch is for the OE-core release, right?
(21:16:10) khem: traffic delayed me
(21:16:11) RP__: koen: yes
(21:16:19) RP__: khem: I pasted scroll back for you
(21:16:37) RP__: There wasn't much else of interest
(21:17:03) khem: thanks
(21:17:15) RP__: How about <year>.<number>
(21:17:34) koen: 2011.r1 ?
(21:17:40) koen: 2011.1 would be confusing :)
(21:17:40) RP__: yes
(21:17:48) fray: I thought when we talked earlier it was year . month
(21:17:48) khem: rp yy.mm is nicers
(21:17:54) fray: the month was the "expected" month vs actual..
(21:18:06) fray: i.e. if we expected to release in Sept.. it's be 2011.09
(21:18:12) ***RP__ is wondering if numbers like r1 and r2 make more sense
(21:18:12) fray: even if it didn't come out til 10 or 11
(21:18:30) khem: r1 could mean release n
(21:18:31) RP__: first release in 2011, second release in 2011
(21:18:37) koen: but we agree that at least the year would be in it?
(21:18:41) fray: IMHo it should be year.<something> I don't really care
about the something
(21:18:53) khem: yeah thats ok
(21:18:55) RP__: I think having the year is a reasonable reference frame
(21:20:00) khem: 2011r1 2011r2 ... seems reasonable
(21:20:12) koen: I'm fine with 2011<something>
(21:20:41) koen: next question, when do we ask the layer maintainers to
branch?
(21:21:04) khem: first core should be tagged/branched
(21:21:11) khem: then may be 2-3 weeks
(21:21:47) RP__: koen: I'd suggest sometime after core :)
(21:21:57) RP__: koen: The timing tbd by the layer maintainers?
(21:22:15) koen: I phrased it wrong, sorry
(21:22:29) koen: I meant when do we ask if they are going to branch
(21:22:38) koen: and if so, when
(21:23:21) RP__: koen: When OE-Core branches?
(21:23:38) RP__: and I guess another question for here is do we think
OE-Core is approaching branch point?
(21:24:04) koen: like kergoth I can't say if oe-core is getting better or
worse
(21:24:28) khem: some layers might decide not to release but trunk is always
to be followed
(21:24:51) RP__: koen: Anything that would help make your mind up in that
regard?
(21:24:54) koen: we gain multilib, but the eglibc-locale stuff tooks weeks
to debug and fix
(21:25:48) khem: RP__: how about the hash-style fixes to gcc did that make
sense ?
(21:26:07) khem: I have been occupied didnt follow ml lately
(21:26:15) fray: BTW I never posted, but I did try khem's gcc changes and
they worked fine..
(21:26:17) koen: RP__: I can't really put my finger on what's bothering me
with OE-core
(21:26:39) ***fray has been heads down in prelinker problems for the past 2
1/2 weeks so I've been out of the look on oe-core..
(21:26:42) RP__: khem: I need to look at those patches again, I think there
was something bothering me but offhand I can't remember what
(21:26:45) khem: for me bitbake's memory consumption bothers me
(21:26:49) fray: I need to get back into it this week to provide the updates
and such..
(21:27:09) RP__: koen: Any clues or you really just don't know?
(21:27:22) fray: 2-3 weeks ago I was "happy".. not sure how things have
been since then
(21:27:36) khem: RP__: there was an problem in gcc long standing distros
hacked gcc specs but this option solved it nicely
(21:28:47) RP__: khem: right, it was the implementation, not the concept
that worried me. I think it was because you were forcing people to use the
target hash pieces rather than making it optional which was how it was
implemented originally
(21:28:58) RP__: khem: e.g. trying to remove it from darwin after those
changes would be painful
(21:29:34) RP__: khem: re: bitbake memory consumption I agree it needs
looking at
(21:29:35) koen: RP__: I've been thinking about it all week and I think
OE-core has no "real" targets like "make foo-image run well on board X" so
various things fall between the cracks
(21:29:53) RP__: Sadly, the parallel parsing totally smashed all the
profiling ability I used to have with bitbake
(21:30:10) RP__: I'm now effectively blind wrt to performance (and memory
usage)
(21:30:55) RP__: koen: so its too generic and needs to specialise?
(21:31:16) khem: RP__: defaults remain same earlier it was implicit sysv and
now its just specified on cmdline
(21:31:16) RP__: koen: this is partly why there is real hardware in
meta-yocto fwiw
(21:31:33) RP__: khem: you're not understanding what I'm saying
(21:31:38) koen: RP__: I think more people like pb_ and me need to get
serious about oe-core and get more involved
(21:31:51) RP__: khem: You now force "--linker-hash-style" or whatever it is
into LDFLAGS
(21:32:05) RP__: koen: it is happening over time
(21:32:16) RP__: koen: pb_ is reporting bugs which is a good sign he's using
it
(21:32:24) koen: yes
(21:32:25) RP__: and the frequency is down
(21:32:36) RP__: which I'm hoping is good
(21:32:41) koen: yes
(21:33:01) koen: I'm saying that with more people like him, we'd catch bugs
earlier
(21:33:06) khem: RP__: it was foced before too. just that defualt was to not
pass anything and if you pass nothing then --hash-style=sysv is assumed
(21:33:26) RP__: khem: no, it wasn't. You could override one variable and it
wouldn't be in LDFLAGS
(21:33:26) khem: and that should work on darwin too
(21:33:44) fray: my feeling is we're hitting critical mass finally on
features and such that people are using it (and finding problems)
(21:33:45) RP__: now you have to override LDFLAGS to get rid of it
(21:33:46) koen: RP__: anyway, it's just a subjective feeling I have
(21:33:59) fray: I'm still a bit stumped on the adduser issue.. (todays
thread) ;)
(21:34:09) RP__: koen: thats fine, I'm just interested in those feelings
(21:34:26) RP__: fray: I haven't looked at that one yet
(21:34:37) khem: -export TARGET_LDFLAGS = "-Wl,-O1
${TARGET_LINK_HASH_STYLE}"
(21:34:37) khem: +export TARGET_LDFLAGS = "-Wl,-O1
-Wl,--hash-style=${LINKER_HASH_STYLE}"
(21:34:41) ***RP__ is suffering interrupt stack overflow
(21:34:54) fray: it shows he's got a slightly different (small system) usage
then we'd been testing against..
(21:34:59) fray: which is good!
(21:35:02) RP__: khem: right. before you can set TARGET_LINK_HASH_STYLE = ""
and it removes the option from LDFLAGS
(21:35:12) khem: so what changed ?
(21:35:18) RP__: khem: how do I not pass that option to LDFLAGS after your
change?
(21:35:18) khem: default is still sysv
(21:35:35) khem: what would you gain by not passing it
(21:35:48) khem: I understand one option less on cmdline
(21:35:55) RP__: khem: general configurability regarding toolchains
(21:35:59) khem: since its default
(21:36:11) RP__: khem: We do not want to hardcode the toolchain options
(21:36:27) khem: hmmm so non GNU ld
(21:36:33) RP__: right
(21:36:40) RP__: I don't want to make assumptions in the core
(21:36:51) RP__: once we start to its a slippery slope
(21:37:06) RP__: this case may or may not be minor, its the principle
(21:37:35) RP__: fray: agreed, I'm pleased to see it
(21:37:59) koen: so, before I forget, any volunteers to poke the board about
our elections?
(21:38:17) RP__: koen: I don't mind...
(21:38:31) koen: philip asked for a description of what we wanted to help
them remember
(21:38:50) RP__: koen: description of what?
(21:39:48) RP__: koen: perhaps since you know what Philip wants you could
tell him? :)
(21:41:26) khem: on infra side git move to final destination is still
pending
(21:42:07) RP__: khem: ok
(21:42:21) RP__: Yocto git/web services have moved to their new home now
(21:42:36) khem: cool
(21:42:40) RP__: Also, gitolite now supports free form user repos
(21:42:43) koen: RP__: who will be stepping down :)
(21:42:54) khem: it was me
(21:43:12) RP__: Khem, Koen, Mark, Tom in that order?
(21:43:19) RP__: alphabetical iirc
(21:43:46) RP__: we're enabling free form user contrib repos on git.yp.org
(21:44:41) ***koen was amused by people not getting a pull model on oe-devel
this week
(21:46:33) RP__: ok, so anything left to discuss?
(21:46:57) RP__: koen: I guess if you've not been around the kernel
community it might be a bit more alien
(21:48:32) khem: RP__: the user repos ?
(21:48:33) khem: cool
(21:48:41) khem: I would use it
(21:48:54) RP__: khem: on git.yp.org?
(21:48:58) khem: RP__: yes
(21:49:21) koen: ah, that dropbear failure wasn't due to fedora 15
(21:49:46) RP__: khem: ok, we're about to trail it with a few intel people
and it will take 1-2 weeks to get cgit to show the repos but I'll ping you
then about using it
(21:49:57) khem: RP__: ok
(21:50:38) koen: RP__: what are your thoughts on ditching the combined repo
and use seperate git repos for poky/yocto in the future?
(21:50:54) RP__: koen: which combined repo?
(21:51:00) RP__: koen: you mean the -contrib ones?
(21:51:40) koen: no, poky
(21:52:08) RP__: koen: so drop the poky repo and replace it with nothing,
just scripts?
(21:52:35) koen: something like that
(21:52:39) RP__: koen: why?
(21:53:12) koen: it confuses the hell out of TI people
(21:53:14) RP__: people actually find it easy to use so I'm reluctant to
make thing harder for them
(21:53:48) RP__: koen: I'm sure they'll figure it out ;-)
(21:53:59) koen: I'm not saying it isn't easy to use
(21:54:13) koen: but it is showing a lack of faith in layers from the yocto
side
(21:54:42) RP__: I'd disagree with that
(21:55:17) RP__: and its ironic given I've done more than most people to
promote layers in the first place :)
(21:55:35) koen: but you see why I'm saying that?
(21:55:56) RP__: koen: yes, I can see why you could say it
(21:56:45) RP__: I don't have any objection to others packaging up
collections of layers, be it via scripts or an automated repo
(21:56:47) koen: I don't have strong opinions on it, just passing on the
confusion
(21:57:16) RP__: Yocto tends to the latter since its easier for newcomers to
understand
(21:57:41) koen: the layer tooling blew up, so I'm not updating the angstrom
combined repo anymore
(21:58:02) RP__: koen: thanks. I'm hoping with a little more time there will
less confusion
(21:58:41) RP__: koen: hopefully we'll iron out issues like that with the
tooling
(21:58:57) koen: if only git submodules worked....
(21:59:10) khem: koen: for my needs git submodules work
(21:59:24) RP__: ok, before we start on that I'd like to close the meeting
;-)
--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
[-- Attachment #2: Type: text/html, Size: 16207 bytes --]
^ permalink raw reply
* Re: MINUTES: OE-TSC meeting 29-Sep-2011
From: Khem Raj @ 2011-10-03 19:25 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CABcZANk1DnADdN2F39QYOOM--KyJkxbguhQ0GPmv9BFeEPG_oA@mail.gmail.com>
On 9/30/2011 11:16 AM, Chris Larson wrote:
> On Fri, Sep 30, 2011 at 11:14 AM, Jeff Osier-Mixon<jefro@jefro.net> wrote:
>> 1. Jefro
>> 2. a. some minutes not making it to mailing list, Jefro to post on wiki
>> b. yocto evaluating gerrit, possible patchwork replacement for OE, khem
>> will research
>
> ReviewBoard may be worth looking at as an alternative to gerritt, as well.
thank you for pointer. If someone has used it then please inform us here
on ml about its +/-
^ permalink raw reply
* Re: [PATCH v2 10/16] Fix mdadm for powerpc64
From: Khem Raj @ 2011-10-03 19:22 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Matthew McClintock
In-Reply-To: <1317322353-30258-1-git-send-email-msm@freescale.com>
On 9/29/2011 11:52 AM, Matthew McClintock wrote:
> This fixes build failures from build warnings on powerpc64
>
> Signed-off-by: Matthew McClintock<msm@freescale.com>
> ---
> meta/recipes-extended/mdadm/mdadm_3.2.2.bb | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/meta/recipes-extended/mdadm/mdadm_3.2.2.bb b/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
> index 5d29ae7..1c83f89 100644
> --- a/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
> +++ b/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
> @@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
> file://mdmon.c;beginline=4;endline=18;md5=af7d8444d9c4d3e5c7caac0d9d34039d \
> file://mdadm.h;beglinlne=4;endline=22;md5=462bc9936ac0d3da110191a3f9994161"
>
> -PR = "r0"
> +PR = "r1"
>
> SRC_URI = "${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.bz2"
>
> @@ -16,6 +16,7 @@ SRC_URI[md5sum] = "12ee2fbf3beddb60601fb7a4c4905651"
> SRC_URI[sha256sum] = "0d1a04e688b082bc88846e3f524abd50bc782b6ffc06123140f7d358c8f9b906"
>
> CFLAGS += "-fno-strict-aliasing"
> +EXTRA_OEMAKE_append_powerpc64 = "CXFLAGS=-Wno-error=format"
>
> inherit autotools
>
what kind of errors do you get ? and I wonder why they dont show up on
x86_64. It may be something to fix in the madadm code.
^ permalink raw reply
* [PATCH] webkit-gtk: add --enable-dependency-tracking to EXTRA_OECONF
From: Andreas Müller @ 2011-10-03 19:17 UTC (permalink / raw)
To: openembedded-core
After [1] build failed with error message
| Couldn't open file ./DerivedSources/webkit/WebKitDOMCSSStyleDeclarationPrivate.h for writing at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1122.
| Couldn't open file ./DerivedSources/webkit/WebKitDOMCSSRulePrivate.h for writing at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1122.
| Couldn't open file ./DerivedSources/webkit/WebKitDOMCSSStyleSheetPrivate.h for writing at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1122.
| make: *** [DerivedSources/webkit/WebKitDOMCSSStyleDeclaration.h] Error 2
Discussion on this patch see [2]
Build tested in angstrom environment
[1] http://cgit.openembedded.org/cgit.cgi/openembedded-core/commit/?id=970e0ae610804638d00b0a6b85c6e2e895778e8e
[2] http://lists.linuxtogo.org/pipermail/openembedded-core/2011-October/010590.html
Signed-off-by: Andreas Müller <schnitzeltony@gmx.de>
---
meta/recipes-sato/webkit/webkit-gtk_svn.bb | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-sato/webkit/webkit-gtk_svn.bb b/meta/recipes-sato/webkit/webkit-gtk_svn.bb
index 5eb9b2e..d655999 100644
--- a/meta/recipes-sato/webkit/webkit-gtk_svn.bb
+++ b/meta/recipes-sato/webkit/webkit-gtk_svn.bb
@@ -14,7 +14,7 @@ SRCREV_FORMAT = "source"
SRCREV = "90727"
PV = "1.5.1+svnr${SRCPV}"
-PR = "r0"
+PR = "r1"
SRC_URI = "\
svn://svn.webkit.org/repository/webkit/trunk/;module=Source;proto=http;name=source \
@@ -40,6 +40,7 @@ EXTRA_OECONF = "\
--enable-fullscreen-api \
--enable-image-resizer \
--enable-link-prefetch \
+ --enable-dependency-tracking \
UNICODE_CFLAGS=-D_REENTRANT \
"
--
1.7.4.4
^ permalink raw reply related
* Re: Selectable linker (ld or gold) per recipe
From: Khem Raj @ 2011-10-03 19:12 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1317305306.3304.8.camel@lenovo.internal.reciva.com>
On 9/29/2011 7:08 AM, Phil Blundell wrote:
> On Tue, 2011-09-27 at 18:10 -0700, Khem Raj wrote:
>> I have thought of that and we know about kernel and eglibc but we
>> don't know about rest of apps
>> that we build. I don't know if gold has been deployed distro wide
>> thats why the approach was to have gold replace parts where it really matters
>> then we might have packages where they use linker directly and or have
>> own linker
>> scripts which are tuned to ld and may yield something different with
>> gold of-course
>> those problems should be fixed but having something in place to make package
>> wise choice sounded better to me.
>
> I think I would rather wait until such issues actually arise before
> trying to fix them. Adding per-recipe linker selection seems like quite
> a lot of mechanism, with associated potential fragility, to solve a
> problem that might not even exist in reality.
>
> Also, thinking about this more, I am not convinced that wrapping ld
> directly is going to work reliably. If I remember right, gcc inspects
> some attributes of the target linker (plugin support being the most
> obvious one) during configure and adapts itself accordingly.
plugin support is now supported in both linkers 2.21+ should not be any
issue
any other differences between both linkers I am not aware that gcc
would care when configuring itself
> Subsequently swapping out the linker under its feet at runtime seems
> like it would be a bad idea. If it does turn out that there are
> packages which simply must be built with BFD ld, I think we should
> either:
>
> a) just declare them incompatible with the ld-is-gold DISTRO_FEATURE,
> and say that the programs in question aren't supported by such DISTROs
> (which might or might not be a defensible position, depending on the
> extent to which such programs are a fringe interest); or
this could be a starter
>
> b) fix the programs and/or gold to make them compatible, or if that's
> really intractable; or
obviously wanted to avoid that
>
> c) work with upstream gcc to figurd
yes
>
> c) build a parallel toolchain which uses BFD ld and has its own copy of
> gcc which is appropriately configured, and arrange for the recipes in
> question to find that toolchain in their $PATH.
>
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [PATCH v3 01/16] libnl2: Fix a race on route/pktloc_syntax.h
From: Martin Jansa @ 2011-10-03 19:04 UTC (permalink / raw)
To: McClintock Matthew-B29882,
Patches and discussions about the oe-core layer
In-Reply-To: <CAEsOVNdMVdbMaM-E0X2T4+v-Y_TbpiFMdcV+Lu3s7gX4dHLPHA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]
On Mon, Oct 03, 2011 at 06:39:52PM +0000, McClintock Matthew-B29882 wrote:
> On Fri, Sep 30, 2011 at 12:26 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Fri, Sep 30, 2011 at 12:21:23PM -0500, Matthew McClintock wrote:
> >> From: Tom Rini <tom_rini@mentor.com>
> >>
> >> At issue is that route/pktloc.c (not generated) depends on
> >> route/pktloc_syntax.h (generated).
> >
> > On Fri, Sep 30, 2011 at 9:13 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> >
> > and when you're at it, please also add packaging changes from meta-oe,
> > so we can remove libnl from meta-oe and keep only libnl1 there.
>
> Sorry, I'm not sure I follow. Are you referring to all the other stuff
> in the old openembedded? I'm not following this package particularly
> closely.
just see diff oe-core/meta/recipes*/libnl* and meta-openembedded/meta-oe/recipes*/libnl*
and it will be clearer
Regards,
> * 9fef5f0 Add 'ucred' structure declaration in netlink headers for the integrity
> * f9e4241 libnl-1.1: rename to libnl1 and build only static lib
> * 4ccaf2c libnl_git: remove fix-pktloc-dep-race.patch from this version
> * 91e03b2 libnl: add libnl.inc and use INC_PR
> * 4702231 libnl: don't use /usr/include/libnl2 anymore
> * 5ef679a libnl: rename libnl2 to libnl as used in openembedded-core
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: help2man
From: Khem Raj @ 2011-10-03 19:06 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317297541.12332.85.camel@ted>
On 9/29/2011 4:58 AM, Richard Purdie wrote:
> The more I look at and think about help2man, the more it looks like
> something we just shouldn't need/use.
>
> In summary, it runs a binary and captures its --help output. This rules
> it out from being useful in most cross compiling scenarios, i.e. all
> target packages.
right. This should be disabled for cross builds. May be it should be
disabled in autotools bbclass do_configure itself.
>
> In the -native/-cross cases, we don't really care about man pages.
>
> I'm therefore thinking we should really just drop the dependency and
> symlink help2man to /bin/false. The missing script in autotools should
> then just silently touch the man page files instead of regenerating
> them.
>
> I tried to figure out which recipes actually use help2man:
>
> $ grep HELP2MAN * -r --exclude=Makefile.in 2> /dev/null | grep -v missing
>
> and against a core-image-sato this gave:
>
> libtool
> libtasn1
> gettext
> automake
> autoconf
> flex
> bison
> m4
>
> which isn't that many recipes to go and beat up manually if necessary.
> It certainly doesn't warrant a global include in autotools.bbclass IMO.
>
> Cheers,
>
> Richard
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: bitbake webkit-gtk fails with clean temp dir
From: Andreas Müller @ 2011-10-03 18:45 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E89D4F0.9080900@mlbassoc.com>
On Monday, October 03, 2011 05:29:52 PM Gary Thomas wrote:
> >> NOTE: package webkit-gtk-1.5.1+svnr90727-r0: task do_compile: Failed
> >> ERROR: Task 7 (/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-sato/webkit/webkit-gtk_svn.bb, do_compile) failed with exit code '1'
> >>
> >> ideas what causes this?
> >
> > no idea, but I get the same error
> >
>
> It builds in Yocto/Poky so you might compare with those recipes.
Dit you pull [1] and rebuild webkit-gtk?
>
>
some investigation later: by diff'ing log files created by working environment with the current environment I fell over log.do_configure:
--disable-dependency-tracking
was added in [1]. Tried manual bisecting by
git reset --hard 288343e30604b944dc18fd82172febd314d9c520
é voilà: webkit-gtk builds again. Will send a patch with --enable-dependency-tracking after testing...
Andreas
[1] http://cgit.openembedded.org/cgit.cgi/openembedded-core/commit/?id=970e0ae610804638d00b0a6b85c6e2e895778e8e
^ permalink raw reply
* Re: [PATCH v3 01/16] libnl2: Fix a race on route/pktloc_syntax.h
From: McClintock Matthew-B29882 @ 2011-10-03 18:39 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20110930172628.GE7364@jama.jama.net>
On Fri, Sep 30, 2011 at 12:26 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Fri, Sep 30, 2011 at 12:21:23PM -0500, Matthew McClintock wrote:
>> From: Tom Rini <tom_rini@mentor.com>
>>
>> At issue is that route/pktloc.c (not generated) depends on
>> route/pktloc_syntax.h (generated).
>
> On Fri, Sep 30, 2011 at 9:13 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>
> and when you're at it, please also add packaging changes from meta-oe,
> so we can remove libnl from meta-oe and keep only libnl1 there.
Sorry, I'm not sure I follow. Are you referring to all the other stuff
in the old openembedded? I'm not following this package particularly
closely.
* 9fef5f0 Add 'ucred' structure declaration in netlink headers for the integrity
* f9e4241 libnl-1.1: rename to libnl1 and build only static lib
* 4ccaf2c libnl_git: remove fix-pktloc-dep-race.patch from this version
* 91e03b2 libnl: add libnl.inc and use INC_PR
* 4702231 libnl: don't use /usr/include/libnl2 anymore
* 5ef679a libnl: rename libnl2 to libnl as used in openembedded-core
-M
^ permalink raw reply
* Re: [RFC] .la files cleanup
From: Otavio Salvador @ 2011-10-03 18:34 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <j6cq5j$snr$1@dough.gmane.org>
On Mon, Oct 3, 2011 at 14:06, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> On 10/03/2011 06:55 PM, Phil Blundell wrote:
...
> I see... Then I'd drop some local patches dropping .la files and just push
> them into -dev packages.
>
> RP, is that suitable for you?
Isn't a post install hook with:
find ${D} -name '*.la' -exec rm '{}' ';'
All we need?
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply
* Re: [PATCH v2 1/2] Fix the --root option in shadow-native programs.
From: Saul Wold @ 2011-10-03 17:38 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Julian Pidancet
In-Reply-To: <1317427816-31888-2-git-send-email-julian.pidancet@gmail.com>
On 09/30/2011 05:10 PM, Julian Pidancet wrote:
> The add_root_cmd_options.patch that we apply to shadow-native allow the
> various programs from the shadow utility package to chroot() so they can
> be used to modify etc/passwd and etc/group if they are located in a
> sysroot.
>
> Some of the shadow programs (gpasswd, useradd and usermod) need to parse
> the command line in two passes. But we can't use getopt_long() twice
> because getopt_long() reorders the command line arguments, and
> consequently corrupts the option parsing during the second pass.
>
> This patch fixes this issue by replacing the first pass by a very simple
> manual walk of the command line to handle the --root argument.
>
> This change is a patch of another patch, I apologize if it is
> difficult to read. But IMHO it wouldn't make sense to put the patch for
> this issue in another separated file.
>
> The --root options in groupadd and useradd are needed to make the
> useradd class work, and this issue was preventing to use useradd and
> groupadd long options while using the class.
>
> Signed-off-by: Julian Pidancet<julian.pidancet@gmail.com>
> ---
> .../shadow/files/add_root_cmd_options.patch | 180 ++++++++++----------
> 1 files changed, 89 insertions(+), 91 deletions(-)
>
> diff --git a/meta/recipes-extended/shadow/files/add_root_cmd_options.patch b/meta/recipes-extended/shadow/files/add_root_cmd_options.patch
> index c5f2bec..2604ad8 100644
> --- a/meta/recipes-extended/shadow/files/add_root_cmd_options.patch
> +++ b/meta/recipes-extended/shadow/files/add_root_cmd_options.patch
> @@ -26,8 +26,8 @@ Workaround is specific to our build system.
> Signed-off-by: Scott Garman<scott.a.garman@intel.com>
>
Julian,
Since you modified this patch, it would be helpful to explain what you
did in the patch itself and add an Signed-off-by line.
Thanks
Sau!
> diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c
> ---- shadow-4.1.4.3.orig//src/gpasswd.c 2011-02-13 09:58:16.000000000 -0800
> -+++ shadow-4.1.4.3//src/gpasswd.c 2011-06-28 15:12:03.539504372 -0700
> +--- shadow-4.1.4.3.orig//src/gpasswd.c 2011-09-29 12:00:45.211000091 +0100
> ++++ shadow-4.1.4.3//src/gpasswd.c 2011-09-29 12:09:54.590000090 +0100
> @@ -63,6 +63,7 @@
> * (/etc/gshadow present) */
> static bool is_shadowgrp;
> @@ -52,7 +52,7 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c
> " -r, --remove-password remove the GROUP's password\n"
> " -R, --restrict restrict access to GROUP to its members\n"
> " -M, --members USER,... set the list of members of GROUP\n"
> -@@ -226,6 +229,55 @@
> +@@ -226,6 +229,57 @@
> }
>
> /*
> @@ -68,23 +68,26 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c
> + /*
> + * Parse the command line options.
> + */
> -+ int flag;
> -+ int option_index = 0;
> -+ static struct option long_options[] = {
> -+ {"root", required_argument, NULL, 'Q'},
> -+ {NULL, 0, NULL, '\0'}
> -+ };
> ++ int i;
> ++ char *root;
> +
> -+ while ((flag = getopt_long (argc, argv, "a:A:d:gM:Q:rR", long_options,&option_index)) != -1) {
> -+ switch (flag) {
> -+ case 'Q':
> -+ if ('/' != optarg[0]) {
> ++ for (i = 0; i< argc; i++) {
> ++ if (!strcmp (argv[i], "--root") || !strcmp (argv[i], "-Q")) {
> ++ if (i + 1 == argc) {
> ++ fprintf (stderr,
> ++ _("%s: option '%s' requires an argument\n"),
> ++ Prog, argv[i]);
> ++ exit (E_BAD_ARG);
> ++ }
> ++ root = argv[i + 1];
> ++
> ++ if ('/' != root[0]) {
> + fprintf (stderr,
> + _("%s: invalid chroot path '%s'\n"),
> -+ Prog, optarg);
> ++ Prog, root);
> + exit (E_BAD_ARG);
> + }
> -+ newroot = optarg;
> ++ newroot = root;
> +
> + if (access (newroot, F_OK) != 0) {
> + fprintf(stderr,
> @@ -99,7 +102,6 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c
> + exit (E_BAD_ARG);
> + }
> + break;
> -+ /* no-op on everything else - they will be hanled by process_flags() */
> + }
> + }
> +}
> @@ -108,7 +110,7 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c
> * process_flags - process the command line options and arguments
> */
> static void process_flags (int argc, char **argv)
> -@@ -235,6 +287,7 @@
> +@@ -235,6 +289,7 @@
> static struct option long_options[] = {
> {"add", required_argument, NULL, 'a'},
> {"delete", required_argument, NULL, 'd'},
> @@ -116,7 +118,7 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c
> {"remove-password", no_argument, NULL, 'r'},
> {"restrict", no_argument, NULL, 'R'},
> {"administrators", required_argument, NULL, 'A'},
> -@@ -242,7 +295,7 @@
> +@@ -242,7 +297,7 @@
> {NULL, 0, NULL, '\0'}
> };
>
> @@ -125,7 +127,7 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c
> switch (flag) {
> case 'a': /* add a user */
> aflg = true;
> -@@ -283,6 +336,9 @@
> +@@ -283,6 +338,9 @@
> }
> Mflg = true;
> break;
> @@ -135,7 +137,7 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c
> case 'r': /* remove group password */
> rflg = true;
> break;
> -@@ -995,6 +1051,8 @@
> +@@ -995,6 +1053,8 @@
> setbuf (stdout, NULL);
> setbuf (stderr, NULL);
>
> @@ -145,8 +147,8 @@ diff -urN shadow-4.1.4.3.orig//src/gpasswd.c shadow-4.1.4.3//src/gpasswd.c
> is_shadowgrp = sgr_file_present ();
> #endif
> diff -urN shadow-4.1.4.3.orig//src/groupadd.c shadow-4.1.4.3//src/groupadd.c
> ---- shadow-4.1.4.3.orig//src/groupadd.c 2011-02-13 09:58:16.000000000 -0800
> -+++ shadow-4.1.4.3//src/groupadd.c 2011-06-28 15:12:03.539504372 -0700
> +--- shadow-4.1.4.3.orig//src/groupadd.c 2011-09-29 12:00:45.212000091 +0100
> ++++ shadow-4.1.4.3//src/groupadd.c 2011-09-29 11:59:28.386000092 +0100
> @@ -76,6 +76,7 @@
> static gid_t group_id;
> static /*@null@*/char *group_passwd;
> @@ -208,8 +210,8 @@ diff -urN shadow-4.1.4.3.orig//src/groupadd.c shadow-4.1.4.3//src/groupadd.c
> rflg = true;
> break;
> diff -urN shadow-4.1.4.3.orig//src/groupdel.c shadow-4.1.4.3//src/groupdel.c
> ---- shadow-4.1.4.3.orig//src/groupdel.c 2011-02-13 09:58:16.000000000 -0800
> -+++ shadow-4.1.4.3//src/groupdel.c 2011-06-28 15:12:03.539504372 -0700
> +--- shadow-4.1.4.3.orig//src/groupdel.c 2011-09-29 12:00:45.212000091 +0100
> ++++ shadow-4.1.4.3//src/groupdel.c 2011-09-29 11:59:28.386000092 +0100
> @@ -36,6 +36,7 @@
>
> #include<ctype.h>
> @@ -340,8 +342,8 @@ diff -urN shadow-4.1.4.3.orig//src/groupdel.c shadow-4.1.4.3//src/groupdel.c
> #ifdef USE_PAM
> {
> diff -urN shadow-4.1.4.3.orig//src/groupmod.c shadow-4.1.4.3//src/groupmod.c
> ---- shadow-4.1.4.3.orig//src/groupmod.c 2011-02-13 09:58:16.000000000 -0800
> -+++ shadow-4.1.4.3//src/groupmod.c 2011-06-28 15:12:03.539504372 -0700
> +--- shadow-4.1.4.3.orig//src/groupmod.c 2011-09-29 12:00:45.212000091 +0100
> ++++ shadow-4.1.4.3//src/groupmod.c 2011-09-29 11:59:28.387000092 +0100
> @@ -79,6 +79,7 @@
> static char *group_passwd;
> static gid_t group_id;
> @@ -401,8 +403,8 @@ diff -urN shadow-4.1.4.3.orig//src/groupmod.c shadow-4.1.4.3//src/groupmod.c
> usage ();
> }
> diff -urN shadow-4.1.4.3.orig//src/grpconv.c shadow-4.1.4.3//src/grpconv.c
> ---- shadow-4.1.4.3.orig//src/grpconv.c 2011-02-13 09:58:16.000000000 -0800
> -+++ shadow-4.1.4.3//src/grpconv.c 2011-06-28 15:12:03.539504372 -0700
> +--- shadow-4.1.4.3.orig//src/grpconv.c 2011-09-29 12:00:45.213000091 +0100
> ++++ shadow-4.1.4.3//src/grpconv.c 2011-09-29 11:59:28.387000092 +0100
> @@ -39,6 +39,7 @@
>
> #include<errno.h>
> @@ -527,8 +529,8 @@ diff -urN shadow-4.1.4.3.orig//src/grpconv.c shadow-4.1.4.3//src/grpconv.c
> fprintf (stderr,
> _("%s: cannot lock %s; try again later.\n"),
> diff -urN shadow-4.1.4.3.orig//src/grpunconv.c shadow-4.1.4.3//src/grpunconv.c
> ---- shadow-4.1.4.3.orig//src/grpunconv.c 2011-02-13 09:58:16.000000000 -0800
> -+++ shadow-4.1.4.3//src/grpunconv.c 2011-06-28 15:12:03.539504372 -0700
> +--- shadow-4.1.4.3.orig//src/grpunconv.c 2011-09-29 12:00:45.213000091 +0100
> ++++ shadow-4.1.4.3//src/grpunconv.c 2011-09-29 11:59:28.387000092 +0100
> @@ -43,6 +43,7 @@
> #include<stdlib.h>
> #include<string.h>
> @@ -653,8 +655,8 @@ diff -urN shadow-4.1.4.3.orig//src/grpunconv.c shadow-4.1.4.3//src/grpunconv.c
> exit (0); /* no /etc/gshadow, nothing to do */
> }
> diff -urN shadow-4.1.4.3.orig//src/passwd.c shadow-4.1.4.3//src/passwd.c
> ---- shadow-4.1.4.3.orig//src/passwd.c 2011-02-13 09:58:16.000000000 -0800
> -+++ shadow-4.1.4.3//src/passwd.c 2011-06-28 15:12:03.539504372 -0700
> +--- shadow-4.1.4.3.orig//src/passwd.c 2011-09-29 12:00:45.214000091 +0100
> ++++ shadow-4.1.4.3//src/passwd.c 2011-09-29 11:59:28.388000092 +0100
> @@ -75,6 +75,7 @@
> static char *name; /* The name of user whose password is being changed */
> static char *myname; /* The current user's name */
> @@ -718,8 +720,8 @@ diff -urN shadow-4.1.4.3.orig//src/passwd.c shadow-4.1.4.3//src/passwd.c
> /* -r repository (files|nis|nisplus) */
> /* only "files" supported for now */
> diff -urN shadow-4.1.4.3.orig//src/pwconv.c shadow-4.1.4.3//src/pwconv.c
> ---- shadow-4.1.4.3.orig//src/pwconv.c 2011-02-13 09:58:16.000000000 -0800
> -+++ shadow-4.1.4.3//src/pwconv.c 2011-06-28 15:12:03.539504372 -0700
> +--- shadow-4.1.4.3.orig//src/pwconv.c 2011-09-29 12:00:45.214000091 +0100
> ++++ shadow-4.1.4.3//src/pwconv.c 2011-09-29 11:59:28.388000092 +0100
> @@ -59,6 +59,7 @@
>
> #include<errno.h>
> @@ -847,8 +849,8 @@ diff -urN shadow-4.1.4.3.orig//src/pwconv.c shadow-4.1.4.3//src/pwconv.c
> fprintf (stderr,
> _("%s: cannot lock %s; try again later.\n"),
> diff -urN shadow-4.1.4.3.orig//src/pwunconv.c shadow-4.1.4.3//src/pwunconv.c
> ---- shadow-4.1.4.3.orig//src/pwunconv.c 2011-02-13 09:58:16.000000000 -0800
> -+++ shadow-4.1.4.3//src/pwunconv.c 2011-06-28 15:12:03.539504372 -0700
> +--- shadow-4.1.4.3.orig//src/pwunconv.c 2011-09-29 12:00:45.214000091 +0100
> ++++ shadow-4.1.4.3//src/pwunconv.c 2011-09-29 11:59:28.388000092 +0100
> @@ -35,6 +35,7 @@
> #ident "$Id: pwunconv.c 2852 2009-04-30 21:44:35Z nekral-guest $"
>
> @@ -969,8 +971,8 @@ diff -urN shadow-4.1.4.3.orig//src/pwunconv.c shadow-4.1.4.3//src/pwunconv.c
> /* shadow not installed, do nothing */
> exit (0);
> diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c
> ---- shadow-4.1.4.3.orig//src/useradd.c 2011-02-13 09:58:16.000000000 -0800
> -+++ shadow-4.1.4.3//src/useradd.c 2011-06-28 15:12:14.608787030 -0700
> +--- shadow-4.1.4.3.orig//src/useradd.c 2011-09-29 12:00:45.215000091 +0100
> ++++ shadow-4.1.4.3//src/useradd.c 2011-09-29 11:59:28.520000092 +0100
> @@ -112,6 +112,7 @@
> #ifdef WITH_SELINUX
> static const char *user_selinux = "";
> @@ -995,7 +997,7 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c
> (void) fputs (_(" -r, --system create a system account\n"), stderr);
> (void) fputs (_(" -s, --shell SHELL login shell of the new account\n"), stderr);
> (void) fputs (_(" -u, --uid UID user ID of the new account\n"), stderr);
> -@@ -943,6 +946,59 @@
> +@@ -943,6 +946,57 @@
> }
>
> /*
> @@ -1011,27 +1013,26 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c
> + /*
> + * Parse the command line options.
> + */
> -+ int c;
> -+ static struct option long_options[] = {
> -+ {"root", required_argument, NULL, 'R'},
> -+ {NULL, 0, NULL, '\0'}
> -+ };
> -+ while ((c = getopt_long (argc, argv,
> -+#ifdef WITH_SELINUX
> -+ "b:c:d:De:f:g:G:k:K:lmMNop:R:rs:u:UZ:",
> -+#else
> -+ "b:c:d:De:f:g:G:k:K:lmMNop:R:rs:u:U",
> -+#endif
> -+ long_options, NULL)) != -1) {
> -+ switch (c) {
> -+ case 'R':
> -+ if ('/' != optarg[0]) {
> ++ int i;
> ++ char *root;
> ++
> ++ for (i = 0; i< argc; i++) {
> ++ if (!strcmp (argv[i], "--root") || !strcmp (argv[i], "-R")) {
> ++ if (i + 1 == argc) {
> ++ fprintf (stderr,
> ++ _("%s: option '%s' requires an argument\n"),
> ++ Prog, argv[i]);
> ++ exit (E_BAD_ARG);
> ++ }
> ++ root = argv[i + 1];
> ++
> ++ if ('/' != root[0]) {
> + fprintf (stderr,
> + _("%s: invalid chroot path '%s'\n"),
> -+ Prog, optarg);
> ++ Prog, root);
> + exit (E_BAD_ARG);
> + }
> -+ newroot = optarg;
> ++ newroot = root;
> +
> + if (access (newroot, F_OK) != 0) {
> + fprintf(stderr,
> @@ -1046,7 +1047,6 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c
> + exit (E_BAD_ARG);
> + }
> + break;
> -+ /* no-op on everything else - they will be hanled by process_flags() */
> + }
> + }
> +}
> @@ -1055,7 +1055,7 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c
> * process_flags - perform command line argument setting
> *
> * process_flags() interprets the command line arguments and sets
> -@@ -978,6 +1034,7 @@
> +@@ -978,6 +1032,7 @@
> {"no-user-group", no_argument, NULL, 'N'},
> {"non-unique", no_argument, NULL, 'o'},
> {"password", required_argument, NULL, 'p'},
> @@ -1063,7 +1063,7 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c
> {"system", no_argument, NULL, 'r'},
> {"shell", required_argument, NULL, 's'},
> #ifdef WITH_SELINUX
> -@@ -989,9 +1046,9 @@
> +@@ -989,9 +1044,9 @@
> };
> while ((c = getopt_long (argc, argv,
> #ifdef WITH_SELINUX
> @@ -1075,7 +1075,7 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c
> #endif
> long_options, NULL)) != -1) {
> switch (c) {
> -@@ -1156,6 +1213,9 @@
> +@@ -1156,6 +1211,9 @@
> }
> user_pass = optarg;
> break;
> @@ -1085,7 +1085,7 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c
> case 'r':
> rflg = true;
> break;
> -@@ -1735,6 +1795,36 @@
> +@@ -1735,6 +1793,36 @@
> }
> }
> #endif
> @@ -1122,7 +1122,7 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c
> /*
> * create_home - create the user's home directory
> *
> -@@ -1748,34 +1838,31 @@
> +@@ -1748,34 +1836,31 @@
> #ifdef WITH_SELINUX
> selinux_file_context (user_home);
> #endif
> @@ -1175,7 +1175,7 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c
> }
>
> /*
> -@@ -1861,6 +1948,7 @@
> +@@ -1861,6 +1946,7 @@
> */
> user_groups[0] = (char *) 0;
>
> @@ -1184,8 +1184,8 @@ diff -urN shadow-4.1.4.3.orig//src/useradd.c shadow-4.1.4.3//src/useradd.c
> is_shadow_pwd = spw_file_present ();
> #ifdef SHADOWGRP
> diff -urN shadow-4.1.4.3.orig//src/userdel.c shadow-4.1.4.3//src/userdel.c
> ---- shadow-4.1.4.3.orig//src/userdel.c 2011-02-13 09:58:16.000000000 -0800
> -+++ shadow-4.1.4.3//src/userdel.c 2011-06-28 15:12:03.549503721 -0700
> +--- shadow-4.1.4.3.orig//src/userdel.c 2011-09-29 12:00:45.216000091 +0100
> ++++ shadow-4.1.4.3//src/userdel.c 2011-09-29 11:59:28.389000092 +0100
> @@ -79,6 +79,7 @@
> static char *user_name;
> static uid_t user_id;
> @@ -1239,8 +1239,8 @@ diff -urN shadow-4.1.4.3.orig//src/userdel.c shadow-4.1.4.3//src/userdel.c
> rflg = true;
> break;
> diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c
> ---- shadow-4.1.4.3.orig//src/usermod.c 2011-02-13 09:58:16.000000000 -0800
> -+++ shadow-4.1.4.3//src/usermod.c 2011-06-28 15:12:03.549503721 -0700
> +--- shadow-4.1.4.3.orig//src/usermod.c 2011-09-29 12:00:45.216000091 +0100
> ++++ shadow-4.1.4.3//src/usermod.c 2011-09-29 11:59:28.390000092 +0100
> @@ -110,6 +110,7 @@
> static long user_newinactive;
> static long sys_ngroups;
> @@ -1265,7 +1265,7 @@ diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c
> " -s, --shell SHELL new login shell for the user account\n"
> " -u, --uid UID new UID for the user account\n"
> " -U, --unlock unlock the user account\n"
> -@@ -802,6 +805,60 @@
> +@@ -802,6 +805,58 @@
> }
>
> /*
> @@ -1281,28 +1281,27 @@ diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c
> + /*
> + * Parse the command line options.
> + */
> -+ int c;
> -+ static struct option long_options[] = {
> -+ {"root", required_argument, NULL, 'R'},
> -+ {NULL, 0, NULL, '\0'}
> -+ };
> -+ while ((c = getopt_long (argc, argv,
> -+#ifdef WITH_SELINUX
> -+ "ac:d:e:f:g:G:hl:Lmop:R:s:u:UZ:",
> -+#else
> -+ "ac:d:e:f:g:G:hl:Lmop:R:s:u:U",
> -+#endif
> -+ long_options, NULL)) != -1) {
> -+ switch (c) {
> -+ case 'R':
> -+ if ( (!VALID (optarg) )
> -+ || ( ('/' != optarg[0]) ) ) {
> ++ int i;
> ++ char *root;
> ++
> ++ for (i = 0; i< argc; i++) {
> ++ if (!strcmp (argv[i], "--root") || !strcmp (argv[i], "-R")) {
> ++ if (i + 1 == argc) {
> ++ fprintf (stderr,
> ++ _("%s: option '%s' requires an argument\n"),
> ++ Prog, argv[i]);
> ++ exit (E_BAD_ARG);
> ++ }
> ++ root = argv[i + 1];
> ++
> ++ if ( (!VALID (root) )
> ++ || ( ('/' != root[0]) ) ) {
> + fprintf (stderr,
> + _("%s: invalid chroot path '%s'\n"),
> -+ Prog, optarg);
> ++ Prog, root);
> + exit (E_BAD_ARG);
> + }
> -+ newroot = optarg;
> ++ newroot = root;
> +
> + if (access (newroot, F_OK) != 0) {
> + fprintf(stderr,
> @@ -1317,7 +1316,6 @@ diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c
> + exit (E_BAD_ARG);
> + }
> + break;
> -+ /* no-op on everything else - they will be hanled by process_flags() */
> + }
> + }
> +}
> @@ -1326,7 +1324,7 @@ diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c
> * process_flags - perform command line argument setting
> *
> * process_flags() interprets the command line arguments and sets the
> -@@ -895,6 +952,7 @@
> +@@ -895,6 +950,7 @@
> {"move-home", no_argument, NULL, 'm'},
> {"non-unique", no_argument, NULL, 'o'},
> {"password", required_argument, NULL, 'p'},
> @@ -1334,7 +1332,7 @@ diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c
> #ifdef WITH_SELINUX
> {"selinux-user", required_argument, NULL, 'Z'},
> #endif
> -@@ -905,9 +963,9 @@
> +@@ -905,9 +961,9 @@
> };
> while ((c = getopt_long (argc, argv,
> #ifdef WITH_SELINUX
> @@ -1346,7 +1344,7 @@ diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c
> #endif
> long_options, NULL)) != -1) {
> switch (c) {
> -@@ -999,6 +1057,9 @@
> +@@ -999,6 +1055,9 @@
> user_pass = optarg;
> pflg = true;
> break;
> @@ -1356,7 +1354,7 @@ diff -urN shadow-4.1.4.3.orig//src/usermod.c shadow-4.1.4.3//src/usermod.c
> case 's':
> if (!VALID (optarg)) {
> fprintf (stderr,
> -@@ -1715,6 +1776,8 @@
> +@@ -1715,6 +1774,8 @@
>
> OPENLOG ("usermod");
>
^ permalink raw reply
* Re: [RFC] .la files cleanup
From: Dmitry Eremin-Solenikov @ 2011-10-03 17:06 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1317653702.13337.4.camel@phil-desktop>
On 10/03/2011 06:55 PM, Phil Blundell wrote:
> On Mon, 2011-10-03 at 14:58 +0400, Dmitry Eremin-Solenikov wrote:
>> My proposal would be to include a special task or a
>> do_install_append() part that
>> will remove specified .la files. (like ${libdir}/xorg/modules/*/.la,
>> ${libdir}/matchbox-panel/*.la, etc.). I see this usually done in
>> do_install or in special do_install_append
>> parts, but I think it would be better to handle this globally.
>
> I guess the ideal solution would be to find a way to stop libtool from
> installing these things in the first place. It isn't totally obvious to
> me that the .la files are a net benefit even for real shared libraries,
> and for plugins I think they are probably a net loss in most/all cases.
>
> When this issue last came up it seemed that Richard's preferred fix was
> to just ship the .la files in FILES_${PN}-dev, and I guess that approach
> does at least have the merit of simplicity. See:
>
> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-July/005533.html
I see... Then I'd drop some local patches dropping .la files and just
push them into -dev packages.
RP, is that suitable for you?
--
With best wishes
Dmitry
^ permalink raw reply
* sstate_clean() overzealous?
From: Phil Blundell @ 2011-10-03 16:47 UTC (permalink / raw)
To: oe-core
The sstate_clean() function in sstate.bbclass is doing (inter alia):
stfile = d.getVar("STAMP", True) + ".do_" + ss['task']
[...]
oe.path.remove(stfile + ".*")
oe.path.remove(stfile + "_setscene" + ".*")
which means that, for tasks which set the stamp-extra-info flag to
${MACHINE}, it ends up blowing away the stamps for all machines rather
than just the current one. The net effect of this seems to be that
there is no way to have the setscene stamps populated for more than one
MACHINE at any time, and hence all those tasks get rerun every time you
change MACHINE even if nothing else has been altered.
Is this behaviour deliberate? It is certainly a little bit annoying but
I don't understand the internals of sstate well enough to judge what
exactly that glob is trying to accomplish.
thanks
p.
^ permalink raw reply
* Re: [PATCHv2 04/30] xf86-video-omapfb: bump SRCREV and add patch from meta-oe
From: Phil Blundell @ 2011-10-03 16:00 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <7a380e5d1538c175e164b2d249d182c723fcda15.1317648040.git.Martin.Jansa@gmail.com>
On Mon, 2011-10-03 at 15:28 +0200, Martin Jansa wrote:
> From: Martin Jansa <martin.jansa@gmail.com>
>
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
This is a bit of a lame checkin message. "Add patch from meta-oe"
doesn't really say anything useful about what you're changing, and there
is no long comment at all. Also ...
>@@ -1,25 +1,25 @@
>-require xorg-driver-driver.inc
>+require xorg-driver-video.inc
>
> SUMMARY = "X.Org X server -- Texas Instruments OMAP framebuffer driver"
>
> DESCRIPTION = "omapfb driver supports the basic Texas Instruments OMAP \
> framebuffer."
>
>-LICENSE = "MIT-X"
>-LIC_FILES_CHKSUM = "file://src/omapfb-driver.c;beginline=1;endline=30;md5=a44c2a37e04d1c2c5f0313afb493f833"
>+LICENSE = "MIT-X & GPLv2+"
>+LIC_FILES_CHKSUM = "file://COPYING;md5=63e2cbac53863f60e2f43343fb34367f"
> DEPENDS += "virtual/libx11"
... these changes don't seem to be covered by the description above.
And, finally, if this is an OMAP-specific driver, why is it in oe-core
in the first place? I would have thought it would be better placed in
meta-ti or some such layer.
p.
^ permalink raw reply
* Re: bitbake webkit-gtk fails with clean temp dir
From: Gary Thomas @ 2011-10-03 15:29 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <C4A96559-DE0F-4549-8A49-909A168B8A66@dominion.thruhere.net>
On 2011-10-03 09:24, Koen Kooi wrote:
>
>
> Op 3 okt. 2011 om 09:03 heeft Andreas Müller<schnitzeltony@gmx.de> het volgende geschreven:
>
>> Have pulled yesterday all the angstom layers (oe-core / meta-oe ..) and deleted all files from temp build dir. For
>>
>> bitbake webkit-gtk
>>
>> I get
>>
>> NOTE: package webkit-gtk-1.5.1+svnr90727-r0: task do_compile: Started
>> ERROR: Function 'do_compile' failed (see /home/Superandy/tmp/oe-core-eglibc/work/armv7a-angstrom-linux-gnueabi/webkit-gtk-1.5.1+svnr90727-r0/temp/log.do_compile.13377 for further information)
>> ERROR: Logfile of failure stored in: /home/Superandy/tmp/oe-core-eglibc/work/armv7a-angstrom-linux-gnueabi/webkit-gtk-1.5.1+svnr90727-r0/temp/log.do_compile.13377
>> Log data follows:
>> | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
>> | + cd /home/Superandy/tmp/oe-core-eglibc/work/armv7a-angstrom-linux-gnueabi/webkit-gtk-1.5.1+svnr90727-r0/
>> | + do_compile
>> | + base_do_compile
>> | + '[' -e Makefile -o -e makefile ']'
>> | + oe_runmake
>> | + '[' xmake = x ']'
>> | + bbnote make -j 4
>> | + echo 'NOTE: make -j 4'
>> | NOTE: make -j 4
>> | + make -j 4
>> | /usr/bin/perl -I./Source/WebCore/bindings/scripts ./Source/WebCore/bindings/scripts/generate-bindings.pl --include ./Source/WebCore/dom --include ./Source/WebCore/html --include ./Source/WebCore/css --include ./Source/WebCore/page --include ./Source/WebCore/xml --include ./Source/WebCore/svg --outputDir "./DerivedSources/webkit" --defines "LANGUAGE_GOBJECT=1 ENABLE_CHANNEL_MESSAGING=1 ENABLE_METER_TAG=1 ENABLE_PROGRESS_TAG=1 ENABLE_JAVASCRIPT_DEBUGGER=1 ENABLE_OFFLINE_WEB_APPLICATIONS=1 ENABLE_DATABASE=1 ENABLE_DATALIST=1 ENABLE_EVENTSOURCE=1 ENABLE_DOM_STORAGE=1 ENABLE_VIDEO=1 ENABLE_FULLSCREEN_API=1 ENABLE_VIDEO_TRACK=1 ENABLE_XPATH=1 ENABLE_XSLT=1 ENABLE_WORKERS=1 ENABLE_SHARED_WORKERS=1 ENABLE_FILTERS=1 ENABLE_WEB_SOCKETS=1 ENABLE_BLOB=1" --generator GObject ./Source/WebCore/css/CSSRule.idl
>> | /usr/bin/perl -I./Source/WebCore/bindings/scripts ./Source/WebCore/bindings/scripts/generate-bindings.pl --include ./Source/WebCore/dom --include ./Source/WebCore/html --include ./Source/WebCore/css --include ./Source/WebCore/page --include ./Source/WebCore/xml --include ./Source/WebCore/svg --outputDir "./DerivedSources/webkit" --defines "LANGUAGE_GOBJECT=1 ENABLE_CHANNEL_MESSAGING=1 ENABLE_METER_TAG=1 ENABLE_PROGRESS_TAG=1 ENABLE_JAVASCRIPT_DEBUGGER=1 ENABLE_OFFLINE_WEB_APPLICATIONS=1 ENABLE_DATABASE=1 ENABLE_DATALIST=1 ENABLE_EVENTSOURCE=1 ENABLE_DOM_STORAGE=1 ENABLE_VIDEO=1 ENABLE_FULLSCREEN_API=1 ENABLE_VIDEO_TRACK=1 ENABLE_XPATH=1 ENABLE_XSLT=1 ENABLE_WORKERS=1 ENABLE_SHARED_WORKERS=1 ENABLE_FILTERS=1 ENABLE_WEB_SOCKETS=1 ENABLE_BLOB=1" --generator GObject ./Source/WebCore/css/CSSRuleList.idl
>> | /usr/bin/perl -I./Source/WebCore/bindings/scripts ./Source/WebCore/bindings/scripts/generate-bindings.pl --include ./Source/WebCore/dom --include ./Source/WebCore/html --include ./Source/WebCore/css --include ./Source/WebCore/page --include ./Source/WebCore/xml --include ./Source/WebCore/svg --outputDir "./DerivedSources/webkit" --defines "LANGUAGE_GOBJECT=1 ENABLE_CHANNEL_MESSAGING=1 ENABLE_METER_TAG=1 ENABLE_PROGRESS_TAG=1 ENABLE_JAVASCRIPT_DEBUGGER=1 ENABLE_OFFLINE_WEB_APPLICATIONS=1 ENABLE_DATABASE=1 ENABLE_DATALIST=1 ENABLE_EVENTSOURCE=1 ENABLE_DOM_STORAGE=1 ENABLE_VIDEO=1 ENABLE_FULLSCREEN_API=1 ENABLE_VIDEO_TRACK=1 ENABLE_XPATH=1 ENABLE_XSLT=1 ENABLE_WORKERS=1 ENABLE_SHARED_WORKERS=1 ENABLE_FILTERS=1 ENABLE_WEB_SOCKETS=1 ENABLE_BLOB=1" --generator GObject ./Source/WebCore/css/CSSStyleDeclaration.idl
>> | /usr/bin/perl -I./Source/WebCore/bindings/scripts ./Source/WebCore/bindings/scripts/generate-bindings.pl --include ./Source/WebCore/dom --include ./Source/WebCore/html --include ./Source/WebCore/css --include ./Source/WebCore/page --include ./Source/WebCore/xml --include ./Source/WebCore/svg --outputDir "./DerivedSources/webkit" --defines "LANGUAGE_GOBJECT=1 ENABLE_CHANNEL_MESSAGING=1 ENABLE_METER_TAG=1 ENABLE_PROGRESS_TAG=1 ENABLE_JAVASCRIPT_DEBUGGER=1 ENABLE_OFFLINE_WEB_APPLICATIONS=1 ENABLE_DATABASE=1 ENABLE_DATALIST=1 ENABLE_EVENTSOURCE=1 ENABLE_DOM_STORAGE=1 ENABLE_VIDEO=1 ENABLE_FULLSCREEN_API=1 ENABLE_VIDEO_TRACK=1 ENABLE_XPATH=1 ENABLE_XSLT=1 ENABLE_WORKERS=1 ENABLE_SHARED_WORKERS=1 ENABLE_FILTERS=1 ENABLE_WEB_SOCKETS=1 ENABLE_BLOB=1" --generator GObject ./Source/WebCore/css/CSSStyleSheet.idl
>> | Unquoted string "attributes" may clash with future reserved word at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1036.
>> | Unquoted string "attributes" may clash with future reserved word at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1036.
>> | Unquoted string "attributes" may clash with future reserved word at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1036.
>> | Couldn't open file ./DerivedSources/webkit/WebKitDOMCSSRuleListPrivate.h for writing at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1122.
>> | Couldn't open file ./DerivedSources/webkit/WebKitDOMCSSStyleSheetPrivate.h for writing at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1122.
>> | make: *** [DerivedSources/webkit/WebKitDOMCSSRuleList.h] Error 2
>> | make: *** Waiting for unfinished jobs....
>> | Couldn't open file ./DerivedSources/webkit/WebKitDOMCSSStyleDeclarationPrivate.h for writing at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1122.
>> | make: *** [DerivedSources/webkit/WebKitDOMCSSStyleSheet.h] Error 2
>> | make: *** [DerivedSources/webkit/WebKitDOMCSSStyleDeclaration.h] Error 2
>> | Unquoted string "attributes" may clash with future reserved word at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1036.
>> | Couldn't open file ./DerivedSources/webkit/WebKitDOMCSSRulePrivate.h for writing at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1122.
>> | make: *** [DerivedSources/webkit/WebKitDOMCSSRule.h] Error 2
>> | + die 'oe_runmake failed'
>> | + bbfatal 'oe_runmake failed'
>> | + echo 'ERROR: oe_runmake failed'
>> | ERROR: oe_runmake failed
>> | + exit 1
>> | ERROR: Function 'do_compile' failed (see /home/Superandy/tmp/oe-core-eglibc/work/armv7a-angstrom-linux-gnueabi/webkit-gtk-1.5.1+svnr90727-r0/temp/log.do_compile.13377 for further information)
>> NOTE: package webkit-gtk-1.5.1+svnr90727-r0: task do_compile: Failed
>> ERROR: Task 7 (/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-sato/webkit/webkit-gtk_svn.bb, do_compile) failed with exit code '1'
>>
>> ideas what causes this?
>
> no idea, but I get the same error
>
It builds in Yocto/Poky so you might compare with those recipes.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: bitbake webkit-gtk fails with clean temp dir
From: Koen Kooi @ 2011-10-03 15:24 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Cc: openembedded-core@lists.openembedded.org
In-Reply-To: <201110031603.31007.schnitzeltony@gmx.de>
Op 3 okt. 2011 om 09:03 heeft Andreas Müller <schnitzeltony@gmx.de> het volgende geschreven:
> Have pulled yesterday all the angstom layers (oe-core / meta-oe ..) and deleted all files from temp build dir. For
>
> bitbake webkit-gtk
>
> I get
>
> NOTE: package webkit-gtk-1.5.1+svnr90727-r0: task do_compile: Started
> ERROR: Function 'do_compile' failed (see /home/Superandy/tmp/oe-core-eglibc/work/armv7a-angstrom-linux-gnueabi/webkit-gtk-1.5.1+svnr90727-r0/temp/log.do_compile.13377 for further information)
> ERROR: Logfile of failure stored in: /home/Superandy/tmp/oe-core-eglibc/work/armv7a-angstrom-linux-gnueabi/webkit-gtk-1.5.1+svnr90727-r0/temp/log.do_compile.13377
> Log data follows:
> | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
> | + cd /home/Superandy/tmp/oe-core-eglibc/work/armv7a-angstrom-linux-gnueabi/webkit-gtk-1.5.1+svnr90727-r0/
> | + do_compile
> | + base_do_compile
> | + '[' -e Makefile -o -e makefile ']'
> | + oe_runmake
> | + '[' xmake = x ']'
> | + bbnote make -j 4
> | + echo 'NOTE: make -j 4'
> | NOTE: make -j 4
> | + make -j 4
> | /usr/bin/perl -I./Source/WebCore/bindings/scripts ./Source/WebCore/bindings/scripts/generate-bindings.pl --include ./Source/WebCore/dom --include ./Source/WebCore/html --include ./Source/WebCore/css --include ./Source/WebCore/page --include ./Source/WebCore/xml --include ./Source/WebCore/svg --outputDir "./DerivedSources/webkit" --defines "LANGUAGE_GOBJECT=1 ENABLE_CHANNEL_MESSAGING=1 ENABLE_METER_TAG=1 ENABLE_PROGRESS_TAG=1 ENABLE_JAVASCRIPT_DEBUGGER=1 ENABLE_OFFLINE_WEB_APPLICATIONS=1 ENABLE_DATABASE=1 ENABLE_DATALIST=1 ENABLE_EVENTSOURCE=1 ENABLE_DOM_STORAGE=1 ENABLE_VIDEO=1 ENABLE_FULLSCREEN_API=1 ENABLE_VIDEO_TRACK=1 ENABLE_XPATH=1 ENABLE_XSLT=1 ENABLE_WORKERS=1 ENABLE_SHARED_WORKERS=1 ENABLE_FILTERS=1 ENABLE_WEB_SOCKETS=1 ENABLE_BLOB=1" --generator GObject ./Source/WebCore/css/CSSRule.idl
> | /usr/bin/perl -I./Source/WebCore/bindings/scripts ./Source/WebCore/bindings/scripts/generate-bindings.pl --include ./Source/WebCore/dom --include ./Source/WebCore/html --include ./Source/WebCore/css --include ./Source/WebCore/page --include ./Source/WebCore/xml --include ./Source/WebCore/svg --outputDir "./DerivedSources/webkit" --defines "LANGUAGE_GOBJECT=1 ENABLE_CHANNEL_MESSAGING=1 ENABLE_METER_TAG=1 ENABLE_PROGRESS_TAG=1 ENABLE_JAVASCRIPT_DEBUGGER=1 ENABLE_OFFLINE_WEB_APPLICATIONS=1 ENABLE_DATABASE=1 ENABLE_DATALIST=1 ENABLE_EVENTSOURCE=1 ENABLE_DOM_STORAGE=1 ENABLE_VIDEO=1 ENABLE_FULLSCREEN_API=1 ENABLE_VIDEO_TRACK=1 ENABLE_XPATH=1 ENABLE_XSLT=1 ENABLE_WORKERS=1 ENABLE_SHARED_WORKERS=1 ENABLE_FILTERS=1 ENABLE_WEB_SOCKETS=1 ENABLE_BLOB=1" --generator GObject ./Source/WebCore/css/CSSRuleList.idl
> | /usr/bin/perl -I./Source/WebCore/bindings/scripts ./Source/WebCore/bindings/scripts/generate-bindings.pl --include ./Source/WebCore/dom --include ./Source/WebCore/html --include ./Source/WebCore/css --include ./Source/WebCore/page --include ./Source/WebCore/xml --include ./Source/WebCore/svg --outputDir "./DerivedSources/webkit" --defines "LANGUAGE_GOBJECT=1 ENABLE_CHANNEL_MESSAGING=1 ENABLE_METER_TAG=1 ENABLE_PROGRESS_TAG=1 ENABLE_JAVASCRIPT_DEBUGGER=1 ENABLE_OFFLINE_WEB_APPLICATIONS=1 ENABLE_DATABASE=1 ENABLE_DATALIST=1 ENABLE_EVENTSOURCE=1 ENABLE_DOM_STORAGE=1 ENABLE_VIDEO=1 ENABLE_FULLSCREEN_API=1 ENABLE_VIDEO_TRACK=1 ENABLE_XPATH=1 ENABLE_XSLT=1 ENABLE_WORKERS=1 ENABLE_SHARED_WORKERS=1 ENABLE_FILTERS=1 ENABLE_WEB_SOCKETS=1 ENABLE_BLOB=1" --generator GObject ./Source/WebCore/css/CSSStyleDeclaration.idl
> | /usr/bin/perl -I./Source/WebCore/bindings/scripts ./Source/WebCore/bindings/scripts/generate-bindings.pl --include ./Source/WebCore/dom --include ./Source/WebCore/html --include ./Source/WebCore/css --include ./Source/WebCore/page --include ./Source/WebCore/xml --include ./Source/WebCore/svg --outputDir "./DerivedSources/webkit" --defines "LANGUAGE_GOBJECT=1 ENABLE_CHANNEL_MESSAGING=1 ENABLE_METER_TAG=1 ENABLE_PROGRESS_TAG=1 ENABLE_JAVASCRIPT_DEBUGGER=1 ENABLE_OFFLINE_WEB_APPLICATIONS=1 ENABLE_DATABASE=1 ENABLE_DATALIST=1 ENABLE_EVENTSOURCE=1 ENABLE_DOM_STORAGE=1 ENABLE_VIDEO=1 ENABLE_FULLSCREEN_API=1 ENABLE_VIDEO_TRACK=1 ENABLE_XPATH=1 ENABLE_XSLT=1 ENABLE_WORKERS=1 ENABLE_SHARED_WORKERS=1 ENABLE_FILTERS=1 ENABLE_WEB_SOCKETS=1 ENABLE_BLOB=1" --generator GObject ./Source/WebCore/css/CSSStyleSheet.idl
> | Unquoted string "attributes" may clash with future reserved word at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1036.
> | Unquoted string "attributes" may clash with future reserved word at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1036.
> | Unquoted string "attributes" may clash with future reserved word at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1036.
> | Couldn't open file ./DerivedSources/webkit/WebKitDOMCSSRuleListPrivate.h for writing at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1122.
> | Couldn't open file ./DerivedSources/webkit/WebKitDOMCSSStyleSheetPrivate.h for writing at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1122.
> | make: *** [DerivedSources/webkit/WebKitDOMCSSRuleList.h] Error 2
> | make: *** Waiting for unfinished jobs....
> | Couldn't open file ./DerivedSources/webkit/WebKitDOMCSSStyleDeclarationPrivate.h for writing at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1122.
> | make: *** [DerivedSources/webkit/WebKitDOMCSSStyleSheet.h] Error 2
> | make: *** [DerivedSources/webkit/WebKitDOMCSSStyleDeclaration.h] Error 2
> | Unquoted string "attributes" may clash with future reserved word at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1036.
> | Couldn't open file ./DerivedSources/webkit/WebKitDOMCSSRulePrivate.h for writing at Source/WebCore/bindings/scripts/CodeGeneratorGObject.pm line 1122.
> | make: *** [DerivedSources/webkit/WebKitDOMCSSRule.h] Error 2
> | + die 'oe_runmake failed'
> | + bbfatal 'oe_runmake failed'
> | + echo 'ERROR: oe_runmake failed'
> | ERROR: oe_runmake failed
> | + exit 1
> | ERROR: Function 'do_compile' failed (see /home/Superandy/tmp/oe-core-eglibc/work/armv7a-angstrom-linux-gnueabi/webkit-gtk-1.5.1+svnr90727-r0/temp/log.do_compile.13377 for further information)
> NOTE: package webkit-gtk-1.5.1+svnr90727-r0: task do_compile: Failed
> ERROR: Task 7 (/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-sato/webkit/webkit-gtk_svn.bb, do_compile) failed with exit code '1'
>
> ideas what causes this?
no idea, but I get the same error
>
> Andreas
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [PATCHv2 26/30] glx-use-tls: add from meta-oe layer
From: Martin Jansa @ 2011-10-03 15:09 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317654131.13337.6.camel@phil-desktop>
[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]
On Mon, Oct 03, 2011 at 04:02:10PM +0100, Phil Blundell wrote:
> Can you add some commentary explaining why this is necessary -- i.e.
> what exactly is lacking in uClibc to mean it doesn't have "prober TLS
> support"?
I'm not using uClibc myself and tracking original bbclass in OE-classic
leads to this commit
http://git.openembedded.org/cgit.cgi/openembedded/commit/packages/mesa/mesa-tls.inc?id=b527d8f723c98c77f2f5c5358062e5348493d767
So I'm CCing woglinde and he will probably explain it.
Regards,
>
> p.
>
> On Mon, 2011-10-03 at 15:28 +0200, Martin Jansa wrote:
> > * it's in .bbclass instead of .inc because it's used by mesa and
> > xserver-xf86 recipes
> >
> > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > ---
> > meta/classes/glx-use-tls.bbclass | 7 +++++++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
> > create mode 100644 meta/classes/glx-use-tls.bbclass
> >
> > diff --git a/meta/classes/glx-use-tls.bbclass b/meta/classes/glx-use-tls.bbclass
> > new file mode 100644
> > index 0000000..7530872
> > --- /dev/null
> > +++ b/meta/classes/glx-use-tls.bbclass
> > @@ -0,0 +1,7 @@
> > +def get_tls_setting(bb, d):
> > + # until we have no prober TLS support in uclibc disable it
> > + if bb.data.getVar('TARGET_OS', d, 1).find('uclibc') >= 0 :
> > + return ""
> > + return "--enable-glx-tls"
> > +
> > +EXTRA_OECONF += "${@get_tls_setting(bb, d)}"
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: [PATCHv2 26/30] glx-use-tls: add from meta-oe layer
From: Phil Blundell @ 2011-10-03 15:02 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <3ffacbd5138165278774387c51b4bd3bb625eaff.1317648041.git.Martin.Jansa@gmail.com>
Can you add some commentary explaining why this is necessary -- i.e.
what exactly is lacking in uClibc to mean it doesn't have "prober TLS
support"?
p.
On Mon, 2011-10-03 at 15:28 +0200, Martin Jansa wrote:
> * it's in .bbclass instead of .inc because it's used by mesa and
> xserver-xf86 recipes
>
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
> meta/classes/glx-use-tls.bbclass | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
> create mode 100644 meta/classes/glx-use-tls.bbclass
>
> diff --git a/meta/classes/glx-use-tls.bbclass b/meta/classes/glx-use-tls.bbclass
> new file mode 100644
> index 0000000..7530872
> --- /dev/null
> +++ b/meta/classes/glx-use-tls.bbclass
> @@ -0,0 +1,7 @@
> +def get_tls_setting(bb, d):
> + # until we have no prober TLS support in uclibc disable it
> + if bb.data.getVar('TARGET_OS', d, 1).find('uclibc') >= 0 :
> + return ""
> + return "--enable-glx-tls"
> +
> +EXTRA_OECONF += "${@get_tls_setting(bb, d)}"
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox