Re: posix thread scaling issue
Jeff wrote: > Thanks. I am doing the memory allocation in a single thread. > The compute uses all the threads I can get, and the compute isn't > scaling very well with cygwin. > It does work well on my 16 core 32 thread processor, so for most people > the posix threading is fine. > jeff For the multi-threaded program that I wrote, with up to 64 threads, I compile each file with: x86_64-w64-mingw32-c++ -O3 -c file.cpp and link with: x86_64-w64-mingw32-c++ -o program *.o -static-libgcc -static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread -Wl,-Bdynamic And I get could results. 100% CPU use; I even need to lower the priority of the program to keep a snapy Windows UI. You may try the same to see if it improves the performance of your program. Regards, - André Bleau -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: posix thread scaling issue
Jeff wrote: > I have a program that is embarrassing parallel. > On my older computer which has an epyc 7302 (16 cores, 32 threads) it > scales very well using cygwin, and fully utilized all threads. > On my new computer which has an epyc 7B13 (64 cores, 128 threads) it > does not scale very well. > According to the windows task manager, it only uses 74% of the cpu > resources. > The time it takes the program to run on windows is 166 seconds. > Using the same hardware on a recent version of linux, I can get 100% cpu > utilization and the program takes 100 seconds to run. > I suspect there may be something in cygwin that doesn't scale well with > lots of posix threads. > I know this is a bit of an unusual situation, but you can buy a 128 core > / 256 thread system now. > Enclosed is the output of cygcheck. > I updated my version of cygwin to be current as of today, Sep 2 2023. > thanks, > jeff Hi Jeff, Cygwin's memory allocation, and anything that uses it under the hood, such as some containers from the C++ standard library, don't scale well with many threads. I have observed even worse scalling than yours in my own massively multi-thread programs. My advice would be to either rewrite your program to centralize memory allocation in a specialized thread that serves the other processing threads, or, if you don't need Posix things, compile with the Mingw cross-compiler, which produces code that uses M$ implementation for memory allocation, which scales better. Regards, - André Bleau -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Latest versions of cygwin - Paths with spaces
Hi Giovani. Giovani Erthal wrote: > I'm using rsync to perform backups. But I have errors in paths with spaces. > > Source: C:\Users\giova\Downloads\Teste com espaço > Destination: C:\Users\giova\Downloads\Destino com espaço > > Command: > > rsync.exe -avz -s --no-perms --no-owner --no-group --chmod=ugo=rw > /cygdrive/C/Users/giova/Downloads/Teste" > > "com" "Espaço /cygdrive/C/Users/giova/Downloads/Destino" "com" "espaço Wrong space quoting. Try: rsync.exe -avz -s --no-perms --no-owner --no-group --chmod=ugo=rw "/cygdrive/C/Users/giova/Downloads/Teste com Espaço" "/cygdrive/C/Users/giova/Downloads/Destino com espaço" > > Result: > > sending incremental file list > rsync: link_stat "/cygdrive/C/Users/giova/Downloads/Teste" "com" "Espaço" > failed: No such file or directory (2) > > sent 18 bytes received 12 bytes 60.00 bytes/sec > total size is 0 speedup is 0.00 > rsync error: some files/attrs were not transferred (see previous errors) > (code 23) at main.c(1178) [sender=3.1.2] > > Initially I was using cwrsync 6.2.4 (it has the same problem). Using cwrsync > 5.5.0 everything works perfectly. > > Now I downloaded cygwin and installed rsync (latest version), but the problem > is the same. > > How to make this work without using an old version of cygwin? Regards, - André Bleau -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Problem with mail archives?
Achim Gratz via Cygwin writes: > André Bleau via Cygwin writes: > > I noticed that no message has been archived for cygwin-patches since > > August 3rd, and to cygwin-developers since July 2nd. > What exactly makes you think that there were any messages that need to > be archived since those dates? cygwin-patches has usually more than 1 message per day. 18 days without any message is very out of ordinary. > Regards, > Achim. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Problem with mail archives?
Hello, I noticed that no message has been archived for cygwin-patches at https://cygwin.com/pipermail/cygwin-patches/2021q3/date.html since August 3rd, and to cygwin-developers at https://cygwin.com/pipermail/cygwin-developers/2021-July/date.html since July 2nd. The main archive at https://cygwin.com/pipermail/cygwin/2021-August/date.html is up-to-date. - André Bleau -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: C++ program using
Mark Geisert wrote: >Hi André, > >André Bleau via Cygwin wrote: >> Hi all, >> >> I have a small C++ program using . Mainly, I have a series of long >> tasks for which I can use a chosen >>number of threads. I create a given number of instances of the std::thread >>class, each executing the same function but >>with different data. After launching the threads, my program waits for the >>results by calling thread.join() on each >>thread. Some threads finish sooner than others, depending on the data they >>process. >> >> I have 16 cores with hyperthreading, so 32 virtual cores. I tried a big run >> with 63 threads. >> >> If I compile as a Cygwin program with g++ 10.2.0, when the program runs with >> 63 threads the CPU load for the >>program never exceeds 6 or 7%. It remains constants when some of the threads >>finish, unless the number of threads >>remaining goes down to about 4. >> >> If I compile as a Mingw program with x86_64-w64-mingw32-c++ 10.2.0, when the >> program runs with 63 threads the >> CPU load for the program reaches 98% then gradually diminishes as threads >> finish their task. >> >> Needless to say, the total running time for the Mingw version is much >> shorter. >> >> So, is there a limit to the CPU load that a threaded Cygwin program can get? >> If yes, how can it be changed? > >Fascinating report; thanks! I doubt there's an intentional limit, but perhaps >there is some difference between the Cygwin and MinGW environments that >explains >the symptoms. No idea at this point though. > >Oh, does your program set process or thread affinity anywhere? > >Would you be able to post the source of your test program, or provide it to me >by >private email? I would run my cygmon profiler on it to look for clues. There >have been several other reports of multi-threaded programs taking far too long >to >complete, but the reports came in as possibly malloc-related issues so they may >differ from yours. But cygmon has found something troubling in those cases >that >I'm still investigating. >Regards, > >..mark Thanks for your interest in my problem, Mark. I have tried to build a simple test case with the same thread structure as my program. In that STC, the threaded function doesn't do any allocation and doesn't use anything from the standard library. With the STC, the Cygwin and Mingw versions behave similarly to each other as the number of threads increases. So, I guess that Cygwin's threaded program limit on CPU usage comes either from allocation or from something in std. I will try to add more things to the test program threaded function to discover the culprit. Regards, and sorry to have first responded to you personally instead of responding to the list. Outlook.com is somewhat awkward with mailing lists. - André Bleau -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
C++ program using
Hi all, I have a small C++ program using . Mainly, I have a series of long tasks for which I can use a chosen number of threads. I create a given number of instances of the std::thread class, each executing the same function but with different data. After launching the threads, my program waits for the results by calling thread.join() on each thread. Some threads finish sooner than others, depending on the data they process. I have 16 cores with hyperthreading, so 32 virtual cores. I tried a big run with 63 threads. If I compile as a Cygwin program with g++ 10.2.0, when the program runs with 63 threads the CPU load for the program never exceeds 6 or 7%. It remains constants when some of the threads finish, unless the number of threads remaining goes down to about 4. If I compile as a Mingw program with x86_64-w64-mingw32-c++ 10.2.0, when the program runs with 63 threads the CPU load for the program reaches 98% then gradually diminishes as threads finish their task. Needless to say, the total running time for the Mingw version is much shorter. So, is there a limit to the CPU load that a threaded Cygwin program can get? If yes, how can it be changed? Regards, - André Bleau -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.2.0-0.1 (TEST)
Takashi Yano wrote: >On Wed, 10 Mar 2021 03:38:52 +0000 >André Bleau wrote: >> Hi, >> >> Last year, I reported a problem about console output with pcon support. For >> the simple test program, see: >> https://cygwin.com/pipermail/cygwin/2020-May/244742.html >> >> I was told (https://cygwin.com/pipermail/cygwin/2020-May/244745.html) that I >> need to inset the following lines in my program: >> >> #include >> ... >> DWORD mode; >> GetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), &mode); >> mode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING; >> SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), mode); >> >> It worked. >> >> Now, I just downloaded cygwin 3.2.0-0.1 and retested my program with and >> without the above lines. Both work correctly. >> >> Are the above lines no longer necessary? In that case, it could be useful to >> say so in the release notes. > >This is due to behaviour change of pseudo console itself. >In Win10 20H2 (and perhaps also in 2004), >ENABLE_VIRTUAL_TERMINAL_PROCESSNG is set by default in pseudo >console. However, older Win10 such as 1809, this flag is not >set. Therefore, you need to set this flag explicitly. > >Also, in command prompt, this flag is not set even with Win10 >20H2. So, I recommend to keep this flag set for portability. Hi Takashi, I use Win10 2004 and I can confirm that my program needs those lines when run from cmd but not from mintty. So that behavior change was caused by a change in Win10, not in cygwin. As for cygwin 3.2.0-0.1, then I can only report for now that: make v4.3 works correctly, x86_64-w64-mingw32-c++ v10.2.0 works correctly, mintty v3.4.6 works correctly, bash v4.4.12(3) works correctly, my simple C++ console program works correctly. -André Bleau -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.2.0-0.1 (TEST)
Hi, Last year, I reported a problem about console output with pcon support. For the simple test program, see: https://cygwin.com/pipermail/cygwin/2020-May/244742.html I was told (https://cygwin.com/pipermail/cygwin/2020-May/244745.html) that I need to inset the following lines in my program: #include ... DWORD mode; GetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), &mode); mode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING; SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), mode); It worked. Now, I just downloaded cygwin 3.2.0-0.1 and retested my program with and without the above lines. Both work correctly. Are the above lines no longer necessary? In that case, it could be useful to say so in the release notes. Thanks to contributors for the good work. - André Bleau -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Failed assertion dialog box ATTN: Takashi Yano
De : Cygwin de la part de Thomas Wolff
Envoyé : 19 novembre 2020 13:30
À : cygwin@cygwin.com
Objet : Re: Failed assertion dialog box ATTN: Takashi Yano
---
Am 19.11.2020 um 15:21 schrieb André Bleau via Cygwin:
> ...
> Here's some more info:
>
> It seems the bug is related to pseudo-console support; that explains why it
> is Windows 10 specific.
>
> Experiment:
>
> CYGWIN=disable_pcon /usr/bin/mintty &
>
> In the newly created window:
>
> $ ./a.exe output.txt 2>&1
> Aborted (core dumped)
>
> No message box popup.
>
> $ cat output.txt
> assertion "false" failed: file "assert.cpp", line 3, function: int main()
>
> In the original mintty window, with empty CYGWIN env variable:
>
> $ ./a.exe output.txt 2>&1
> Aborted (core dumped)
>
> A message box pops
>
> AND:
>
> $ cat output.txt
>
> output.txt is empty
>
> So, 2 problems here.
>
> In a CMD Window:
>
> set path=%PATH%D:\Cygwin\bin;
> a.exe outcmd.txt 2>&1
> 1 [main] a 759 cygwin_exception::open_stackdumpfile: Dumping stack
>trace to a.exe.stackdump
>
> type outcmd.txt
> assertion "false" failed: file "assert.cpp", line 3, function: int main()
> 1 [main] a 759 cygwin_exception::open_stackdumpfile: Dumping stack
>trace to a.exe.stackdump
>
> The bug could be in cygwin or in mintty. Maybe this is something that Thomas
> Wolff (mintty author) or Takashi Yano (pseudo-console support expert) would
> want to look at.
> ---
>
> OK, I opened an issue for mintty and it was quickly closed with that quote:
>
> "Quick generic answer: if it's caused by ConPTY support, it's not related to
> mintty; also mintty never shows any popups.
> Funny thing, though, but really: assert isn't handled by the terminal."
>
> So the issue can only be with pseudo-console support in cygwin.
It does not seem to happen in xterm which is weird.
It does however also happen in rxvt-unicode, xfce4-terminal, and vte.
The message text of the popup can be easily found in cygwin code.
Thomas
---
One more data point:
The following program:
$ cat stderr.c
#include
int main() {
fprintf(stdout, "To stdout\n");
fprintf(stderr, "To stderr\n");
return 0;
}
$ gcc stderr.c
$ ./a.exe output.txt 2>&1
Behaves normally, with either empty CYGWIN env variable or with
$ CYGWIN=disable_pcon /usr/bin/mintty &
So the problem is narrowly confined to how Cygwin handles assert when
pseudo-console is used and stdin, stdout, and stderr are redirected. Not in all
cases where pseudo-console is used and stdin, stdout, and stderr are
redirected.
- André Bleau
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Failed assertion dialog box ATTN: Takashi Yano
--- De : Cygwin de la part de André Bleau via Cygwin Envoyé : 15 novembre 2020 15:39 À : The Cygwin Mailing List Objet : Re: Failed assertion dialog box --- De : Cygwin de la part de André Bleau via Cygwin Envoyé : 15 novembre 2020 15:04 À : The Cygwin Mailing List Objet : Re: Failed assertion dialog box --- De : Cygwin de la part de William M. (Mike) Miller via Cygwin Envoyé : 15 novembre 2020 08:12 À : The Cygwin Mailing List Objet : Re: Failed assertion dialog box On Sat, Nov 14, 2020 at 11:49 PM Duncan Roe wrote: ... > > Sorry, should have mentioned running on Win7 Home. > > When I try it on my wife's Win10 system, I get the dialog box same as you. > That's disappointing. Thanks for the additional information, though. --- I would say we got some useful info: 1- The bug is OS specific; it occurs in Windows 10 2- Three persons were able to reproduce it on Windows 10, which improves the probability of getting fixed. - André Bleau --- Here's some more info: It seems the bug is related to pseudo-console support; that explains why it is Windows 10 specific. Experiment: CYGWIN=disable_pcon /usr/bin/mintty & In the newly created window: $ ./a.exe output.txt 2>&1 Aborted (core dumped) No message box popup. $ cat output.txt assertion "false" failed: file "assert.cpp", line 3, function: int main() In the original mintty window, with empty CYGWIN env variable: $ ./a.exe output.txt 2>&1 Aborted (core dumped) A message box pops AND: $ cat output.txt output.txt is empty So, 2 problems here. In a CMD Window: set path=%PATH%D:\Cygwin\bin; a.exe outcmd.txt 2>&1 1 [main] a 759 cygwin_exception::open_stackdumpfile: Dumping stack trace to a.exe.stackdump type outcmd.txt assertion "false" failed: file "assert.cpp", line 3, function: int main() 1 [main] a 759 cygwin_exception::open_stackdumpfile: Dumping stack trace to a.exe.stackdump The bug could be in cygwin or in mintty. Maybe this is something that Thomas Wolff (mintty author) or Takashi Yano (pseudo-console support expert) would want to look at. --- OK, I opened an issue for mintty and it was quickly closed with that quote: "Quick generic answer: if it's caused by ConPTY support, it's not related to mintty; also mintty never shows any popups. Funny thing, though, but really: assert isn't handled by the terminal." So the issue can only be with pseudo-console support in cygwin. - André Bleau - André Bleau -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Failed assertion dialog box
--- De : Cygwin de la part de André Bleau via Cygwin Envoyé : 15 novembre 2020 15:04 À : The Cygwin Mailing List Objet : Re: Failed assertion dialog box --- De : Cygwin de la part de William M. (Mike) Miller via Cygwin Envoyé : 15 novembre 2020 08:12 À : The Cygwin Mailing List Objet : Re: Failed assertion dialog box On Sat, Nov 14, 2020 at 11:49 PM Duncan Roe wrote: ... > > Sorry, should have mentioned running on Win7 Home. > > When I try it on my wife's Win10 system, I get the dialog box same as you. > That's disappointing. Thanks for the additional information, though. --- I would say we got some useful info: 1- The bug is OS specific; it occurs in Windows 10 2- Three persons were able to reproduce it on Windows 10, which improves the probability of getting fixed. - André Bleau --- Here's some more info: It seems the bug is related to pseudo-console support; that explains why it is Windows 10 specific. Experiment: CYGWIN=disable_pcon /usr/bin/mintty & In the newly created window: $ ./a.exe output.txt 2>&1 Aborted (core dumped) No message box popup. $ cat output.txt assertion "false" failed: file "assert.cpp", line 3, function: int main() In the original mintty window, with empty CYGWIN env variable: $ ./a.exe output.txt 2>&1 Aborted (core dumped) A message box pops AND: $ cat output.txt output.txt is empty So, 2 problems here. In a CMD Window: set path=%PATH%D:\Cygwin\bin; a.exe outcmd.txt 2>&1 1 [main] a 759 cygwin_exception::open_stackdumpfile: Dumping stack trace to a.exe.stackdump type outcmd.txt assertion "false" failed: file "assert.cpp", line 3, function: int main() 1 [main] a 759 cygwin_exception::open_stackdumpfile: Dumping stack trace to a.exe.stackdump The bug could be in cygwin or in mintty. Maybe this is something that Thomas Wolff (mintty author) or Takashi Yano (pseudo-console support expert) would want to look at. - André Bleau -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Failed assertion dialog box
--- De : Cygwin de la part de William M. (Mike) Miller via Cygwin Envoyé : 15 novembre 2020 08:12 À : The Cygwin Mailing List Objet : Re: Failed assertion dialog box On Sat, Nov 14, 2020 at 11:49 PM Duncan Roe wrote: ... > > Sorry, should have mentioned running on Win7 Home. > > When I try it on my wife's Win10 system, I get the dialog box same as you. > That's disappointing. Thanks for the additional information, though. --- I would say we got some useful info: 1- The bug is OS specific; it occurs in Windows 10 2- Three persons were able to reproduce it on Windows 10, which improves the probability of getting fixed. - André Bleau -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Failed assertion dialog box
On Fri, Nov 13, 2020 at 10:45 PM Duncan Roe
wrote:
> Hi William,
>
> On Fri, Nov 13, 2020 at 12:27:57PM -0500, cygwin wrote:
> > I've run into a problem running a collection of tests under Cygwin and I
> > wonder if anyone can suggest a way around it.
> >
> > The problem occurs when a program being run fails a C/C++ runtime
> > assertion. Ordinarily, this just writes an error message on stderr and
> > aborts. Under Cygwin, however, if both stdin and stderr are redirected to
> > files, the program instead pops up a dialog box that must be
> interactively
> > dismissed before the failed program will exit - holding up all the tests
> > that follow it.
> >
> > Specifically, if I have the following as assert.cpp:
> >
> > #include
> > int main() {
> > assert(false);
> > }
> >
> > and say
> >
> > gcc assert.cpp
> > ./a.exe < /dev/null > output 2>&1
> >
> > I get an error dialog box saying
> >
> > Failed assertion
> > false
> > at line 3 of file assert.cpp
> > in function int main()
> >
> > If I omit either the stdin or the stderr redirection, the program behaves
> > as desired with no dialog box.
> >
> > Is there an environment setting or compiler command-line option I can
> give
> > to suppress the dialog box and always just write a message to stderr and
> > abort? Thanks for any insights.
>
> Your example WFFM, (Cygwin64, gcc 10.2.0, everything else also up to date).
>
> Do you still see this behaviour if you run the installer?
>
Thanks for your reply; unfortunately, yes, it does. I had refreshed
the installation fairly recently, and running the installer only updated a
few things, not cygwin.dll and not gcc; my installation is the same as
yours. I've tried it with three different shells (tcsh, bash, mksh) and
with both gcc and clang, and all have the same behavior. (Interestingly, if
I compile the example with MSVC and run it in a Cygwin shell, it does _not_
pop up an error dialog box, so presumably it's in the Cygwin runtime,
specifically the definition of __assert_func.)
--
William M. (Mike) Miller | Edison Design Group
I see the same behavior as William:
./a.exe < /dev/null > output.txt 2>&1
pops a message box.
gcc (GCC) 10.2.0
CYGWIN_NT-10.0 XXX 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
mintty 3.4.1 (x86_64-pc-cygwin)
- André Bleau
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: incorrect text mode graphic character display
Brian wrote: __ success! That did it. What i find particularly strange is that it fixes the problem in mintty as well as the terminals i'm running in x-windows, for example the xfce4-terminal. I had no idea such a thing as the cygwin.dll existed, i would have never have thought to try that. Thanks very much for your help. Now. If anyone is interested in figuring out what the problem is so that it can be fixed in the next version. Please let me know. I will be happy to help if i can. Brian __ It should be no surprise as both mintty and xfce4-terminal are both linked to cygwin.dll . One main difference between cygwin version 3.0.x and 3.1.x is that pseudo-console (pcon) support has been added to cygwin. Pseudo-console is a new feature of the latest versions of Windows 10. - André -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: incorrect text mode graphic character display
Brian wrote: > Assuming Julia is a not Cygwin program, > you can try "CYGWIN=disable_pcon" before any Cygwin process Did not help. Thanks for that though, I had no idea those kind of env variables were available. Brian Hi Brian, Character display problems do not depend only on the program you run, in your case, "Julia", whatever that is, but also in which terminal or console you run it, as it is the terminal that does the actual character display. If you run in in mintty for example, you could try: CYGWIN=disable_pcon /usr/bin/mintty and run Julia in the just opened mintty. I just happened to have a similar issue. If interested, look at: https://cygwin.com/pipermail/cygwin/2020-May/244742.html Regards, - André Bleau -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Problems with a combination of a mingw program, mintty, and CYGWIN=disable_pcon
Takashi Yano wrote: Hi André, Thanks for the report. On Thu, 7 May 2020 03:38:25 + André Bleau via Cygwin wrote: > Hi cygwin users, > > I have cli program that I run with mintty. It is a simple C++ program, > reading from cin and outputing to cout. It is cross-compiled as a mingw > program. I've been running it without problems fro over 2 years. Recently, I > updated cygwin to 3.1.4-1 and noticed the pcon support. Since then, the > output of my program has been messy: output lines have intermittent gaps in > them. I made a simple test case that reproduces the problem, from the > following simple C++ file, hello.cpp : > > #include > using namespace std; > static string Green = "\033[32m"; > static string Yellow = "\033[33m"; > static string Reset = "\033[0m"; To use escape sequences in pseudo console, please add the following code just like in normal cosole (command prompt). #include ... DWORD mode; GetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), &mode); mode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING; SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), mode); This should solve your problem. -- Takashi Yano Hi Takashi. Thanks for the quick response. Adding these lines of codes to my program and to the simple test case mentioned solved the problem of gaps in lines when run from mintty with pcon enabled. However, it does not solve the problem of mintty misbehavior when started from a bash script to run the same program. Maybe this is a problem that Thomas Wolf would be interested in. Regards, - André Bleau -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Problems with a combination of a mingw program, mintty, and CYGWIN=disable_pcon
in green characters. 28 A simple line of printing in green characters. 29 A simple line of printing in green characters. q to Quit, p to Print q If I start mintty with CYGWIN=disable_pcon and run the hello program in it, everything is fine and the program always outputs correctly, as it did before I updated cygwin. CYGWIN=disable_pcon /usr/bin/mintty & OK, no big deal then, I'll make a small bash script to automate this: hellobash #/bin/bash CYGWIN=disable_pcon /usr/bin/mintty absolutePath/hello.exe & This is where it gets weird. Running ./hellobash sometimes gets the hello program run correctly. It accepts input and displays output as expected. But in about 1 in 5 runs, it will not accept input. A prompt is displayed, but no cursor is shown and typing produces nothing. ^C does not stop the program. Weirder: in about 1 in 20 to 30 runs, it's the converse: it will be stuck in a loop as if input was continuously feed to it, even if you don't type anything. Output of cygcheck -c is attached. Regards, - André Bleau cygcheck.out Description: cygcheck.out -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Obsoleted: openGL package
The openGL package has now been marked as obsolete. Please note that it is still possible build programs using Windows' native openGL interface by using the w32api package. Users of the native GLUT library should adapt their programs to build with the freeGLUT packages. The native GLUT library was based on Nate Robins' GLUT, which has not been maintained in years, while freeGLUT is alive and kicking. freeGLUT requires the use of an X server. Thanks to anyone who helped supporting the openGL package over the years. - André Bleau, cygwin's (former) volunteer opengl package maintainer Please reply to cygwin at cygwin dot com, not to me directly. -- To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and keep clicking "Next". If you have questions or comments, please send them to the Cygwin mailing list. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
Someone is pretending to be some Cygwin's support
Hi, A few minutes after sending my last post to the cygwin at cygwin dot com list, I received this, seemingly from cygwin at cygwin dot com, but really from some joe1assitly at gmail dot com. --- __ Type your response ABOVE THIS LINE to reply Re: Time to obsolete the opengl package ? 1QA4xxx2a | MAY 14, 2012 | 12:57PM UTC Thank you for submitting your request. We have received your request and are working on responding to you as soon as possible. If you have any additional information to add to this case, please reply to this email. Thanks in advance for your patience and support. This message was sent to myname at myaddress in reference to Case #81939. --- I guess that someone has setup a program to monitor our list and send automated replies. A little googling shows that it also appended recently on debian's lists. The funniest thing is the request to top-post. The less funny thing is that might be a fishing attempt. Please advise, - André Bleau, cygwin's volunteer opengl package maintainer Please reply to the list, not to me directly. -- 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
Re: Glut Problem
Klaus Ramstöck wrote:
> Dear list,
Hi Klaus,
>
> I tried to compile f90gl under a current cygwin. With some grey hair, I
> succeded, but my programs dont start.
"Dont start". What does that mean? Your programs crash? You get an error
message? Please be more
explicit.
> I analysed the problem an can
> reproduce it with this modified example glut program.
> >From /usr/share/doc/opengl-1.1.0/GLUTexamples/helloGlut.c:
> cut
> #include
> #include
> #include
What is glutf90.h ? It is not part of the OpenGL package.
>
> ...
>
> #define GLUTCALLBACKFCB
> typedef void (GLUTCALLBACKFCB *GLUTbuttonBoxFCBUSR) (int *, int *);
> int main(int argc, char* argv[])
> {
> atexit(exit_func);
> glutInit(&argc, argv);
> glutCreateWindow("Hello GLUT!");
> glutDisplayFunc(display_func);
> glutKeyboardFunc(keyboard_func);
> printf("Press any key to toggle color.\n");
> printf("Press Esc to end.\n");
> glutMainLoop();
glutMainLoop loops forever (up to program exit). Code after it will never get
executed.
> int button, state;
> ((GLUTbuttonBoxFCBUSR)__glutGetFCB(GLUT_FCB_BUTTON_BOX))(&button, &state);
These 2 lines are total nonsense. FCB stands for Fortran CallBack.
- Fortran is unsupported by the OpenGL package. I am not interrested in adding
that support,
but I would accept patches that do.
- Even if it was supported, you cannot blindly insert a call to a Fortran
function into a C function.
- glutGetFCB is called to know the function associated with some callback, in
the case above,
the callback for the button box. You try to call the callback function
directly, but you have not
set such a callback function previously (in C, with glutButtonBoxFunc, in
Fortran, presumably with
glutSetFCB).
- I don't think that button boxes are supported on Windows. They were some
Silicon Graphics things.
- Calling things begining by __glut makes no sense. The functions names in the
Glut library begin
by glut. The linker is responsible for finding the internal name of the
corresponding function.
> return 0;
> }
> cut
> The only relevant difference is this line:
> ((GLUTbuttonBoxFCBUSR)__glutGetFCB(GLUT_FCB_BUTTON_BOX))(&button, &state)
>
> Without this line, the program compiles and works as expected.
> It seems there is a mismatch between the definition of __glutGetFCB
> in the .a and in the .dll file.
I think your problem is deeper than that. You need to explain what you are
trying to do. If you
are trying to port some Fortran program that was meant to run on Silicon
Graphics to Windows
you will have a hard time.
>
> Can anybody confirm this and help me fix it?
>
> Thank you.
>
> Klaus
André Bleau, Cygwin's OpenGL package maintainer.
Please send any question or comment about the OpenGL package to cygwin at
cygwin dot com,
not directly to me.
--
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
Re: Segmentation Fault in OpenGL - glutMainLoop
Nathan Rose wrote: > Hi AndrÃ, Hi Nathan, > > Thanks for your response. The native GLUT programs compiled and ran > fine. I've uninstalled the opengl > package but I'm still getting the segmentation fault. > > Running the program in the Cygwin Bash Shell (ie, not Cygwin/X) gives > the error message >freeglut (./test): failed to open display '' > - would it be right to assume that that means it is looking for the X > server? Yes, freeglut on Cygwin is build to interact with an X server. You need to install it and start it before running your application. X-related issues are discussed in their own mailing list: cygwin-xfree at cygwin dot com . > > Thanks, > > Nathan > André Bleau, Cygwin's OpenGL package maintainer Please send any questiopn or comment about the OpenGL package to cygwin at cygwin dot com, not directly to me. -- 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
Re: Segmentation Fault in OpenGL - glutMainLoop
Nathan Rose wrote: > Hi all, Hi Nathan, > > I suspect this problem may be beyond the scope of this mailing list, but I > would really appreciate any > help that you could provide. > > I have someone else's code that uses OpenGL (it's a massive set of files, so > I'm not going to attach them > here). It compiles fine on Cygwin, but when > the glutMainLoop method is called I get a segmentation fault. > I have tested > it on Ubuntu and this does not occur there, so my assumption is that there is > something > wrong with how I have set up Cygwin. The following packages have been > installed: > libglut-devel > freeglut > libglut3 > opengl > glproto > libGL-devel > libGL1 > libGLU-devel > libGLU1 > libglitz > libxcb-dlx-devel > libxcb-glx0 > (basically, I've installed everything from the Select Packages page that has > 'gl' in its name) > > I have attached the stackdump from the segfault and the output from cygcheck, > in case they can help > identify the cause of this issue. I'm not expecting that anyone will be able > to magically solve this with > what little information I have provided, but any hints as to which direction > I should proceed would be > appreciated. First thing: there are 2 ways to use OpenGL and GLUT under Cygwin: through an X server and natively. As you ran it under Unbutu, I suspect you use the X server, but please confirm it. I cannot deduce anything from your stackdump. Some applications have configure script to build with an X server on Linux and natively on Windows. If your application goes for the native route, my package (the opengl package) is concerned and I will try to help you further. In that case, you may uninstall the other packages mentionned above to clear any possible (but improbable) confusion. Try some simple program first: see if one of the native GLUT example programs run properly: /usr/lib/glut-examples/helloGlut.exe , then /usr/lib/glui-examples/example6.exe . If they work, try rebuilding them by going to /usr/share/doc/opengl-1.1.0/GLUTexamples and /usr/share/doc/opengl-1.1.0/GLUIexamples and typing "make". If your application goes for the X server route, I will let the maintainers of the related packages take you from here. You may uninstall the opengl package to clear any possible (again improbable) confusion. X related issues should be discussed on a separate list: cygwin-xfree at cygwin dot com . > > Thanks, > > Nathan > HTH, André Bleau, Cygwin's OpenGL package maintainer Please send any questiopn or comment about the OpenGL package to cygwin at cygwin dot com, not directly to me. -- 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
Re: OpenGL under Cygwin with GtkGlExt
Stedy wrote: > Hi AndrÃ, > > Yes, Im using X11.. > In the meanwhile I've installed every GL package I found at Cygwin setup > incl. libGL-devel and libGL1 but I still get the error :-/ > do I have to manual install this libs? > I just run cygwin setup process If you have installed the packages, you have installed the libs. This seems to be a configure script problem. You will have to discuss this with the GtkGlExt author(s). André Bleau, Cygwin's volunteer OpenGL package maintainer. Please send any question or comment about the opengl package to cygwin at cygwin dot com, not to directly to me. -- 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
Re: OpenGL under Cygwin with GtkGlExt
Stedy wrote: > Hi, Hi Stedy, > > I'm using Cygwin under Windows Vista and have installed the OpenGL Libs at > Cygwin setup. > > Now im trying to configure GtkGlExt (with ./configure). But I get a message > "GL not installed".. Are you configuring to use OpenGL in an X11 window? If yes, you need the libGL* packages, not the opengl package, which is meant for native Win32 graphics. > > Can you help me? > > Regards André Bleau, Cygwin's volunteer OpenGL package maintainer. Please send any question or comment about the opengl package to cygwin at cygwin dot com, not to directly to me. -- 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
Re: can't compile opengl using w32api with gcc
chm wrote: > Hi- Hi Chris, > > I've been trying to compile the Perl OpenGL > module for cygwin using the w32api opengl32, > glu32,.. for performance. I used to be able > to add either -I/usr/X11R6/include or > -I/usr/include/w32api to the gcc flags to > get the compile to work. > > Going back with cygwin 1.7.1 now, I am unable to > get the w32api compile to work. After some > debugging, the problem is that /usr/include/w32api > is in the gcc system headers list. As a result, > duplicate -Idir flags are discarded and since both > /usr/include and /usr/include/w32api are in the > system search path (in that order), the compile > *always* picks up the gl.h in /usr/include/GL > which is the Mesa one. > > I was able to get the compile to work by using > the -isystem flag instead of -I as the gcc > option but now I have a compiler-specific flag > that I have to track. Are there any other > options here? > > Thanks much, > Chris > > P.S. It turns out the previous use of flags > had the same problem but since the X11/Mesa > GL include files were in /usr/X11R6/include > and not /usr/include, the duplicate use of > -I/usr/include/w32api was ignored but that > was the one being pulled in by the default > search. Then when I put -I/usr/X11R6/include > on the compile, it did get added to the > header search path since it was not in the > gcc system paths by default. Your problem is the consequence of the libGL-devel package (Mesa GL) taking over /usr/include/GL in 2008. If you want native GL, you need to install the opengl package, and compile with -I/usr/include/opengl , as stated in /usr/share/doc/opengl-1.1.0/README.txt . André Bleau, Cygwin's volunteer OpenGL package maintainer. Please send any question or comment about the opengl package to cygwin at cygwin dot com, not to directly to me. -- 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
Re: OpenGL / GLUT / FreeGlut and the mouse wheel in PyMol.
"Jan Gebauer" wrote: > > Hi, Hi Jan, > > I'm new to this mailing list and hope my question is not a total obvious > one, but at the end of the day I'm more a scientist than a programmer. So > I hope I got the facts right. > > I'm trying to build PyMol, an open-core molecular visualisation program > with cygwin (www.pymol.org). > This software uses OpenGL for displaying three-dimensional structures of > proteins on the screen and allows manipulating these structure in various > ways in 3D. It also allows true three-dimensional display with the > (Nvidia) shutter glasses. > > It took my a while to get all the dependencies right, but I was finally > able to build it successfully and it works in nearly all aspects. > > However, the program does not recognise any input in the "graphic/display > window" from the mouse wheel, although the TKinter/Tcl based menu window > does accept scroll events. > Together with a colleague, we figured out that the win32 port of GLUT > might be the problem, as it seems not to handle mouse wheel events > (source:http://www.realmtech.net/opengl/glut.php) The win32 port of GLUT predates the mouse wheel and has stalled. No hope of an update upstream. > My colleague was able to build PyMol with the X11 headers and Libs and > then the mouse wheel worked, but the speed was (as expected) not > acceptable. > What are you thinking, is the win32 version of GLUT really the problem? > > I did found FreeGlut and as it should be a "modern clone" of GLUTÂ, I > tried to compile it for Cygwin. I got an cygglut-0.dll and some header > files, but they never compiled well with PyMol (which uses a rather > complicated python script). > > My colleague found this message from Andrà Bleau > http://www.cygwin.com/ml/cygwin/2009-04/msg00264.html, where Mr. Bleau > stated he hopes to publish GLUT32 replacement based on FreeGlut around > 2010. I tried porting the Win32 version of FreeGLUT to Cygwin, but ran into problems, mainly with the menus. Replacing GLUT by FreeGlut in my package would not be a wise thing to do at this point. > > I just wonder if this new package will be available any-time soon or if > anyone else has a good idea how to proceed with this problem? I am working, very slowly, on improving FreeGLUT. Don't expect anything from me before 2011. The X11 version of FreeGlut might benefit from hardware accelerated OpenGL at some point, but that is something that I will let the X11 maintainers talk about. You can find some previous discussion at http://cygwin.com/ml/cygwin-xfree . For the immediate time, your only option seems to stick with Win32 GLUT and do without mousewheel support. > > With kind regards, > Jan Gebauer > > PS: Thanks to all the cygwin contributors, it's the first time I used it > and it works rather great! > -- > Dr. Jan Gebauer > Phone: +44 20 7594 7915 | Fax: +44 20 7589 0191 > > Research group: Dr. E. Hohenester > Division of Cell & Molecular Biology > Imperial College London > Biophysics Section, Blackett Laboratory > London SW7 2AZ > Regards, André Bleau, Cygwin's OpenGL package maintainer. Please send any comment or question about the OpenGL package to cygwin at cygwin dot com, not to me. -- 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
Re: OpenGL linking problems
David Doria wrote: > Hi André, Hi David, > > I think I'm trying to build an X11 application - I'm trying to use a > library called VTK (http://www.vtk.org/). I don't believe it uses > glut, and I do see a bunch of X11 options in the CMake files. Even if > there is no support for hardware acceleration with this method, it > should still build, right? For X11, you need at least the following packages:libGL1, libGL-devel; and possibly libGLU1 and libGLU-devel. Ask questions at cygwin-xfree at cygwin dot com if you need help with these. You should link with /usr/lib/libGL.dll.a by using -lGL > > I do have C:\Windows\System32\opengl32.dll . Expected; it comes with every version of Windows since Widows 98! > I should also have the > w32api package because I installed all of the cygwin packages. That's no use for an X11 app. > > Any other thoughts of things that would causes these linking errors? > > Thanks for your help so far, > > David - André Bleau, Cygwin's opengl package maintainer. Please send any question or comment about the opengl package to cygwin at cygwin dot com, not directly to me. -- 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
Re: OpenGL linking problems
David Doria wrote: > I'm trying to build a library (VTK) in Cygwin. I am getting a lot of > errors like this > > undefined reference to `_glDepthMask' > undefined reference to?`_glGetIntegerv' > undefined reference to?`_glMatrixMode' > > I installed ALL of the cygwin packages to try to avoid problems like > this. I also added > > export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/lib > > to my ~/.bash_profile > > Anyone know how to get something to link against OpenGL in cygwin? Well, we need more info to help us help you. What kind of application are you trying to build? X11 or native? There are 2 ways to build OpenGL-related programs: 1- Using native OpenGL, with driver supported hardware acceleration. For that, you need some way to get a graphic device context. One portable way to do that is to use the GLUT library, provided by the opengl package that I maintain. Look at the doc in /usr/share/doc/opengl-1.1.0 to learn how to do that. The OpenGL implementation in that case is provided by Window's opengl32.dll. Cygwin's w32api package provides the headers and link library for that version of OpenGL. LD_LIBRARY_PATH has no effect if you go that way. 2- Using X11, which provides an opengl implementation. At one point, there was support for hardware acceleration; then, it went away; I don't know if it came back or if it is coming back "soon". I will let the maintainer of the libGL* packages answer questions you may have about it. You would better send them to cygwin-xfree at cygwin dot com . > > Thanks, > > David > - André Bleau, Cygwin's opengl package maintainer. Please send any question or comment about the opengl package to cygwin at cygwin dot com, not directly to me. -- 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
Re: Static linking issue under cygwin.
jean-luc malet wrote: > I never managed to build something that link against those libs. if > you strip the "32" at the end of each libs it shall work > ie use : > lglut -lglu -lGL > however I don't know but every package that use autotools try to link > with theses what is the difference between -lopengl32 and -lGL? > thanks > JLM Extract from /usr/share/doc/opengl-1.1.0/FAQ.txt : What is the difference betwwn the opengl package and the libGL-devel, libGLU-devel, libglut-devel packages ? -- The opengl package uses the Win32 API to render directly to Windows. It uses driver and hardware acceleration to get fast rendering. The other packages render through an X server, that needs to be installed and run. - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com Many other persons will be able to help you if you do. _ Découvrez toute l'actualité de vos amis au même endroit. http://go.microsoft.com/?linkid=9660831 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Static linking issue under cygwin.
"Vladimir A. Petrov" wrote: > Hello! Hello Vladimir, > ... > > The similar problem is also reproducible at the another PC with > different Cygwin installation and with different set of libraries > (opengl-1.1.0-10 and freeglut-2.4.0-1) that in this case are part of > the Cygwin distribution and were installed via standard Cygwin setup > program. For details see attached fly-cubes-cygcheck.out and > fly-cubes-link-failure.out. See my comments about fly-cubes-link-failure.out bellow > ... fly-cubes-link-failure.out contains: > $ gcc -o fly-cubes.exe -lopengl32 -lglut32 -lglu32 fly-cubes.c The correct order for searching the libraries is: -lglut32 -lglu32 -lopengl32 fly-cubes.c must be _before_ the libraries. Chuck's response was correct about this last point, but wrong about the librairies order. This -lglut32 does _not_ link to freeglut btw. It links to glut32.dll from the openGL package. Please read: /usr/share/doc/opengl-1.1.0/README.txt and /usr/share/doc/opengl-1.1.0/FAQ.txt - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com Many other persons will be able to help you if you do. _ Créez un personnage à votre image pour votre WL Messenger http://go.microsoft.com/?linkid=9656622 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Those "job opening VISION SPECIALIST" messages
Hi folks, Sorry about those "job opening VISION SPECIALIST" messages that shouldn't have been sent to the list. I realized too late that some private mail I sent previously was bearing a Reply-to:cygwin at cygwin dot com field. I have changed my settings and notified my correspondants, and will make sure it does not happen again. I apologize for the noise. - André Bleau _ Internet Explorer 8 permet de naviguer plus vite. http://go.microsoft.com/?linkid=9655574 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [Attention: opengl^H^H^H^H^H w32api,libGLdevel maintainer] Incorrect GL_DOT3_RGB_EXT in glext.h
Bryan Thrall wrote: Hi Brian, >The opengl 1.1.0-10 package has incorrect values for GL_DOT3_RGB_EXT and > GL_DOT3_RGBA_EXT: > > #define GL_DOT3_RGB_EXT 0x86AE > #define GL_DOT3_RGBA_EXT 0x86AF > > According to > http://www.opengl.org/registry/specs/EXT/texture_env_dot3.txt, they > should be: > > GL_DOT3_RGB_EXT0x8740 > GL_DOT3_RGBA_EXT 0x8741> > > I thought I'd report this here, since it doesn't seem like the canonical > source (according to /usr/share/doc/Cygwin/opengl-1.1.0-10.README, > http://www.xmission.com/~nate/glut.html) of the package hasn't been > updated since 2001; so I guess Andre would be the person to handle this? Well, no, I'm not going to handle this, because glext.h is _not_ part of my OpenGL package. As a "Setup Package Search" reveals: usr/include/GL/glext.h is part of libGL-devel-7.2-2 usr/include/w32api/GL/glext.h is part of w32api/w32api-3.13-1, w32api/w32api-3.12-1, w32api/w32api-3.11-1 So, it will be up to the maintainers of w32api and/or libGL-devel. I understand your confusion. For the record, here's a few facts about OpenGL and Cygwin: 1- There is no (and there never was any) Win32 implementation of OpenGL for Cygwin. M$'s implementation, supplemented by the graphic drivers for hardware accceleration, is used. 2- The Cygwin packages provide only headers and import libraries to this implementation. First, they were provided by the OpenGL package. Then, the w32api package started to provide them too, so I droped them from the OpenGL package. 3- Cygwin's X server provides a software only (no hardware acceleration) implementation of OpenGL. 4- The headers and import libraries to this implementation are provided by the libGL-devel package. 5- The OpenGL package now only provides OpenGL-related librairies: GLUT and GLUI (native Win32 implementation). 6- The OpenGL package has reached the end of its life. As you stated, GLUT is unmaintained since 2001, and GLUI is fading away too. 7- Before 2010 (I hope!), the OpenGL package will be obsoleted and replaced by 3 new packages: FreeGLUT-native: A Cygwin 1.7, gcc 4 replacement for GLUT32.dll. FreeGLUT-native-devel: Corresponding headers and import libraries. GLUI-native: A Cygwin 1.7, gcc 4 replacement for the static libGLUI.a 8- For this to happen, I need: 8a- A stable gcc 4 8b- A Cygwin 1.7, gcc 4, w32api package 8c- Continue working with the FreeGLUT maintainers to get FreeGLUT native build for Cygwin. I hope that the above will clarify things for you (and others). - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com Many other persons will be able to help you if you do. _ Clavardez avec tout le groupe et rassemblez-les. http://go.microsoft.com/?linkid=9650742 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: response to opengl email exchange with Reini Urban
sxmboer AT purdue DOT edu wote: > > Dear André Bleau, > First thing: don't write directly to me. All my messages regarding opengl/glut/freeglut end with this line: "Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com" Please respect that policy. > > In your emails between Reini back in Feb you ask him if your tips > resolved the problems. I too had huge problems this week and I can tell > you that this tip: > > As stated in the opengl-1.1.0-9 and -10 anouncements and in > /usr/share/doc/opengl-1.1.0/README.txt , you must now add > -I/usr/include/opengl at compile time to avoid conflicts with freeglut. > > finally did indeed solve all my problems. the problem is, when people > update cygwin, the mechanism more or less picks up a whole bunch of > updates without the user knowing exactly which packages are updated. Let > alone that one typically will look for all the README.txt files that are > newly installed. That was clealy stated in the announcement for the package: http://cygwin.com/ml/cygwin-announce/2008-12/msg5.html And was discussed previously: http://cygwin.com/ml/cygwin/2008-11/msg00056.html > > I spent 3 days figuring out what was wrong with my computer after I > updated cygwin to include gcc-4. Apparently, along the way it updated > the w32api, so now the glut32.a was missing and a project that I have > been working on for years suddenly stopped working. > After finally figuring out the problem wasn't gcc-4, I stumbled on some > of your emails back in 2008 in which you proposed how you were going to > change the glut32 library. I wish I had seen that email then... Was > there really no way to resolve the freeglut issue without moving the > glut library? > There is *tons* of glut source code out there that doesn't > require the special -I option. This cygwin patch breaks all > compatibility. That's not a good thing in my opinion. If you read the announcement and the previous discussion, you should know, that no, there was no way to avoid the change *** if you also installed the following packages: libGL-devel, libGLU-devel, libglut-devel *** if you didn't, there was no conflict, and you could continue to compile as usual. To quote the announcement: What has changed since opengl-1.1.0-8 - A new symbolic link, /usr/include/opengl/GL -> /usr/include/w32api/GL was added to be able to compile native OpenGL, GLU, GLUT, GLUI, and GLUIX program when the libGL-devel, libGLU-devel, libglut-devel packages are also installed. In that case, compiling with -I/usr/include/opengl is REQUIRED, otherwise the headers from libGL-devel, libGLU-devel, libglut-devel will be used, leading to missing functions at link time. If the libGL-devel, libGLU-devel, libglut-devel package are not installed, you can compile as usual. That was, I think, pretty clear. > And what is that > AT_EXIT_HACK thing about? Again, read he announcement: A bug introduced in opengl-1.1.0-6 was corrected in glut.h. The bug caused the program to continue to run in the background if its window was closed by using the close (X) icon in the title bar. If you prefer to keep that behavior, you must recompile with -DGLUT_DISABLE_ATEXIT_HACK . > > One question I still have is the following. Is there any way to use the > freeglut library in non-X windows binaries? Currently my problem is that > running glut/gl in X11 mode is extremely slow because it doesn't find a > direct rendering context (or something along those lines). I therefore > prefer the native windows mode for my software. However, the neat > features of freeglut are not supported on my current installation. I`m currently working with the Freeglut developpers to provide Freeglut as a replacement for non-X11 GLUT as a new Cygwin package. There are still issues to settle and the no dateline for a release yet. > > > Many thanks for your help. > Steef - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com Many other persons will be able to help you if you do. _ Réunissez-vous avec les gens qui vous sont proches- clavardez face à face grâce à Messenger. http://go.microsoft.com/?linkid=9650743 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Problem with cygwin-xfree mailimg list ?
Something fishy seems to have happen to the cygwin-xfree mailimg list. It usually receives 5 to 15 messages per day, with very few spam. For the last 5 days (March 01 - March 05), not a _single_ real message and 4 spams have got through. It looks like as if the spam filter had been turned around to allow only spam. .. that or Yaakov and John have taken very deserved vacations after killing the very last of the X server bugs, and every user in the world is using X happily ever since! - André Bleau Cygwin's OpenGL package volunteer maintainer. _ Réunissez-vous avec les gens qui vous sont proches- clavardez face à face grâce à Messenger. http://go.microsoft.com/?linkid=9650743 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: opengl-1.1.0-10 glut32 linking problems
Hi Reini, In January, you wrote about some problems linking with opengl-1.1.0-10's glut32.a . I answered on January 29th, asking for some extra info and offering some advice. Could you please tell us if the problem is now solved? This might help other users if they run into a similar problem. - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com _ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: opengl-1.1.0-10 glut32 linking problems
Hi Reini,
Reini Urban wrote:
> The importlib /usr/lib/w32api/libglut32.a has some problems. Linking
> to the dll directly works fine.
>
> $ cat test.c
> #include
> #include
> #include
> int main(int argc, char *argv[])
> {
> if(glutInit == NULL) {
> printf("glutInit is NULL\n");
> return EXIT_FAILURE;
> }
I really don't know what you are trying to do with that test. glutInit is not
called here, you're only checking the address of that function. As it is not
loaded dynamically, it can only be different from NULL, otherwise linking would
have failed.
> printf("GLUT %d\n",GLUT_API_VERSION);
> return EXIT_SUCCESS;
> }
> $ gcc test.c -lglut32 -lglu -lopengl32
As stated in the opengl-1.1.0-9 and -10 anouncements and in
/usr/share/doc/opengl-1.1.0/README.txt , you must now add
-I/usr/include/opengl at compile time to avoid conflicts with freeglut.
Also, the correct linking for glu is -lglu32. It didn't matter here, but it
will when you
build a more elaborate program. Please check
/usr/share/doc/opengl-1.1.0/README.txt .
> undefined reference to `___glutInitWithExit'
> undefined reference to `___glutCreateWindowWithExit'
> undefined reference to `___glutCreateMenuWithExit'
libglut32.a was part of the w32api package before version 3.13-1 . If you have
w32api-3.12-1 or older, you're getting libglut32.a from the w32api package, not
the one
from the opengl package. The opengl package depends on the w32api package, so
updating the
opengl package should have updated the w32api package first.
What is the result of:
cygcheck -c opengl
cygcheck -c w32api
cygcheck -c libglut3
cygcheck -c libglut-devel
?
> $ gcc test.c /bin/glut32.dll -lglu -lopengl32
>
> $ ./a
> GLUT 3
>
> Note that there are two more ___glut* functions, not only these three.
> $ nm /lib/w32api/libglut32.a | grep " ___glut"
> T ___glutset...@8
> T ___glutinitwithe...@12
> T ___glutget...@4
> T ___glutcreatewindowwithe...@8
> T ___glutcreatemenuwithe...@8
> $ objdump -t /lib/w32api/libglut32.a | grep " ___glut"
> [ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x ___glutset...@8
> [ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x
> ___glutinitwithe...@12
> [ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x ___glutget...@4
> [ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x
> ___glutcreatewindowwithe...@8
> [ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x
> ___glutcreatemenuwithe...@8
>
> I see nothing problematic, but I'm no expert
What is the output of ls -l /usr/lib/w32api/libglut32.a ?
It should match:
Fri Dec 5 15:57:41 2008 90472 usr/lib/w32api/libglut32.a
from the opengl-1.1.0-10 package; otherwise, you have the file from an old
w32api package.
You can also try:
gcc test.c /usr/lib/w32api/libglut32.a -lglu32 -lopengl32
To check if -lglut32 leads to the right thing.
> --
> Reini Urban
HTH,
- André Bleau, Cygwin's volunteer OpenGL package maintainer.
Please direct any question or comment about the OpenGL package to cygwin at
cygwin dot com
_
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: OpenGL-1.1.0 link problem (glXMakeCurrent undefined symbols)
"Phan, Linh H" wrote: > Hi, Hi Linh, > I'm trying to port OpenInventor code and using the new opengl-1.1.0 and I > am getting > undefined _glXMakeCurrent symbols: > /usr/bin/CC -g Main.o ClassDef.o Man.o Reader.o Writer.o BuildIssues.o > -lInventor -lstdc++ > -L/usr/X11R6/lib -L/usr/local/lib -limage -ljpeg -liconv -lFL -lfreetype > -lglu32 -lopengl32 -lXm -lXt -lXext -lXi -lX11 -lm -o ivman > /usr/local/lib/libInventor.a(So.o): In function > `_ZN19SoOffscreenRendererD2Ev': > /usr/local/src/inventor2/lib/database/src/so/SoOffscreenRenderer.c++:173: > undefined reference to > `_glXDestroyGLXPixmap' > /usr/local/src/inventor2/lib/database/src/so/SoOffscreenRenderer.c++:174: > undefined reference to > `_glXDestroyContext' > /usr/local/src/inventor2/lib/database/src/so/SoOffscreenRenderer.c++:755: > undefined reference to > `_glXMakeCurrent' > ... > I could see it in: > [EMAIL PROTECTED] ...inventor2/lib]$ nm /usr/X11R6/lib/libGL-1.dll.a |grep > glXMakeCurrent > I __imp__glXMakeCurrentReadSGI > T _glXMakeCurrentReadSGI > I __imp__glXMakeCurrent > T _glXMakeCurrent > What library in the new opengl-1.1.0 can I used to fix this problem? > Thank you, > Linh > Yeurk! The problem here is that you are trying to mix to incompatible things: 1- libraries from the w32api package (-lglu32 -lopengl32) which are about displaying openGL graphics directly through a native Windows interface (Win32) without any X server; 2- some other librairies (-lX...) that are about displaying through an X server. Than cannot work. You must make up your mind: Either you follow the Win32 road and you move your discussion to cygwin at cygwin dot com (as Yaakov suggested). Or you follow the X server road. As OpenInventor is some SGI thing, it is probably the best choice. In that case, you should update all your X11-related packages (-L/usr/X11R6/lib is related to the old version). In particular, you will need the following packages: libGL-devel, libGL1, libGLU-devel, libGLU1, which are about displaying openGL graphics through an X server. In that case, keep the discussion at cygwin-xfree at cygwin dot com. - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com _ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: opengl-1.1.0-10
Version 1.1.0-10 of the opengl package has been released. This package contains OpenGL-related libraries: GLUT, GLUI, and GLUIX librairies to develop portable OpenGL programs that do not require an X server to run. These programs can display through the native Windows interface (Win32) and benefit from hardware and driver acceleration. This update should solve the problems about a missing .lib file, such as: http://cygwin.com/ml/cygwin-xfree/2008-12/msg00030.html The previous conflict with the w32api package over the libglut32.a file has been solved by the latest w32api package update, thanks to Chris Sutcliffe. See: http://cygwin.com/ml/cygwin-apps/2008-12/msg00027.html You must update to w32api-3.13-1 to update to opengl-1.1.0-10 . Automatic dependency checking in the setup program should take care of that. Unfortunately, users of the opengl package might have to change the way they build their applications. More specificaly, compiling with -I/usr/include/opengl is REQUIRED when the libGL-devel, libGLU-devel, libglut-devel packages are also installed. See: http://cygwin.com/ml/cygwin/2008-11/msg00056.html Exerbs from the updated README.txt: >---< What has changed since opengl-1.1.0-9 - The usr/lib/w32api/glut32.lib that was supposed to be provided was in fact missing. The conflict over usr/lib/w32api/libglut32.a with the w32api package has been resolved; that file is now part of the opengl package. What has changed since opengl-1.1.0-8 - A new symbolic link, /usr/include/opengl/GL -> /usr/include/w32api/GL was added to be able to compile native OpenGL, GLU, GLUT, GLUI, and GLUIX program when the libGL-devel, libGLU-devel, libglut-devel packages are also installed. In that case, compiling with -I/usr/include/opengl is REQUIRED, otherwise the headers from libGL-devel, libGLU-devel, libglut-devel will be used, leading to missing functions at link time. If the libGL-devel, libGLU-devel, libglut-devel package are not installed, you can compile as usual. A bug introduced in opengl-1.1.0-6 was corrected in glut.h. The bug caused the program to continue to run in the background if its window was closed by using the close (X) icon in the title bar. If you prefer to keep that behavior, you must recompile with -DGLUT_DISABLE_ATEXIT_HACK . glut-examples was added to /usr/lib. The helloGLUT example program was improved. FAQ.txt was added. >---< Enjoy, - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. _ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: opengl-1.1.0-9
Version 1.1.0-9 of the opengl package has been released. This package contains OpenGL-related libraries: GLUT, GLUI, and GLUIX librairies to develop portable OpenGL programs that do not require an X server to run. These programs can display through the native Windows interface (Win32) and benefit from hardware and driver acceleration. This update should solve the problems that have been reported after the release of new X server, such as: http://cygwin.com/ml/cygwin/2008-11/msg00022.html http://cygwin.com/ml/cygwin-xfree/2008-12/msg3.html The problems were due to some conflict with the last version of the libGL-devel, libGLU-devel, libglut-devel packages. See: http://cygwin.com/ml/cygwin-apps/2008-11/msg00037.html http://cygwin.com/ml/cygwin-apps/2008-11/msg00043.html Unfortunately, users of the opengl package might have to change the way they build their applications. See: http://cygwin.com/ml/cygwin/2008-11/msg00056.html There is a remaining conflict with the w32api package, with a workaround. I am currently working with the w32api maintainers to solve it. Another update might be coming soon. Exerbs from the updated README.txt: >---< What has changed since opengl-1.1.0-8 - A new symbolic link, /usr/include/opengl/GL -> /usr/include/w32api/GL was added to be able to compile native OpenGL, GLU, GLUT, GLUI, and GLUIX program when the libGL-devel, libGLU-devel, libglut-devel packages are also installed. In that case, compiling with -I/usr/include/opengl is REQUIRED, otherwise the headers from libGL-devel, libGLU-devel, libglut-devel will be used, leading to missing functions at link time. If the libGL-devel, libGLU-devel, libglut-devel package are not installed, you can compile as usual. usr/lib/glut32.lib is now provided. It should used instead of libglut32.a. A bug introduced in opengl-1.1.0-6 was corrected in glut.h. The bug caused the program to continue to run in the background if its window was closed by using the close (X) icon in the title bar. If you prefer to keep that behavior, you must recompile with -DGLUT_DISABLE_ATEXIT_HACK . glut-examples was added to /usr/lib. The helloGLUT example program was improved. FAQ.txt was added. >---< Enjoy, - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. _ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Defrag and some other exe not seen by cygwin on XP64
Bruce Dobrin wrote: > This is weird > I couldn't find it in my search of the site; > I was on a XP64 machine and tried to run the defrag command from the Cygwin > shell > and it could not locate the command. I could see the command via the cmd > shell. > Below I cd usng the cmd shell on 64bit XP and using ls it is not seen and dir > it is seen: > C:\WINDOWS\system32>ls |grep defrag > C:\WINDOWS\system32>dir |grep defrag > 02/16/2007 08:33 PM35,840 defrag.exe > C:\WINDOWS\system32>cacls defrag.exe > C:\WINDOWS\system32\defrag.exe BUILTIN\Administrators:F >NT AUTHORITY\BATCH:R >Everyone:R >NT AUTHORITY\INTERACTIVE:R >NT AUTHORITY\SERVICE:R >NT AUTHORITY\SYSTEM:F > I then copied the file in the cmd shell to c:\cygwin\ and then Cygwin can see > it there: > [EMAIL PROTECTED]:/c/WINDOWS/system32> ls -al ./defrag > ls: cannot access ./defrag: No such file or directory > [EMAIL PROTECTED]:/c/WINDOWS/system32> cd / > [EMAIL PROTECTED]:/> ls -al ./defrag >> -rwx--+ 1 dobrin Domain Users 35840 Feb 16 2007 ./defrag > I confirmed that this isn't an issue on XP32 or Vista > > And Ideas? > Thanks For 32 bit processes (like bash), C:\Windows\System32 is aliased to C:\Windows\SysWOW64. 64 bit processes (like the 64 bit version of cmd) see the real C:\Windows\System32. For more about this weirdness, see: http://searchenterprisedesktop.techtarget.com/tip/0,289483,sid192_gci1204121,00.html If you would like your bash shell see the content of the real System32 folder, you can do the following: As administrator in a 64 bit cmd (NOT a bash shell): C: cd \Windows mklink /D System64 System32 Then you can access the real System32 folder via the System64 symbolic link: $ ls -l /cygdrive/c/Windows/System64/Defrag.exe -rwxrwx---+ 2 232960 Jan 19 2008 /cygdrive/c/Windows/System64/Defrag.exe HTH, - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com _ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Upcoming modification to the opengl package
Attention all users of the opengl package: Due to a conflict with the libglut-devel package and with the upcoming modular X11R7 (see http://cygwin.com/ml/cygwin-apps/2008-11/msg00043.html), I am considering the following change to the opengl package: Addition of a directory: /usr/include/opengl that will contain only a symbolic link: GL -> ../w32api/GL Then all users of the opengl package would be forced to update their build system to add -I/usr/include/opengl at compile time. I really don't like to push that sort of change down the throat of the developpers that were using a package that was working well before some other package was added to the distribution, but as there is no other package depending on the opengl one and there are many that do or will depend on finding Mesa opengl and freeglut in /usr/include, it seems to be the lesser evil. If you disagree with that change or if it will be very inconvenient to you (and I know that many universities teach computer graphic classes using the opengl package), it is time to voice your concerns. If there is no or little disagrement, an upcoming version of the opengl package with the above change will be made avaliable by november 30, 2008. As it will be the only change in the package, those that wish to finish the current semester undisturbed can obsiously keep the previous (the now current) version. Regards, - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com _ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problem with cygwin and GLUT on Vista
Hello Michael, I managed to install Cygwin, its development packages and the opengl package on a computer running Vista Home Premium 64-bit edition with SP1 yesterday. Everything runs fine: the GLUI examples, the helloGLUT test program, and your own "main" test program. Possible causes for your problems: 1- BLODA. See http://cygwin.com/faq/faq.using.html#faq.using.bloda 2- Conflict between the opengl package and the libglut-devel package. If you have both, try to uninstall the libglut-devel package with the setup program. 3- You have a conflicting copy of one of the dlls installed somewhere. To help us help you further, you need to: 1- Go to the directory where your "main.exe" is. 2- Run: cygcheck ./main.exe 3- Send the output here. Also _attach_ the output of: cygcheck -s Regards, - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com _ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problem with cygwin and GLUT on Vista
Michael McGuffin wrote:
> Hello,
Hello Michael,
> I'm using cygwin on Vista,
Which version? 32-bit or 64-bit? with or without SP1?
> and have a problem running C++ code that contains calls to
> GLUT routines. I've isolated the problem down to a very simple piece of code,
> and have
> searched the web without being able to find help.
>
> Note that I have packages opengl 1.1.0-8, freeglut 2.4.0-1, and gcc-g++
> 3.4.4-3,
> and "uname -a" outputs
> CYGWIN_NT-6.0 opticon-w 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
The standard (and more complete) way to provide that information is to attach
the output of
cygcheck -s to your problem report.
Please note that there is currently a conflict between the opengl package and
the libglut-devel
package. If you have both, you will have to uninstall one of them. See:
http://cygwin.com/ml/cygwin/2008-11/msg00033.html
> Here's the problem, as best as I can isolate it. If I create a file called
> main.cpp containing
> the following code:
>
>
> #include
> #include
>
>
> int main( int argc, char *argv[] ) {
> if ( argc> 100 ) {
> // glutInit( &argc, argv );
> glClear(GL_COLOR_BUFFER_BIT);
> }
> char str[100];
> printf("Enter a string:");
> scanf("%s",str);
> }
> and then I compile it with
>
> g++ -o main main.cpp -lm -lglut32 -lglu32 -lopengl32
This is just plain C, not C++. Can you rename it main.c and recompile with:
gcc -o main main.cpp -lglut32 -lglu32 -lopengl32
This would clear-up if it is an issue with the stdc++ library.
> and then run the code without any arguments, it runs fine (note that the call
> to glClear()
> never happens). However, if I uncomment the call to the glutInit() routine
> and comment the
> glClear() call,
>
>
> #include
> #include
>
>
> int main( int argc, char *argv[] ) {
> if ( argc> 100 ) {
> glutInit( &argc, argv );
> // glClear(GL_COLOR_BUFFER_BIT);
> }
> char str[100];
> printf("Enter a string:");
> scanf("%s",str);
> }
>
> and compile the same way and run again without any arguments, Windows Vista
> gives me> an error message with the following details:
>
>
> Nom d'événement de problème:APPCRASH
> Nom de l'application: main.exe
> Version de l'application: 0.0.0.0
> Horodatage de l'application:49103229
> Nom du module par défaut: ntdll.dll
> Version du module par défaut: 6.0.6001.18000
> Version du module par défaut: 4791a7a6
> Code de l'exception:c022
> Décalage de l'exception:9cac
> Version du système: 6.0.6001.2.1.0.256.4
> Identificateur de paramètres régionaux: 3084
> etc.
Your example compiles and runs fine for me under XP SP3.
>
> Note, again, that the call to glutInit() never happens. I suspect that simply
> linking with GLUT> somehow causes a problem, perhaps in some initialization
> of GLUT.
>
Then try one of the precompiled examples. What happens if you run
/usr/lib/glui-examples/example6 ?
> Note that I have tried running the main.exe as "administrator" (by right
> clicking on
> main.exe and choosing the "run as administrator" option from the right-click
> menu), and I
> get the same error message as when I try running main.exe from a cygwin shell
> prompt.
>
> Any help would be appreciated, thanks.
I don't have a Vista machine with Cygwin installed right now. It might take a
week before I
get one. When I do, I will report back here.
Regards,
- André Bleau, Cygwin's volunteer OpenGL package maintainer.
Please direct any question or comment about the OpenGL package to cygwin at
cygwin dot com
_
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Trouble Compiling Cygwin GLUT Examples
John M Fernandes-Salling wrote: > > Hello, > > I'm running Cygwin on a Windows Vista computer, and I'm having trouble > compiling the > example GLUT c file "helloGlut.c" provided in the Cygwin OpenGL package. > > Using Cygwin, after navigating to the directory > "/cygdrive/c/cygwin/usr/share/doc/opengl-1.1.0/GLUTExamples/Cygwin", I type > "make helloGlut" without quotes, and the output is: > "cc -c -O2 helloGlut.c > cc -O2 helloGlut.o -lglut32 -lglu32 -lopengl32 -o helloGlut > helloGlut.o:helloGlut.c:(.text+0x86): undefined reference to '_glutInit' > helloGlut.o:helloGlut.c:(.text+0x92): undefined reference to > '_glutCreateWindow' > > helloGlut.o:helloGlut.c:(.text+0x9e): undefined reference to > '_glutDisplayFunc' > helloGlut.o:helloGlut.c:(.text+0xaa): undefined reference to > '_glutKeyboardFunc' > > helloGlut.o:helloGlut.c:(.text+0xbb): undefined reference to '_glutMainLoop' > collect2: ld returned 1 exit status > make: *** [helloGlut] Error 1" without quotes. > > As far as I can tell, I've followed the instructions for setting up OpenGL, > GLU, and GLUT > within Cygwin, so I'm at a loss as to what the problem is. I'm new both to > programming in> C, OpenGL, and using Cygwin, having formerly programmed in > Java with the JOGL binding > for OpenGL. Any help would be greatly appreciated. > > Thank you for your time, > John Fernandes-Salling > I just discovered that the last version of the libglut-devel package now installs a glut.h file in /usr/include/GL. This file takes precedance over the one in /usr/include/w32api/GL and declares the same functions but with a different calling convention. This makes the packages libglut-devel and opengl incompatible; you will have to uninstall one of them if you have both. libglut-devel is for applications that will run through and X server while opengl is for application that will use the natve Windows interface. The first is Linux compatible at the source level while the second is not, but is much faster. I will have to discuss the issue with the libglut-devel maintainer on the cygwin-apps list. Regards, - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com _ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Trouble Compiling Cygwin GLUT Examples
John M Fernandes-Salling wrote: > > Hello, > > I'm running Cygwin on a Windows Vista computer, and I'm having trouble > compiling the > example GLUT c file "helloGlut.c" provided in the Cygwin OpenGL package. > > Using Cygwin, after navigating to the directory > "/cygdrive/c/cygwin/usr/share/doc/opengl-1.1.0/GLUTExamples/Cygwin", I type > "make helloGlut" without quotes, and the output is: > "cc -c -O2 helloGlut.c > cc -O2 helloGlut.o -lglut32 -lglu32 -lopengl32 -o helloGlut > helloGlut.o:helloGlut.c:(.text+0x86): undefined reference to '_glutInit' > helloGlut.o:helloGlut.c:(.text+0x92): undefined reference to > '_glutCreateWindow' > > helloGlut.o:helloGlut.c:(.text+0x9e): undefined reference to > '_glutDisplayFunc' > helloGlut.o:helloGlut.c:(.text+0xaa): undefined reference to > '_glutKeyboardFunc' > > helloGlut.o:helloGlut.c:(.text+0xbb): undefined reference to '_glutMainLoop' > collect2: ld returned 1 exit status > make: *** [helloGlut] Error 1" without quotes. > > As far as I can tell, I've followed the instructions for setting up OpenGL, > GLU, and GLUT > within Cygwin, so I'm at a loss as to what the problem is. I'm new both to > programming in> C, OpenGL, and using Cygwin, having formerly programmed in > Java with the JOGL binding > for OpenGL. Any help would be greatly appreciated. > > Thank you for your time, > John Fernandes-Salling > The undefined references are supposed to be satisfied by /usr/lib/w32api/libglut32.a Do you have that file? If not, install the w32api package, as stated in /usr/share/doc/opengl-1.1.0/README.txt Regards, - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com _ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: OpenGL: Linker errors when trying to compile w/GLUI
godescbach wrote: > Hi, > > I am trying to compile example1.cpp in > /var/share/doc/opengl-1.1.0/GLUIexamples/Cygwin. After trying numerous > possibilities, I am at a loss. And there is no information on the web > about this specific issue. Please advise. > > $ uname -a > CYGWIN_NT-5.1 escher_notebook 1.5.25(0.156/4/2) 2008-04-17 12:11 i686 Cygwin This info is not very usefull for me to help you; it tells only which version of the cygwin1.dll you use. It would be more significant to report the output of : cygcheck -c openGL which would tell us which version of the openGL package you have. I will assume 1.1.0-8 which is the latest; if not, please upgrade to it using the setup program. > > $ g++ -O2 -mno-cygwin example1.cpp -o example1 -L/usr/lib/w32api -lglui > -lglut3 > 2 -lglu32 -lopengl32 > /usr/lib/w32api/libglui.a(glui_spinner.o):glui_spinner.cpp:(.text+0xd): > undefine > d reference to `___getreent' > ... > /usr/lib/w32api/libglui.a(glui_edittext.o):glui_edittext.cpp:(.text+0x237): > more > undefined references to `___getreent' follow> collect2: ld returned 1 exit > status > No surprise: -mno-cygwin and -L/usr/lib/w32api are incompatible > [EMAIL PROTECTED] /usr/share/doc/opengl-1.1.0/GLUIexamples/Cygwin > $ view /usr/share/doc/Cygwin/opengl-1.1.0-8.README > That file tells you how to rebuild the package from its sources. I don't think that's what you intended. To learn how to _use_ the package, please view: /usr/share/doc/opengl-1.1.0/README.txt > [EMAIL PROTECTED] /usr/share/doc/opengl-1.1.0/GLUIexamples/Cygwin > $ make> g++ -c -O2 -mno-cygwin example1.cpp > g++ -O2 -mno-cygwin example1.o -L/usr/lib/w32api -lglui -lglut32 -lglu32 -lope > ngl32 -o example1> > /usr/lib/w32api/libglui.a(glui_spinner.o):glui_spinner.cpp:(.text+0xd): > undefine > d reference to `___getreent' > ... > /usr/lib/w32api/libglui.a(glui_edittext.o):glui_edittext.cpp:(.text+0x237): > more > undefined references to `___getreent' follow > collect2: ld returned 1 exit status > make: *** [example1] Error 1 Obviously you added -L/usr/lib/w32api to the makefile. Undo all your changes to that file; if unsure reinstall the package with the setup program. Then: cd /usr/share/doc/opengl-1.1.0/GLUIexamples make clean make That will build all 6 examples for both Cygwin (executables in the Cygwin subdir) and Mingw (executables in the Mingw subdir). Regards, - André Bleau, volunteer Cygwin's openGL package maintainer. P.S.: Please send all questions and comments about the openGL package to cygwin at cygwin dot com. _ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: bug in cygwin_conv_to_posix_path() caused by period in win32 path
Corinna Vinschen wrote: [...] (*) and, funny enough, there's no API call in Win32 to return a DCWD. There's just a call GetCurrentDirectory() which returns *the* CWD. Which makes sense, given that the RTL_USER_PROCESS_PARAMETERS can only store one CWD per process. Well, this is not surprising, as there is no such thing as a DCWD in Windows. It is strictly a cmd thing. Try this: start 2 instances of cmd in parallel: *** First cmd *** Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\Documents and Settings\ableau>cd \winnt C:\WINNT>D: D:\>c: C:\WINNT> *** Second cmd *** Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\Documents and Settings\ableau.SOLVISION>d: D:\>c: C:\Documents and Settings\ableau> *** The "DCWD" is clearly independant for each cmd. - André Bleau, cygwin's OpenGL package maintainer. Please address any question about the OpenGL package to cygwin at cygwin dot com. _ Windows Live Hotmail. Plus stylé que jamais. Voyez par vous-même dès maintenant. www.nouveauhotmail.ca?icid=WLHMFRCA121 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Bug in cygcheck 1.90
hides C:\WINNT\system32\USER32.dll C:/WINNT/system32\USER32.dll (already done) Warning: C:/WINNT/system32\ADVAPI32.dll hides C:\WINNT\system32\ADVAPI32.dll C:/WINNT/system32\ADVAPI32.dll (already done) Warning: C:/WINNT/system32\SHELL32.DLL hides C:\WINNT\system32\SHELL32.DLL C:/WINNT/system32\SHELL32.DLL - os=5.0 img=5.0 sys=4.0 "SHELL32.dll" v0.0 ts=2006/3/18 4:51 Warning: C:/WINNT/system32\ntdll.dll hides C:\WINNT\system32\ntdll.dll C:/WINNT/system32\ntdll.dll (already done) Warning: C:/WINNT/system32\GDI32.dll hides C:\WINNT\system32\GDI32.dll C:/WINNT/system32\GDI32.dll (already done) Warning: C:/WINNT/system32\USER32.dll hides C:\WINNT\system32\USER32.dll C:/WINNT/system32\USER32.dll (already done) Warning: C:/WINNT/system32\KERNEL32.dll hides C:\WINNT\system32\KERNEL32.dll C:/WINNT/system32\KERNEL32.dll (already done) Warning: C:/WINNT/system32\ADVAPI32.dll hides C:\WINNT\system32\ADVAPI32.dll C:/WINNT/system32\ADVAPI32.dll (already done) Warning: C:/WINNT/system32\SHLWAPI.dll hides C:\WINNT\system32\SHLWAPI.dll C:/WINNT/system32\SHLWAPI.dll (already done) Warning: C:/WINNT/system32\COMCTL32.dll hides C:\WINNT\system32\COMCTL32.dll C:/WINNT/system32\COMCTL32.dll (already done) Warning: C:/WINNT/system32\MSVCRT.DLL hides C:\WINNT\system32\MSVCRT.DLL C:/WINNT/system32\MSVCRT.DLL (already done) Warning: C:/WINNT/system32\NTDLL.DLL hides C:\WINNT\system32\NTDLL.DLL C:/WINNT/system32\NTDLL.DLL (already done) The warnings are obviously wrong. - André Bleau, Cygwin's OpenGL package maintainer. Please respond to the list only, not to me directly. Hotmail cannot set a Reply-To: header. _ Jouez à Q6 et vous pourriez GAGNER de fabuleux prix. http://q6trivia.imagine-live.com/frca/landing -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: opengl-1.1.0-8
I've uploaded new version of the OpenGL package, version 1.1.0-8. Excerpts from README.txt: __ What has changed since opengl-1.1.0-7 This package was released to avoid conflicts with the new X11R7.0 packages, including FreeGlut. See http://cygwin.com/ml/cygwin-apps/2006-04/msg00079.html for details. glui-examples were moved from /usr/bin tio /usr/lib glut.h was moved from /usr/include/GL to /usr/include/w32api/GL glui.h and gluix.h were moved from /usr/include to /usr/include/w32api libglui.a and libgluix.a were moved from /usr/lib to /usr/lib/w32api __ To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. Look for "opengl" in the 'Graphics' or 'Libs' categories. If you have general questions or comments, please send them to the Cygwin mailing list at: "cygwin at cygwin dot com". I would appreciate it if you would use this mailing list rather than emailing me directly. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. - André Bleau, Cygwin's OpenGL package maintainer. Please address all questions and problem reports about Cygwin's OpenGL package to cygwin at cygwin dot com. _ Balayez vos courriels entrants et sortants et les pièces jointes et contribuez à éliminer les virus destructeurs susceptibles dy être intégrés. http://join.msn.com/?pgmarket=fr-ca&page=features/virus Commencez dès maintenant à profiter de tous les avantages de MSN Premium et obtenez les deux premiers mois GRATUITS*. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Linker Error: cannot find -lGL [in Cygwin]
Olumide wrote: --- Hi - I'm sure theres' a straightforward answer to this question. I'm trying to link an object file (main.o) with the OpenGL libraries but I'm getting the following error: $ g++ main.o -lglut -lGL -lGLU -o demo /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lGL collect2: ld returned 1 exit status Which is quite surprising because I only just reinstalled the latest version of Cygwin (all of it). What am I not doing right? Thanks, - Olumide --- Olumide, For instructions about compiling/linking OpenGL and GLUT programs, please read: /usr/share/doc/opengl-1.1.0/README.txt André Bleau, Cygwin's OpenGL package maintainer Please send any question regarding the OpenGL package to cygwin at cygwin dot com Anything writen below this line is from my mailing agent and I have no control over it. _ Partagez une seule photo ou un diaporama complet dans MSN Messenger. http://join.msn.com/?pgmarket=fr-ca&page=features/messenger Commencez dès maintenant à profiter de tous les avantages de MSN Premium et obtenez les deux premiers mois GRATUITS*. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question about OpenGL
Thom DeCarlo wrote: I'm wondering if there is any new development in the OpenGL libraries within cygwin. The package in the distribution says it is version 1.1, but the current OpenGL release, from Sept 2004, is v2.0. The last pre-2.0 version was 1.5. The last comment I found in the archives was from Andre Bleau in Feb 2003. He laid out a development plan but I can't find any changes after that time. Does anyone know if anything has happened lately? I'd like to use some of the 2.0 capabilities, but it doesn't look like I can get there with cygwin. Thanks for any info, Thom Thom, There never was an implementation of native OpenGL for Cygwin. All there is is a way for Cygwin programs to access the underlying implementation of OpenGL for Windows, and that implementation is stuck at version 1.1. Unless Bill Gates changes his mind about OpenGL, it will never be upgraded. There are ways to use the features of more recent OpenGL implementations provided with graphic card drivers through the use of extensions. That's a problem that all OpenGL developpers on the Windows platform have to face, not just the ones programming for Cygwin. If you want more info about how to do that, please look at the programming forums at http://www.opengl.org/ . The "development plan" you mentionned was about GLUT, a library often used by OpenGL programs, not about OpenGL itself. André Bleau, Cygwin's OpenGL package maintainer Please send any question regarding the OpenGL package to cygwin at cygwin dot com _ Balayez vos courriels entrants et sortants et les pièces jointes et contribuez à éliminer les virus destructeurs susceptibles dy être intégrés. http://join.msn.com/?pgmarket=fr-ca&page=features/virus Commencez dès maintenant à profiter de tous les avantages de MSN Premium et obtenez les deux premiers mois GRATUITS*. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: OpenGL does not render when linked with -mno-cygwin
Arvind N wrote: I am using g++ Version 3.3.3 on a Windows XP box to write a program that draws mathematical functions as graphs. The program works fine when I compile and link without -mno-cygwin and the graphs are rendered fine. However, if I add -mno-cygwin to the compile line and "-L/usr/lib/mingw -lstdc++" to the link line, all I get is a black screen. I am using GLUT to create the window and the menus and all of those work fine but there is nothing rendered into the window. I do not get any errors either. Such a difference between a Mingw and a Cygwin application is often clue of a hidden bug in the application. Something may be corrupted or not initialized properly. I do not get any compiler/linker warnings or errors when I compile with -mno-cygwin. Are there any dependencies that OpenGL has with cygwin1.dll? No, OpenGL has no dependency on cygwin1.dll. The OpenGL implementation used is the one provided by M$ for Windows. The link line uses the libraries in the order "-lglut32 -lglu32 -lopengl32" which seems to be what the documentation says. Here are the cygcheck outputs with and without mno-cygwin: * With mno-cygwin: ... * Without mno-cygwin ... I would appreciate any help with this. There are 6 examples of C++ programs using GLUI, GLUT and OpenGL under /usr/bin/GLUI-examples these were compiled with -mno-cygwin. Are you able to run them ? Sources for these examples, including a Makefile, are in /usr/share/doc/opengl-1.1.0/GLUIexamples Thanks in advance, Arvind André Bleau, Cygwin's OpenGL package maintainer Please adress any question or comment about the OpenGL package to cygwin at cygwin.com _ Profitez des puissants filtres de courriels indésirables articulé sur la technologie brevetée Microsoft SmartScreen.s http://join.msn.com/?pgmarket=fr-ca&page=features/popup Commencez dès maintenant à profiter de tous les avantages de MSN Premium et obtenez les deux premiers mois GRATUITS*. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: OpenGL problem
From: Denis Roegel <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: Denis Roegel <[EMAIL PROTECTED]> Subject: Re: OpenGL problem Date: Tue, 15 Feb 2005 23:36:00 +0100 Dear André, Hi Denis, I did not mean to offend you, but I have written (as you suggested a year ago) to cygwin@cygwin.com, and then Larry Hall suggested to use cygwin-apps. Maybe you didn't read the message because it was lost after the server problems. No offense taken. I've read both of your 2 messages to cygwin at cygwin.com and the one you sent to cygwin-apps at cygwin.com. I replied to all of them, in their respective mailing list: http://cygwin.com/ml/cygwin/2005-02/msg00408.html http://cygwin.com/ml/cygwin/2005-02/msg00409.html http://cygwin.com/ml/cygwin-apps/2005-02/msg00024.html What Larry meant is that if you find a packaging error in the OpenGL package, that is, if the package does not respect the layout required for Cygwin's packages, you should report it to the cygwin-apps list. If you have any other sort of trouble with the OpenGL package, report it to the main cygwin list. Now, I also apologize for writing to you directly, but although I am subscribed to cygwin-apps, I didn't receive the message to which I am now replying. I only found it on the web. This is why I thought it better to reply directly to you. This is really surprising. If you are subscribed to the list, you should receive all messages sent to it. If not, you should inquire with the list manager. If your email connection with Cygwin's lists is unreliable, I suggest that you add the following line to messages you send to the lists: "Please CC your response to this message directly to my address." I never reply directly to people sending messages to lists, unless they require it explicitely. I have been subscribed to the cygwin list, and now instead to the cygwin-apps list. Should I return to the main cygwin list? Yes. I am confused... If you can solve the problem, I would be very thankful, as I have had it for a year. None of my complex programs using tessellation seem to work on cygwin (and also apparently not on some other Windows environment, from what my students tell me). On the other hand, I have the feeling that I am the only one on Earth needing such features, or somehow nobody is trying tessellation with cygwin. Denis The "solution" to your problem was in my reply to your original message to the cygwin list: http://cygwin.com/ml/cygwin/2005-02/msg00408.html Regarding tessallation and Cygwin, the tess.c sample program about which you wrote to me last year works reliably on Cygwin. Your new program doesn't, but as outlined in message msg00408, it is because of a programming error. Please try the suggestions in that message, and if you have other problems that are specific to OpenGL under Cygwin, write about it to the cygwin list. André Bleau, Cygwin's OpenGL package maintainer _ Partagez une seule photo ou un diaporama complet dans MSN Messenger. http://join.msn.com/?pgmarket=fr-ca&page=features/messenger Commencez dès maintenant à profiter de tous les avantages de MSN Premium et obtenez les deux premiers mois GRATUITS*. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: OPENGL package maintainer?
Larry Hall wrote, in response to Denis Roegel : At 04:38 PM 2/9/2005, you wrote: >Hi, > >I have tried unsuccessfully to reach André Bleau who is/was >the OpenGL package maintainer. Does anybody know how I can >reach him or whom I should send my problems with the OpenGL >package? This list is generally the preferred way to discuss Cygwin issues unless they are actual packaging issues, in which case cygwin-apps is the preferred list. You are right, Larry. Issues regarding Glut, Glu, GLUI, GLUIX and OpenGL in the Cygwin environment should be reported to cygwin@cygwin.com, not to me directly. André Bleau, Cygwin's OpenGL package maintainer. _ MSN Calendar vous aide à vous organiser et simplifie la planification des rencontres. http://join.msn.com/?pgmarket=fr-ca&page=features/calendar Commencez dès maintenant à profiter de tous les avantages de MSN Premium et obtenez les deux premiers mois GRATUITS*. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: still a tessellation problem with OpenGL
wrote:
Hi,
Hi Denis,
using an advice by Andre Bleau a year ago, I got the two
tessellation examples (tess.c and tesswind.c) from OpenGL working.
However, the example below, slightly different from
tess.c doesn't work. I get a segmentation fault, but I have no idea
how to solve the problem.
Well, reading the manual about how to properly call "glu" functions would be
a step in the right direction; see below.
I would appreciate any help as this is
a reduced case of a larger program which works well on linux,
and that I'd love to port on cygwin. I suspect this problem is related with
tessellation, but I am not sure.
Your problem is indeed related to tessellation, but this time it is not
Cygwin-specific. I'll give you some help anyway.
Thanks in advance,
Denis
$ gcc -g -o mytess mytess.c -lopengl32 -lglu32 -lglut32
First thing: the proper order for linking is -lglut32 -lglu32 -lopengl32
, as documented in /usr/share/doc/opengl-1.1.0/README.txt
Order is important; you were just lucky this time.
$mytess.exe
Ok here
Segmentation fault (core dumped)
...
->
// adapted from tess.c
#include
#include
#include
#ifndef CALLBACK #define CALLBACK __attribute__ ((__stdcall__))
#endif
...
void CALLBACK vertexCallback(GLvoid *vertex)
{
const GLdouble *pointer;
pointer = (GLdouble *) vertex;
glColor3dv(pointer+3);
glVertex3dv(vertex);
}
...
void tess_properties(GLUtesselator *tobj) {
gluTessProperty (tobj, GLU_TESS_WINDING_RULE,
GLU_TESS_WINDING_POSITIVE); gluTessCallback(tobj,
GLU_TESS_VERTEX,(_GLUfuncptr)glVertex3dv); gluTessCallback(tobj,
GLU_TESS_BEGIN,(_GLUfuncptr)beginCallback); gluTessCallback(tobj,
GLU_TESS_END,(_GLUfuncptr)endCallback);
gluTessCallback(tobj, GLU_TESS_ERROR,(_GLUfuncptr)errorCallback);
gluTessCallback(tobj, GLU_TESS_COMBINE, (_GLUfuncptr)combineCallback);
gluTessCallback(tobj,
GLU_TESS_VERTEX_DATA,(_GLUfuncptr)&vertexCallback);
}
...
Here's the problem: vertexCallback is your GLU_TESS_VERTEX_DATA callback
function. Proper GLU_TESS_VERTEX_DATA callback functions need to have the
following prototype:
void CALLBACK vertexData (void * vertex_data, void * polygon_data);
Maybe your version of linux and/or gcc on linux is more tolerant to missing
arguments. Or maybe you screwed-up the stack there too, only just not enough
for crashing your program.
You may find other useful info about gluTessCallback in the man pages for
glu. There are available at many places on the web. Example:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/opengl/glufnc01_9bu3.asp
I've modified a single line in your test program:
void CALLBACK vertexCallback(GLvoid *vertex)
was changed to:
void CALLBACK vertexCallback(GLvoid *vertex, GLvoid *polygon)
Running it opens an all-black window. Probably not what you would like, but
certainly no crash. As this is not some problem specific to cygwin's support
of glut, glu or open GL, please use some open GL forum, such as:
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=forum;f=2
if you need further help with your program.
Regards,
André Bleau, Cygwin's OpenGL package maintainer.
_
Balayez vos courriels entrants et sortants et les pièces jointes et
contribuez à éliminer les virus destructeurs susceptibles dy être intégrés.
http://join.msn.com/?pgmarket=fr-ca&page=features/virus Commencez dès
maintenant à profiter de tous les avantages de MSN Premium et obtenez les
deux premiers mois GRATUITS*.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
