Re: Question about the ldd output

Re: Question about the ldd output

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin]

Well, I don't think there's anything special that Cygwin does to load executables, because these are essentially Windows processes, so they are loaded by Windows, first and foremost.

But it gets even weirder.  Below are two _consecutive!_ runs of ldd on the very same executable.  Why the output differs so drastically (including the unknown dlls all of a sudden)?

1.
        ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc339d0000)
        KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffc31a00000)
        KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffc30090000)
        cygbz2-1.dll => /usr/bin/cygbz2-1.dll (0x3f6a40000)
        cygcom_err-2.dll => /usr/bin/cygcom_err-2.dll (0x3ef750000)
        cyggssapi_krb5-2.dll => /usr/bin/cyggssapi_krb5-2.dll (0x3eceb0000)
        cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ec980000)
        cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x3eb1a0000)
        cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3ee3a0000)
        cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3ea280000)
        cygz.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygz.dll (0x3aba30000)
        cygk5crypto-3.dll => /usr/bin/cygk5crypto-3.dll (0x3ec300000)
        cygwin1.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygwin1.dll (0x180040000)
        ??? => ??? (0xe80000)
        ??? => ??? (0x1440000)
        ??? => ??? (0xe80000)
        cygkrb5-3.dll => /usr/bin/cygkrb5-3.dll (0x3ec170000)
        cygkrb5support-0.dll => /usr/bin/cygkrb5support-0.dll (0x3ec150000)
        cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3ec8d0000)

2.
        ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc339d0000)
        KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffc31a00000)
        KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffc30090000)
        cygbz2-1.dll => /usr/bin/cygbz2-1.dll (0x3f6a40000)
        cygcom_err-2.dll => /usr/bin/cygcom_err-2.dll (0x3ef750000)
        cyggssapi_krb5-2.dll => /usr/bin/cyggssapi_krb5-2.dll (0x3eceb0000)
        cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ec980000)
        cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x3eb1a0000)
        cygwin1.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygwin1.dll (0x180040000)
        cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3ee3a0000)
        cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3ea280000)
        cygk5crypto-3.dll => /usr/bin/cygk5crypto-3.dll (0x3ec300000)
        cygkrb5-3.dll => /usr/bin/cygkrb5-3.dll (0x3ec170000)
        cygz.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygz.dll (0x3aba30000)
        cygkrb5support-0.dll => /usr/bin/cygkrb5support-0.dll (0x3ec150000)
        cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3ec8d0000)
	

--
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

Re: Question about the ldd output

[Brian Inglis]

On 2019-07-08 12:00, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
> Well, I don't think there's anything special that Cygwin does to load executables, because these are essentially Windows processes, so they are loaded by Windows, first and foremost.
> 
> But it gets even weirder.  Below are two _consecutive!_ runs of ldd on the very same executable.  Why the output differs so drastically (including the unknown dlls all of a sudden)?
> 
> 1.
>         ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc339d0000)
>         KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffc31a00000)
>         KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffc30090000)
>         cygbz2-1.dll => /usr/bin/cygbz2-1.dll (0x3f6a40000)
>         cygcom_err-2.dll => /usr/bin/cygcom_err-2.dll (0x3ef750000)
>         cyggssapi_krb5-2.dll => /usr/bin/cyggssapi_krb5-2.dll (0x3eceb0000)
>         cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ec980000)
>         cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x3eb1a0000)
>         cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3ee3a0000)
>         cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3ea280000)
>         cygz.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygz.dll (0x3aba30000)
>         cygk5crypto-3.dll => /usr/bin/cygk5crypto-3.dll (0x3ec300000)
>         cygwin1.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygwin1.dll (0x180040000)
>         ??? => ??? (0xe80000)
>         ??? => ??? (0x1440000)
>         ??? => ??? (0xe80000)
>         cygkrb5-3.dll => /usr/bin/cygkrb5-3.dll (0x3ec170000)
>         cygkrb5support-0.dll => /usr/bin/cygkrb5support-0.dll (0x3ec150000)
>         cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3ec8d0000)
> 
> 2.
>         ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc339d0000)
>         KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffc31a00000)
>         KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffc30090000)
>         cygbz2-1.dll => /usr/bin/cygbz2-1.dll (0x3f6a40000)
>         cygcom_err-2.dll => /usr/bin/cygcom_err-2.dll (0x3ef750000)
>         cyggssapi_krb5-2.dll => /usr/bin/cyggssapi_krb5-2.dll (0x3eceb0000)
>         cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ec980000)
>         cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x3eb1a0000)
>         cygwin1.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygwin1.dll (0x180040000)
>         cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3ee3a0000)
>         cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3ea280000)
>         cygk5crypto-3.dll => /usr/bin/cygk5crypto-3.dll (0x3ec300000)
>         cygkrb5-3.dll => /usr/bin/cygkrb5-3.dll (0x3ec170000)
>         cygz.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygz.dll (0x3aba30000)
>         cygkrb5support-0.dll => /usr/bin/cygkrb5support-0.dll (0x3ec150000)
>         cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3ec8d0000)

Libraries may be loaded asynchronously as they are accessed, and ldd just dumps
the dll import table once the subprocess is ready to run.
Perhaps these are import entries that ldd should detect and skip or annotate in
some more useful way.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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

Re: Question about the ldd output

[René Berber]

On 7/9/2019 11:40 AM, Brian Inglis wrote:

> Libraries may be loaded asynchronously as they are accessed, and ldd just dumps
> the dll import table once the subprocess is ready to run.
> Perhaps these are import entries that ldd should detect and skip or annotate in
> some more useful way.

True, its just the way Windows works, some libraries are dynamically
loaded, some may not exist, and are not needed.

Try the view from SysInternals' Dependency Walker (which now seems to be
named ListDLLs, or maybe was added to ProcessExplorer), shows the same
thing (if the Windows PATH is set to include Cygwin's libraries), with
lots of interrogation signs... except that it also shows exactly which
dll is "missing".
-- 
R.Berber



--
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

Re: Question about the ldd output

[Jon Turney]

On 09/07/2019 17:40, Brian Inglis wrote:
> On 2019-07-08 12:00, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
>> Well, I don't think there's anything special that Cygwin does to load executables, because these are essentially Windows processes, so they are loaded by Windows, first and foremost.
>>
>> But it gets even weirder.  Below are two _consecutive!_ runs of ldd on the very same executable.  Why the output differs so drastically (including the unknown dlls all of a sudden)?

This is probably a 'bug'.

> Libraries may be loaded asynchronously as they are accessed, and ldd just dumps
> the dll import table once the subprocess is ready to run.
> Perhaps these are import entries that ldd should detect and skip or annotate in
> some more useful way.

Please don't spread misinformation based upon guessing how Cygwin's ldd 
works.

It's not necessary, as the source code is available [1] :)

[1] 
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=history;f=winsup/utils/ldd.cc


--
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

Re: Question about the ldd output

[Brian Inglis]

[-- Attachment #1: Type: text/plain, Size: 2641 bytes --]

On 2019-07-09 12:02, Jon Turney wrote:
> On 09/07/2019 17:40, Brian Inglis wrote:
>> On 2019-07-08 12:00, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
>>> Well, I don't think there's anything special that Cygwin does to load
>>> executables, because these are essentially Windows processes, so they are
>>> loaded by Windows, first and foremost.
>>>
>>> But it gets even weirder.  Below are two _consecutive!_ runs of ldd on the
>>> very same executable.  Why the output differs so drastically (including the
>>> unknown dlls all of a sudden)?
> 
> This is probably a 'bug'.
> 
>> Libraries may be loaded asynchronously as they are accessed, and ldd just dumps
>> the dll import table once the subprocess is ready to run.
>> Perhaps these are import entries that ldd should detect and skip or annotate in
>> some more useful way.
> 
> Please don't spread misinformation based upon guessing how Cygwin's ldd works.

The ldd(1) man page documents how it works, and how to get dll info is
documented: the guesses are about how and with what Windows populates the
dll import table, and how ldd may misinterpret it: a slightly more informative
version of "This is probably a 'bug'" ;^>

> It's not necessary, as the source code is available [1] :)
> [1]
> https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=history;f=winsup/utils/ldd.cc

Uncommented, undocumented source code with mainly Windows calls is no help to
most of us with little background in Windows development.

David Macek did some debugging and suggested a patch to ignore threads with
entry points in ntdll.dll, but I could not see any followup, response, or
similar patch in the commits or source:
"Re: Why does ldd not show cyg*.dll in its output?"
https://sourceware.org/ml/cygwin/2016-06/msg00478.html

Based on what I see and PE format docs, ldd should iterate over all the
entries in the dll import directory table, until the end or an all zeros/nulls
entry is reached, and the name pointers should all be 32 bit image base relative
addresses, but they are being handled as section relative addresses in
dump_import_directory(), which might amount to the same thing here.

The attached shows the opinions of ldd, cygcheck, and SysInternals listdlls64
run against "$ yes > /dev/null &" process, so a comparison of the first two
might help, but the latter is proprietary closed source and the process is
executing, so may show dlls dynamically loaded by other Windows dlls.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

[-- Attachment #2: y.txt --]
[-- Type: text/plain, Size: 2122 bytes --]

$ ldd /bin/yes
	ntdll.dll => /proc/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff88e7a0000)
	KERNEL32.DLL => /proc/cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ff88ba30000)
	KERNELBASE.dll => /proc/cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ff88b2e0000)
	cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000)
	cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3d17d0000)
	cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3e21f0000)
$ cygcheck /bin/yes
C:\cygwin64\bin\yes.exe
  C:\cygwin64\bin\cygwin1.dll
    C:\WINDOWS\system32\KERNEL32.dll
      C:\WINDOWS\system32\ntdll.dll
      C:\WINDOWS\system32\KERNELBASE.dll
      C:\WINDOWS\system32\api-ms-win-core-processthreads-l1-1-1.dll
      C:\WINDOWS\system32\api-ms-win-core-synch-l1-2-0.dll
      C:\WINDOWS\system32\api-ms-win-core-file-l1-2-0.dll
      C:\WINDOWS\system32\api-ms-win-core-timezone-l1-1-0.dll
      C:\WINDOWS\system32\api-ms-win-core-localization-l1-2-0.dll
      C:\WINDOWS\system32\api-ms-win-core-file-l2-1-0.dll
      C:\WINDOWS\system32\api-ms-win-core-xstate-l2-1-0.dll
  C:\cygwin64\bin\cygintl-8.dll
    C:\cygwin64\bin\cygiconv-2.dll
$ listdlls64 yes			# SysInternals Suite
------------------------------------------------------------------------------
yes.exe pid: 7948
Command line: "C:\cygwin64\bin\yes.exe"

Base                Size      Path
0x0000000000400000  0xf000    C:\cygwin64\bin\yes.exe
0x000000008e7a0000  0x1ed000  C:\WINDOWS\SYSTEM32\ntdll.dll
0x000000008ba30000  0xb3000   C:\WINDOWS\System32\KERNEL32.DLL
0x000000008b2e0000  0x293000  C:\WINDOWS\System32\KERNELBASE.dll
0x00000000d17d0000  0x14000   C:\cygwin64\bin\cygintl-8.dll
0x0000000080040000  0x5f0000  C:\cygwin64\bin\cygwin1.dll
0x00000000e21f0000  0x105000  C:\cygwin64\bin\cygiconv-2.dll
0x000000008c090000  0xa3000   C:\WINDOWS\System32\advapi32.dll
0x000000008e350000  0x9e000   C:\WINDOWS\System32\msvcrt.dll
0x000000008c250000  0x9e000   C:\WINDOWS\System32\sechost.dll
0x000000008d9a0000  0x122000  C:\WINDOWS\System32\RPCRT4.dll
0x000000008a190000  0xc000    C:\WINDOWS\SYSTEM32\CRYPTBASE.DLL
0x000000008b680000  0x7e000   C:\WINDOWS\System32\bcryptPrimitives.dll


[-- Attachment #3: Type: text/plain, Size: 219 bytes --]


--
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

Re: Question about the ldd output

[Mark Geisert]

Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
> Well, I don't think there's anything special that Cygwin does to load executables, because these are essentially Windows processes, so they are loaded by Windows, first and foremost.
> 
> But it gets even weirder.  Below are two _consecutive!_ runs of ldd on the very same executable.  Why the output differs so drastically (including the unknown dlls all of a sudden)?
> 
> 1.
>          ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc339d0000)
>          KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffc31a00000)
>          KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffc30090000)
>          cygbz2-1.dll => /usr/bin/cygbz2-1.dll (0x3f6a40000)
>          cygcom_err-2.dll => /usr/bin/cygcom_err-2.dll (0x3ef750000)
>          cyggssapi_krb5-2.dll => /usr/bin/cyggssapi_krb5-2.dll (0x3eceb0000)
>          cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ec980000)
>          cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x3eb1a0000)
>          cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3ee3a0000)
>          cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3ea280000)
>          cygz.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygz.dll (0x3aba30000)
>          cygk5crypto-3.dll => /usr/bin/cygk5crypto-3.dll (0x3ec300000)
>          cygwin1.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygwin1.dll (0x180040000)
>          ??? => ??? (0xe80000)
>          ??? => ??? (0x1440000)
>          ??? => ??? (0xe80000)

Briefly, ldd acts as a Windows debugger starting up the given executable. It 
receives LOAD_DLL_EVENTs from Windows and decodes the event info to print each 
line of output.

The drastically lower memory addresses being shown on the last three lines lead 
me to speculate these are due to Windows repositioning non-Cygwin DLLs, or maybe 
Cygwin DLLs rebase doesn't know about, due to address space collisions at their 
normal load address(es).

That said, ldd might be enhanced to show more info in these transient cases. 
Patches thoughtfully considered...

..mark

--
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

