Rebuilding MPSS locally

[eudoxos]

I am buildling MPSS-3.5 and I am facing two issues:

First is the --same-order vs. -c option of tar mentioned above (also see https://lists.yoctoproject.org/pipermail/yocto/2013-October/016540.html) which can be worked around by downgrading tar to 1.26 (I just copied an older distro binary to /usr/local/bin).

The second one is fixed at
http://git.buildroot.net/buildroot/commit/?id=600375d18e6ccd08505153863666f2e8b10251be
and fails in m4:

ccache gcc -std=gnu99  -I.   -isystem/home/eudoxos/build/yocto/mpss-3.5/build/poky/build/tmp/sysroots/x86_64-linux/usr/include  -isystem/home/eudoxos/build/yocto/mpss-3.5/build/poky/build/tmp/sysroots/x86_64-linux/usr/include -O2 -pipe -c execute.c
In file included from clean-temp.h:22:0,
                 from clean-temp.c:23:
./stdio.h:477:20: error: 'gets' undeclared here (not in a function)
 _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
                    ^
Makefile:1401: recipe for target 'clean-temp.o' failed
make[3]: *** [clean-temp.o] Error 1

How can I work around that one? I seem to be out of control since bitbaker downloads the tarball from upstream, and I don't know where to put some patch to be applied.

Do you have some public git branch where this is updated? Or some other updates on MPSS-source? Both issues were trivially patched 3 years ago upstream.

Cheers, v.

[Frances_R_Intel]

I'm sorry, but I feel like I have popped into the middle of an ongoing discussion. Could you help me get up to speed?

What is your starting point? Are you starting from the contents of the mpss-3.5.*/src directory and creating a Yocto project environment as Evan showed in this post: https://software.intel.com/en-us/forums/topic/509077#comment-1785888? When you say "First is the --same-order vs. -c option of tar mentioned above", I'm not sure what the "mentioned above" refers to. Are you referring to the fact that some of the scripts in the poky directory still use the -s option on a create? If so, I can check on that and submit a request to have that changed, if it isn't already being fixed.

On the second issue, your are saying that the source code for m4 should be updated so that it matches the later version of glibc, right? But I don't understand the bit about bitbaker. You say "I seem to be out of control since bitbaker downloads the tarball from upstream, and I don't know where to put some patch to be applied." When you say out of control, is that a general statement or are you referring to a specific control mechanism? And I'm afraid I don't understand what tarball is being downloaded.

As to there being a github somewhere, I'm afraid not. I believe what is in the MPSS distribution is the latest release of the source code.

[eudoxos]

Hi,

sorry for the delay in communication. I could not post for some reason to the thread you mention (https://software.intel.com/en-us/forums/topic/509077#comment-1785888) so the "above" referred indeed to that one. I apologize for the messiness of the post, I try to summarize again:

I am using the script in that other post to re-build the minimal image (bitbake mpss-image-minimal), as a starting point (later, I will need to build also boost and other bigger libs, but that's the future), using latest MPSS source (mpss-src-3.5). My system is Ubuntu 15.04 which probably has more recent components than officially supported systems (RHEL). I am having two issues.

One issue is tar with --same-order, which can be worked around (older tar version) as said above. If you can fix that in your package, that would be great. Newer tar will be in RHEL soon, and the same problem will pop up for you anyway.

The second issue is "gets undeclared" when building m4. I would like to patch m4 locally (should be pretty trivial), but as far as I understand bitbaker, it downloads upstream m4 tarball, unpacks it, applies patches stored somewhere, compile. Basically, I am looking for a way to produce a patch of m4 source and place it somewhere where bitbaker finds it and applies it before compiling -- ?

Cheers, v.