date:20150223

[yocto] [Recipe reporting system] Upgradable recipe name list

2015-02-23 Thread recipe-report

This mail was sent out by Recipe reporting system.

This message list those recipes which need to be upgraded. If maintainers
believe some of them needn't to upgrade this time, they can fill in
RECIPE_NO_UPDATE_REASON_pn-"xxx" in upstream_tracking files to ignore this
recipe remainder until newer upstream version was detected.

Example:
RECIPE_NO_UPDATE_REASON_pn-"xxx" = "Not upgrade to 2.0 is unstable"

You can check the detail information at:

http://packages.yoctoproject.org/upgradepkgname

Package   Version  Upstream version  Maintainer   
NoUpgradeReason
  ---    ---  
--
python-smmap  0.8.20.9.0 Alejandro Hernandez
gnome-icon-theme  2.31.0   3.12.0Alejandro Hernandez  
waiting for the sato gtk3 port
nfs-utils 1.3.11.3.2 Alejandro Hernandez
midori0.5.80.5.9 Alejandro Hernandez
sqlite3   3.8.7.4  3.8.8.2.  Aníbal Limón
screen4.0.34.2.1 Aníbal Limón
jpeg  8d   9aAníbal Limón 
webkit-gtk 1.8.3 doesn't wo...
apt   0.9.9.4  1.0.9.6   Aníbal Limón
dpkg  1.17.21  1.17.24   Aníbal Limón
nettle2.7.13.0   Armin Kuster 
3.0.0 breaks gnutls, api ch...
sudo  1.8.11p2 1.8.12Chen Qi
sysstat   11.0.2   11.1.3Chen Qi
resolvconf1.76 1.76.1Chen Qi
console-tools 0.3.21999.03.02Chen Qi
systemd   216+gitX 219+gitAUTOINC+d3...  Chen Qi
util-linux2.25.2   2.26  Chen Qi
dbus-glib 0.1020.104 Chong Lu
dbus-test 1.8.10   1.9.12Chong Lu
dbus  1.8.10   1.9.12Chong Lu 
D-BUS 1.9.x is the developm...
bison 2.7.13.0.4 Chong Lu
libatomics-ops7.2  7.4.0 Cristian Iorga
speex 1.2rc1   1.2rc2Cristian Iorga
db6.0.30   6.1.19.NC Cristian Iorga   
API compatibility issue
libical   1.0.01.0.1 Cristian Iorga
quota 4.01 4.02  Cristian Iorga
bluez44.1015.28  Cristian Iorga   
BlueZ 5.x is not backward-c...
gst-plugin-bluetooth  4.1015.28  Cristian Iorga
iproute2  3.17.0   3.19.0Cristian Iorga
gst-ffmpeg0.10.13  0.11.2Cristian Iorga
gst-fluendo-mp3   0.10.31  0.10.32   Cristian Iorga
gst-plugins-bad   0.10.23  1.4.5 Cristian Iorga   
not compatible with gst-flu...
gst-plugins-base  0.10.36  1.4.5 Cristian Iorga   
not compatible with gst-flu...
gst-plugins-good  0.10.31  1.4.5 Cristian Iorga   
not compatible with gst-flu...
gst-plugins-ugly  0.10.19  1.4.5 Cristian Iorga
gstreamer 0.10.36  1.4.5 Cristian Iorga   
not compatible with gst-fl...
hwlatdetect   0.89 0.91  Darren Hart
rt-tests  0.89 0.91  Darren Hart
qmmp  0.7.70.8.3 Hongxu Jia
patch 2.7.12.7.4 Hongxu Jia
perl  5.20.0   5.21.9Hongxu Jia
createrepo0.4.11   0.10.3Hongxu Jia   
Versions after 0.9.* use YU...
gnupg 2.1.12.1.2 Hongxu Jia
bash  4.3  4.3.30Hongxu Jia   
The latest version in yocto...
groff 1.22.2   1.22.3Hongxu Jia   
1.18.1.4 is latest GPLv2 Ve...
man-pages 3.76 3.80  Hongxu Jia
directfb  1.7.61.7.7 Hongxu Jia
dhcp  4.3.14.3.2 Hongxu Jia
socat 1.7.2.4  1.7.3.0   Hongxu Jia
distcc3.1  3.2rc1Hongxu Jia
python-mako   0.9.11.0.1 Khem Raj
python-nose   1.2.11.3.4 Khem Raj
python-numpy  1.7.01.9.1 Khem Raj
python3-distribute0.6.32   0.7.3 Khem Raj
rpm   5.4.14   5.4.15Mark Hatle
libpfm4   4.3.04.6.0

