[BRLTTY] dlsym/dlerror (was Re: Clumping all the braille driver modules into one big app?)

[Willie Walker]

Hi Dave:

The _ex_unwind thing happens somewhere way prior to the call to dlsym. 
I'm not sure of the exact time or why it is referenced -- I can try to 
find the exact specifics if you really need them, but I believe it has 
something to do with cleaning up threads when they exit.  It is not 
referenced as a part of the call to dlsym.

In any case, yes, I tested the code before and after the one line 
change.  It fails before and works after.  :-)

Thanks!

Will

PS - I've asked the folks responsible for the _ex_unwind thing to clean 
up the dlerror state if they caused it to come into being.  While what 
they are doing is probably OK, the resulting error is confusing and 
unexpected.

Dave Mielke wrote:
> [quoted lines by Willie Walker on 2008/08/29 at 09:55 -0400]
> 
>> I'm not sure I understand the issue.  Here's the docs from Solaris:
> 
> Unfortunately, it doesn't get into the _ex_unwind thing. As written, both the 
> Solaris and Linux documents say essentially the same thing.
> 
>> So, what I'm suggesting is merely adding a call to dlerror prior to the 
>> call to dlsym in the code in question.  This would clear any prior error 
>> state and thus make sure that the existing call to dlerror would obtain 
>> results (if any) for the existing call to dlsym.  
> 
> I understand what you're suggesting but am not convinced that it'll deal with 
> the _ex_unwind problem. As I see it, there's not really any difference between 
> calling dlerror() before vs after a dlsym() which succeeds.
> 
> Do you have a way to reliably reproduce the problem so that you can then add in 
> the pre-call to dlerror() to see if it actually does work?
> 
>> The _ex_unwind thing is a bit of a mystery to me, but it has something 
>> to do with C/C++ linkage, I believe.  The code checks for the existence 
>> of this symbol and moves on if it doesn't exist.  But, it seems to fail 
>> to clear the error state.
>>
>> However, the fix already provided works and if you want to go with it, 
>> I'm happy with that.  :-)
> 
> I'd rather go with the most accurate fix, which your most recent suggestion is, 
> but I also don't like assuming that a fix will work when the cause of the 
> problem isn't understood. I'd appreciate it, therefore, if you could test it.
>