Hi,
> It seems still the same problem with dri-drivers
> https://sourceware.org/ml/cygwin/2016-04/msg00283.html
>
> probably caused by LLVM 3.7
FYI, if this is caused truly by LLVM 3.7, maybe i've already
experienced a kind of this issue w/ non-OpenGL app too.
https://github.com/nickg/nvc/issues/
Hi,
> Have there been any changes to OpenGL libraries in 32-bit cygwin in the last
> six months?
i also have another OpenGL app crashing.
glxinfo reports wrong Video memory size.
glxgears raises SIGSEGV under swrast_dri.so.
i could not reach exact crash point, b/c dri-drivers looks having no
deb
Hi,
>> i'm now revisiting this topic b/c mingw-*-fftw3 are not OpenMP capable.
>> can someone (maybe, Yaakov?) update them?
>
> That's because there were many (32 in total) otherwise "internal" symbols
> are used by the threaded libraries which were not being exported, resulting
> in linking error
Hi,
i'm now revisiting this topic b/c mingw-*-fftw3 are not OpenMP capable.
can someone (maybe, Yaakov?) update them?
Peace,
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info
Hi,
>> >> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to
>> >> glibc's?
>> >
>> > Cygwin is using newlib, newlib is BSD based. We introduced the
>> > compatibility checking macros from FreeBSD lately.
>>
>> i roughly checked FreeBSD include/stdio.h and sys/sys/cdefs.h.
>>
Hi,
>> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to
>> glibc's?
>
> Cygwin is using newlib, newlib is BSD based. We introduced the
> compatibility checking macros from FreeBSD lately.
i roughly checked FreeBSD include/stdio.h and sys/sys/cdefs.h.
https://github.com/free
oops!
forgot to attach p.c, so resending now...
> Hi,
>
>>> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to
>>> glibc's?
>>> especially, i meant routines in POSIX 1003.1:2001 (popen(), pclose(), etc).
>>> for a specific example, see a cparser issue[1] i submitted.
>>>
>>
>>
Hi,
>> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to
>> glibc's?
>> especially, i meant routines in POSIX 1003.1:2001 (popen(), pclose(), etc).
>> for a specific example, see a cparser issue[1] i submitted.
>>
>
> Cygwin isn't wrong. __STRICT_ANSI__ doesn't mix with POSIX
Hi,
is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to glibc's?
especially, i meant routines in POSIX 1003.1:2001 (popen(), pclose(), etc).
for a specific example, see a cparser issue[1] i submitted.
Peace,
-
[1] https://github.com/MatzeB/cparser/issues/10
--
Problem repor
Hi,
can someone bump libusb packages to v1.0.20 or HEAD?
FYI, v1.0.20 and HEAD have a compilation issue[1],
was already reported to the upstream, but is not fixed ATM.
Peace,
-
[1] https://github.com/libusb/libusb/issues/104
-
$ cygcheck -c -d libusb1.0 libusb1.0-devel
Cygwin Package Info
Hi,
> done
> https://cygwin.com/ml/cygwin-announce/2015-08/msg4.html
thank you, it just works.
Peace,
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygw
Hi,
can someone update FFTW packages for OpenMP capable?
just adding --enable-openmp on configure, i think.
Peace,
-
hiyuh@lynx ~
$ uname -a
CYGWIN_NT-6.1-WOW lynx 2.1.0(0.287/5/3) 2015-07-14 21:26 i686 Cygwin
hiyuh@lynx ~
$ cygcheck -c -d fftw3 libfftw3-devel
Cygwin Package Information
Pack
Hi,
> The Cygwin project has too many mailing lists.
+1
> I see real value in only 3 lists:
>
> 1. User discussions
> 2. Development of Cygwin-the-project (broader than the DLL)
> 3. Talk
-1
just unify only 1 ML is simple.
the cygwin ML flow looks not so massive.
we know using well compos
Hi,
sorry for METOO(tm) notice.
but check-0.9.10 is totally broken on cygwin.
http://sourceforge.net/p/check/bugs/88/
one of following should apply ASAP IMHO.
* remove 0.9.10 and stick 0.9.8
* remove 0.9.10 and bump 0.9.11 or later
Peace,
2014-04-22 5:41 GMT+09:00 waterlan :
> Chris J. Bre
Hi,
2014-02-14 1:42 GMT+09:00 Urs Janßen :
> Here's a log-entry from a configure (autoconf) script (when looking for
> ncursesw):
>
> configure:9503: clang -c -g -I/usr/lib/gcc/i686-pc-cygwin/4.8.2/include -O0
> -std=c99 -pedantic -W -Wall -Wextra -Wcast-align -D_XOPEN_SOURCE=600
> --I/usr/inclu
> You made it harder than necessary to debug your problem.
>
> If you had created a very small test case which demonstrated the issue
> with clear instructions for building it, then this back and forth
> wouldn't be necessary.
>
> Actually, even that would likely not have been necessary if you had
2014/1/8 Christopher Faylor wrote:
> On Tue, Jan 07, 2014 at 11:35:57AM +0900, KIMURA Masaru wrote:
>>fopen() stackdump file immediately after cygwin_stackdump() calling in
>>signle process fails.
>>is this intentional?
>>https://github.com/hiyuh/cygwin-stackdump-example
Hi,
fopen() stackdump file immediately after cygwin_stackdump() calling in
signle process fails.
is this intentional?
https://github.com/hiyuh/cygwin-stackdump-example
Peace,
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
Hi,
SSIA, anyone can manage this bug?
http://llvm.org/bugs/show_bug.cgi?id=13430
--
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-simp
Hi Marco,
> newlib (and so cygwin) is missing most of the long double functions
> see
>http://cygwin.com/cygwin-api/std-notimpl.html
>
> it is on my TODO list for some time, put personal life took over
> and I was unable to fill yet the gap.
ok, thank you.
Peace,
--
Problem reports: h
Hi,
anyone can reproduce following symptoms?
cygwin does not support some long double math functions?
and no fftw3l available?
Peace,
-
hiyuh@lynx /tmp
$ uname -a
CYGWIN_NT-6.1-WOW64 lynx 1.7.22(0.268/5/3) 2013-07-22 17:06 i686 Cygwin
hiyuh@lynx /tmp
$ gcc -std=gnu11 -Wall -DUSE_FLOAT -DUSE_
Hi,
anyone can reproduce this dvipdfmx bug?
i've already fixed this by replacing rungs to gs in
/usr/share/texmf/dvipdfmx/dvipdfmx.cfg like this:
--- /usr/share/texmf/dvipdfmx/dvipdfmx.cfg.orig 2013-01-26
02:21:56.31250 +0900
+++ /usr/share/texmf/dvipdfmx/dvipdfmx.cfg 2013-01-26
02:22:0
Hi,
2012/2/20 KIMURA Masaru :
> And more Google'ing, I found this post on LLVMdev ML:
>
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2005-June/004364.html
>
> > 2. The LLI test failures occur because the dlsym function on cygwin can
> > only find symbols in a lo
2012/2/20 marco atzeri :
> On 2/19/2012 5:45 PM, KIMURA Masaru wrote:
>>
>> Hmm..., could you mind to try test/run_regr.sh too?
>> I think you can see same error that I wrote my TODO.txt.
>
> how ?
>
> $ test/run_regr.sh all
>> analyze
>> elaborate
&
Hi,
> first some correction/suggestion to your instructions
>
> $ git clone g...@github.com:hiyuh/nvc.git
> $ cd ~/git-repos/nvc
>
> will not work for us. You need to report
>
> $ git clone https://github.com/hiyuh/nvc.git
> $ cd nvc
Right, I noticed after post my message, sorry.
> for lib/i
Hi,
I've posted a question about porting problem a while ago[1].
Now I have another one[2].
As the subject said, I may encounter a llvm's bug but it looks cygwin
related to me.
Anyone can reproduce this error?
If so, I'd like to ask cygwin devs who packaged llvm and upstream llvm
devs about why t
Hi,
2012/2/16 marco atzeri :
> rename local signal.h is effective.
>
> I guess that -I. is influencing the inclusion order with unexpected
> results.
thanks.
and I checked gcc include order on my linux env.
renaming works fine but it's awkward to me.
after more investigation, I realized that:
Hi,
I'm now porting Nick Gasson's nvc[1] to cygwin 1.7.
and i'm stuck a porting problem triggered by gcc include search order[2].
Should I rename local signal.h?
Or, anyone can tell me better way to solve this problem?
Peace,
-
[1] https://github.com/nickg/nvc
[2] https://github.com/hiyuh/nvc
28 matches
Mail list logo