Re: [yocto] [PATCH] Add mpich support

2015-02-23 Thread Burton, Ross

Patches for meta-oe should go to the openembedded-devel list, not yocto@.

Ross

On 19 February 2015 at 21:43, Alexandru.Vaduva 
wrote:

> From: Victor Rodriguez 
>
> This patch add mpich support to yocto in order to run MPI framework on
> embedded
> systems.
>
> Signed-off-by: Alejandro Hernandez 
> Signed-off-by: Victor Rodriguez 
> Signed-off-by: Alexandru.Vaduva 
> ---
>  meta-oe/recipes-devtools/mpich/mpich_3.1.1.bb | 29
> +++
>  1 file changed, 29 insertions(+)
>  create mode 100644 meta-oe/recipes-devtools/mpich/mpich_3.1.1.bb
>
> diff --git a/meta-oe/recipes-devtools/mpich/mpich_3.1.1.bb
> b/meta-oe/recipes-devtools/mpich/mpich_3.1.1.bb
> new file mode 100644
> index 000..2f4226e
> --- /dev/null
> +++ b/meta-oe/recipes-devtools/mpich/mpich_3.1.1.bb
> @@ -0,0 +1,29 @@
> +SUMMARY = "Message Passing Interface(MPI) implementation"
> +HOMEPAGE = "http://git.mpich.org/mpich.git/";
> +SECTION = "devel"
> +
> +LICENSE = "BSD-2-Clause"
> +LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=2106f0435056f3dd9349747a766e5816"
> +
> +SRC_URI = "http://www.mpich.org/static/downloads/${PV}/mpich-${PV}.tar.gz
> "
> +SRC_URI[md5sum] = "40dc408b1e03cc36d80209baaa2d32b7"
> +SRC_URI[sha256sum] =
> "455ccfaf4ec724d2cf5d8bff1f3d26a958ad196121e7ea26504fd3018757652d"
> +
> +RDEPENDS_${PN} += "bash perl tcsh"
> +S = "${WORKDIR}/${PN}-${PV}"
> +
> +EXTRA_OECONF = "--enable-debuginfo \
> +--enable-fast \
> +--enable-shared  \
> +--disable-f77 \
> +--disable-fc \
> +--disable-fortran \
> +--disable-cxx"
> +
> +inherit autotools-brokensep gettext
> +
> +do_configure_prepend() {
> +autoreconf --verbose --install --force -I . -I confdb/ -I maint/
> +oe_runconf
> +exit
> +}
> --
> 1.9.1
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [psplash][PATCH] Adding support for systemd and its service files

2015-02-23 Thread Burton, Ross

Hi Petter,

On 22 February 2015 at 21:20, Petter Mabäcker  wrote:

> Anyone who knows what happened with this change? Any problem detected? I
> was looking into adding support for systemd in psplash and found this old
> changeset that is not included in the psplash repo yet.
>
>
I dropped the ball on testing it.  Last time I looked systemd pretty much
assumed that plymouth was being used.  If you can verify that this patch
set is right, then that's awesome.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] bitbake: fetch2: Revalidate checksums, YOCTO #5571

2015-02-23 Thread Clemens Lang

