Failed to start process after linking with a shared library
Hi,
I encountered this problem after trying to link my app with an external dll library. The dll libray build and works fine on desktop build. However, on Symbian it builds fine and links successfully with my app but when I try to run the app on my Nokia N8 I get the following error:
[INDENT]Failed to start process: 'Failed to create the process (verify that the executable and all required DLLs have been transferred) (permission denied)' Code: -46[/INDENT]
I also checked the pkg file and exctracted the sis file contents and found out that the external dll is there.
Any idea what I missed?
Re: Failed to start process after linking with a shared library
I just checked the 'sys\bin' contents on my SD card. Both, exe and dll files are there.
Why is there a "permission denied" error?
Re: Failed to start process after linking with a shared library
[QUOTE=mohs3nmo;879081]Why is there a "permission denied" error?[/QUOTE]
Most likely there's a platform security capability mismatch between the DLL and the loading process. In Symbian, a DLL needs to have at least the same capability set as the process that tries to load it. What TARGET.CAPABILITY have you defined for them, both the app and the DLL?
Re: Failed to start process after linking with a shared library
Thanks, that solved the problem. But what happens if I don't have any control over the TARGET.CAPABILITY of the DLL? Does the DLL need to have exact same capabilities of the process?
Re: Failed to start process after linking with a shared library
[QUOTE=mohs3nmo;879407]Thanks, that solved the problem. But what happens if I don't have any control over the TARGET.CAPABILITY of the DLL? Does the DLL need to have exact same capabilities of the process?[/QUOTE]
No. The capabilities of the DLL must be a superset of those in the loading process, that is, it must have at least all the capabilities that the loading process has, but it can have more. In practice, this means that if you want to make certain any client can load your DLL, it needs to have ALL (typically, ALL -TCB) capabilities even though they would not be needed for the functionality provided by the DLL. This is because the DLL cannot know the capabilities of the client beforehand.
Distributing DLLs with an extensive capability set does mean more red tape, of course, as the sensitive capabilities need to be separately approved.