search for: lt_dlerror

...manual.html#index-lt_005fdlsym-167 says: Function: lt_ptr lt_dlsym(lt_dlhandle handle, const char *name) Return the address in the module handle, where the symbol given by the null-terminated string name is loaded. If the symbol cannot be found, NULL is returned. And lt_dlerror() also appears to have the same behaviour as its non-lt_ counterpart, so you'd think you'd have to do the same as above; use lt_dlerror(). However, it appears things like libtool's static lt_ptr sys_dl_sym (loader_data, module, symbol) lt_user_data loader_data;...

...> > Function: lt_ptr lt_dlsym(lt_dlhandle handle, const char *name) > > Return the address in the module handle, where the symbol given > by the null-terminated string name is loaded. If the symbol > cannot be found, NULL is returned. > > And lt_dlerror() also appears to have the same behaviour as its non-lt_ > counterpart, so you'd think you'd have to do the same as above; use > lt_dlerror(). > > However, it appears things like libtool's > > static lt_ptr > sys_dl_sym (loader_data, module, symbol) >...

Hi Chris, > Once you have that, you are hitting another problem. Specifically, > the JIT::getPointerToNamedFunction method in > lib/ExecutionEngine/JIT/Intercept.cpp just does a dlsym on missing > symbols. If dlsym returns null, you get the error message. > > The problem here is that .objc_class_name_* are special symbols that > are used by the objc linker support and they

...x: DynamicLibrary.cpp =================================================================== --- DynamicLibrary.cpp (revision 40112) +++ DynamicLibrary.cpp (working copy) @@ -130,11 +130,19 @@ if (I != g_symbols.end()) return I->second; + // Clear the error status of the ltdl library + lt_dlerror(); + // Now search the libraries. for (std::vector<lt_dlhandle>::iterator I = OpenedHandles.begin(), E = OpenedHandles.end(); I != E; ++I) { lt_ptr ptr = lt_dlsym(*I, symbolName); - if (ptr) + + // Get the error for the lt_dlsym call. If there was no error and the res...

Hi Ralph, On Fri, 2007-07-20 at 10:38 +0100, Ralph Corderoy wrote: > Hi Chris, > I could be missing something, but shouldn't the use of dlsym() be > > char *err; > void *p; > > if ((err = dlerror())) { > error("earlier undetected dlerror: %s\n", err); > } > p = dlsym(handle, sym); > if ((err = dlerror())) { >

On Fri, 20 Jul 2007, Ralph Corderoy wrote: > I could be missing something, but shouldn't the use of dlsym() be > The authors of dlsym() realised the return value was overloaded AFAICS. Yep, patches welcome :) -Chris -- http://nondot.org/sabre/ http://llvm.org/

...lve the symbol. I am at my wits end with this problem, the dlopen documentation states that if it explicidly fails, it will return a NULL pointer. However it doesn't say anything about succeeding with a NULL pointer. If the simple Objective-C program is still failing, even when checking if the lt_dlerror() code is set. I see two possibilities: a) The error code is being set even when the symbol is found and has a 0 address b) The error is caused by some other problem, maybe further upstream, indicated by the fact that the JIT interpreter crashes with a segfault. Because normal unresolved symbols w...

...ts end with this problem, the dlopen documentation states > that if it > explicidly fails, it will return a NULL pointer. However it doesn't > say anything about > succeeding with a NULL pointer. If the simple Objective-C program is > still failing, even > when checking if the lt_dlerror() code is set. I see two > possibilities: > > > a) The error code is being set even when the symbol is found and has a > 0 address unlikely > b) The error is caused by some other problem, maybe further upstream, > indicated by the > fact that the JIT interpreter crashes...