[YOCTO #5571] -- https://bugzilla.yoctoproject.org/show_bug.cgi?id=5571

The following workflow (whether accidentally or deliberately) would
previously not result in a checksum error, but would be helpful to do
so:
 - Write a recipe with correct checksums
 - Fetch the sources for this recipe using bitbake
 - Change the checksums
Since the bitbake fetcher writes a done stamp after the initial download
and does not verify the checksums again (even if they are changed in the
recipe afterwards), the change of checksums is silently ignored.

Fix this without the overhead of computing the checksums from scratch on
every do_fetch by storing them in pickled format in the done stamp and
verifying that they still match those in the recipe.

Signed-off-by: Clemens Lang 
---
 bitbake/lib/bb/fetch2/__init__.py | 106 ++
 1 file changed, 96 insertions(+), 10 deletions(-)

diff --git a/bitbake/lib/bb/fetch2/__init__.py 
b/bitbake/lib/bb/fetch2/__init__.py
index 599ea8c..c0c8312 100644
--- a/bitbake/lib/bb/fetch2/__init__.py
+++ b/bitbake/lib/bb/fetch2/__init__.py
@@ -45,6 +45,13 @@ _checksum_cache = bb.checksum.FileChecksumCache()
 
 logger = logging.getLogger("BitBake.Fetcher")
 
+try:
+import cPickle as pickle
+except ImportError:
+import pickle
+logger.info("Importing cPickle failed. "
+"Falling back to a very slow implementation.")
+
 class BBFetchException(Exception):
 """Class all fetch exceptions inherit from"""
 def __init__(self, message):
@@ -525,7 +532,7 @@ def fetcher_compare_revisions(d):
 def mirror_from_string(data):
 return [ i.split() for i in (data or "").replace('\\n','\n').split('\n') 
if i ]
 
-def verify_checksum(ud, d):
+def verify_checksum(ud, d, precomputed={}):
 """
 verify the MD5 and SHA256 checksum for downloaded src
 
@@ -533,13 +540,28 @@ def verify_checksum(ud, d):
 the downloaded file, or if BB_STRICT_CHECKSUM is set and there are no
 checksums specified.
 
+Returns a dict of checksums that can be stored in a done stamp file and
+passed in as precomputed parameter in a later call to avoid re-computing
+the checksums from the file. This allows verifying the checksums of the
+file against those in the recipe each time, rather than only after
+downloading. See https://bugzilla.yoctoproject.org/show_bug.cgi?id=5571.
 """
 
+_MD5_KEY = "md5"
+_SHA256_KEY = "sha256"
+
 if ud.ignore_checksums or not ud.method.supports_checksum(ud):
-return
+return {}
 
-md5data = bb.utils.md5_file(ud.localpath)
-sha256data = bb.utils.sha256_file(ud.localpath)
+if _MD5_KEY in precomputed:
+md5data = precomputed[_MD5_KEY]
+else:
+md5data = bb.utils.md5_file(ud.localpath)
+
+if _SHA256_KEY in precomputed:
+sha256data = precomputed[_SHA256_KEY]
+else:
+sha256data = bb.utils.sha256_file(ud.localpath)
 
 if ud.method.recommends_checksum(ud):
 # If strict checking enabled and neither sum defined, raise error
@@ -589,6 +611,66 @@ def verify_checksum(ud, d):
 if len(msg):
 raise ChecksumError('Checksum mismatch!%s' % msg, ud.url, md5data)
 
+return {
+_MD5_KEY: md5data,
+_SHA256_KEY: sha256data
+}
+
+
+def verify_donestamp(ud, d):
+"""
+Check whether the done stamp file has the right checksums (if the fetch
+method supports them). If it doesn't, delete the done stamp and force
+a re-download.
+
+Returns True, if the donestamp exists and is valid, False otherwise. When
+returning False, any existing done stamps are removed.
+"""
+if not os.path.exists(ud.donestamp):
+return False
+
+if not ud.method.supports_checksum(ud):
+# done stamp exists, checksums not supported; assume the local file is
+# current
+return True
+
+if not os.path.exists(ud.localpath):
+# done stamp exists, but the downloaded file does not; the done stamp
+# must be incorrect, re-trigger the download
+bb.utils.remove(ud.donestamp)
+return False
+
+precomputed_checksums = {}
+try:
+with open(ud.donestamp, "rb") as cachefile:
+pickled = pickle.Unpickler(cachefile)
+precomputed_checksums.update(pickled.load())
+except Exception as e:
+# Avoid the warnings on the upgrade path from emtpy done stamp files to
+# those containing the checksums.
+if not isinstance(e, EOFError):
+# Ignore errors, they aren't fatal
+logger.warn("Couldn't load checksums from donestamp %s: %s "
+"(msg: %s)" % (ud.donestamp, type(e).__name__, str(e)))
+
+try:
+checksums = verify_checksum(ud, d, precomputed_checksums)
+# If the cache file did not have the checksums, compute and store them
+# as an upgrade path from the previous done stamp file format.
+if checksums != precomputed_checksums:

[yocto] cannot compile kernel module - headers missing

2015-02-23 Thread Jens Rapp


hi,

i have a simple hello world kernel module and i cannot compile it. linux 
headers are missing

i tried to set -I $(OECORE_TARGET_SYSROOT)usr/src/kernel/include/
but there seems to be much more missing..

is there any way to do this easier?

here's what i have:

module.c
-
#include 
#include 
#include 
#include 

#include 

/**
 * initialisiert das Kernel - Modul
 */
int init_module(void) {
printk(KERN_DEBUG "Hallo Kernel!\n");
return 0;
}

void cleanup_module (void) {
printk (KERN_DEBUG "Ciao!\n");
}


and my Makefile
--
# file  Makefile
# copyright Copyright (c) 2012 Toradex AG
#   [Software License Agreement]
# author$Author$
# version   $Rev$
# date  $Date$
# brief a simple makefile to (cross) compile.
#   uses the openembedded provided sysroot and toolchain
# targetlinux on Colibri T20 / Colibri T30
# caveats   -

##
# Setup your project settings
##

# Set the input source files, the binary name and used libraries to link
SRCS = module.c
PROG := module
LIBS =
CONF_LIBS =
C_FLAGS = -D__KERNEL__ -D__SMP__ -DMODULE -DMODVERSIONS
# Set flags to the compiler and linker
CFLAGS += -O2 -g -Wall `$(PKG-CONFIG) --cflags $(CONF_LIBS)` 
$(ARCH_CFLAGS) $(C_FLAGS)

LDFLAGS += `$(PKG-CONFIG) --libs $(CONF_LIBS)`

##
# Setup your build environment
##

# Set the path to the oe built sysroot and
# Set the prefix for the cross compiler
OECORE_NATIVE_SYSROOT ?= 
$(HOME)/oe-core/build/out-eglibc/sysroots/x86_64-linux/
OECORE_TARGET_SYSROOT ?= 
$(HOME)/oe-core/build/out-eglibc/sysroots/apalis-imx6/
CROSS_COMPILE ?= 
$(OECORE_NATIVE_SYSROOT)usr/bin/armv7at2hf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-


##
# The rest of the Makefile usually needs no change
##

# Set differencies between native and cross compilation
ifneq ($(strip $(CROSS_COMPILE)),)
  LDFLAGS += -L$(OECORE_TARGET_SYSROOT)usr/lib 
-Wl,-rpath-link,$(OECORE_TARGET_SYSROOT)usr/lib 
-L$(OECORE_TARGET_SYSROOT)lib -Wl,-rpath-link,$(OECORE_TARGET_SYSROOT)lib
  ARCH_CFLAGS = -march=armv7-a -fno-tree-vectorize -mthumb-interwork 
-mfloat-abi=hard -mtune=cortex-a9

  BIN_POSTFIX =
  PKG-CONFIG = export PKG_CONFIG_SYSROOT_DIR=$(OECORE_TARGET_SYSROOT); \
   export 
PKG_CONFIG_PATH=$(OECORE_TARGET_SYSROOT)/usr/lib/pkgconfig/; \

   $(OECORE_NATIVE_SYSROOT)usr/bin/pkg-config
else
# Native compile
  PKG-CONFIG = pkg-config
  ARCH_CFLAGS =
# Append .x86 to the object files and binaries, so that native and cross 
builds can live side by side

  BIN_POSTFIX = .x86
endif

# Toolchain binaries
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)gcc
STRIP = $(CROSS_COMPILE)strip
RM = rm -f

