linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

Re: [Linaro-dev] Maverick cross toolchain

by Marcin Juszkiewicz

Dnia czwartek, 1 lipca 2010 o 18:44:26 Wookey napisał(a): > +++ Marcin Juszkiewicz [2010-06-28 16:06 +0200]: > > Dnia piątek, 18 czerwca 2010 o 17:15:59 Marcin Juszkiewicz napisał(a): > > > > Latest version of cross toolchains are available in prebuilt form on: > Marcin. I've been trying to get round to reading stuff and find out > what was what but have failed so far. It's proably quicker to just ask > you: > Can you tell me what you have done to the toolchain build process. > I am familiar with the existing cross-build mechanisms as used in the > emdebian toolchains and the buildcross tool we use to build them. But > it looks to me like you have moved stuff around and changed targets > and things and I would like the high level view on what is changed and > why. One of things which I did was merging code used for native builds/packaging with cross one. In result we got less packaging code to worry and cross packages are improved now: - libraries have -dbg packages - libmudflap is cross built > Also what decisions have been made about using existing or sysroot or > multiarch paths or some combination of those in default search paths. I did not changed any of those. > Do we still have work to do to make the cross-toolchains buildable > in-archive by the buildds? Yes, this has to be done. I have ugly patch which adds stage1 to eglibc (attached - build will fail on packaging step), managed also to build stage1/stage2 in gcc-4.5 but in style which needs to be rewritten totally (attached - use by "fakeroot debian/rules stage1_install"). > Or is that done? > If it is done have you used the scheme worked out by Doko and Hector at last > years Debconf, or some new scheme? I asked Matthias (doko) about it and he told that talk was mainly about merging cross code with native one and that part is already done (but I am finding small improvements from time to time). Second part was biarch and here nothing got changed. > Has any progress been made on making it easier to set the default cpu > build options without building a whole new toolchain? Not that I know. > Some of these things affect other tools (like dpkg-cross and > multiarch transition - second stage (cross building)), and I'd just > like to see which choices have been made and why so I can see if there > are any problems coming down the track. Most of my already done work does not change anything related to a way how of building cross toolchain. Binutils have it easier now as "binary-cross" target got merged into "binary" one but note about it is printed if someone tries old way. > There are some tricky transitions which it would be nice not to make > too much of a mess of, as it is likely to be a bit painful whatever we > do, especially if there is skew between Debian and ubuntu. All my changes lands in Debian's svn area which keeps gcc packaging. > Cheers for any clues you can give me to get me up to speed. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

14 years, 10 months

[Linaro-dev] Call for testing: lp:~zkrynicki/launch-control/hw-profile

by Zygmunt Bazyli Krynicki

Hello everyone! I'd like to ask for early testing of a new launch-control branch adding support for generating system profile information on ARM systems. I need you to find all the ARM hardware you have access to and run a bit of python code and send me the result. See below for details. == Prerequisites == 1) Debian-based system 2) Installed packages: * python-2.6 (2.5 support is coming) * python-apt * python-debian * lsb-release * usbutils == Instructions == The branch is at: lp:~zkrynicki/launch-control/hw-profile Instructions: $ bzr get lp:~zkrynicki/launch-control/hw-profile \ launch-control.hw-profile $ cd launch-control.hw-profile $ ./get-system-profile -i -o system-profile-with-a-sensible-name.json If something goes wrong please attach the output of the following commands: * lsb_release -a * cat /proc/cpuinfo * cat /proc/meminfo * lsusb * uname -m Report bugs at: https://bugs.edge.launchpad.net/launch-control/+filebug == About launch-control == Launch control is project that aims to implement the Validation Dashboard spec. See: https://blueprints.launchpad.net/ubuntu/+spec/arm-m-validation-dashboard == System Detection Features == Hardware: * CPU (for x86, x86_64 and arm, PPC is *not* supported yet) * Board detection * Memory * USB Software: * distribution * installed debian packages (via apt) Best regards Zygmunt -- Zygmunt Bazyli Krynicki <zygmunt.krynicki(a)canonical.com>

