Hello, this is ltdl-related, especially related to the case when you try to open an invalid module without knowing that it actually is invalid. The story is that if you try to lt_dlopen a module that can't be dlopened (for example when it has unsatisfied dependencies), the lt_dlopen function will return null module handle. If you want to know where is the problem, you usually call the lt_dlerror() function immediatelly afterwards and examine the error string. The problem is that you always get the 'file not found' message. But it is not the case: If you manage to fix the error in your module, you can experience that it becomes "magically" dlopenable, although all files remain on the same place as before.
This is caused by lt_dlopen's behavior: It may not know what file to actually open. Even if you pass the module's .la file, which should be by intuition the best solution, it attempts to dlopen all sorts of files, some of them may even not be present. Therefore if one attempt fails, lt_dlopen tries the next one. And this happens even if the reason of the failiure was not the inability to locate the file. If everything fails, an error is set. Obviously it is the error from the last attempt, that usually is that 'file not found' case. The error that matters is therefore overwritten by every subsequent error. I have briefly tested the git version, the bug is still there. I would like to contribute to fix this bug. Could you please provide me with advice here and there? What I have thought of is stopping any attempt to open any new module filename if the previous attempt has failed for another reason that because the file wasn't there. Do you think this is a good assumption? Regards, Matej _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool