Re: lt_dlerror 'file not found' bug
Hello Matěj, On Sun 13 Dec 2009 22:45, Matěj Týč writes: > 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. I don't have anything to add, only that this bug is really, really irritating. We've suffered through it with Guile for quite some time now. So go Matěj go, you will have many many thankful people if you fix this bug!!! Andy -- O O O O O O O O O O O O O O B L O N G O ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: lt_dlerror 'file not found' bug
On Sun, 13 Dec 2009, Matěj Týč wrote: 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? The problem is that libltdl supports several different types of loaders and every available type of loader is used. So (as you say) the last loader used is the one which produces the final error. The first loader type which is always used is the preloader, which tries to load a static implementation from a library and a library which uses shared modules will usually fail the preloader. The preloader likely also pretends that the "file is not there" if there is no preloadable module. The bug you are encountering was reported at least two years ago. It is still awaiting a good idea for how to fix it. There needs to be some notion of error priority so that the error with the most priority gets saved. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ http://lists.gnu.org/mailman/listinfo/libtool
lt_dlerror 'file not found' bug
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
