soletta building from source fails

[dborquez]

• Plattform: Linux kernel 3.13.0-30-generic I2c fix v2 #55~precise1-Ubuntu SMP Fri Jul 4 21:52:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
• gcc 4:4.6.3-1
• make 3.81-8.1
• Python 3.3.5
• steps to reproduce the issue:

1. git clone https://github.com/solettaproject/soletta.git
2. make alldefconfig
3. make

• the step (3) fails returning the following output:

' ./src/lib/common/sol-worker-thread-impl-glib.c:54:45: error: ‘__ATOMIC_SEQ_CST’ undeclared (first use in this function) '

• complete output here: http://pastebin.intel.com/view/2eb2a875

[tcanabrava]

try with a newer GCC - __ATOMIC was introduced with gcc 4.7

[anselmolsm]

My bet is that soletta should require gcc>=4.7.

[anselmolsm]

Also, it should require python>=3.4.
I remember there was an issue with versions older than that (I can't remember the issue itself).

[dborquez]

It could be good to complement the Installation Required Packages along with its version in the README file in order to build Soletta from source.

[dborquez]

• I have updated the gcc and python packages to:
  gcc 4.9.2
  Python 3.4
• the gcc update solved the missing ‘__ATOMIC_SEQ_CST’ declaration.
• A new issue appears in compilation:

' ./src/lib/flow/sol-flow-js.c:36:21: fatal error: duktape.h: No such file or directory
#include "duktape.h" '
compilation terminated.

• The console output: http://pastebin.intel.com/view/6ca1d586

[tcanabrava]

dukttape is a library that's cloned inside the soletta repository via a git submodule, it seems that it failed downloading it.
can you do a git clean -xdf and then make alldefconfig again?

[dborquez]

I did the git clean command that you suggested but I got the same compilation output:

./src/lib/flow/sol-flow-js.c:36:21: fatal error: duktape.h: No such file or directory
#include "duktape.h"

[anselmolsm]

duktape is a javascript vm that is distributed as a pair of .c and .h files, meant to be built as part of the project. Due to several reasons, Soletta is fetching this pair of files as a git submodule (in fact, it is not an actual submodule).

git clean is not enough, more steps are needed to overcome this invalid state of the tree, we're investigating this.

[davidmaxwaterman]

I would like to add that I also had big trouble building Soletta, while Elliot didn't - the difference seems to be that I use Ubuntu and he uses Fedora. The issues I came across seemed to be missing Python modules, which I found relatively simply using 'apt-cache search' and installed using 'apt-get install'. It would be nice if these dependencies were obtained automatically, or at least mentioned in the README.

[barbieri]

+1 to mention in the README.md
-1 to install automatically as that's hard given how different distros handle packages.

OTOH, should we add more fields to dependencies.json and print more useful information to the user when a test fail? Like a description that says why such test is being done ("description": "Checks for built in compiler support of integer overflow"), if it fails what to say ("on_failure": "using fallback overflow checks -- may not be as fast, GCC 4.8 supports it").

The dependencies resolver should also have a way to print the test that failed. Maybe linked with "make V=1" to pass a --verbose. For pkg-config it would print the exact command line and execution envvars, with all output from pkg-config. For ccode it should also print the full test source and the compiler errors, as well as command line and envvars.

This is what autoconf's config.log was. We may generate such file as well if we wish.

More work for @dorileo

[anselmolsm]

We're populating this wiki page with the build requirements. Let's add to README.md a link to this page.

[barbieri]

ping. Is this still pending?

[anselmolsm]

• The build requirements wiki is being populated ( @dorileo++ for using tables).
• The README section Build from source points to the wiki page mentioned above.
• The duktape submodule black magic was replaced with actual git submodule, so we shouldn't face problems related to our script.
• The dep-resolver results go to config.log

So, all issues pointed out here were covered. Closing, tks.