The following packages have recently been added to the Cygwin net release:
libgii1-1.0.0-1
libgii1-devel-1.0.0-1
libgii1-input-x-1.0.0-1
LibGII is a "General Input Interface" and is primarily the input
layer for LibGGI, the "General Graphics Interface".
The main purpose
The following packages have recently been added to the Cygwin net release:
libggi2-2.2.0-1
libggi2-devel-2.2.0-1
libggi2-display-file-2.2.0-1
libggi2-display-terminfo-2.2.0-1
libggi2-display-x-2.2.0-1
libggi2-samples-2.2.0-1
LibGGI is a "General Gr
The following packages have recently been added to the Cygwin net release:
libggiwmh0-0.3.0-1
libggiwmh0-devel-0.3.0-1
libggiwmh0-display-x-0.3.0-1
libggiwmh0-samples-0.3.0-1
libggiwmh is a libggi extension whereby wmh stands for 'Window Manager Hints'.
It ad
The following packages have recently been added to the Cygwin net release:
libggimisc2-2.2.0-1
libggimisc2-devel-2.2.0-1
libggimisc2-samples-2.2.0-1
LibGGIMisc is the externsion for misc features for the General Graphics
Interface. Misc features are features which do not
A new version of 'libggi' is available for download. This update includes
a new backend in the package 'libggi2-display-aa' based on the recently added
'aalib' package. It also adds a new demo 'ggi-flying_ggis' to the package
'libggi2-samples'.
libggi2-2.2.0-2
libggi2-devel-2.2.0-2
A new version of 'libgii' is available for download. It is an upstreams
bugfix release, but also includes a packaging fix to enable debugging.
- Look at GII_DEBUGSYNC instead of GGI_DEBUGSYNC
- Update doc/README.directx to help MinGW users configure properly
- input-mouse: ignore undefined bit in
A new version of 'libggi' is available for download. It is an upstreams
bugfix release, but also includes a packaging fix to enable debugging.
- Update doc/README.directx to help MinGW users configure properly
- display-fbdev(7): correct path in config-file. The mach64 fbdev
accelerator-sublib l
A new version of 'libggimisc' is available for download. It is an upstreams
bugfix release, but also includes a packaging fix to enable debugging.
- Cleanup properly on failure in ggiMiscInit
- pseudo-stubs: kill leftover (debugging) printf
- buildsystem: libtool update / fixes
New packages:
A new version of 'libggiwmh' is available for download. It is an upstreams
bugfix release, but also includes a packaging fix to enable debugging.
- Cleanup properly on failure in ggiWmhInit
- buildsystem: libtool update / fixes
New packages:
libggiwmh2-0.3.1-1
libggiwmh2-devel-0.
On Tue, Apr 25, 2006 at 11:33:52PM +0200, Christian Franke wrote:
> Dave Korn wrote:
> >...
> >diff -rup patch-2.5.8-8.orig/partime.c patch-2.5.8-8/partime.c
> >--- patch-2.5.8-8.orig/partime.c 2002-12-15 21:37:32.00100 +0100
> >+++ patch-2.5.8-8/partime.c 2006-04-25 12:14:59.797168500 +02
On Fri, May 12, 2006 at 07:49:30PM -0400, Charles Wilson wrote:
> Yaakov S (Cygwin Ports) wrote:
...
> >3) In addition, it is possible to have a wrapper for automake with our
> >setup. Gentoo has a similar setup, and uses this:
> >
> >http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/sys-deve
On Sun, May 28, 2006 at 10:40:34PM +, Torfinn Ottesen wrote:
>
> I did this for three programs, prog1 (commercial, external),
> prog2 (inhouse, compiled on Cygwin) and native cygwin prog3:
> "echo". I claim that I saw increased increase memory usage
> fo
Hi!
I have been looking at a failure in the testsuite in
libtool-cvs which I have reduced to the following
script. I have included the approximate output from
any program execed by it in comments along with
comments as to what is going wrong.
$ gcc --version | head -1
gcc (GCC) 3.4.4 (cygming spe
* Charles Wilson wrote on Friday, September 16, 2005 05:28 CEST:
> FWIW, this is not a "recent" regression --- nothing "changed" in
> binutils or gcc. I just installed binutils-20040725-2 from
> the Cygwin
> Time Machine and got identical output.
Oh, I can see how you think I thought it was a
Hello!
The subject says it all. Intentional or an oversight? You tell me...
Cheers,
Peter
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cy
Hello!
I recently tried to build a package that was using cpp for other
purposes than preprocessing C files. Its configure script was
looking for a way to not have cpp predefine anything, and it
specifically tried the -undef option, but failed. From reading the
docs, I couldn't figure out why. Her
On Mon, Jan 09, 2006 at 01:42:35PM +0100, Corinna Vinschen wrote:
> On Jan 9 09:43, Peter Ekberg wrote:
> > The subject says it all. Intentional or an oversight? You tell me...
>
> You know the answer: http://cygwin.com/acronyms/#WJM
:-)
> Thanks, I've applied a patch.
On Mon, Jan 09, 2006 at 10:58:00AM +0100, Peter Ekberg wrote:
> Hello!
>
> I recently tried to build a package that was using cpp for other
> purposes than preprocessing C files. Its configure script was
> looking for a way to not have cpp predefine anything, and it
> spec
On Mon, Jan 16, 2006 at 10:49:38PM -0600, * * wrote:
> On 1/16/06, Peter Ekberg <[EMAIL PROTECTED]> wrote:
> > On Mon, Jan 09, 2006 at 10:58:00AM +0100, Peter Ekberg wrote:
> > > Hello!
> > >
> > > I recently tried to build a package that was using cpp for
On Mon, Jan 16, 2006 at 12:13:12PM +0100, Peter Ekberg wrote:
> On Mon, Jan 09, 2006 at 10:58:00AM +0100, Peter Ekberg wrote:
> > Hello!
> >
> > I recently tried to build a package that was using cpp for other
> > purposes than preprocessing C files. Its configure scrip
On Mon, Jan 23, 2006 at 10:01:44PM +0100, Peter Ekberg wrote:
> On Mon, Jan 16, 2006 at 12:13:12PM +0100, Peter Ekberg wrote:
> > On Mon, Jan 09, 2006 at 10:58:00AM +0100, Peter Ekberg wrote:
> > > Hello!
> > >
> > > I recently tried to build a package that wa
On Tue, Jan 31, 2006 at 09:37:05PM +0100, Gerrit P. Haase wrote:
> Peter schrieb:
>
> > On Mon, Jan 23, 2006 at 10:01:44PM +0100, Peter Ekberg wrote:
> >> On Mon, Jan 16, 2006 at 12:13:12PM +0100, Peter Ekberg wrote:
> >> > On Mon, Jan 09, 2006 at 10:
Hello!
What is going on here?
~$ ps -f | grep $$
peda2316 1 con 20:21:51 /usr/bin/bash
peda31802316 con 21:51:47 /usr/bin/ps
peda31642316 con 21:51:47 /usr/bin/grep
[I use bash, if that matters]
~$ tail -f frame.log | grep Antenna
2005-05-11,21:51:07:
Lev Bishop wrote:
> On 11/05/05, Peter Ekberg wrote:
>> What is going on here?
>
> My guess: "tail frame.log" closes its stdout as soon as it has read
> the requested lines from the file, "tail -f frame.log" keeps its
> stdout open, since it is waiting f
Lev Bishop wrote:
> Try "grep --line-buffered" to get grep to flush output after every
> line. There is a performance penalty for doing this. I don't know why
> you don't see the buffering when grep's stdout isn't redirected.
> Perhaps grep (or the std library) removes/reduces buffering in the
> ca
Hello!
I'm finding that I have a need to select on a win32 handle. I found the
function cygwin_attach_handle_to_fd which sounded promising, but I do
not have any luck when I try to use it.
I did look through the sources in winsup, but came to the perhaps
misguided conclusion that there needs to b
On Mon, Oct 09, 2006 at 10:55:18AM +0200, Corinna Vinschen wrote:
> On Oct 7 04:52, Peter Ekberg wrote:
> > Hello!
> >
> > I'm finding that I have a need to select on a win32 handle. I found the
> > function cygwin_attach_handle_to_fd which sounded promising, but
limited to non-cygwin apps? I.e. is it true
that an app that depends directly on the cygwin1.dll is incapable of
dlopening dlls that depend on cygwin1.dll?
Regards,
Peter Ekberg
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Christopher Faylor wrote:
>On Thu, Aug 05, 2004 at 09:09:40AM +0200, Peter Ekberg wrote:
>>I have read several messages stating that dlopen does not work for
dlls
>>that depend on cygwin1.dll.
>>(e.g. http://sources.redhat.com/ml/cygwin/2004-06/msg01056.html).
>>I have a
Reid Thompson wrote:
> well -- i just redid the entire thing, with the correct spelling and
> your original post works
>
> $ ./load
> pseudo_stub.dll ok
> foo.dll ok
That's strange, did my original post first get you error 998 for
pseudo_stubs.dll and now, after some juggling, the same thing i
I wrote:
> Reid Thompson wrote:
> > well -- i just redid the entire thing, with the correct spelling and
> > your original post works
> >
> > $ ./load
> > pseudo_stub.dll ok
> > foo.dll ok
>
> That's strange, did my original post first get you error 998 for
> pseudo_stubs.dll and now, after some
> > Ah, now I see it. You have to be careful with your typing.
> > pseudo_stubs.dll (with one s in the end) is the name that fails.
> > Apparently both pseudo_stub.dll (no s) and psuedo_stubs.dll (bad
> > spelling) work. And pseudo_stubss.dll (double s) definitely
> works, that
> > I have tried my
rch/000309.html
This post can also be related:
http://www.cygwin.com/ml/cygwin/2003-10/msg00556.html
Any suggestions? Is it reproducable?
Cheers,
Peter Ekberg
cygcheck.out
Description: cygcheck.out
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://
I wrote:
> ~/ggi-cygwin/libgii$ ../../ggi3/ggi-core/libgii/configure
> --prefix=/usr
> -C --with-extra-includes=/cygdrive/c/dx9csdk/include
> configure: error: invalid package name: extra-includes
> ~/ggi-cygwin/libgii$ ../../ggi3/ggi-core/libgii/configure
> --prefix=/usr
> -C --with-extra-incl
> The last time I tried to build ggi-project failed with compilation
> errors. That probably means that I was able to configure it
> or parts of
> it.
I have spent some time on getting libggi working. I believe it does work
now, you have to use the cvs version though as the released versions do
Gerrit wrote:
> Peter wrote:
>
> >> The last time I tried to build ggi-project failed with compilation
> >> errors. That probably means that I was able to configure it
> >> or parts of
> >> it.
>
> > I have spent some time on getting libggi working. I believe
> it does work
> > now, you have
> - Fix mysterious configure script premature exit. (Pierre Humblet)
I'm sorry to report that 1.5.11-1 does not fix this configure script
premature exit:
http://sources.redhat.com/ml/cygwin/2004-08/threads.html#01025
Is there any other output I can provide to help debug this?
Cheers,
Peter
--
Christopher Faylor wrote:
> On Mon, Sep 13, 2004 at 09:54:29PM -0400, Pierre A. Humblet wrote:
> >The surprise is that the error message:
> >"configure: error: invalid package name: extra-includes"
> >is produced at time 29722848 by bash 2624 (the main script
> pid). This
> >is BEFORE the second
Bogdan Vacaliuc wrote:
> In your *new* trace there are the same trace (on line 176632)
> in the 'zone' between the fork() and the parent-shell exit decision
> point of your most recent trace.
>
> Did you update your cygwin since your last run? Perhaps its
> just an artifact? The set happens 4
> On Mon, Sep 13, 2004 at 10:25:52PM -0400, Christopher Faylor wrote:
> >I will create a snapshot with double the number of pids cached in
> >cygwin. This will cause the last 8 pids to be held from reuse by
> >windows.
>
> Hmm. I woke up this morning to see people busily flooding
> the airwaves
Christopher Faylor wrote:
> Grr... This was the newlib problem previously mentioned. I forgot to
> generate the snapshot in such a way as to work around this problem.
>
> The new snapshot should work better.
Indeed it does. I have tried a couple of times without any hickups.
With 1.5.11 a have
Hello!
I'm working on a project (GGI) that uses DirectX (DirectInput and
DirectDraw) and would like to be able to compile it without downloading
the DirectX SDK from Microsoft. So, I tried to get it to work with the
DirectX headers available in Wine and this was a success after some
trivial #defin
Pierre A. Humblet wrote:
> FWIW, attached is a patch to bash that may improve its
> behavior on Cygwin.
> The idea is that when a new process is stored in the memory array, any
> existing process with the same pid is marked "reused".
> "reused" processes
> are never considered when searching for
Hello!
I miss a declaration for siginterrupt(3). Should there
not be one in signal.h or somewhere?
Background:
Make in a package that needs it ends with:
error: implicit declaration of function `siginterrupt'
Yes, I know that I don't need to specify
-Werror-implicit-function-declaration, but I
Chuck wrote:
> New alpha versions of libtool available for test. This is
> very close to
> what libtool-2.0 will be. Please evaluate.
>
> NOTE: cygwin maintainers: do NOT release any updates of your packages
> built using this version of libtool! Be sure to revert back to
> "regular" libtool-de
Reini Urban wrote:
> Peter Ekberg schrieb:
>> I have one problem with libtool 1.9d, that I suspect is still present
>> in 1.9f. If I specify -lpthread when linking, libtool searches for a
>> real file matching -lpthread, like this:
>>
>> *** Warning: linker
Reini Urban wrote:
> Peter Ekberg schrieb:
>> Reini Urban wrote:
>>> Peter Ekberg schrieb:
>>>
>>>> I have one problem with libtool 1.9d, that I suspect is still
>>>> present in 1.9f. If I specify -lpthread when linking, libtool
>>
Chuck wrote:
> New alpha versions of libtool available for test. This is
> very close to
> what libtool-2.0 will be. Please evaluate.
>
> NOTE: cygwin maintainers: do NOT release any updates of your packages
> built using this version of libtool! Be sure to revert back to
> "regular" libtool-de
Chuck wrote:
> New alpha versions of libtool available for test. This is
> very close to what libtool-2.0 will be. Please evaluate.
I have further problems in that linking against -ldxguid prevents
a library from being linked as a dll. I only get a static lib,
which is not what I want.
I realiz
Chuck wrote:
> Peter Ekberg wrote:
>> I have a problem with "make install" of a built executable.
> In your case, you have a wrapper script -- but an empty
> noninst_deplibs. One of two things is true:
>
> (1) your exe really truly does not depend on any uninstall
Chuck wrote:
> New alpha versions of libtool available for test. This is
> very close to what libtool-2.0 will be. Please evaluate.
"make install-strip" on a shared library strips the import
lib, not the dll which was what I was hoping for.
Not a show-stopper I suppose...
/bin/sh ../libtool -
Chuck wrote:
> Gerrit P. Haase wrote:
>>> "make install-strip" on a shared library strips the import
>>> lib, not the dll which was what I was hoping for.
>>> Not a show-stopper I suppose...
>>
>> Yes, this is a showstopper! Import libraries may be broken after
>> stripping.
>
> I'm going out of
Chuck wrote:
> It seems like a design decision was made, that IF in a given project
> there are ANY libtool libs, then libtool will "know" about it
> by having
> build_libtool_libs set to "yes". And thus, every executable is
> *assumed* to be linked against those libs, and will therefore have a
>
I wrote:
> Chuck wrote:
>> Gerrit P. Haase wrote:
"make install-strip" on a shared library strips the import
lib, not the dll which was what I was hoping for.
Not a show-stopper I suppose...
>>>
>>> Yes, this is a showstopper! Import libraries may be broken after
>>> stripping.
>>
Chuck wrote:
> New alpha versions of libtool available for test. This is
> very close to what libtool-2.0 will be. Please evaluate.
Ok, I found another problem. You cannot add the flag
-Werror-implicit-function-declaration to CFLAGS as that
kills the build of the wrapper executable. While there,
Hello!
I'm writing to inform that GGI works on Cygwin (and MinGW for
that matter). v2.1 release candidate 4 is available for
testing, see the announcement for details on how to get it:
http://marc.theaimsgroup.com/?l=ggi-develop&m=109958791202306&w=2
It has been working for a while, but this seem
56 matches
Mail list logo
