qt4x11 vs. uicmoc4-native vs. qmake2-native

qt4x11 vs. uicmoc4-native vs. qmake2-native

[Geoffrey Wossum]

Hi all,

I've been doing some work with some Qt4 based applications, and I must say 
that I'm confused by the relationship between OE's qt4x11, uicmoc4-native, 
and qmake2-native packages.

As far as I can tell, this is what each package provides:

qt4x11 - headers and libraries for target system
uicmoc4-native - All Qt tools except qmake for host system
qmake2-native - qmake and mkspecs for host system

My main question is why can't uicmoc4-native and qmake2-native be combined 
into a single package?  Let me share my pain.

I need Qt 4.4 because I'm using Phonon.  So I make a new Bitbake recipe for 
qt4x11-4.4.0.  uicmoc4-native is still from 4.3.3.  Oh, noes!  uic from 4.3.3 
doesn't generate code that works with QT_NO_ACCESSIBILITY, but that was fixed 
in 4.4.0.  So I make a uicmoc4-native recipe and patches for 4.4.0.  Now I'm 
building a package that uses CMake (phonon-vlc-mplayer) and Qt.  CMake uses 
qmake (NOOOOO!) to figure out how to build Qt based applications.  
phonon-vlc-mplayer's build system punts because the qmake it finds from 
qmake2-native is for 4.3.3, and it wants at least 4.4.0.  So now I'm creating 
a qmake2-native recipe and patches that builds qmake from 4.4.0, and it feels 
like deja vu all over again.  

But it gets even worse.  uicmoc4-native gets its version number from the 
version of Qt used to build it.  But qmake2-native gets it's version number 
from the qmake version, which is independent of the Qt version.  Both Qt 
4.3.3 and 4.4.0 include qmake 2.10a.  However, qmake also remembers the 
version of Qt used to build it, which is what makes CMake unhappy.  So the 
qmake version of 2.10a really isn't the whole story.

I understand that Qt's build system doesn't really handle building host tools 
and target libraries in one shot, so at least two recipes are almost 
certainly necessary.  However, is there any good reason why uicmoc4-native 
and qmake2-native couldn't be combined into a single package?

TIA,
---
Geoffrey

Toolchain

[Stefano Regno]

In openEmbedded Project where is the file to undestanding the toolchain?
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>
>   


-- 
Peace cannot be kept by force; it can only be achieved by understanding --Albert Einstein

Re: Toolchain

[Leon Woestenberg]

Hello Stefano,

On Fri, Jul 4, 2008 at 8:54 AM, Stefano Regno
<stefano.regno@spesonline.com> wrote:
> In openEmbedded Project where is the file to undestanding the toolchain?
>>
Start with org.openembedded.dev/packages/gcc/gcc-cross-4.3.1.bb

Regards,
-- 
Leon

Re: Toolchain

[Stefano Regno]

i don't undestand what are u doing there is a mistake in your work or i 
m wronning?


-- 
Peace cannot be kept by force; it can only be achieved by understanding --Albert Einstein

Re: toolchain

[Finn Thain]

On Sat, 5 Sep 2009, Maxim Kuvyrkov wrote:

> Finn Thain wrote:
> ...
> > But in that post (June 28) Maxim recommends using mainline binutils, 
> > and since then we have HJL binutils-2.19.51.0.14 released, "...based 
> > on binutils 2009 0722 in CVS on sourceware.org..." So I guess I should 
> > start there.
> 
> The last binutils TLS patches went in on 2009-08-26; the patches fixed 
> generation of invalid TLS relocations.

OK. Debian has 2.19.51.20090827-1 in the sid archive. I wonder if it has 
been built yet?

> > I understand that the current GCC (4.4) lacks the necessary patches, 
> > and 4.5 is still uncooked (and that's a scary prospect). Can someone 
> > confirm that this is the necessary patch for 4.4: 
> > http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
> 
> I think GCC 4.4 should be good enough.

That's encouraging.

> 
> > As for eglibc, there are a number of branches listed here,
> > http://www.eglibc.org/repository
> > The question is, which branch, snapshot or release might meet be suitable?
> 
> EGLIBC does not yet have NPTL patches checked in, they are in review on 
> libc-ports@.  Once the review is finished, I will likely backport the 
> patches from EGLIBC trunk to 2.10 branch.

I guess I'll wait for that, and then perhaps look into patching 2.9 if 
that turns out to be straight forward. (Debian has 2.10 in the 
experimental archive, 2.9 (more or less) in stable and testing.)

> 
> > With this information, I could attempt to build a toolchain from 
> > upstream sources, or figure out whether or not the debian archive has 
> > the necessary source packages...
> 
> You will also need a patch for kernel, posted on linux-m68k@.

Right.

Thanks for the update.

Finn

> 
> --
> Maxim
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: toolchain

[Finn Thain]

On Sat, 5 Sep 2009, Maxim Kuvyrkov wrote:

> > With this information, I could attempt to build a toolchain from 
> > upstream sources, or figure out whether or not the debian archive has 
> > the necessary source packages...
> 
> You will also need a patch for kernel, posted on linux-m68k@.

Stephen, this patch will be needed in order to build glibc with TLS, since 
it provides the userspace headers for TLS.

http://marc.info/?l=linux-m68k&m=125145669021517&w=2

Not sure how debian handles the kernel headers. I presume that 
linux-libc-dev (probably 2.6.30) needs the patch? (As will the other 
kernel packages of course.)

Finn

Re: toolchain

[Stephen R Marenka]

On Sun, Sep 06, 2009 at 12:37:24PM +1000, Finn Thain wrote:

> OK. Debian has 2.19.51.20090827-1 in the sid archive. I wonder if it has 
> been built yet?

No, binutils buildds were failing, now that are stuck in autoconf 
dependency hell. I've been meaning to have a look. It will at the 
least take manually messing with older dependencies to get a set 
installed.

Peace,

Stephen

-- 
Stephen R. Marenka     If life's not fun, you're not doing it right!
<stephen@marenka.net>

Re: toolchain

[Finn Thain]

On Sun, 6 Sep 2009, I wrote:

> Stephen, this patch will be needed in order to build glibc with TLS, 
> since it provides the userspace headers for TLS.
> 
> http://marc.info/?l=linux-m68k&m=125145669021517&w=2
> 
> Not sure how debian handles the kernel headers. I presume that 
> linux-libc-dev (probably 2.6.30) needs the patch? (As will the other 
> kernel packages of course.)

The patch doesn't apply to 2.6.30, because the rt_tgsigqueueinfo syscall 
is not there.

Will see how far I get with binutils and gcc while I wait for the 2.6.31 
kernel release and eglibc patches.

Finn

toolchain

[Edward Vidal]

[-- Attachment #1.1: Type: text/plain, Size: 941 bytes --]

Hello all,
I am currently working with the zedboard using a rootfs generated with a
dylan branch of yocto (gsl, gnuplot, gnuradio, java, vlc, v4l-utils, and
openCV with C920 camera).  My zImage and devicetree.dtb were built with
yocto sdk.  My BOOT.BIN (FSBL system.bit and u-boot) were built with 14.4
of Xilinx Tools.  This requires dual booting a CentOS 6.4 x86_64 (Xilinx
Tools) and Fedora19 x86_64 (Yocto).  I have not been able to run Yocto on
CentOS since the need for higher version of python.

Is it possible to generate a BOOT.BIN with the files generated with
Yocto?

This requires 2 toolchains.  I was checking the difference between the 2
see the attached files.
Should the difference between the toolchains be of concern going forward?

My Xilinx tools are node locked and I can only use on a single system.
Is there a method to run Yocto on CentOS6.4 x86_64?
Any and all help will be appreciated.

Thanks

[-- Attachment #1.2: Type: text/html, Size: 996 bytes --]

[-- Attachment #2: poky-toolchain.txt --]
[-- Type: text/plain, Size: 2953 bytes --]

arm-poky-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-poky-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/lto-wrapper
Target: arm-poky-linux-gnueabi
Configured with: /home/vidal/POKY/dylan_build/poky/build/tmp/work-shared/gcc-4.7.2-r20/gcc-4.7.2/configure 
--build=x86_64-linux 
--host=x86_64-pokysdk-linux 
--target=arm-poky-linux-gnueabi 
--prefix=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr 
--exec_prefix=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr 
--bindir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi 
--sbindir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi 
--libexecdir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi 
--datadir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/share 
--sysconfdir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/etc 
--sharedstatedir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/com 
--localstatedir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/var 
--libdir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/lib/armv7a-vfp-neon-poky-linux-gnueabi 
--includedir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/include 
--oldincludedir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/include 
--infodir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/share/info 
--mandir=/opt/poky/1.4.3/sysroots/x86_64-pokysdk-linux/usr/share/man 
--disable-silent-rules 
--disable-dependency-tracking 
--with-libtool-sysroot=/home/vidal/POKY/dylan_build/poky/build/tmp/sysroots/x86_64-nativesdk-pokysdk-linux 
--with-gnu-ld 
--enable-shared 
--enable-languages=c,c++ 
--enable-threads=posix 
--enable-multilib 
--enable-c99 
--enable-long-long 
--enable-symvers=gnu 
--enable-libstdcxx-pch 
--program-prefix=arm-poky-linux-gnueabi- 
--without-local-prefix 
--enable-target-optspace 
--enable-lto 
--enable-libssp 
--disable-bootstrap 
--disable-libmudflap 
--with-system-zlib 
--with-linker-hash-style=gnu 
--enable-linker-build-id 
--with-ppl=no 
--with-cloog=no 
--enable-checking=release 
--enable-cheaders=c_global 
--with-gxx-include-dir=/opt/poky/1.4.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr/include/c++ 
--with-build-time-tools=/home/vidal/POKY/dylan_build/poky/build/tmp/sysroots/x86_64-linux/usr/arm-poky-linux-gnueabi/bin 
--with-sysroot=/opt/poky/1.4.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi 
--with-build-sysroot=/home/vidal/POKY/dylan_build/poky/build/tmp/sysroots/zedboard 
--disable-libunwind-exceptions 
--disable-libssp 
--disable-libgomp 
--disable-libmudflap 
--with-mpfr=/home/vidal/POKY/dylan_build/poky/build/tmp/sysroots/x86_64-nativesdk-pokysdk-linux 
--with-mpc=/home/vidal/POKY/dylan_build/poky/build/tmp/sysroots/x86_64-nativesdk-pokysdk-linux 
--enable-nls
Thread model: posix
gcc version 4.7.2 (GCC)

[-- Attachment #3: xilinx-toolchain.txt --]
[-- Type: text/plain, Size: 2986 bytes --]

arm-xilinx-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-xilinx-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/opt/Xilinx/14.4/SDK/SDK/gnu/arm/lin/bin/../libexec/gcc/arm-xilinx-linux-gnueabi/4.6.3/lto-wrapper
Target: arm-xilinx-linux-gnueabi
Configured with: /scratch/janisjo/2012.03-xilinx-linux-lite/src/gcc-4.6-2012.03/configure 
--build=i686-pc-linux-gnu 
--host=i686-pc-linux-gnu 
--target=arm-xilinx-linux-gnueabi 
--enable-threads 
--disable-libmudflap 
--disable-libssp 
--disable-libstdcxx-pch 
--enable-extra-sgxxlite-multilibs 
--with-arch=armv5te 
--with-cpu=cortex-a9 
--with-float=softfp 
--with-fpu=neon-fp16 
--disable-multilib 
--with-gnu-as 
--with-gnu-ld 
--with-specs='%{save-temps: -fverbose-asm} %{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables} -D__CS_SOURCERYGXX_MAJ__=2012 -D__CS_SOURCERYGXX_MIN__=3 -D__CS_SOURCERYGXX_REV__=79 %{O2:%{!fno-remove-local-statics: -fremove-local-statics}} %{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}' 
--enable-languages=c,c++ 
--enable-shared 
--enable-lto 
--enable-symvers=gnu 
--enable-__cxa_atexit 
--with-pkgversion='Sourcery CodeBench Lite 2012.03-79' 
--with-bugurl=https://support.codesourcery.com/GNUToolchain/ 
--disable-nls 
--prefix=/opt/codesourcery 
--with-sysroot=/opt/codesourcery/arm-xilinx-linux-gnueabi/libc 
--with-build-sysroot=/scratch/janisjo/2012.03-xilinx-linux-lite/install/arm-xilinx-linux-gnueabi/libc 
--with-gmp=/scratch/janisjo/2012.03-xilinx-linux-lite/obj/pkg-2012.03-79-arm-xilinx-linux-gnueabi/xilinx-2012.03-79-arm-xilinx-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr 
--with-mpfr=/scratch/janisjo/2012.03-xilinx-linux-lite/obj/pkg-2012.03-79-arm-xilinx-linux-gnueabi/xilinx-2012.03-79-arm-xilinx-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr 
--with-mpc=/scratch/janisjo/2012.03-xilinx-linux-lite/obj/pkg-2012.03-79-arm-xilinx-linux-gnueabi/xilinx-2012.03-79-arm-xilinx-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr 
--with-ppl=/scratch/janisjo/2012.03-xilinx-linux-lite/obj/pkg-2012.03-79-arm-xilinx-linux-gnueabi/xilinx-2012.03-79-arm-xilinx-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr 
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' 
--with-cloog=/scratch/janisjo/2012.03-xilinx-linux-lite/obj/pkg-2012.03-79-arm-xilinx-linux-gnueabi/xilinx-2012.03-79-arm-xilinx-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr 
--with-libelf=/scratch/janisjo/2012.03-xilinx-linux-lite/obj/pkg-2012.03-79-arm-xilinx-linux-gnueabi/xilinx-2012.03-79-arm-xilinx-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr 
--disable-libgomp 
--disable-libitm 
--enable-poison-system-directories 
--with-build-time-tools=/scratch/janisjo/2012.03-xilinx-linux-lite/install/arm-xilinx-linux-gnueabi/bin 
--with-build-time-tools=/scratch/janisjo/2012.03-xilinx-linux-lite/install/arm-xilinx-linux-gnueabi/bin
Thread model: posix
gcc version 4.6.3 (Sourcery CodeBench Lite 2012.03-79)

Re: toolchain

[Philip Balister]

Please post meta-xilinx questions to the meta-xilinx list.

On 01/03/2014 11:46 AM, Edward Vidal wrote:
> Hello all,
> I am currently working with the zedboard using a rootfs generated with a
> dylan branch of yocto (gsl, gnuplot, gnuradio, java, vlc, v4l-utils, and
> openCV with C920 camera).  My zImage and devicetree.dtb were built with
> yocto sdk.  My BOOT.BIN (FSBL system.bit and u-boot) were built with 14.4
> of Xilinx Tools.  This requires dual booting a CentOS 6.4 x86_64 (Xilinx
> Tools) and Fedora19 x86_64 (Yocto).  I have not been able to run Yocto on
> CentOS since the need for higher version of python.
> 
> Is it possible to generate a BOOT.BIN with the files generated with
> Yocto?

See:

https://github.com/balister/meta-xilinx/tree/working-branch/recipes-bsp/u-boot

Basically, I use a pre-compiled fsbl.elf. This only needs the bootgen
command (from ISE) in the path. U-boot builds fine with the toolchain
built in OE. (Also, you can build the fsbl with an OE toolchain last
time I checked.

Philip

> 
> This requires 2 toolchains.  I was checking the difference between the 2
> see the attached files.
> Should the difference between the toolchains be of concern going forward?
> 
> My Xilinx tools are node locked and I can only use on a single system.
> Is there a method to run Yocto on CentOS6.4 x86_64?
> Any and all help will be appreciated.
> 
> Thanks
> 
> 
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 

Re: toolchain

[Gary Thomas]

On 2014-01-03 15:48, Philip Balister wrote:
> Please post meta-xilinx questions to the meta-xilinx list.
>
> On 01/03/2014 11:46 AM, Edward Vidal wrote:
>> Hello all,
>> I am currently working with the zedboard using a rootfs generated with a
>> dylan branch of yocto (gsl, gnuplot, gnuradio, java, vlc, v4l-utils, and
>> openCV with C920 camera).  My zImage and devicetree.dtb were built with
>> yocto sdk.  My BOOT.BIN (FSBL system.bit and u-boot) were built with 14.4
>> of Xilinx Tools.  This requires dual booting a CentOS 6.4 x86_64 (Xilinx
>> Tools) and Fedora19 x86_64 (Yocto).  I have not been able to run Yocto on
>> CentOS since the need for higher version of python.
>>
>> Is it possible to generate a BOOT.BIN with the files generated with
>> Yocto?
>
> See:
>
> https://github.com/balister/meta-xilinx/tree/working-branch/recipes-bsp/u-boot
>
> Basically, I use a pre-compiled fsbl.elf. This only needs the bootgen
> command (from ISE) in the path. U-boot builds fine with the toolchain
> built in OE. (Also, you can build the fsbl with an OE toolchain last
> time I checked.
>
> Philip
>
>>
>> This requires 2 toolchains.  I was checking the difference between the 2
>> see the attached files.
>> Should the difference between the toolchains be of concern going forward?
>>
>> My Xilinx tools are node locked and I can only use on a single system.
>> Is there a method to run Yocto on CentOS6.4 x86_64?
>> Any and all help will be appreciated.

You could try installing the meta-toolchain which installs updated host
tools that Yocto can use.  Find them at
   http://downloads.yoctoproject.org/releases/yocto/yocto-1.5/toolchain/x86_64/

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Toolchain

[Michael Gloff]

[-- Attachment #1: Type: text/plain, Size: 225 bytes --]

Is there a reason why the toolchain cannot be built with a machine name
that contains capital letters? Seems weird, everything else builds fine,
but meta-toolchain fails complaining about caps.

Thanks,

Michael Gloff

[-- Attachment #2: Type: text/html, Size: 291 bytes --]

Re: Toolchain

[Paul Eggleton]

Hi Michael,

On Sunday 02 March 2014 19:58:41 Michael Gloff wrote:
> Is there a reason why the toolchain cannot be built with a machine name
> that contains capital letters? Seems weird, everything else builds fine,
> but meta-toolchain fails complaining about caps.

Although machine names are traditionally all lower case in our build system, 
there's no deliberate restriction in place that enforces this.

Would you be able to provide more details, such as the version of the build 
system you are using, the exact capital letters you used in the machine name, 
and the error you received? 

Thanks,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Toolchain

[Michael Gloff]

[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]

Paul,
The error is below. Machine name: PMX-090T. This is on dora 1.5.1

ERROR: Function failed: opkg-build execution failed
ERROR: Logfile of failure stored in:
/opt/oe/build/tmp/work/i686-nativesdk-emacsdk-linux/meta-environment-PMX-090T/1.0-r8/temp/log.do_package_write_ipk.15358
Log data follows:
| DEBUG: Executing python function sstate_task_prefunc
| DEBUG: Python function sstate_task_prefunc finished
| DEBUG: Executing python function do_package_write_ipk
| DEBUG: Executing python function read_subpackage_metadata
| DEBUG: Python function read_subpackage_metadata finished
| DEBUG: Executing python function do_package_ipk
| meta-environment-PMX-090T
| *** Error: Package name  contains illegal characters, (other than
[a-z0-9.+-])
|
| opkg-build: Please fix the above errors and try again.
| DEBUG: Python function do_package_ipk finished
| DEBUG: Python function do_package_write_ipk finished
| ERROR: Function failed: opkg-build execution failed
ERROR: Task 788 (/opt/oe/recipes/poky/meta/recipes-core/meta/
meta-environment.bb, do_package_write_ipk) failed with exit code '1'

Thanks,

Michael Gloff



On Mon, Mar 3, 2014 at 12:52 PM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> Hi Michael,
>
> On Sunday 02 March 2014 19:58:41 Michael Gloff wrote:
> > Is there a reason why the toolchain cannot be built with a machine name
> > that contains capital letters? Seems weird, everything else builds fine,
> > but meta-toolchain fails complaining about caps.
>
> Although machine names are traditionally all lower case in our build
> system,
> there's no deliberate restriction in place that enforces this.
>
> Would you be able to provide more details, such as the version of the build
> system you are using, the exact capital letters you used in the machine
> name,
> and the error you received?
>
> Thanks,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>

[-- Attachment #2: Type: text/html, Size: 2540 bytes --]

Re: Toolchain

[Paul Eggleton]

On Wednesday 05 March 2014 11:00:31 Michael Gloff wrote:
> On Mon, Mar 3, 2014 at 12:52 PM, Paul Eggleton 
> <paul.eggleton@linux.intel.com> wrote:
> > On Sunday 02 March 2014 19:58:41 Michael Gloff wrote:
> > > Is there a reason why the toolchain cannot be built with a machine name
> > > that contains capital letters? Seems weird, everything else builds fine,
> > > but meta-toolchain fails complaining about caps.
> > 
> > Although machine names are traditionally all lower case in our build
> > system, there's no deliberate restriction in place that enforces this.
> > 
> > Would you be able to provide more details, such as the version of the
> > build system you are using, the exact capital letters you used in the
> > machine name, and the error you received?
>
> The error is below. Machine name: PMX-090T. This is on dora 1.5.1
> 
> ERROR: Function failed: opkg-build execution failed
> ERROR: Logfile of failure stored in:
> /opt/oe/build/tmp/work/i686-nativesdk-emacsdk-linux/meta-environment-PMX-090
> T/1.0-r8/temp/log.do_package_write_ipk.15358
> Log data follows:
> | DEBUG: Executing python function sstate_task_prefunc
> | DEBUG: Python function sstate_task_prefunc finished
> | DEBUG: Executing python function do_package_write_ipk
> | DEBUG: Executing python function read_subpackage_metadata
> | DEBUG: Python function read_subpackage_metadata finished
> | DEBUG: Executing python function do_package_ipk
> | meta-environment-PMX-090T
> | *** Error: Package name  contains illegal characters, (other than
> [a-z0-9.+-])

Perhaps I spoke too soon. There might not be a direct restriction on machine 
names; but opkg does restrict characters allowed in package names, and for 
meta-environment the machine name ends up as part of the package name. You 
could probably hack around it if you felt the need to, but the simplest thing 
would be to just change the machine name to be all lower-case.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Toolchain

[Michael Gloff]

[-- Attachment #1: Type: text/plain, Size: 2339 bytes --]

Thanks,
Not a big deal at all to build the toolchain with a different machine name.
Just curious.

Michael Gloff


On Wed, Mar 5, 2014 at 11:45 AM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> On Wednesday 05 March 2014 11:00:31 Michael Gloff wrote:
> > On Mon, Mar 3, 2014 at 12:52 PM, Paul Eggleton
> > <paul.eggleton@linux.intel.com> wrote:
> > > On Sunday 02 March 2014 19:58:41 Michael Gloff wrote:
> > > > Is there a reason why the toolchain cannot be built with a machine
> name
> > > > that contains capital letters? Seems weird, everything else builds
> fine,
> > > > but meta-toolchain fails complaining about caps.
> > >
> > > Although machine names are traditionally all lower case in our build
> > > system, there's no deliberate restriction in place that enforces this.
> > >
> > > Would you be able to provide more details, such as the version of the
> > > build system you are using, the exact capital letters you used in the
> > > machine name, and the error you received?
> >
> > The error is below. Machine name: PMX-090T. This is on dora 1.5.1
> >
> > ERROR: Function failed: opkg-build execution failed
> > ERROR: Logfile of failure stored in:
> >
> /opt/oe/build/tmp/work/i686-nativesdk-emacsdk-linux/meta-environment-PMX-090
> > T/1.0-r8/temp/log.do_package_write_ipk.15358
> > Log data follows:
> > | DEBUG: Executing python function sstate_task_prefunc
> > | DEBUG: Python function sstate_task_prefunc finished
> > | DEBUG: Executing python function do_package_write_ipk
> > | DEBUG: Executing python function read_subpackage_metadata
> > | DEBUG: Python function read_subpackage_metadata finished
> > | DEBUG: Executing python function do_package_ipk
> > | meta-environment-PMX-090T
> > | *** Error: Package name  contains illegal characters, (other than
> > [a-z0-9.+-])
>
> Perhaps I spoke too soon. There might not be a direct restriction on
> machine
> names; but opkg does restrict characters allowed in package names, and for
> meta-environment the machine name ends up as part of the package name. You
> could probably hack around it if you felt the need to, but the simplest
> thing
> would be to just change the machine name to be all lower-case.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>

[-- Attachment #2: Type: text/html, Size: 2987 bytes --]

Re: Toolchain

[Khem Raj]

On Wed, Mar 5, 2014 at 9:00 AM, Michael Gloff <mgloff@emacinc.com> wrote:
> | *** Error: Package name  contains illegal characters, (other than
> [a-z0-9.+-])

hmm meta-environment-PMX-090T is a package name and
thats limitation of opkg backend, if you are too tied to

Re: Toolchain

[Paul Barker]

On 5 March 2014 21:14, Khem Raj <raj.khem@gmail.com> wrote:
> On Wed, Mar 5, 2014 at 9:00 AM, Michael Gloff <mgloff@emacinc.com> wrote:
>> | *** Error: Package name  contains illegal characters, (other than
>> [a-z0-9.+-])
>
> hmm meta-environment-PMX-090T is a package name and
> thats limitation of opkg backend, if you are too tied to

opkg itself doesn't seem to have this limitation, I just created and installed a
test package named 'A' perfectly fine.

The Debian policy says:
    Package names (both source and binary, see Package, Section 5.6.7) must
    consist only of lower case letters (a-z), digits (0-9), plus (+) and minus
    (-) signs, and periods (.). They must be at least two characters long and
    must start with an alphanumeric character.

So I think the restriction is there to keep generated packages
compatible with dpkg-deb.

We could consider removing the restriction if that compatibility isn't
necessary.

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Toolchain

[Virgilia Eigner]

[-- Attachment #1: Type: text/html, Size: 1027 bytes --]