14 years, 10 months

[Linaro-dev] Linaro 10.11 alpha 2 released

by Alexander Sack

Hello World, The Linaro Platform Team is proud to announce the release of its first milestone release for the current development branch dubbed Linaro-M. This release features an early preview of Linaro core platform on it's way to the Linaro 10.11 release in November 2010 and consists of: * a small Linaro headless image (linaro core) * with basic OMAP3 beagle board (c3/c4) enablement included More Information on this development release as well as download and installation instructions can be found at the URL below: * https://wiki.linaro.org/Releases/1011/Alpha2 More information on Linaro in general and the 10.11 plans can be found at the URLs below: * Homepage: http://www.linaro.org * Wiki: https://wiki.linaro.org * 10.11: https://wiki.linaro.org/Releases/1011 Also subscribe to the important Linaro mailing lists and join our IRC channels to stay on top of Linaro developments and, of course, to start working with us: * Linaro Announce: http://lists.linaro.org/mailman/listinfo/linaro-announce * Linaro Development: http://lists.linaro.org/mailman/listinfo/linaro-dev * IRC: #linaro on irc.freenode.net See you there and enjoy this release, - Alexander -- Linaro Platform Team

14 years, 10 months

[Linaro-dev] Python2.5 compatibilty requirement for the Infrastructure Team

by Zygmunt Bazyli Krynicki

Hello everyone. Our current developer guidelines for python development state that we should support both python2.5 and python2.6. I'd like to ask if python2.5 can be dropped from the list. I just took the steps required to test python2.5 (and removed 2.6-only features in the process). I had to use Hardy VM to do so because python 2.5 is no longer available in the Lucid archive. Doing additional testing in a VM is cumbersome and error-prone as we can accidentally slip in a 2.6-only code or trigger 2.5 bug we didn't know about and it might go untested. Can we rationalise the requirements for supporting python2.5 and if so, devise a sensible testing plan for our python development? BTW: It's worth publishing our python development practices on the Linaro wiki. Best regards Zygmunt

14 years, 10 months

[Linaro-dev] Integrating Debian/Ubuntu GCC Patch Set in Ubuntu

by Andrew Stubbs

