Dll hell, there and back again

[Adrian_Edmonds1]

Now that I'm working on Windows 7 64 bit with a 64 bit application I sometimes feel on top of the world and all those troubles from the 90's with dll hell are behind me.Until I come to redistribing the Intel Primitives libraries and the MKL libraries.Currently we're a small startup with a wonderful product and I'm the software manager. We have 5 Composer licenses of varying releases and I'm working on getting the license server up and running for a floating license we just purchased. Yes, another few thousand to Intel. Not there yet.I have just spent 9 hours over two days trying to make our 64 bit application work in release build on two varying PCs' with different processors. To say that it's frustrating would be an understatment. Well, I'm a Brit. I got it working eventually but it was unguided and felt wrong. Now, I don't expect to get an answer from this forum as I intend to raise this as a paid for support issue. I don't even expect to get an answer that route either.I've become a blue belt in using dependency walker and debug view but I very much do not appreciate the rather unhelpful FAQs , various PDF's and tons upon tons of caveats with license conditions. We currently evaluate a new Intel based SBC every month to find the one that suits our needs. Making our app work on each one as it comes is very very painful. If there was ever a case for moving to an ARM processor and Linux it's now made.CheersAdrian EdmondsCMosaix Ltd

[Ying_H_Intel]

Hello Adrain,

According to your discription, I guess, you must had experienced untold hardships before post them here : dll hell,  get license sever up, make 64bit applicaton work on different processor and tremendous unhelpful documentation and more.  Each of them seems an huge problem.  Here is IPP Forum, could you please tell some details about your problem on IPP library.  I'm not sure how we can help but just hope to get the attentions here so more developers can share their views.

Best Regards,
Ying

[Adrian_Edmonds1]

Hi Ying;

Thanks very much for the reply. It's such a relief to know there's someone out there. The question is:

For a given application using Intel Composer in all it's very many forms how can I tell what Intel distributables are needed without having to try it and see?

As part of our development cycle we regularly test release builds and that's where we're getting problems. A working version that had been stable for three weeks suddenly stopped working. I had to add an addtional dll to the executable folder (ippmsg.dll) to make it work.  Patch Tuesday is my current favourite suspect. Our latest release , using ipp and QT 4.8.0 rather than QT4.7.2 no longer works in release build and silently dies. This is a load dependency issue. Running it though dependency walker shows no problems in dependencies apart from the usual suspect ieshims.dll. 

Profiling our application  using dependency walker also shows no problems and our application runs! WTF?

Of course, running on the various development PCs shows no problems at all but that's expected. checking release builds is and will remain part of our dev cycle while I live and breathe.

I can fix the license issue by hitting management over the head repeatedly until they respond and take the issue seriously.

Regards

Adrian

[Sergey_K_Intel]

Dear Adrian,

Do you use IPP status message localization in you applications?

I am asking this because the only one place in IPP libraries, where "ippmsg.dll" is required, is "ippGetMessageStatusI18n" function (and all functions around it). The dll is loaded dynamically, so it cannot be seen in static dependency checkers.

However, even without "ippmsg.dll" the application must work if it checks the function statuses. Look at the sample below. It works with and without having "ippmsg.dll" in the path.

[cpp]#include 
#include 

int main()
{
    IppStatus myStat = ippStsNoErr;
    IppMsgCatalog *pMsgCat = NULL;
    int msgCatOpen = 0;

    myStat = ippMessageCatalogOpenI18n(&pMsgCat);
    if(ippStsNoErr != myStat) {
        printf("Execution continues without ippmsg\n");
        msgCatOpen = 0;
    }
    else {
        msgCatOpen = 1;
    }
    myStat = ippStsH263MCBPCInterCodeErr; /* Test error code */

    if(msgCatOpen) {
        IppMsg StatMsg;
        if(ippStsNoErr != ippGetMessageStatusI18n(pMsgCat, myStat, &StatMsg))
            printf("Could not get translation message!\n");
        else
            printf("ippmsg-based message: %ls\n", StatMsg);
    } else {
        printf("static message: %s\n", ippGetStatusString(myStat));
    }
    ippMessageCatalogCloseI18n(pMsgCat);
    return 0;
}
[/cpp]

Anyway, you are right, the "ippmsg.dll" library usage must be explicitly described in the IPP docs. We will work on that.

Regards,

Sergey

[Adrian_Edmonds1]

Sergey;

Thank you very much for the prompt and detailed reply. I have not found any references to any of the functions calls you described. I can make the application work by hitting it  hard with whatever dlls it feels it needs. As the question is:

How can I find out what the dependiences are without having to try it and see?

perhaps you might like to reconsider your answer.

Adrian

[elhefe38]

