Could not find resource

I have been having this problem on my Linux machine...
could not find the resource:a148e300-5740-11d1-a904-080036aaa103.Location

Due to this the document services cannot be availed.

I could not find out the cause on Linux. My windows version used to work fine. Now all of a sudden the same error has come up on Windows too. I tried reinstalling OCC but in vain.

Roman Lygin's picture

Here is a (full) checklist you have to check:

1. Env var CSF_Defaults is defined and points to the directory with file inside,
where is a name returned by the ResourcesName() method of your subclass of TDocStd_Application.

2. Inside there are groups of entries:

.Description:
.FileExtension:
.StoragePlugin:
.RetrievalPlugin:

where is a string from a sequence returned by the Formats() method of your subclass of TDocStd_Application

3. Env var CSF_PluginDefaults is defined and points to the directory with Plugin file inside

4. The Plugin file contains
.Location:
.Location:

where is a reduced name of the library with respective plugin inside (e.g. MyLib for libMyLib.so
on Unix/Linux or MyLib.dll on Windows)

5. The ibrary and all other libraries it depends on are found in PATH (on Windows) or LD_LIBRARY_PATH (on Linux/Unix)

Next step once you have checked this will be to use a debugger and see where failure happens. Is the name of the library
correctly identified ? Is it loaded into memory ? Is the plugin factory function correctly retrieved and so forth

Hope this helps.
Roman
---
opencascade.blogspot.com - blog on Open CASCADE

Sharjith Naramparambath's picture

Thank you for the directions. With your guidelines I did all the checks and the problem got solved, the path settings were getting messed up since I am doing it programatically as shown in the OCAF sample. On linux there is no readymade function to get the current exe path. I used the /proc//self/exe/ to get the path. It returns the path including the exe name itself which I skipped to notice and was causing the problem.

Thanks again.

Roman Lygin's picture

Glad this worked !
On Unix, shouldn't argv[0] be enough to get the app path ?

Roman
---
opencascade.blogspot.com - blog on Open CASCADE

Sharjith Naramparambath's picture

argv[0] gives only the executable name not the full path. I have kept thr resource and plugin file in the bin folder and the run.csh script in the project directory hence to get the directory in which the exe resides you have to play around a little bit using the unix function 'readlink'. Windows has a function ::GetModuleFileName to which if you pass NULL as first argument you get the full path of the current process(module).

BTW my problem has only partially been solved. The error message of the plugin has disappeared but save and open crashes yet on Linux.