# Sets the output filename and object files
PROG := $(PROG)$(BIN_POSTFIX)
OBJS = $(SRCS:.c=$(BIN_POSTFIX).o)
DEPS = $(OBJS:.o=.o.d)

# pull in dependency info for *existing* .o files
-include $(DEPS)

all: $(PROG)

$(PROG): $(OBJS) Makefile
$(CC) $(CFLAGS) -o $@ $(OBJS) $(LIBS) $(LDFLAGS)
#$(STRIP) $@

%$(BIN_POSTFIX).o: %.c
$(CC) -c $(CFLAGS) -o $@ $<
$(CC) -MM $(CFLAGS) $< > $@.d

clean:
$(RM) $(OBJS) $(PROG) $(DEPS)

.PHONY: all clean

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cannot compile kernel module - headers missing

2015-02-23 Thread Bruce Ashfield


On 2015-02-23 10:02 AM, Jens Rapp wrote:

hi,

i have a simple hello world kernel module and i cannot compile it. linux
headers are missing
i tried to set -I $(OECORE_TARGET_SYSROOT)usr/src/kernel/include/
but there seems to be much more missing..


What release are you using ? The kernel sources recently changed
in master (for the 1.8 release), so that could be catching you
in transition.



is there any way to do this easier?


We have an example in meta-skeleton for a hello world module.
(meta-skeleton/recipes-kernel/hello-mod/). Have a look there and
it may answer most (if not all) questions.

