* Re: Question about the ldd output
@ 2019-07-08 20:13 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
2019-07-09 16:40 ` Brian Inglis
2019-07-17 2:38 ` Mark Geisert
0 siblings, 2 replies; 9+ messages in thread
From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin @ 2019-07-08 20:13 UTC (permalink / raw)
To: 'cygwin@cygwin.com'
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question about the ldd output
2019-07-08 20:13 Question about the ldd output Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
@ 2019-07-09 16:40 ` Brian Inglis
2019-07-09 17:39 ` René Berber
2019-07-09 18:02 ` Jon Turney
2019-07-17 2:38 ` Mark Geisert
1 sibling, 2 replies; 9+ messages in thread
From: Brian Inglis @ 2019-07-09 16:40 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question about the ldd output
2019-07-09 16:40 ` Brian Inglis
@ 2019-07-09 17:39 ` René Berber
2019-07-09 18:02 ` Jon Turney
1 sibling, 0 replies; 9+ messages in thread
From: René Berber @ 2019-07-09 17:39 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question about the ldd output
2019-07-09 16:40 ` Brian Inglis
2019-07-09 17:39 ` René Berber
@ 2019-07-09 18:02 ` Jon Turney
2019-07-10 22:55 ` Brian Inglis
1 sibling, 1 reply; 9+ messages in thread
From: Jon Turney @ 2019-07-09 18:02 UTC (permalink / raw)
To: The Cygwin Mailing List
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question about the ldd output
2019-07-09 18:02 ` Jon Turney
@ 2019-07-10 22:55 ` Brian Inglis
0 siblings, 0 replies; 9+ messages in thread
From: Brian Inglis @ 2019-07-10 22:55 UTC (permalink / raw)
To: cygwin
[-- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question about the ldd output
2019-07-08 20:13 Question about the ldd output Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
2019-07-09 16:40 ` Brian Inglis
@ 2019-07-17 2:38 ` Mark Geisert
1 sibling, 0 replies; 9+ messages in thread
From: Mark Geisert @ 2019-07-17 2:38 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question about the ldd output
@ 2019-07-08 21:07 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
0 siblings, 0 replies; 9+ messages in thread
From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin @ 2019-07-08 21:07 UTC (permalink / raw)
To: 'cygwin@cygwin.com'
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question about the ldd output
2019-07-05 18:28 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
@ 2019-07-06 6:45 ` Brian Inglis
0 siblings, 0 replies; 9+ messages in thread
From: Brian Inglis @ 2019-07-06 6:45 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Question about the ldd output
@ 2019-07-05 18:28 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
2019-07-06 6:45 ` Brian Inglis
0 siblings, 1 reply; 9+ messages in thread
From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin @ 2019-07-05 18:28 UTC (permalink / raw)
To: 'cygwin@cygwin.com'
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-07-17 2:38 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-08 20:13 Question about the ldd output Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
2019-07-09 16:40 ` Brian Inglis
2019-07-09 17:39 ` René Berber
2019-07-09 18:02 ` Jon Turney
2019-07-10 22:55 ` Brian Inglis
2019-07-17 2:38 ` Mark Geisert
-- strict thread matches above, loose matches on Subject: below --
2019-07-08 21:07 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
2019-07-05 18:28 Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
2019-07-06 6:45 ` Brian Inglis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).