Patches pending for merging from O.S. Systems tree
cover Patches pending for merging from O.S. Systems tree
The following changes since commit f05b7ee7716d1e5cc1ba0bbab57e91c3a0569e9e:
x-load: Update to 1.5.0 (2011-07-05 14:16:33 +0100)
are available in the git repository at:
git://github.com/OSSystems/oe-core master
https://github.com/OSSystems/oe-core/tree/master
Chris Larson (2):
Rework how the devshell functions
oe.terminal: improve how we spawn screen
Otavio Salvador (6):
cmake.bbclass: use CPPFLAGS and CXXFLAGS
cmake: refactor recipe
libarchive: add 2.8.4 version
cmake: add nativesdk and target versions
cmake: update to 2.8.5-rc3
fix SDK building due TARGET_ARCH use in installation path
meta/classes/cmake.bbclass | 8 +- meta/classes/devshell.bbclass | 26 ++--- meta/classes/populate_sdk.bbclass | 2 +- meta/classes/terminal.bbclass | 30 ++++++ meta/conf/bitbake.conf | 2 +- meta/lib/oe/classutils.py | 2 + meta/lib/oe/terminal.py | 107 ++++++++++++++++++++ meta/recipes-devtools/cmake/cmake-native_2.8.3.bb | 7 -- meta/recipes-devtools/cmake/cmake-native_2.8.5.bb | 12 ++ meta/recipes-devtools/cmake/cmake.inc | 6 +- .../cmake/cmake/dont-run-cross-binaries.patch | 22 ++++ .../cmake/cmake/support-oe-qt4-tools-names.patch | 14 ++-- meta/recipes-devtools/cmake/cmake_2.8.5.bb | 50 +++++++++ .../0001-Patch-from-upstream-revision-1990.patch | 42 ++++++++ .../0002-Patch-from-upstream-revision-1991.patch | 31 ++++++ .../0003-Patch-from-upstream-rev-2516.patch | 63 ++++++++++++ .../0004-Patch-from-upstream-rev-2514.patch | 33 ++++++ .../0005-Patch-from-upstream-rev-2520.patch | 31 ++++++ .../0006-Patch-from-upstream-rev-2521.patch | 28 +++++ ...YS-error-when-setting-up-xattrs.-Closes-5.patch | 31 ++++++ .../libarchive/libarchive_2.8.4.bb | 25 +++++ 21 files changed, 534 insertions(+), 38 deletions(-) create mode 100644 meta/classes/terminal.bbclass create mode 100644 meta/lib/oe/terminal.py delete mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.3.bb create mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.5.bb create mode 100644 meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch create mode 100644 meta/recipes-devtools/cmake/cmake_2.8.5.bb create mode 100644 meta/recipes-extended/libarchive/libarchive/0001-Patch-from-upstream-revision-1990.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0002-Patch-from-upstream-revision-1991.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0003-Patch-from-upstream-rev-2516.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0004-Patch-from-upstream-rev-2514.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0005-Patch-from-upstream-rev-2520.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0006-Patch-from-upstream-rev-2521.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0007-Ignore-ENOSYS-error-when-setting-up-xattrs.-Closes-5.patch create mode 100644 meta/recipes-extended/libarchive/libarchive_2.8.4.bb
Signature · 1 line
1.7.2.5
PATCH 1/8 Rework how the devshell functions
From: Chris Larson <[email protected]>
In the new implementation, each known terminal is defined as a class in oe.terminal, as a subclass of bb.process.Popen. terminal.bbclass wraps this functionality, providing the metadata pieces. It obeys the OE_TERMINAL variable, which is a 'choice' typed variable. This variable may be 'auto', 'none', or any of the names of the defined terminals.
When using 'auto', or requesting an unsupported terminal, we attempt to spawn them in priority order until we get one that's available on this system (and in the case of the X terminals, has DISPLAY defined). The 'none' value is used when we're doing things like automated builds, and want to ensure that no terminal is *ever* spawned, under any circumstances.
Current available terminals:
gnome
konsole
xterm
rxvt
screen
--- meta/classes/devshell.bbclass | 26 ++++------- meta/classes/terminal.bbclass | 30 ++++++++++++ meta/lib/oe/classutils.py | 2 + meta/lib/oe/terminal.py | 102 +++++++++++++++++++++++++++++++++++++++++ 4 files changed, 143 insertions(+), 17 deletions(-) create mode 100644 meta/classes/terminal.bbclass create mode 100644 meta/lib/oe/terminal.py
meta/classes/devshell.bbclass +9 -17
@@ -1,22 +1,14 @@ -do_devshell[dirs] = "${S}" -do_devshell[nostamp] = "1" +inherit terminal -XAUTHORITY ?= "${HOME}/.Xauthority" -devshell_do_devshell() { - export DISPLAY='${DISPLAY}' - export DBUS_SESSION_BUS_ADDRESS='${DBUS_SESSION_BUS_ADDRESS}' - export XAUTHORITY='${XAUTHORITY}' - export TERMWINDOWTITLE="Bitbake Developer Shell" - export EXTRA_OEMAKE='${EXTRA_OEMAKE}' - export SHELLCMDS="bash" - ${TERMCMDRUN} - if [ $? -ne 0 ]; then - echo "Fatal: '${TERMCMD}' not found. Check TERMCMD variable." - exit 1 - fi +export XAUTHORITY ?= "${HOME}/.Xauthority" +export SHELL ?= 'bash' + +python do_devshell () { + oe_terminal(d.getVar('SHELL', True), 'OpenEmbedded Developer Shell', d) } -addtask devshell after do_patch -EXPORT_FUNCTIONS do_devshell +addtask devshell after do_patch +do_devshell[dirs] = "${S}" +do_devshell[nostamp] = "1"
meta/classes/terminal.bbclass new file +30 -0
@@ -0,0 +1,30 @@ +OE_TERMINAL ?= 'auto' +OE_TERMINAL[type] = 'choice' +OE_TERMINAL[choices] = 'auto none \ + ${@" ".join(o.name \ + for o in oe.terminal.prioritized())}' + + +def oe_terminal(command, title, d): + import oe.data + import oe.terminal + + terminal = oe.data.typed_value('OE_TERMINAL', d).lower() + if terminal == 'none': + bb.fatal('Devshell usage disabled with OE_TERMINAL') + elif terminal != 'auto': + try: + oe.terminal.spawn(terminal, command, title) + return + except oe.terminal.UnsupportedTerminal: + bb.warn('Unsupported terminal "%s", defaulting to "auto"' % + terminal) + except oe.terminal.ExecutionError as exc: + bb.fatal('Unable to spawn terminal %s: %s' % (terminal, exc)) + + try: + oe.terminal.spawn_preferred(command, title) + except oe.terminal.NoSupportedTerminals: + bb.fatal('No valid terminal found, unable to open devshell') + except oe.terminal.ExecutionError as exc: + bb.fatal('Unable to spawn terminal %s: %s' % (terminal, exc))
meta/lib/oe/classutils.py +2 -0
@@ -1,3 +1,5 @@ +__author__ = 'kergoth' + class ClassRegistry(type): """Maintain a registry of classes, indexed by name.
meta/lib/oe/terminal.py new file +102 -0
102 lines not on this page · raw message
Signature · 1 line
1.7.2.5
Re: [PATCH 1/8] Rework how the devshell functions
Quoted 46 lines · Otavio Salvador
From: Chris Larson <[email protected]>
In the new implementation, each known terminal is defined as a class in oe.terminal, as a subclass of bb.process.Popen. terminal.bbclass wraps this functionality, providing the metadata pieces. It obeys the
OE_TERMINALvariable, which is a 'choice' typed variable. This variable may be 'auto', 'none', or any of the names of the defined terminals.When using 'auto', or requesting an unsupported terminal, we attempt to spawn them in priority order until we get one that's available on this system (and in the case of the X terminals, has DISPLAY defined). The 'none' value is used when we're doing things like automated builds, and want to ensure that no terminal is *ever* spawned, under any circumstances.
Current available terminals:
gnome
konsole
xterm
rxvt
screenSigned-off-by Chris Larson <[email protected]>Signed-off-by Otavio Salvador <[email protected]>--- meta/classes/devshell.bbclass | 26 ++++------- meta/classes/terminal.bbclass | 30 ++++++++++++ meta/lib/oe/classutils.py | 2 + meta/lib/oe/terminal.py | 102 +++++++++++++++++++++++++++++++++++++++++ 4 files changed, 143 insertions(+), 17 deletions(-) create mode 100644 meta/classes/terminal.bbclass create mode 100644 meta/lib/oe/terminal.pymeta/classes/devshell.bbclass +1
-5@@ -1,22 +1,14 @@ -do_devshell[dirs] = "${S}" -do_devshell[nostamp] = "1" +inherit terminal -XAUTHORITY ?= "${HOME}/.Xauthority" -devshell_do_devshell() { - export DISPLAY='${DISPLAY}'
meta/classes/devshell.bbclass line 17
Quoted 10 lines
meta/classes/devshell.bbclass +0
-10- export DBUS_SESSION_BUS_ADDRESS='${DBUS_SESSION_BUS_ADDRESS}' - export XAUTHORITY='${XAUTHORITY}' - export TERMWINDOWTITLE="Bitbake Developer Shell" - export EXTRA_OEMAKE='${EXTRA_OEMAKE}' - export SHELLCMDS="bash" - ${TERMCMDRUN} - if [ $? -ne 0 ]; then - echo "Fatal: '${TERMCMD}' not found. Check TERMCMD variable." - exit 1 - fi
For reference, the reason I keep putting off merging this is that there are a number of variables above that were added there for a reason (e.g. DBUS_SESSION_BUS_ADDRESS) and this patch wipes them out.
The patch therefore makes someone's usecase work better and the expense of breaking some others and to me that doesn't make a good patch.
I'm the first to agree that the bitbake environment handling sucks, badly. It would be nice if there were some way we could save off the original environment and then restore it under certain conditions which would then make the need for gross code like the above go away. Likely that would need changes at the bitbake level but I think we need to try and fix this problem properly...
[I'm fine with the other changes that patch makes, I just worry about the environment bits]
Cheers,
Richard
PATCH 2/8 oe.terminal: improve how we spawn screen
In reply to Otavio SalvadorFrom: Chris Larson <[email protected]>
- Name the screen session 'devshell', to avoid confusion if running bitbake itself under a screen session.
- Display a warning message when spawning screen, so it's clear to the user that screen has been run (otherwise do_devshell just appears to hang).
--- meta/lib/oe/terminal.py | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)
meta/lib/oe/terminal.py +6 -1
@@ -71,7 +71,12 @@ class Rxvt(XTerminal): priority = 1 class Screen(Terminal): - command = 'screen -D -m -t "{title}" {command}' + command = 'screen -D -m -t "{title}" -S devshell {command}' + + def __init__(self, command, title=None): + Terminal.__init__(self, command, title) + logger.warn('Screen started. Please connect in another terminal with ' + '"screen -r devshell"') def prioritized():
Signature · 1 line
1.7.2.5
PATCH 3/8 cmake.bbclass: use CPPFLAGS and CXXFLAGS
In reply to Otavio SalvadorSome classes, as for example nativesdk, defines CPPFLAGS and CXXFLAGS to be passed to compiler. Using those makes more sense and avoid some hacks on packages using CMake.
--- meta/classes/cmake.bbclass | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)
meta/classes/cmake.bbclass +4 -4
@@ -19,10 +19,10 @@ OECMAKE_C_COMPILER ?= "`echo ${CC} | sed 's/^\([^ ]*\).*/\1/'`" OECMAKE_CXX_COMPILER ?= "`echo ${CXX} | sed 's/^\([^ ]*\).*/\1/'`" # Compiler flags -OECMAKE_C_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${TARGET_CPPFLAGS}" -OECMAKE_CXX_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${TARGET_CPPFLAGS} -fpermissive" -OECMAKE_C_FLAGS_RELEASE ?= "${SELECTED_OPTIMIZATION} -DNDEBUG" -OECMAKE_CXX_FLAGS_RELEASE ?= "${SELECTED_OPTIMIZATION} -DNDEBUG" +OECMAKE_C_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CPPFLAGS}" +OECMAKE_CXX_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CXXFLAGS} -fpermissive" +OECMAKE_C_FLAGS_RELEASE ?= "${SELECTED_OPTIMIZATION} ${CPPFLAGS} -DNDEBUG" +OECMAKE_CXX_FLAGS_RELEASE ?= "${SELECTED_OPTIMIZATION} ${CXXFLAGS} -DNDEBUG" OECMAKE_RPATH ?= ""
Signature · 1 line
1.7.2.5
Richard Purdie
AppliedRe: [PATCH 3/8] cmake.bbclass: use CPPFLAGS and CXXFLAGS
Quoted 8 lines · Otavio Salvador
Some classes, as for example nativesdk, defines CPPFLAGS and CXXFLAGS to be passed to compiler. Using those makes more sense and avoid some hacks on packages using CMake.
Signed-off-by Otavio Salvador <[email protected]>--- meta/classes/cmake.bbclass | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)
Merged to master, thanks.
Richard
PATCH 4/8 cmake: refactor recipe
In reply to Otavio Salvador * use INC_PR;
* show configure's failure on error;
* gather major version from PV;
--- meta/recipes-devtools/cmake/cmake-native_2.8.3.bb | 4 ++-- meta/recipes-devtools/cmake/cmake.inc | 6 +++++- 2 files changed, 7 insertions(+), 3 deletions(-)
meta/recipes-devtools/cmake/cmake-native_2.8.3.bb +2 -2
@@ -1,7 +1,7 @@ -CMAKE_MAJOR_VERSION="2.8" require cmake.inc inherit native -PR = "r1" + +PR = "${INC_PR}.1" SRC_URI[md5sum] = "a76a44b93acf5e3badda9de111385921" SRC_URI[sha256sum] = "689ed02786b5cefa5515c7716784ee82a82e8ece6be5a3d629ac3cc0c05fc288"
meta/recipes-devtools/cmake/cmake.inc +5 -1
@@ -9,11 +9,15 @@ LICENSE = "BSD" LIC_FILES_CHKSUM = "file://Copyright.txt;md5=f372516292ff7c33337bf16a74a5f9a8 \ file://Source/cmake.h;beginline=1;endline=10;md5=341736dae83c9e344b53eeb1bc7d7bc2" +INC_PR = "r1" + +CMAKE_MAJOR_VERSION = "${@'.'.join(bb.data.getVar('PV',d,1).split('.')[0:2])}" + SRC_URI = "http://www.cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \ file://support-oe-qt4-tools-names.patch" inherit autotools do_configure () { - ./configure --prefix=${prefix} || die "./bootstrap failed" + ./configure --prefix=${prefix} }
Signature · 1 line
1.7.2.5
Richard Purdie
AppliedRe: [PATCH 4/8] cmake: refactor recipe
Quoted 5 lines · Otavio Salvador
* use
INC_PR;
* show configure's failure on error;
* gather major version from PV;Signed-off-by Otavio Salvador <[email protected]>
Merged to master, thanks.
Richard
PATCH 5/8 libarchive: add 2.8.4 version
In reply to Otavio SalvadorThis recipe has been imported from OpenEmbedded (rev 6db4b9050e0e8b963e2a6b63790e48e3042ea99e).
--- .../0001-Patch-from-upstream-revision-1990.patch | 42 +++++++++++++ .../0002-Patch-from-upstream-revision-1991.patch | 31 ++++++++++ .../0003-Patch-from-upstream-rev-2516.patch | 63 ++++++++++++++++++++ .../0004-Patch-from-upstream-rev-2514.patch | 33 ++++++++++ .../0005-Patch-from-upstream-rev-2520.patch | 31 ++++++++++ .../0006-Patch-from-upstream-rev-2521.patch | 28 +++++++++ ...YS-error-when-setting-up-xattrs.-Closes-5.patch | 31 ++++++++++ .../libarchive/libarchive_2.8.4.bb | 25 ++++++++ 8 files changed, 284 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-extended/libarchive/libarchive/0001-Patch-from-upstream-revision-1990.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0002-Patch-from-upstream-revision-1991.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0003-Patch-from-upstream-rev-2516.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0004-Patch-from-upstream-rev-2514.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0005-Patch-from-upstream-rev-2520.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0006-Patch-from-upstream-rev-2521.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0007-Ignore-ENOSYS-error-when-setting-up-xattrs.-Closes-5.patch create mode 100644 meta/recipes-extended/libarchive/libarchive_2.8.4.bb
meta/recipes-extended/libarchive/libarchive/0001-Patch-from-upstream-revision-1990.patch new file +42 -0
@@ -0,0 +1,42 @@ +libarchive: Backport patch from upstream (revision 1990) + +Upstream-Status: Backport + +Signed-off-by: Otavio Salvador <[email protected]> + +diff --git a/libarchive/archive_read_disk_entry_from_file.c b/libarchive/archive_read_disk_entry_from_file.c +index 7473c50..27671df 100644 +--- a/libarchive/archive_read_disk_entry_from_file.c ++++ b/libarchive/archive_read_disk_entry_from_file.c +@@ -163,15 +163,26 @@ archive_read_disk_entry_from_file(struct archive *_a, + + #ifdef HAVE_READLINK + if (S_ISLNK(st->st_mode)) { +- char linkbuffer[PATH_MAX + 1]; +- int lnklen = readlink(path, linkbuffer, PATH_MAX); ++ size_t linkbuffer_len = st->st_size + 1; ++ char *linkbuffer; ++ int lnklen; ++ ++ linkbuffer = malloc(linkbuffer_len); ++ if (linkbuffer == NULL) { ++ archive_set_error(&a->archive, ENOMEM, ++ "Couldn't read link data"); ++ return (ARCHIVE_FAILED); ++ } ++ lnklen = readlink(path, linkbuffer, linkbuffer_len); + if (lnklen < 0) { + archive_set_error(&a->archive, errno, + "Couldn't read link data"); ++ free(linkbuffer); + return (ARCHIVE_FAILED); + } + linkbuffer[lnklen] = 0; + archive_entry_set_symlink(entry, linkbuffer); ++ free(linkbuffer); + } + #endif + +-- +1.7.1 +
meta/recipes-extended/libarchive/libarchive/0002-Patch-from-upstream-revision-1991.patch new file +31 -0
@@ -0,0 +1,31 @@ +libarchive: Backport patch from upstream (revision 1991) + +Upstream-Status: Backport + +Signed-off-by: Otavio Salvador <[email protected]> + +diff --git a/libarchive/archive_write_disk.c b/libarchive/archive_write_disk.c +index caf958e..60699e0 100644 +--- a/libarchive/archive_write_disk.c ++++ b/libarchive/archive_write_disk.c +@@ -434,7 +434,7 @@ _archive_write_header(struct archive *_a, struct archive_entry *entry) + if (ret != ARCHIVE_OK) + goto done; + } +-#ifdef HAVE_FCHDIR ++#if defined(HAVE_FCHDIR) && defined(PATH_MAX) + /* If path exceeds PATH_MAX, shorten the path. */ + edit_deep_directories(a); + #endif +@@ -866,7 +866,7 @@ archive_write_disk_new(void) + * object creation is likely to fail, but any error will get handled + * at that time. + */ +-#ifdef HAVE_FCHDIR ++#if defined(HAVE_FCHDIR) && defined(PATH_MAX) + static void + edit_deep_directories(struct archive_write_disk *a) + { +-- +1.7.1 +
meta/recipes-extended/libarchive/libarchive/0003-Patch-from-upstream-rev-2516.patch new file +63 -0
63 lines not on this page · raw message
meta/recipes-extended/libarchive/libarchive/0004-Patch-from-upstream-rev-2514.patch new file +33 -0
@@ -0,0 +1,33 @@ +libarchive: Backport patch from upstream (rev 2514) + +Enable version stripping code in joliet extension support for iso9660. + +http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587316 + +Upstream-Status: Backport + +Signed-off-by: Otavio Salvador <[email protected]> + +diff --git a/libarchive/archive_read_support_format_iso9660.c b/libarchive/archive_read_support_format_iso9660.c +index fdef3fb..8dcfeb4 100644 +--- a/libarchive/archive_read_support_format_iso9660.c ++++ b/libarchive/archive_read_support_format_iso9660.c +@@ -1755,7 +1755,6 @@ parse_file_info(struct archive_read *a, struct file_info *parent, + } + *wp = L'\0'; + +-#if 0 /* untested code, is it at all useful on Joliet? */ + /* trim trailing first version and dot from filename. + * + * Remember we where in UTF-16BE land! +@@ -1775,7 +1774,6 @@ parse_file_info(struct archive_read *a, struct file_info *parent, + /* Chop off trailing '.' from filenames. */ + if (*(wp-1) == '.') + *(--wp) = L'\0'; +-#endif + + /* store the result in the file name field. */ + archive_strappend_w_utf8(&file->name, wbuff); +-- +1.7.1 +
meta/recipes-extended/libarchive/libarchive/0005-Patch-from-upstream-rev-2520.patch new file +31 -0
@@ -0,0 +1,31 @@ +libarchive: Backport patch from upstream (rev 2520) + +Fix version/dot stripping code in joliet extension of iso9660. + +Upstream-Status: Backport + +Signed-off-by: Otavio Salvador <[email protected]> + +diff --git a/libarchive/archive_read_support_format_iso9660.c b/libarchive/archive_read_support_format_iso9660.c +index 8dcfeb4..2d3a855 100644 +--- a/libarchive/archive_read_support_format_iso9660.c ++++ b/libarchive/archive_read_support_format_iso9660.c +@@ -1766,13 +1766,13 @@ parse_file_info(struct archive_read *a, struct file_info *parent, + * *, /, :, ;, ? and \. + */ + /* Chop off trailing ';1' from files. */ +- if (*(wp-2) == ';' && *(wp-1) == '1') { ++ if (*(wp-2) == L';' && *(wp-1) == L'1') { + wp-=2; + *wp = L'\0'; + } + + /* Chop off trailing '.' from filenames. */ +- if (*(wp-1) == '.') ++ if (*(wp-1) == L'.') + *(--wp) = L'\0'; + + /* store the result in the file name field. */ +-- +1.7.1 +
meta/recipes-extended/libarchive/libarchive/0006-Patch-from-upstream-rev-2521.patch new file +28 -0
@@ -0,0 +1,28 @@ +libarchive: Backport patch from upstream (rev 2521). + +Disable dot stripping code since it's still broken +and noone has been able to figure it out (yet). + +Upstream-Status: Backport + +Signed-off-by: Otavio Salvador <[email protected]> + +diff --git a/libarchive/archive_read_support_format_iso9660.c b/libarchive/archive_read_support_format_iso9660.c +index 2d3a855..8661532 100644 +--- a/libarchive/archive_read_support_format_iso9660.c ++++ b/libarchive/archive_read_support_format_iso9660.c +@@ -1771,9 +1771,11 @@ parse_file_info(struct archive_read *a, struct file_info *parent, + *wp = L'\0'; + } + ++#if 0 /* XXX: this somehow manages to strip of single-character file extensions, like '.c'. */ + /* Chop off trailing '.' from filenames. */ + if (*(wp-1) == L'.') + *(--wp) = L'\0'; ++#endif + + /* store the result in the file name field. */ + archive_strappend_w_utf8(&file->name, wbuff); +-- +1.7.1 +
meta/recipes-extended/libarchive/libarchive/0007-Ignore-ENOSYS-error-when-setting-up-xattrs.-Closes-5.patch new file +31 -0
@@ -0,0 +1,31 @@ +libarchive: Ignore ENOSYS error when setting up xattrs. (Closes: #588925) + +Modestas Vainius found out that HPPA returns errno ENOSYS +on listxattrs. Currently, ENOTSUP is ignored so we'll do the +same for ENOSYS as well. + +For full debug info about this see Modestas Vainius awesome +report at: + +http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588925#10 + +Upstream-Status: Pending + +Signed-off-by: Otavio Salvador <[email protected]> + +diff --git a/libarchive/archive_read_disk_entry_from_file.c b/libarchive/archive_read_disk_entry_from_file.c +index 27671df..c49e755 100644 +--- a/libarchive/archive_read_disk_entry_from_file.c ++++ b/libarchive/archive_read_disk_entry_from_file.c +@@ -398,7 +398,7 @@ setup_xattrs(struct archive_read_disk *a, + list_size = listxattr(path, NULL, 0); + + if (list_size == -1) { +- if (errno == ENOTSUP) ++ if (errno == ENOTSUP || errno == ENOSYS) + return (ARCHIVE_OK); + archive_set_error(&a->archive, errno, + "Couldn't list extended attributes"); +-- +1.7.1 +
meta/recipes-extended/libarchive/libarchive_2.8.4.bb new file +25 -0
@@ -0,0 +1,25 @@ +DESCRIPTION = "C library and command-line tools for reading and writing tar, cpio, zip, ISO, and other archive formats" +HOMEPAGE = "http://code.google.com/p/libarchive/" +SECTION = "devel" +LICENSE = "BSD" +LIC_FILES_CHKSUM = "file://COPYING;md5=4255e2e6f0349a4ac8fbd68459296e46" +PR = "r0" + +DEPENDS = "libxml2" + +SRC_URI = "http://libarchive.googlecode.com/files/libarchive-${PV}.tar.gz \ + file://0001-Patch-from-upstream-revision-1990.patch \ + file://0002-Patch-from-upstream-revision-1991.patch \ + file://0003-Patch-from-upstream-rev-2516.patch \ + file://0004-Patch-from-upstream-rev-2514.patch \ + file://0005-Patch-from-upstream-rev-2520.patch \ + file://0006-Patch-from-upstream-rev-2521.patch \ + file://0007-Ignore-ENOSYS-error-when-setting-up-xattrs.-Closes-5.patch \ + " + +SRC_URI[md5sum] = "83b237a542f27969a8d68ac217dc3796" +SRC_URI[sha256sum] = "86cffa3eaa28d3116f5d0b20284026c3762cf4a2b52b9844df2b494d4a89f688" + +inherit autotools lib_package + +BBCLASSEXTEND = "nativesdk"
Signature · 1 line
1.7.2.5
Re: [PATCH 5/8] libarchive: add 2.8.4 version
Quoted 2 lines · Otavio Salvador
This recipe has been imported from OpenEmbedded (rev
6db4b9050e0e8b963e2a6b63790e48e3042ea99e).
The piece of data I don't have here is the reason we need this OE-Core?
Cheers,
Richard
Re: [PATCH 5/8] libarchive: add 2.8.4 version
Quoted 5 lines · Richard Purdie
Quoted 2 lines · Otavio Salvador
This recipe has been imported from OpenEmbedded (rev
6db4b9050e0e8b963e2a6b63790e48e3042ea99e).The piece of data I don't have here is the reason we need this OE-Core?
cmake uses it.
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Re: [PATCH 5/8] libarchive: add 2.8.4 version
Quoted 9 lines · Otavio Salvador
Quoted 5 lines · Richard Purdie
Quoted 2 lines · Otavio Salvador
This recipe has been imported from OpenEmbedded (rev
6db4b9050e0e8b963e2a6b63790e48e3042ea99e).The piece of data I don't have here is the reason we need this OE-Core?
cmake uses it.
How did we get away without that for cmake-native? :/
Cheers,
Richard
Re: [PATCH 5/8] libarchive: add 2.8.4 version
Quoted 4 lines · Richard Purdie
Quoted 3 lines · Otavio Salvador
Quoted 1 line · Richard Purdie
On Fri, 2011-07-08 at 13:47 +0000, Otavio Salvador wrote:
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
This recipe has been imported from OpenEmbedded (rev
6db4b9050e0e8b963e2a6b63790e48e3042ea99e).The piece of data I don't have here is the reason we need this OE-Core?
cmake uses it.
How did we get away without that for cmake-native? :/
It can use the internal one but is wrong; I will work on that for next mergings.
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
PATCH 6/8 cmake: add nativesdk and target versions
In reply to Otavio SalvadorAdds a recipe that provides the nativesdk and target versions of CMake.
This recipe is based on code from OpenEmbeeded (rev b1f2e1501c19540617a829b37415c0616101c7ad).
--- .../cmake/cmake/dont-run-cross-binaries.patch | 22 ++++++++++ meta/recipes-devtools/cmake/cmake_2.8.3.bb | 45 ++++++++++++++++++++ 2 files changed, 67 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch create mode 100644 meta/recipes-devtools/cmake/cmake_2.8.3.bb
meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch new file +22 -0
@@ -0,0 +1,22 @@ +cmake: don't run cross-binaries on host machine + +When doing the cross build we obviously cannot run those binaries on +host since they can be binary incompatible. + +Upstream-Status: Inappropriate [embedded specific] + +Signed-off-by: Otavio Salvador <[email protected]> + +diff -ru cmake-2.8.2.orig/CMakeLists.txt cmake-2.8.2/CMakeLists.txt +--- cmake-2.8.2.orig/CMakeLists.txt 2010-07-28 00:48:42.000000000 +0200 ++++ cmake-2.8.2/CMakeLists.txt 2010-07-28 01:05:17.000000000 +0200 +@@ -518,7 +518,8 @@ + + # build the remaining subdirectories + ADD_SUBDIRECTORY(Source) +-ADD_SUBDIRECTORY(Utilities) ++# Come on! Running the cross-binaries on host is not a good idea. ++#ADD_SUBDIRECTORY(Utilities) + ADD_SUBDIRECTORY(Tests) + + # add a test
meta/recipes-devtools/cmake/cmake_2.8.3.bb new file +45 -0
45 lines not on this page · raw message
Signature · 1 line
1.7.2.5
Re: [PATCH 6/8] cmake: add nativesdk and target versions
Quoted 8 lines · Otavio Salvador
Adds a recipe that provides the nativesdk and target versions of CMake.
This recipe is based on code from OpenEmbeeded (rev
b1f2e1501c19540617a829b37415c0616101c7ad).Signed-off-by Otavio Salvador <[email protected]>---
[...]
meta/recipes-devtools/cmake/cmake_2.8.3.bb line 40
Quoted 5 lines
meta/recipes-devtools/cmake/cmake_2.8.3.bb new file +5
-0+# FIXME: Hack due gcc-crosssdk not being able to detect those automatically +CXXFLAGS_virtclass-nativesdk += " \ + -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++ \ + -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++/${TARGET_SYS} \ + "
I get worried when I see things like this :(
Has anyone attempted to work out why gcc-crosssdk can't locate c++ include files?
Cheers,
Richard
Re: [PATCH 6/8] cmake: add nativesdk and target versions
Quoted 19 lines · Richard Purdie
Quoted 8 lines · Otavio Salvador
Adds a recipe that provides the nativesdk and target versions of CMake.
This recipe is based on code from OpenEmbeeded (rev
b1f2e1501c19540617a829b37415c0616101c7ad).Signed-off-by Otavio Salvador <[email protected]>---
[...]
meta/recipes-devtools/cmake/cmake_2.8.3.bb line 40
Quoted 5 lines
meta/recipes-devtools/cmake/cmake_2.8.3.bb new file +5
-0+# FIXME: Hack due gcc-crosssdk not being able to detect those automatically +CXXFLAGS_virtclass-nativesdk += " \ + -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++ \ + -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++/${TARGET_SYS} \ + "I get worried when I see things like this :(
Quoted 2 lines
Has anyone attempted to work out why gcc-crosssdk can't locate c++ include files?
Not sure why but this is the same things as done on qt4-tools-nativesdk.
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Re: [PATCH 6/8] cmake: add nativesdk and target versions
Quoted 6 lines · On Friday 08 July 2011 16:49:12 Otavio Salvador wrote:
Quoted 6 lines
Quoted 5 lines
+# FIXME: Hack due gcc-crosssdk not being able to detect those automatically +CXXFLAGS_virtclass-nativesdk += " \
(quoted diff) +2
-0+ -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++ \ + -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++/${TARGET_SYS}\ + "
Quoted 6 lines
Quoted 4 lines
I get worried when I see things like this :(
Has anyone attempted to work out why gcc-crosssdk can't locate c++ include files?
Not sure why but this is the same things as done on qt4-tools-nativesdk.
Yes, and I don't like it there either. Suggestions on fixing this would be welcome - in the time I spent trying to figure out why it wasn't working (some months ago) I couldn't find the cause.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Re: [PATCH 6/8] cmake: add nativesdk and target versions
Quoted 9 lines · Paul Eggleton
Quoted 8 lines · On Friday 08 July 2011 16:49:12 Otavio Salvador wrote:
Quoted 8 lines
Quoted 5 lines
+# FIXME: Hack due gcc-crosssdk not being able to detect those automatically +CXXFLAGS_virtclass-nativesdk += " \
(quoted diff) +2
-0+ -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++ \ + -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++/${TARGET_SYS}\ + "
I get worried when I see things like this :(
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Has anyone attempted to work out why gcc-crosssdk can't locate c++ include files?
Not sure why but this is the same things as done on qt4-tools-nativesdk.
Yes, and I don't like it there either. Suggestions on fixing this would be welcome - in the time I spent trying to figure out why it wasn't working (some months ago) I couldn't find the cause.
Ok, I'm not happy but I guess this can go as is for now.
Paul: Can you open a bug against that being needed please?
So I'll merge libarchive and the cmake updates...
Cheers,
Richard
Re: [PATCH 6/8] cmake: add nativesdk and target versions
Quoted 8 lines · On Friday 08 July 2011 17:22:31 Richard Purdie wrote:
Quoted 3 lines · Paul Eggleton
Yes, and I don't like it there either. Suggestions on fixing this would be welcome - in the time I spent trying to figure out why it wasn't working (some months ago) I couldn't find the cause.
Ok, I'm not happy but I guess this can go as is for now.
Paul: Can you open a bug against that being needed please?
Done:
http://bugzilla.pokylinux.org/show_bug.cgi?id=1231
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
PATCH 7/8 cmake: update to 2.8.5-rc3
In reply to Otavio Salvador---
meta/recipes-devtools/cmake/cmake-native_2.8.3.bb | 7 -------
meta/recipes-devtools/cmake/cmake-native_2.8.5.bb | 12 ++++++++++++
.../cmake/cmake/support-oe-qt4-tools-names.patch | 14 +++++++-------
.../cmake/{cmake_2.8.3.bb => cmake_2.8.5.bb} | 9 +++++++--
4 files changed, 26 insertions(+), 16 deletions(-)
delete mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.3.bb
create mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.5.bb
rename meta/recipes-devtools/cmake/{cmake_2.8.3.bb => cmake_2.8.5.bb} (76%)meta/recipes-devtools/cmake/cmake-native_2.8.3.bb deleted +0 -7
@@ -1,7 +0,0 @@ -require cmake.inc -inherit native - -PR = "${INC_PR}.1" - -SRC_URI[md5sum] = "a76a44b93acf5e3badda9de111385921" -SRC_URI[sha256sum] = "689ed02786b5cefa5515c7716784ee82a82e8ece6be5a3d629ac3cc0c05fc288"
meta/recipes-devtools/cmake/cmake-native_2.8.5.bb new file +12 -0
@@ -0,0 +1,12 @@ +require cmake.inc +inherit native + +# This was need to keep version consistent - will be removed once 2.8.5 is released +SRC_URI = "http://www.cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-2.8.5-rc3.tar.gz \ + file://support-oe-qt4-tools-names.patch" +S = "${WORKDIR}/cmake-2.8.5-rc3" + +PR = "${INC_PR}.0" + +SRC_URI[md5sum] = "2d8018f8fa4c499e2c5b288d71660cba" +SRC_URI[sha256sum] = "2987befc451f6404ea93bb99f00a38b80724fb655f121fed3bb0a08b65a771c8"
meta/recipes-devtools/cmake/cmake/support-oe-qt4-tools-names.patch +7 -7
@@ -29,14 +29,14 @@ Signed-off-by: Otavio Salvador <[email protected]> - NAMES moc-qt4 moc + NAMES moc-qt4 moc4 moc PATHS ${QT_BINARY_DIR} - NO_DEFAULT_PATH + NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH ) FIND_PROGRAM(QT_UIC_EXECUTABLE - NAMES uic-qt4 uic + NAMES uic-qt4 uic4 uic PATHS ${QT_BINARY_DIR} - NO_DEFAULT_PATH + NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH ) @@ -1006,49 +1006,49 @@ )
@@ -45,35 +45,35 @@ Signed-off-by: Otavio Salvador <[email protected]> - NAMES rcc + NAMES rcc4 rcc PATHS ${QT_BINARY_DIR} - NO_DEFAULT_PATH + NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH ) FIND_PROGRAM(QT_DBUSCPP2XML_EXECUTABLE - NAMES qdbuscpp2xml + NAMES qdbuscpp2xml4 qdbuscpp2xml PATHS ${QT_BINARY_DIR} - NO_DEFAULT_PATH + NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH ) FIND_PROGRAM(QT_DBUSXML2CPP_EXECUTABLE - NAMES qdbusxml2cpp + NAMES qdbusxml2cpp4 qdbusxml2cpp PATHS ${QT_BINARY_DIR} - NO_DEFAULT_PATH + NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH ) FIND_PROGRAM(QT_LUPDATE_EXECUTABLE - NAMES lupdate-qt4 lupdate + NAMES lupdate-qt4 lupdate4 lupdate PATHS ${QT_BINARY_DIR} - NO_DEFAULT_PATH + NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH ) FIND_PROGRAM(QT_LRELEASE_EXECUTABLE - NAMES lrelease-qt4 lrelease + NAMES lrelease-qt4 lrelease4 lrelease PATHS ${QT_BINARY_DIR} - NO_DEFAULT_PATH + NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH ) FIND_PROGRAM(QT_QCOLLECTIONGENERATOR_EXECUTABLE
meta/recipes-devtools/cmake/cmake_2.8.5.bb renamed from meta/recipes-devtools/cmake/cmake_2.8.3.bb +7 -2
@@ -6,10 +6,15 @@ DEPENDS += "curl expat zlib libarchive ncurses" PR = "${INC_PR}.0" +# This was need to keep version consistent - will be removed once 2.8.5 is released +SRC_URI = "http://www.cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-2.8.5-rc3.tar.gz \ + file://support-oe-qt4-tools-names.patch" +S = "${WORKDIR}/cmake-2.8.5-rc3" + SRC_URI += "file://dont-run-cross-binaries.patch" -SRC_URI[md5sum] = "a76a44b93acf5e3badda9de111385921" -SRC_URI[sha256sum] = "689ed02786b5cefa5515c7716784ee82a82e8ece6be5a3d629ac3cc0c05fc288" +SRC_URI[md5sum] = "2d8018f8fa4c499e2c5b288d71660cba" +SRC_URI[sha256sum] = "2987befc451f6404ea93bb99f00a38b80724fb655f121fed3bb0a08b65a771c8" # Strip ${prefix} from ${docdir}, set result into docdir_stripped python () {
Signature · 1 line
1.7.2.5
Re: [PATCH 7/8] cmake: update to 2.8.5-rc3
Quoted 10 lines · Otavio Salvador
Signed-off-by Otavio Salvador <[email protected]>--- meta/recipes-devtools/cmake/cmake-native_2.8.3.bb | 7 ------- meta/recipes-devtools/cmake/cmake-native_2.8.5.bb | 12 ++++++++++++ .../cmake/cmake/support-oe-qt4-tools-names.patch | 14 +++++++------- .../cmake/{cmake_2.8.3.bb => cmake_2.8.5.bb} | 9 +++++++-- 4 files changed, 26 insertions(+), 16 deletions(-) delete mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.3.bb create mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.5.bb rename meta/recipes-devtools/cmake/{cmake_2.8.3.bb => cmake_2.8.5.bb} (76%)
What is the reason for moving to an -rcX release? When is the main release likely to be made?
Cheers,
Richard
Re: [PATCH 7/8] cmake: update to 2.8.5-rc3
Quoted 12 lines · Richard Purdie
Quoted 10 lines · Otavio Salvador
Signed-off-by Otavio Salvador <[email protected]>---
meta/recipes-devtools/cmake/cmake-native_2.8.3.bb | 7 ------- meta/recipes-devtools/cmake/cmake-native_2.8.5.bb | 12 ++++++++++++ .../cmake/cmake/support-oe-qt4-tools-names.patch | 14 +++++++------- .../cmake/{cmake_2.8.3.bb => cmake_2.8.5.bb} | 9 +++++++-- 4 files changed, 26 insertions(+), 16 deletions(-)delete mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.3.bb create mode 100644 meta/recipes-devtools/cmake/cmake-native_2.8.5.bb rename meta/recipes-devtools/cmake/{cmake_2.8.3.bb => cmake_2.8.5.bb} (76%)
Quoted 2 lines
What is the reason for moving to an -rcX release? When is the main release likely to be made?
Saul asked me to update it since the current one has some license issues that he wants fixed for M2; by the way, this patch has been fixed in my branch to fix a build failure so take the github one, not this (I can send an update patch to ml but seems not worth if not required).
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
PATCH 8/8 fix SDK building due TARGET_ARCH use in installation path
In reply to Otavio SalvadorTARGET_ARCH makes the building too fragile since it changes during building of target and nativesdk binaries thus making it difficult to handle a proper path for installation of binaries. The fix for it is to move it to toolchain tarball name.
--- meta/classes/populate_sdk.bbclass | 2 +- meta/conf/bitbake.conf | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
meta/classes/populate_sdk.bbclass +1 -1
@@ -9,7 +9,7 @@ SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${TARGET_SYS}" TOOLCHAIN_HOST_TASK ?= "task-sdk-host-nativesdk task-cross-canadian-${TRANSLATED_TARGET_ARCH}" TOOLCHAIN_TARGET_TASK ?= "task-core-standalone-sdk-target task-core-standalone-sdk-target-dbg" -TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${DISTRO_VERSION}" +TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-${SDK_ARCH}-${TARGET_ARCH}-toolchain-${DISTRO_VERSION}" RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}" DEPENDS = "virtual/fakeroot-native sed-native"
meta/conf/bitbake.conf +1 -1
@@ -341,7 +341,7 @@ DEPLOY_DIR_TOOLS = "${DEPLOY_DIR}/tools" PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}" -SDK_NAME = "oecore-${SDK_ARCH}-${TARGET_ARCH}" +SDK_NAME = "oecore-sdk-${DISTRO}" SDKPATH = "/usr/local/${SDK_NAME}" SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"
Signature · 1 line
1.7.2.5
Re: [PATCH 8/8] fix SDK building due TARGET_ARCH use in installation path
Quoted 29 lines · Otavio Salvador
TARGET_ARCHmakes the building too fragile since it changes during building of target and nativesdk binaries thus making it difficult to handle a proper path for installation of binaries. The fix for it is to move it to toolchain tarball name.Signed-off-by Otavio Salvador <[email protected]>--- meta/classes/populate_sdk.bbclass | 2 +- meta/conf/bitbake.conf | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)meta/classes/populate_sdk.bbclass +1
-1@@ -9,7 +9,7 @@ SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${TARGET_SYS}" TOOLCHAIN_HOST_TASK ?= "task-sdk-host-nativesdk task-cross-canadian-${TRANSLATED_TARGET_ARCH}" TOOLCHAIN_TARGET_TASK ?= "task-core-standalone-sdk-target task-core-standalone-sdk-target-dbg" -TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${DISTRO_VERSION}" +TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-${SDK_ARCH}-${TARGET_ARCH}-toolchain-${DISTRO_VERSION}" RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}" DEPENDS = "virtual/fakeroot-native sed-native"meta/conf/bitbake.conf +0
-0
meta/conf/bitbake.conf DEPLOY_DIR_TOOLS = "${DEPLOY_DIR}/tools" · line 346
Quoted 7 lines
meta/conf/bitbake.conf +1
-1@@ -341,7 +341,7 @@ DEPLOY_DIR_TOOLS = "${DEPLOY_DIR}/tools" PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}" -SDK_NAME = "oecore-${SDK_ARCH}-${TARGET_ARCH}" +SDK_NAME = "oecore-sdk-${DISTRO}" SDKPATH = "/usr/local/${SDK_NAME}" SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"
I'd really like Koen to take a look at this with his Angstrom hat on. I still suspect the better fix for this is likely to end up with:
SDK_NAME = "oecore-${SDK_ARCH}-${TARGET_ARCH}"
-SDKPATH = "/usr/local/${SDK_NAME}"
+SDKPATH = "/usr/local/oecore-sdk-${DISTRO}"
SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"
Certainly having TARGET_ARCH in SDKPATH is a bad idea but I think the SDK_NAME variable could make sense as it is originally...
Cheers,
Richard
Re: [PATCH 8/8] fix SDK building due TARGET_ARCH use in installation path
I'll take a look when I get back into the country next week
Op 8 jul. 2011 om 16:38 heeft Richard Purdie <[email protected]> het volgende geschreven:
Quoted 53 lines · Otavio Salvador
Quoted 34 lines
TARGET_ARCHmakes the building too fragile since it changes during building of target and nativesdk binaries thus making it difficult to handle a proper path for installation of binaries. The fix for it is to move it to toolchain tarball name.Signed-off-by Otavio Salvador <[email protected]>---
meta/classes/populate_sdk.bbclass | 2 +- meta/conf/bitbake.conf | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)meta/classes/populate_sdk.bbclass +0
-0@@ -9,7 +9,7 @@ SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${TARGET_SYS}"
TOOLCHAIN_HOST_TASK?= "task-sdk-host-nativesdk task-cross-canadian-${TRANSLATED_TARGET_ARCH}"TOOLCHAIN_TARGET_TASK?= "task-core-standalone-sdk-target task-core-standalone-sdk-target-dbg"meta/classes/populate_sdk.bbclass +1
-1-TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${DISTRO_VERSION}" +TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-${SDK_ARCH}-${TARGET_ARCH}-toolchain-${DISTRO_VERSION}"RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}" DEPENDS = "virtual/fakeroot-native sed-native"
meta/conf/bitbake.conf +0
-0@@ -341,7 +341,7 @@ DEPLOY_DIR_TOOLS = "${DEPLOY_DIR}/tools"
PKGDATA_DIR= "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}"meta/conf/bitbake.conf +1
-1-SDK_NAME = "oecore-${SDK_ARCH}-${TARGET_ARCH}" +SDK_NAME = "oecore-sdk-${DISTRO}"Quoted 2 lines
SDKPATH = "
/usr/local/${SDK_NAME}"
SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"I'd really like Koen to take a look at this with his Angstrom hat on. I still suspect the better fix for this is likely to end up with:
SDK_NAME= "oecore-${SDK_ARCH}-${TARGET_ARCH}"(quoted diff) +1
-1-SDKPATH = "/usr/local/${SDK_NAME}" +SDKPATH = "/usr/local/oecore-sdk-${DISTRO}"SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"
Certainly having
TARGET_ARCHin SDKPATH is a bad idea but I think theSDK_NAMEvariable could make sense as it is originally...Cheers,
Richard