The difference, althought it really doesn't matter, is that
libzsh-4.1.1.dll was rebased, while cygggi-2.dll isn't. Something in
the
makeup of cygggi-2.dll causes the same condition as when
libzsh-4.1.1.dll
is rebased.
I found a couple of __declspec(dllexport) and __declspec(dllimport)
Peter A. Castro wrote:
In the case of zsh, it's completely cygwin stuff, no MS stuff.
As is the case with LibGGI.
Is it a known problem?
No. If nothing obvious turns up in your initial efforts to scope
the
problem, you're probably going to be best off debugging into the
Cygwin
Igor Pechtchanski wrote:
One obvious thing to check for is whether the application tries to
dynamically load a Cygwin-dependent DLL (which may result in attempting
to
load cygwin1.dll dynamically, and that is *not supported*).
I assume that by dynamically load, you are referring to dlopen(). If
Larry Hall wrote:
I'd suggest 'cygcheck cygggi-2.dll'. Make sure there's no MS CRT in
there anywhere. If there is, you're on dangerous ground. Comparing the
output of this with that of cygii-0.dll might be instructive too.
~$ cygcheck /bin/cyggg-0.dll
C:/cygwin/bin/cyggg-0.dll
\Microsoft Visual Studio\Common\Tools
c:\Program Files\Microsoft Visual Studio\VC98\bin
C:\cygwin\usr\X11R6\bin
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1000(peda) GID: 513(None)
513(None)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1000(peda) GID: 513(None)
513(None
Hello!
Any chance there is an update of the automake-devel package to 1.8 anytime
soon?
Thanks in advance,
Peter Ekberg
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
6 matches
Mail list logo