Bruce



here's what i have:

module.c
-
#include 
#include 
#include 
#include 

#include 

/**
  * initialisiert das Kernel - Modul
  */
int init_module(void) {
 printk(KERN_DEBUG "Hallo Kernel!\n");
 return 0;
}

void cleanup_module (void) {
 printk (KERN_DEBUG "Ciao!\n");
}


and my Makefile
--
# file  Makefile
# copyright Copyright (c) 2012 Toradex AG
#   [Software License Agreement]
# author$Author$
# version   $Rev$
# date  $Date$
# brief a simple makefile to (cross) compile.
#   uses the openembedded provided sysroot and toolchain
# targetlinux on Colibri T20 / Colibri T30
# caveats   -

##

# Setup your project settings
##


# Set the input source files, the binary name and used libraries to link
SRCS = module.c
PROG := module
LIBS =
CONF_LIBS =
C_FLAGS = -D__KERNEL__ -D__SMP__ -DMODULE -DMODVERSIONS
# Set flags to the compiler and linker
CFLAGS += -O2 -g -Wall `$(PKG-CONFIG) --cflags $(CONF_LIBS)`
$(ARCH_CFLAGS) $(C_FLAGS)
LDFLAGS += `$(PKG-CONFIG) --libs $(CONF_LIBS)`

##

# Setup your build environment
##


# Set the path to the oe built sysroot and
# Set the prefix for the cross compiler
OECORE_NATIVE_SYSROOT ?=
$(HOME)/oe-core/build/out-eglibc/sysroots/x86_64-linux/
OECORE_TARGET_SYSROOT ?=
$(HOME)/oe-core/build/out-eglibc/sysroots/apalis-imx6/
CROSS_COMPILE ?=
$(OECORE_NATIVE_SYSROOT)usr/bin/armv7at2hf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-


##

# The rest of the Makefile usually needs no change
##


# Set differencies between native and cross compilation
ifneq ($(strip $(CROSS_COMPILE)),)
   LDFLAGS += -L$(OECORE_TARGET_SYSROOT)usr/lib
