Moblin/MeeGo Validation Fail - Outdated Beta SDK... or is it?

Moblin/MeeGo Validation Fail - Outdated Beta SDK... or is it?

I tried responding to this request directly, but apparently that doesn't work.
Dear Valued Member, . This is to inform you that Smiles (M) 1.1 has failed to meet Intel(R) Atom(TM) Developer Program's validation criteria. . Failure Reason: ILU03 - Application launch . Additional Comments: The application is compiled with an outdated version of the beta SDK. In order to ensure the best end user experience possible, we now require that apps utilize the most recent version. Please see for the Beta2 for version .91 of the SDK. . Check the failure code against the Intel(R) Application/Component Suitability Guidelines and Validation Criteria document. This document lists the error codes and the associated tests that were run on your application. Additional comments provided may help narrow down the specific failure(s). . Once you revise your code please resubmit it for validation. . Best regards, Intel(R) Atom(TM) Developer Program Team
So okay, I did that. Actually, I was pretty sure I was using the correct library in the first place (I only installed this Linux PC a few weeks ago), but fine. So I downloaded "adpcore-0.9.1-1.i386.deb" again. This time, I took the header files and library files and added them directly to my source tree. I explicitly link "libadpcore.a" in my source tree ("Target/Linux/AppUp/lib/libadpcore.a", 274346 bytes in size) instead of using "-ladpcore". Package it up, send it off. The same validation failure comes back. Okay. So I'm trying to think of what I might be doing that triggers this validation failure. 1. I'm stripping debug symbols. Using nm or objdump on my binary will yeild no symbol results, if my executable is being scanned directly. 2. I'm launching my executable from a shell script. "/opt/sykhronics/smiles/Smiles" is a shell script that changes the working directory, then runs a binary "Smiles.Linux32". If the shell script is being scanned instead of the executable, yeah, no adpcore signatures will be found at all. 3. Again, I'm using the debian adpcore version (on Ubuntu). I'm compiling with the moblin sdk version of gcc and the various shared libraries. From my test, it runs fine from the AppUp client. Insight in to how this requirement is actually tested would be helpful. Thanks,
14 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


Just a quick observation; On the windows side of things, we experienced some issues with installer file caching. In these cases the MSI would not be overwritten upon uploading with the same file name. Could this be happening with your installer? Perhaps try uploading using a different installer file name?

Oh wow. It could be. I used the exact same filenames after all. I'll give that a try.

Thanks for the suggestion Brian.

Best of luck, I hope it is that simple. Please let me know how it turns out. One trick I used in a few apps to verify this was an "easter egg" feature that would display the exact build number when invoked. This allowed me to prove that the MSI was indeed being cached.

Hi Michael:

I have two other suggestions.

1) cat these two files, /usr/lib/pkgconfig/adpruntime.pc and /usr/lib/pkgconfig/adpcore.pc, both should have a version number inside and make sure they said 0.9.1

2) Make sure that /usr/lib is at forefront (or maybe even the first one) under your LD_LIBRARY_PATH env.



Thanks for the further suggestions Vincent.

#1. Yep, both 0.9.1

#2. I'm not using LD_LIBRARY_PATH, but am instead passing library search directories directly to the linker. Putting /usr/lib first might not be the best idea either, since I should be linking against libraries in the moblin sdk (~/moblin-sdk-0.10/moblin-cross-toolchain/i586-moblin-linux/moblin-2.1-developer-sysroot/usr/lib/).


It sounds like you have verified that your app is indeed using the correct version of the ATOM SDK. Did you happen to try uploading a new installer (using a new file name) to see if that alleviated the issue for the validation team?

Yes, I added some "b's" to my file-names uploaded it last night. Hopefully I hear something tomorrow.

Ok, best of luck. Please let me know what happens with that. By the way, Smiles is awesome!

Okay, it came back a failure again. Intel, I'm going to need some help here. I'm using your library, but you're saying I'm not.

Possible reasons may include:

1. I'm executing my game via a shell script (/opt/sykhronics/smiles/Smiles). No ADP library signatures would be found if you scan the shell script.
2. I'm stripping debug symbols. objdump and nm should produce no signatures of ADP as a result (since it's a static library).
3. I'm using the debian version of adpcore.

Or specifically, knowing how you're testing if "The application is compiled with an outdated version of the beta SDK" would help me figure out where I'm going wrong.


Hi Michael,

I have forwarded your request to the validation team.
Shortly somebody from the validation team may contact you to assist you in sorting the issue with your app packaging and to clarify what exactly is causing your app to fail validation.

In the meantime, please can you recompile your application using the Moblin SDK Beta 2 RPM version as the Moblin currently supports only RPM packages and probably this may be causing the issue here, since you are using the DEB version of the SDK.

Have you been able to Beta Test the application on Moblin?


Intel® Customer Support
Intel® Atom™ Developer Program
Intel AppUp(SM) Center

DG Rooven

Thanks Rooven.

Yes, it runs fine on my moblin test machine, and yes I'm generating both packages (DEB and RPM). What I'm referring to by "DEB" is the debian version of the SDK, which should be identical to RPM version, just it's packaged as a DEB for much the same reason we're require to make both packages.

Alright, it's finally approved. Vincent was a big help working with me via e-mail to try and track down the issue. I'm not yet sure what was triggering the fail yet, but I'm happy to finally have it through.

Also, congratz Brian on the Black Belt.

Thanks Michael, happy to hear Smiles is on track.

Leave a Comment

Please sign in to add a comment. Not a member? Join today