From what you wrote, I suspect you do not link statically to IPP. A long time ago, Intel provided an installer that took care of installing dlls on the deployment targets. If you want to avoid finding which dll (there is one version for each processor family), unless you are already using it, you should statically link to IPP libs. It is not so complicated, it will only make your app. bigger... Instead of linking to ipp[xx].lib, link to ipp[xx]_l.lib (single threaded functions) or ipp[xx]_t.lib (multi-threaded version, will require a few additional libraries for deployment, easily found with dependency walker) and call ippInit() at the beginning of your program.

Nicolas

[Sergey_K_Intel]

Adrian,

If your application use dynamic linkage to IPP, with static dependency walkers you will see only references to upper level IPP DLLs - e.g. ippcore-7.0.dll, ipps-7.0.dll, ippi-7.0.dll etc. When the application starts execution, the upper level DLLs load CPU-specific DLLs according to current executing CPU model. There's a table of CPU letters and special chapter in IPP user's guide. That's it. There are no any other DLLs in IPP, besides "ippmsg.dll" of course.

I will check with proper people if there are any other dependencies on "ippmsg.dll" additionally to what i have described earlier. That's strange that your application crashed when no ippmsg.dll is found.

Regards,

Sergey

[SergeyKostrov]

Hi Andrian,

Quoting Adrian Edmonds

...using ipp and QT 4.8.0 rather than QT4.7.2 no longer works in release build and silently dies. This is a load dependency issue. Running it though dependency walker shows no problems in dependencies... 

Please take into account that in case of IPP DLLs MS Depends doesn't show IPP Waterfall DLLs. It means,
that if one of those DLLs is missing an application won't start. However, an error message

     "No DLL was found in the Waterfall procedure"

should be displayed.

It is not clear why your QT-based application "dies". If you have some logging API it has to be enabled in order to
see where a problem happens.

Best regards,
Sergey

[Adrian_Edmonds1]

elhefe38

Thank you very much for the reply. I will suggest this to the various PHD's that run our algorithm group and see what they feel about this. I don't program with ipp myself, I'm just the software manager tasked with delivery.

I only fully find dependencies by running dependency walker in profile mode

Regard

Adrian

[Adrian_Edmonds1]

Sergey

Thank you. I shall have to find the document you referred to . I now suspect that the release build PC next to my desk is no longer as 'clean' as I would like so I'll reformat it and start again.

"That's strange that your application crashed when no ippmsg.dll is found." I agree.

Adrian

[SergeyKostrov]

Quoting Sergey Kostrov

...
It means, that if one of those DLLs is missing an application won't start. However, an error message

     "No DLL was found in the Waterfall procedure"

should be displayed...

I simply wanted to follow up and this is a screenshot with the error message:



Once again, in case of IPP DLLs MS Depends doesn't show IPP Waterfall DLLs.

Best regards,
Sergey

[Ying_H_Intel · Accepted solution]

Just add some reference about IPP dll dependency.

Right, IPP DLL require two levels DLL : upper level IPP DLL, like ippi-7.0.dll, which can be shown in dependency walker and cpu-specific DLL like ippiw7-7.0.dll. 

For upper level IPP DLLs, most of them are following the basic rule as the article:
http://redfort-software.intel.com/en-us/articles/intel-integrated-performance-primitives-intel-ipp-library-dependencies-by-domain/. and Ihe ipp manual give each  untion the domain discription. So you can find them easily.

for cpu-specific DLL,  please see more about this  Understanding CPU Dispatching in the Intel® IPP Library.  In general, you distribute all cpu-specific DLL, so the application can run on any cpu type. 

Best Regards,
Ying

[Adrian_Edmonds1]

Sergey;

Thanks again for the reply. I'd like to close this thread as it's not going anywhere. The only closing points I'd like to make are:

• The error message is less than helpful. Perhaps an indication of the missing dll would be a good idea.
• Dependency walker in profile will show and will show missing dlls with a bit of effort. It needs to be run on the target platform though.
• The original question seems to have become lost in the noise.

Regards

Adrian

[Bernard]

Have you tried to use PE inspection tools like: dumpbin ,LordPE,IDA to perform static analysis of IAT and Export table? More insightful and helpful could have been usage of windbg with help of this debugger you would have been able to put software breakpoints on NtLoader functions and inspect function's parameters(little bit of reversing is always helpful),moreover putting a breakpoint on error message string could have reveal the culprit which is responsible for triggering the error message logic.

[Royi]

I'm also taking my first steps in the library and the documentation is horrible. You must update it to the latest versions of IPP (7.0 and 7.1). I'd like to link statically and have multi threading which is now deprecated. Does it mean I have to add so many dll's with the application? Isn't there a "Nicer Way"?

[Ying_H_Intel]

Hi Royi, Staic threaded library are still avaiable in IPP 7.1.. You can download them from Intel Registration center as <<>>. We plan to deprecate some features (like drop the IPP internal multi-threads, instead , user can use all kind of multi-thread freely) based on user usage model in the future . But 7.0 and 7.1 still keep all of them. Best Regards, Ying