-Wl,-rpath-link,$(OECORE_TARGET_SYSROOT)usr/lib
-L$(OECORE_TARGET_SYSROOT)lib -Wl,-rpath-link,$(OECORE_TARGET_SYSROOT)lib
   ARCH_CFLAGS = -march=armv7-a -fno-tree-vectorize -mthumb-interwork
-mfloat-abi=hard -mtune=cortex-a9
   BIN_POSTFIX =
   PKG-CONFIG = export PKG_CONFIG_SYSROOT_DIR=$(OECORE_TARGET_SYSROOT); \
export
PKG_CONFIG_PATH=$(OECORE_TARGET_SYSROOT)/usr/lib/pkgconfig/; \
$(OECORE_NATIVE_SYSROOT)usr/bin/pkg-config
else
# Native compile
   PKG-CONFIG = pkg-config
   ARCH_CFLAGS =
# Append .x86 to the object files and binaries, so that native and cross
builds can live side by side
   BIN_POSTFIX = .x86
endif

# Toolchain binaries
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)gcc
STRIP = $(CROSS_COMPILE)strip
RM = rm -f

# Sets the output filename and object files
PROG := $(PROG)$(BIN_POSTFIX)
OBJS = $(SRCS:.c=$(BIN_POSTFIX).o)
DEPS = $(OBJS:.o=.o.d)

# pull in dependency info for *existing* .o files
-include $(DEPS)

all: $(PROG)

$(PROG): $(OBJS) Makefile
 $(CC) $(CFLAGS) -o $@ $(OBJS) $(LIBS) $(LDFLAGS)
 #$(STRIP) $@

%$(BIN_POSTFIX).o: %.c
 $(CC) -c $(CFLAGS) -o $@ $<
 $(CC) -MM $(CFLAGS) $< > $@.d

clean:
 $(RM) $(OBJS) $(PROG) $(DEPS)

.PHONY: all clean



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, Feb. 24, 2015 8:00 AM US Pacific Time

2015-02-23 Thread Jolley, Stephen K

Tuesday, February 24, 2015 8:00 AM US Pacific Time



Agenda:



* Opens collection - 5 min (Stephen)

* Yocto Project status - 5 min (Stephen/team)

https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.8_Status

https://wiki.yoctoproject.org/wiki/Yocto_1.8_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_1.8_Features

* SWAT team rotation: Saul/Randy -> Beth

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

* Opens - 10 min

* Team Sharing - 10 min





We encourage people attending the meeting to logon the Yocto Project IRC 
chancel during the meeting (optional):



Yocto IRC: http://webchat.freenode.net/?channels=#yocto

IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html



Conference Details:

Company:   WIND RIVER SYS

Ready-Access Number: 8007302996/9139049836

Access Code: 2705751


For International numbers see: 
https://www.yoctoproject.org/tools-resources/community/weekly-technical-call


Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:  (503) 712-0534
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

2015-02-23 Thread Khem Raj


> On Feb 20, 2015, at 4:27 PM, Peter Urbanec  
> wrote:
> 
> On 21/02/15 05:03, Richard Purdie wrote:
>> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
>>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
> ...
>> For info, I've now merged the glibc part of this change now too.
> 
> It looks like the new glibc turns all gcc warnings into errors. That does not 
> seem to work too well in all cases:

you seem to be overriding default selected optimization to use -Os instead of 
-O2, with 2.21 glibc is now using -Werror by default which is a good thing
but then not all combinations have been tested out so when you override the 
default opt level then please add -Wno-error as well. May be I should just send 
a patch to detect this usecase


> 
> | mipsel-oe-linux-gcc -mel -mabi=32 -mhard-float 
> --sysroot=/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/inihdp-tcbootstrap
>  pthread_equal.c -c -std=gnu99 -fgnu89-inline  -Os -Wall -Werror -Winline 
> -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types 
> -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC
> -I../include 
> -I/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl
>   
> -I/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux
>   -I../sysdeps/unix/sysv/linux/mips/mips32/fpu  
> -I../sysdeps/unix/sysv/linux/mips/mips32  -I../sysdeps/unix/sysv/linux/mips  
> -I../sysdeps/mips/nptl  -I../sysdeps/unix/sysv/linux/include 
> -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  
> -I../sysdeps/gnu  -I..
 /!
> sysdeps/un
> ix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/mips/mips32  
> -I../sysdeps/unix/mips  -I../sysdeps/unix  -I../sysdeps/posix  
> -I../sysdeps/mips/mips32/fpu  -I../sysdeps/mips/mips32  
> -I../sysdeps/mips/ieee754  -I../sysdeps/mips/soft-fp  
> -I../sysdeps/mips/include -I../sysdeps/mips  -I../sysdeps/ieee754/flt-32  
> -I../sysdeps/ieee754/dbl-64  -I../sysdeps/wordsize-32  -I../sysdeps/mips/fpu  
> -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc 
> -isystem 
> /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/x86_64-linux/usr/lib/mipsel-oe-linux.gcc-cross-initial-mipsel/gcc/mipsel-oe-linux/4.9.2/include
>  -isystem 
> /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/x86_64-linux/usr/lib/mipsel-oe-linux.gcc-cross-initial-mipsel/gcc/mipsel-oe-linux/4.9.2/include-fixed
>  -isystem 
> /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/inihdp/usr/include
>   -D_LIBC_RE
 E!
> NTRANT -in
> clude 
> /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/libc-modules.h
>  -DMODULE_NAME=libpthread -include ../include/libc-symbols.h  -DPIC -DSHARED  
>-o 
> /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os
>  -MD -MP -MF 
> /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os.dt
>  -MT 
> /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os
> | In file included from allocatestack.c:30:0,
> |  from pthread_create.c:55:
> | allocatestack.c: In function 'stack_list_add':
> | ../include/list.h:58:1: error: inlining failed in call to 'list_add': call 
> is unlikely and code size would grow [-Werror=inline]
> |  list_add (list_t *newp, list_t *head)
> |  ^
> | In file included from pthread_create.c:55:0:
> | allocatestack.c:159:3: error: called from here [-Werror=inline]
> |list_add (elem, list);
> |^
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

2015-02-23 Thread Khem Raj


> On Feb 21, 2015, at 1:22 AM, Richard Purdie 
>  wrote:
> 
> On Fri, 2015-02-20 at 18:03 +, Richard Purdie wrote:
>> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
>>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
>>> upcoming ) on  a contrib branch ( top 2 patches) its has not got much
>>> testing besides x86 qemu thus far.
>>> 
>>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade
>>> 
>>> I would like to request some help in testing these out in your
>>> respective environments and please report any issues you see so we can
>>> start sorting them out at earlier and making its way into OE-Core.
>>> 
>>> Thanks for your help
>> 
>> For info, I've now merged the glibc part of this change now too.
>> 
>> Khem: Thanks for the work on this!
> 
> New issue that caught my eye:
> 
> https://autobuilder.yoctoproject.org/main/builders/nightly-qa-logrotate/builds/204/steps/Running%20Sanity%20Tests/logs/stdio
> 
> segfault in init within libc :/.

I have booted core-image-minimal, for all arches and that have worked fine for 
both systemd and sysvinit and some of non-oe-core graphic images booted well too
but here it seems its using core-image-sato wondering what changed there … can 
someone try it out and may be see what is it trying to launch during boot that 
is in addition
to core image minimal.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [Recipe reporting system] Upgradable recipe name list

Re: [yocto] [PATCH] Add mpich support

Re: [yocto] [psplash][PATCH] Adding support for systemd and its service files

[yocto] [PATCH] bitbake: fetch2: Revalidate checksums, YOCTO #5571

[yocto] cannot compile kernel module - headers missing

Re: [yocto] cannot compile kernel module - headers missing

[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, Feb. 24, 2015 8:00 AM US Pacific Time

Re: [yocto] [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

Re: [yocto] [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

9 matches

Site Navigation

Mail list logo

Footer information