Re: Help debugging a dll issue

[Duncan Roe <duncan_roe@acslink.net.au>]

On Fri, May 20, 2016 at 06:37:57AM -0400, Eliot Moss wrote:
> On 5/19/2016 11:28 PM, Sam Habiel wrote:
> >I had trouble with dlopen in Cygwin, where it did not behave intuitively. In my case, I was
> >dlopening libicu and friends. If you search using my name on the Cygwin mailing list, you should be
> >able to find out how I resolved the issue. I don't recall exactly what I did, but I think it was
> >that Cygwin put everything in a global namespace, and you need to dlsym NULL to grab the function
> >addresses.
>
> I just tried using NULL for the handle in dlsym, and I get the same result as before, and it
> does not change between using RTLD_LOCAL or RTLD_GLOBAL in dlopen.
>
> What I am seeing is that looking up one symbol is giving the value for a totally different
> one -- it's not returning an error indication.
>
> And this same wrong value is what happens if I just allow the natural linking to take place
> (which is what I really want to happen -- the dl calls simply help focus the issue).
>
> I will look up your previous issue, though, to see if there is something else there of use
> in this situation.
>
> Regards -- EM
>
Hi Eliot,

Do you know what is the name of the totally different symbol? (maybe from nm -D)

I wrote a "findit" utility a while back - it would be interesting if it gave the
same answer for both symbols. If you would git clone
https://github.com/duncan-roe/command_line_tools, cd to the findit subdirectory
and enter "make" then you will have it.

Example use:
> 21:23:15$ ./findit cygwin1.dll printf
> Found printf in cygwin1.dll at 0x18012ecbe
> 21:24:37$

HTH ... Duncan.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple