Forums

Did try somebody build OE4 for more machine ?

Does support OE4 building more machine types in same cloned oe or for each machine must to have cloned own oe?

 

for me - when is builded image for first machine - second machine crashing on "glib-2.0_2.36.4.bb" always

That's interesting, because I was told it was supposed to work this way

 

What does it say? I had something vague with gcc yesterday, but that vanished once I cleaned out the tmp directory.

Our buildserver builds them ALL in one directory. So it should work. It's what it was designed for. (In fact, I've been using that feature at home on OpenPLi 3 too)

I did push a very large update yesterday. I tested a few clean builds on my machine, they ran fine.

BTW does the dm8000 build work (yes, offtopic  )? (I.e. when I flash it, the dm8000 is operational), anyone tested?

tried more times... always same. May it, that when is used INHERIT += "rm_work", then error is not ? I am using building without INHERIT += "rm_work" in .conf

 

What i made:

create env:

1) create openpli4
2) cd openpli4
3) git clone -b upstream git://git.code.sf.net/p/openpli/openpli-oe-core .
4) make

 

then building:
MACHINE=dm800se make image

after it:

cd build;source env.source; MACHINE=dm800se bitbake openpli-enigma2-feed

 

next machine:

cd ~/openpli4

MACHINE=xp1000 make image

cd build;source env.source; MACHINE=xp1000 bitbake openpli-enigma2-feed

 

...

 

there in log for XP1000 is visible ...home/martin/openpli4/build/tmp/sysroots/dm800se/usr/lib ... = previous builded machine

Edited by ims, 7 September 2013 - 09:13.

I did push a very large update yesterday. I tested a few clean builds on my machine, they ran fine.

btw, when I builded first machine, there in mips32el-oe-linux/libmikmod/3.2.0-r1 was some problem with docs.patch

It seems, that may not be removed line:  INHERIT += "rm_work" . Then building for more machine works well.

Huh?

I have "rm_work" active on each and every OE build system I use... And they build for quite a few platforms...

Just be careful that it isn't activated twice, that will lead to some strange behaviour. And never manually delete the "tmp" dir, that will lead to unexpected results too.

Just be careful that it isn't activated twice, that will lead to some strange behaviour. And never manually delete the "tmp" dir, that will lead to unexpected results too.

I often have to, because vague errors force me to do a complete fresh build.

 

How would you suggest to achieve the same goal then?

To "reset", remove both tmp and sstate-cache dirs. That works fine.

I've had some very weird failures further along, when deleting parts of the build/tmp dir that I thought were no longer needed, but caused build failures much later on.

Okay, I always do remove tmp AND remove sstate-cache.

There in OE3 can be removed INHERIT += "rm_work" .  Sources are not removed and it is better for looking etc (but it spend so much hdd, ok) ... Each machine's build has own mips32el-oe-linux. There under 4 it is common=> rm_work must be used, when is more machines.

It is not happy for building clear image for only one machine, when tmp and sstate-cache are "common" too. Where is bonus for this oe4 structure ?

 

I am using usualy cleansstate only. When is changed some in .cpp in enigma2, then I am using cleansstate for enigma2-plugins before building too.

 

How understand this (by MiLo): ?

"And never manually delete the "tmp" dir, that will lead to unexpected results too." and "To "reset", remove both tmp and sstate-cache dirs. That works fine."

Q: how it will be for feeds from my build ?

 

all_feed.conf ...  build/tmp/deploy/ipk/all

machine_feed.conf ... build/tmp/deploy/ipk/machine

mips32el_feed.conf ... build/tmp/deploy/ipk/mips32el

 

"all" and "mips32el" are really common for all machines ?

The "4" structure was intended to build everything into the same directory. Since all boxes have the same CPU and are much alike, OE doesn't need to build everything over and over again for each machine, but it'll just build the differences.

As for feeds, by default, the build will use your machine name and pack it into the feed config files. If you install apache, and create a symlink from
/var/www/feeds/openpli-4 to ${HOME}/openpli-oe-core/build/tmp/deploy/ipk (or so), you're done (if your hostname can be resolved).

A trivial fix is also the following (>>openpli 3.0 <<)

 

Generating /opt/openpli/openpli4/build/env.source

Generating /opt/openpli/openpli4/build/conf/openpli.conf

Generating /opt/openpli/openpli4/build/conf/bblayers.conf

Generating /opt/openpli/openpli4/build/conf/local.conf



Openembedded for the OpenPLi 3.0 environment has been initialized

properly. Now you can start building your image, by doing either:



 MACHINE=... make image



        or:



 cd /opt/openpli/openpli4/build

 source env.source

 MACHINE=... bitbake openpli-enigma2-image

For "3" I am using there in distro-feed-configs.bb DISTRO_FEED_URI = "http://my_pc_ip/${MACHINE_ARCH}" and Apache and links.

 

Similar will be for "4", only different links and name in URI (DISTRO_FEED_URI = "http://my_pc_ip/4${MACHINE_ARCH}"

Hello,

 

 

Can you please help me, i am trying to build OpenPLi 4 but compile fails. Any idea to overcome this issue;

 

ERROR: Task XXX (virtual:native:/opt/openpli/openpli4/openembedded-core/meta/recipes-devtools/bison/bison_2.7.1.bb, do_configure) failed with exit code '1'

 

 log.do_configure.32251.log   70.59KB   8 downloads

 

Build machine is Ubuntu 12.04 x64.

 

Flex is required   ... it seems, is not installed flex in ubuntu ?

Flex is required ... it seems, is not installed flex in ubuntu ?

Flex is already installed.

$ flex --version
flex 2.5.35

This machine is hosted on OpenVZ, is it possible that OpenVZ to cause problem?
Edited by athoik, 8 September 2013 - 08:13.