From: Marco Atzeri <marco.atzeri@gmail.com>
To: lothar atheling <lothar_@warpmail.net>, cygwin@cygwin.com
Subject: Re: directory y: exe runs properly, directory x: exe quits straightaway
Date: Sun, 16 Feb 2014 18:15:00 -0000 [thread overview]
Message-ID: <5300F7C9.2020006@gmail.com> (raw)
In-Reply-To: <1392571459.4260.84059561.1F420E4B@webmail.messagingengine.com>
please reply to the list
On 16/02/2014 18:24, lothar atheling wrote:
>
>
> On Fri, Feb 14, 2014, at 11:31 AM, Marco Atzeri wrote:
>>
>>
>> On 14/02/2014 18:44, lothar atheling wrote:
>>>
>>> i am porting an application built with Visual C++ to build under Mingw
>>> gcc (CXX=/usr/bin/i686-w64-mingw32-g++)
>>
>> this is not the mingw list...
>>
> this is a cygwin problem being reported to the cygwin list!!!!
>
> it is almost certainly not a compiler / toolchain issue.
for me it is a mingw program issue. Just personal opinion.
>>> this behaviour has some reproducibility: if i copy the development
>>> directory with tar and rebuild, the behaviour represents, whereas if i
>>> make a new build directory, copy the sources and the makefile and
>>> rebuild, the behaviour vanishes.
>>
>> ldd is not the right tool for this search.
>> It does not show the DLLs not available on path
>>
>> try:
>> objdump -x mung |grep "DLL Name"
>>
> i had tried
>
> objdump -x mung.exe
>
> for these exes - they were identical in all directories.
That is expected. "objdump -x" provides all the info, while
"ldd" only the list of dlls available on the PATH
> i mentioned that the bash environment and the cygwin environments were
> also the same in all cases.
to me it seems than in one case
>>> $ ldd mung.exe
>>> ntdll.dll => /xp0/WINDOWS/system32/ntdll.dll (0x7c900000)
>>> kernel32.dll => /xp0/WINDOWS/system32/kernel32.dll
(0x7c800000)
ldd find only these dll's in the PATH
While in the second case
>>> while in the copy directory, ldd shows:
>>> $ ldd mung.exe
>>> ntdll.dll => /xp0/WINDOWS/system32/ntdll.dll (0x7c900000)
>> [cut]
>>> glut32.dll => /usr/bin/glut32.dll (0x10000000)
>>> WINMM.dll => /xp0/WINDOWS/system32/WINMM.dll (0x76b40000)
>>> libgcc_s_sjlj-1.dll =>
>>> /usr/i686-w64-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll
>>> (0x6cec0000)
>>> libstdc++-6.dll =>
>>> /usr/i686-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll
>>> (0x6fc40000)
>>>
ldd find all dll's on the PATH
Regards
Marco
--
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
prev parent reply other threads:[~2014-02-16 17:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-14 18:02 lothar atheling
2014-02-14 19:50 ` Marco Atzeri
[not found] ` <1392571459.4260.84059561.1F420E4B@webmail.messagingengine.com>
2014-02-16 18:15 ` Marco Atzeri [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5300F7C9.2020006@gmail.com \
--to=marco.atzeri@gmail.com \
--cc=cygwin@cygwin.com \
--cc=lothar_@warpmail.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).