Re: Question about the ldd output

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin]

> But it gets even weirder.  Below are two _consecutive!_ runs of ldd on the very same executable.  Why the output differs so drastically (including the unknown dlls all of a sudden)?

Another round of consecutive calls of ldd on the very same executable file, and a similar "indeterministic" result (the executable itself is much simpler than the one from my previous post, so the list of DLLs is quite short):

1.
        ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc339d0000)
        KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffc31a00000)
        KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffc30090000)
        cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3ee3a0000)
        ??? => ??? (0xc90000)
        cygwin1.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygwin1.dll (0x180040000)

2.
        ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc339d0000)
        KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffc31a00000)
        KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffc30090000)
        cygwin1.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygwin1.dll (0x180040000)
        cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3ee3a0000)

How can that be?


--
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

Re: Question about the ldd output

[Brian Inglis]

On 2019-07-05 12:28, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
> Here's the output from ldd, of an executable built just recently on Cygwin:
>         ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc339d0000)
>         KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffc31a00000)
>         KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffc30090000)
>         cygwin1.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygwin1.dll (0x180040000)
>         cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ec980000)
>         cygcom_err-2.dll => /usr/bin/cygcom_err-2.dll (0x3ef750000)
>         cygbz2-1.dll => /usr/bin/cygbz2-1.dll (0x3f6a40000)
>         cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3ee3a0000)
>         cyggssapi_krb5-2.dll => /usr/bin/cyggssapi_krb5-2.dll (0x3eceb0000)
>         cygz.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygz.dll (0x3aba30000)
>         cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x3eb1a0000)
>         cygk5crypto-3.dll => /usr/bin/cygk5crypto-3.dll (0x3ec300000)
>         cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3ec8d0000)
>         cygkrb5support-0.dll => /usr/bin/cygkrb5support-0.dll (0x3ec150000)
>         ??? => ??? (0x90000)
> My question would be, how to read the last line? It'd be quite suspicious if 
> ldd is unable to figure out what library (name) is required (the left side
> of the =>), but I understand that the library itself might be missing (so
> it's logical to put "???" on the right side in that case).
> Any insight is appreciated.

I found many Cygwin exes that display zero to multiple lines like that,
depending on the run, but it was flakey and inconsistent, and could not find any
common factors across builds.
Across 1684 /bin/exes, about 400 exes displayed about 600 lines with '???'.

That looks like it might be a limitation of how ldd works under Cygwin.
If you compare ldd output to cygcheck output from the same exe, ldd always omits
and cygcheck always includes the following on my W10 Home:

        C:\WINDOWS\system32\api-ms-win-core-processthreads-l1-1-1.dll
        C:\WINDOWS\system32\api-ms-win-core-synch-l1-2-0.dll
        C:\WINDOWS\system32\api-ms-win-core-file-l1-2-0.dll
        C:\WINDOWS\system32\api-ms-win-core-timezone-l1-1-0.dll
        C:\WINDOWS\system32\api-ms-win-core-localization-l1-2-0.dll
        C:\WINDOWS\system32\api-ms-win-core-file-l2-1-0.dll
        C:\WINDOWS\system32\api-ms-win-core-xstate-l2-1-0.dll

so what we are seeing may be an artifact of Windows dll load table entries, as
Windows programs can not be built with unresolved dll links, but Cygwin
dynamically autoloads dlls when functions are called.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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

Question about the ldd output

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin]

Hi all,

Here's the output from ldd, of an executable built just recently on Cygwin:

        ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc339d0000)
        KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffc31a00000)
        KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffc30090000)
        cygwin1.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygwin1.dll (0x180040000)
        cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ec980000)
        cygcom_err-2.dll => /usr/bin/cygcom_err-2.dll (0x3ef750000)
        cygbz2-1.dll => /usr/bin/cygbz2-1.dll (0x3f6a40000)
        cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3ee3a0000)
        cyggssapi_krb5-2.dll => /usr/bin/cyggssapi_krb5-2.dll (0x3eceb0000)
        cygz.dll => /cygdrive/u/2.4.0/release/Cygwin-64/bin/cygz.dll (0x3aba30000)
        cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x3eb1a0000)
        cygk5crypto-3.dll => /usr/bin/cygk5crypto-3.dll (0x3ec300000)
        cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3ec8d0000)
        cygkrb5support-0.dll => /usr/bin/cygkrb5support-0.dll (0x3ec150000)
        ??? => ??? (0x90000)

My question would be, how to read the last line?  It'd be quite suspicious if ldd is unable to figure out what library (name) is required
(the left side of the =>), but I understand that the library itself might be missing (so it's logical to put "???" on the right side in that case).

Any insight is appreciated.

Thanks,
Anton


--
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