Hi All, Matthias and I have been throught the Ubuntu GCC 4.4 patch set and decided what to do with each of them in Linaro GCC 4.4 and 4.5. Some patches will be integrated into Linaro, and some will remain Debian/Ubuntu local. The patches can be found here: http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-4.4/debian/patches/?p… Here are the patches in alphabetical order, and whether to apply to linaro gcc (yes/no) or already in 4.5 (upstream): PATCH Linaro 4.4 4.5 ---------------------------------------------------------------- ada-acats.diff yes yes ada-arm-eabi.diff yes upstream ada-bug564232.diff no no ada-default-project-path.diff no no ada-driver-check.diff no no ada-gcc-name.diff [1] no no ada-gnatvsn.diff [7] maybe maybe ada-libgnatprj.diff no no ada-libgnatvsn.diff no no ada-library-project-files-soname.diff no no ada-link-lib.diff no no ada-mips.diff no no ada-nobiarch-check.diff no no ada-polyorb-dsa.diff maybe upstream ada-sjlj.diff no no ada-symbolic-tracebacks.diff [2] maybe maybe alpha-ieee.diff no no alpha-ieee-doc.diff no no alpha-no-ev4-directive.diff no no arm-boehm-gc-locks.diff yes upstream armel-hilo-union-class.diff [8] maybe maybe arm-gcc-gcse-cs.diff yes upstream arm-unbreak-eabi-armv4t.diff no no boehm-gc-getnprocs.diff [1] maybe maybe boehm-gc-nocheck.diff no no cell-branch.diff [9] no upstream cell-branch-doc.diff [9] no upstream config-ml.diff no no cross-fixes.diff no no cross-include.diff no no deb-protoize.diff no no fix-warnings.diff no no gcc-arm-implicit-it.diff [5] maybe maybe gcc-arm-thumb2-sched.diff [10] yes upstream gcc-atom.diff in CS upstream gcc-atom-doc.diff in CS upstream gcc-build-id.diff yes upstream gcc-cloog-dl-cs.diff no no gcc-default-format-security.diff [1] no no gcc-default-fortify-source.diff [1] no no gcc-default-relro.diff [1] no no gcc-default-ssp.diff [1] no no gcc-d-lang.diff no no gcc-driver-extra-langs.diff no no gcc-hash-style-both.diff [1] no no gcc-hash-style-gnu.diff [1] no no gcc-ice-apport.diff no no gcc-ice-hack.diff [3] no no gcc-ix86-asm-generic32.diff no no gcc-multiarch-cs.diff no no gcc-multiarch-i686-cs.diff no no gcc-multilib64dir.diff no no gcc-pascal-lang.diff no no gcc-stack_chk_fail-check.diff yes upstream gcc-textdomain.diff [1] no no gcc-unwind-debug-hook.diff yes upstream gcj-use-atomic-builtins.diff yes upstream gcj-use-atomic-builtins-doc.diff yes upstream gold-and-ld.diff no no gold-and-ld-doc.diff no no hurd-changes.diff no no hurd-pthread.diff no no ignore-comp-fail.diff no no kbsd-gnu-ada.diff no no kbsd-gnu.diff no no libgomp-omp_h-multilib.diff [3] no no libjava-armel-unwind.diff no no libjava-atomic-builtins-eabi.diff yes upstream libjava-disable-plugin.diff no upstream libjava-disable-static.diff no upstream libjava-fixed-symlinks.diff no upstream libjava-jnipath.diff no no libjava-josm-fixes.diff yes upstream libjava-nobiarch-check.diff no no libjava-rpath.diff no no libjava-sjlj.diff no no libjava-stacktrace.diff [1,2] no no libjava-subdir.diff no no libstdc++-arm-no-check.diff no no libstdc++-arm-wno-abi.diff no no libstdc++-doclink.diff no no libstdc++-ldbl-compat.diff [4] yes yes libstdc++-man-3cxx.diff no no libstdc++-pic.diff no no libstdc++-test-installed.diff [5] maybe maybe libsupc++-vmi_class_type_info.diff yes upstream link-libs.diff no no m68k-allow-gnu99.diff no no mips-fix-loongson2f-nop-cs.diff no no mips-triarch.diff no no mudflap-nocheck.diff no no note-gnu-stack.diff [3] no no powerpc-biarch.diff no no pr25509.diff no upstream pr25509-doc.diff no upstream pr38333.diff no upstream pr39429.diff yes upstream pr39491.diff no no pr40133.diff yes upstream pr40134.diff [2,6] yes yes pr40521-revert-workaround.diff yes upstream pr41848.diff [4] yes yes pr42321.diff yes upstream pr42748.diff yes upstream pr43323.diff yes upstream pr44261.diff no no rename-info-files.diff no no rev146451.diff yes upstream s390-biarch.diff no no sh4_atomic_update.diff no no sh4-mode-switching.diff no no sh4-multilib.diff no no sh4-scheduling.diff no no sparc-force-cpu.diff no no testsuite-hardening-format.diff no no testsuite-hardening-fortify.diff no no testsuite-hardening-printf-types.diff no no [1] not upstreamable, but maybe another patch would be. [2] Matthias to investigate. [3] Fedora origin. [4] Already submitted upstream, not in 4.5. [5] Requires review. [6] ARM part only. [7] issue closed upstream, no patch. [8] Julian to investigate. [9] Not interesting to Linaro, but Canonical would like CS to unbreak it for Ubuntu. [10] Part of this patch is already in 4.4 Andrew Stubbs

14 years, 10 months

[Linaro-dev] Rebuild of Ubuntu main with initial gcc-4.4 Linaro patch

by Loïc Minier

Hi Wanted to share that Matthias Klose launched a rebuild of Ubuntu main packages on i386 and amd64 with gcc-4.4 + first Linaro diff which we had sent him. All build failures: https://launchpad.net/ubuntu/+archive/test-rebuild-20100628/+builds?build_t… What needs to happen is reviewing the failures to see whether they are regressions caused by the Linaro diff. One way to do that is to compare with: http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi which has failures from a recent rebuilds of Ubuntu (compare the version number as well!). Steve Langasek told me the Foundations team might be able to help sort these into toolchain and non-toolchain bugs. For each build failure: Check whether it's a regression with the same source + version If it's a regression: If it's a toolchain bug: file a bug against gcc-linaro Else: file a bug against the Ubuntu package, tag it gcc-linaro Else: decide whether it's worth filing a bug against the Ubuntu package Thanks! -- Loïc Minier

14 years, 10 months

[Linaro-dev] Linaro 1.0 alpha2 this Thursday

by Jamie Bennett

Hi all, This is a reminder that Linaro 1.0 alpha2 will be release on Thursday 1st July and an archive freeze will be in place from Tuesday 29th June. For more information on the 1.0 release and the upcoming milestones, please take a look at this [1] wiki page. Regards, Jamie. -- Linaro Release Manager [1] https://wiki.linaro.org/Releases/1011#Linaro10.11Schedule

14 years, 10 months

Re: [Linaro-dev] Maverick cross toolchain

by Marcin Juszkiewicz

Dnia wtorek, 15 czerwca 2010 o 16:32:48 Marcin Juszkiewicz napisał(a): > Latest version of cross toolchains are available in prebuilt form on: > > http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ Today I updated gcc-4.4 to Linaro version, gcc-4.5 and binutils to latest Ubuntu versions. As there were requests I changed structure of repository - now only one line for sources.list instead of two. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

14 years, 10 months

Re: [Linaro-dev] Embedded Qt (QWS) packages

by Marcin Juszkiewicz

Dnia poniedziałek, 28 czerwca 2010 o 10:58:32 Yuri Bushmelev napisał(a): > > Is there a X11 server which can run (perhaps windowed) under QWS? This > > would be great for compatibility with X apps. Something like > > Xephyr/Xnest perhaps? > > There was Xqt and Xqt2 but they are based on Opie (QT/E 1.5-2.0 iirc). OPIE was based on Qt/E 2.3 version. 1.5-2.2 were Qtopia versions from which OPIE took lot of code. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

14 years, 10 months

[Linaro-dev] Embedded Qt (QWS) packages

by Alexandros Frantzis

Hi all! As part of the User Platform team's exploration of non X11-based graphical environments I have started experimenting with the QWS variant of the Qt library (also known as Qt/Embedded). Qt/QWS offers the ability to render graphics directly on a Linux framebuffer without the need for X11 or any other windowing system. It provides its own simple windowing system, which is (unsurprisingly) called the Qt Windowing System (QWS). The Qt/QWS variant is mostly API compatible with Qt/X11, except for some X11 specific functions and some missing libraries (eg QtOpenGL). Most Qt programs should build without problems with Qt/QWS. Note, however, that Qt/QWS is *not* ABI compatible with Qt/X11. Qt/QWS has been tested successfully on the x86 architecture under both X11 (using the QVFB virtual framebuffer) and the Linux framebuffer. Tests for the ARM architecture are under way. If you test the libraries on ARM please let us know how it went! You can find installation and usage instructions at: https://wiki.ubuntu.com/Specs/M/ARMQtonEmbedded/Guide You can also find some screenshots at: http://people.canonical.com/~afrantzis/qt4-qws-screenshots/ If you have any issues or questions don't hesitate to contact me! As a side note, the next generation of Embedded Qt, called (for now) project Lighthouse, is planned for Q1 2011 and is going to improve on QWS by offering support for hardware acceleration and a plugin architecture for windowing systems (instead of just a built-in one). We are keeping an eye on that and are planning to eventually provide experimental packages for Lighthouse. Thanks, Alexandros

14 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev