On Wed, 11 Feb 2004 [EMAIL PROTECTED] wrote:
> > 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 cou
> 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)
On Mon, 9 Feb 2004 [EMAIL PROTECTED] wrote:
> Peter A. Castro wrote:
>
> > In the case of zsh, it's completely cygwin stuff, no MS stuff.
>
> As is the case with LibGGI.
The difference, althought it really doesn't matter, is that
libzsh-4.1.1.dll was rebased, while cygggi-2.dll isn't. Something
On Mon, 9 Feb 2004, Jason Tishler wrote:
> Peter,
>
> On Mon, Feb 09, 2004 at 10:14:10AM +0100, [EMAIL PROTECTED] wrote:
> > You're talking about rebased dlls. I don't know if cygggi-2.dll is
> > rebased or not, how can I tell?
>
> Rebasing is a manual process. So, if you didn't run rebaseall or
Peter,
On Mon, Feb 09, 2004 at 10:14:10AM +0100, [EMAIL PROTECTED] wrote:
> You're talking about rebased dlls. I don't know if cygggi-2.dll is
> rebased or not, how can I tell?
Rebasing is a manual process. So, if you didn't run rebaseall or rebase
yourself, then cygggi-2.dll and the rest of you
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 int
At 02:57 AM 2/6/2004, [EMAIL PROTECTED] you wrote:
>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.
>
>~$ cygchec
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
C:/cygwin/b
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().
On Thu, 5 Feb 2004, Igor Pechtchanski wrote:
> On Thu, 5 Feb 2004, Larry Hall wrote:
>
> > At 06:10 AM 2/5/2004, [EMAIL PROTECTED] you wrote:
> > >Hello!
> > >
> > >I have been trying to get LibGGI to build and work on cygwin and
> > >I have the following problem:
Interestingly enough this is the
On Thu, 5 Feb 2004, Larry Hall wrote:
> At 06:10 AM 2/5/2004, [EMAIL PROTECTED] you wrote:
> >Hello!
> >
> >I have been trying to get LibGGI to build and work on cygwin and
> >I have the following problem:
> >
> >When I run an application linked against the resulting cygggi-2.dll
> >it segfaults i
At 06:10 AM 2/5/2004, [EMAIL PROTECTED] you wrote:
>Hello!
>
>I have been trying to get LibGGI to build and work on cygwin and
>I have the following problem:
>
>When I run an application linked against the resulting cygggi-2.dll
>it segfaults in [EMAIL PROTECTED] (according to gdb) before main
>is
Hello!
I have been trying to get LibGGI to build and work on cygwin and
I have the following problem:
When I run an application linked against the resulting cygggi-2.dll
it segfaults in [EMAIL PROTECTED] (according to gdb) before main
is reached.
LibGGI consists of three core libraries: ggi, gii
13 matches
Mail list logo
