Re: changes in 32-bit Cygwin OpenGL causing crashes?
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/283#issuecomment-205436971 Peace, -- 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: changes in 32-bit Cygwin OpenGL causing crashes?
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 debuginfo package ATM. maybe, mesa (or something for GLX) is simply broken? Peace, - $ uname -a CYGWIN_NT-10.0-WOW lynx 2.5.1(0.297/5/3) 2016-04-21 22:12 i686 Cygwin $ cygcheck.exe -c dri-drivers mesa mesa-demos xorg-server Cygwin Package Information Package VersionStatus dri-drivers 11.2.2-1 OK mesa 11.2.2-1 OK mesa-demos 8.3.0-1OK xorg-server 1.18.2-1 OK $ glxinfo | grep -e 'Video memory:' Video memory: -113MB $ gdb glxgears ... Reading symbols from glxgears...Reading symbols from /usr/lib/debug//usr/lib/mesa-demos/glxgears.exe.dbg...done. done. (gdb) r Starting program: /usr/bin/glxgears [New Thread 2452.0xc3c] [New Thread 2452.0x2760] [New Thread 2452.0x212c] [New Thread 2452.0x1930] [New Thread 2452.0x207c] [New Thread 2452.0x22e4] [New Thread 2452.0x25dc] [New Thread 2452.0x19ec] Program received signal SIGSEGV, Segmentation fault. 0xfeac00b5 in ?? () (gdb) bt #0 0xfeac00b5 in ?? () #1 0x5e62b977 in gallium_dri!__driDriverGetExtensions_swrast () from C:/cygwin/lib/dri/swrast_dri.so #2 0x5e62bcff in gallium_dri!__driDriverGetExtensions_swrast () from C:/cygwin/lib/dri/swrast_dri.so #3 0x5e54ea9d in gallium_dri!__driDriverGetExtensions_swrast () from C:/cygwin/lib/dri/swrast_dri.so #4 0x5e5477ed in gallium_dri!__driDriverGetExtensions_swrast () from C:/cygwin/lib/dri/swrast_dri.so #5 0x5e547c77 in gallium_dri!__driDriverGetExtensions_swrast () from C:/cygwin/lib/dri/swrast_dri.so #6 0x5e6714d5 in gallium_dri!__driDriverGetExtensions_swrast () from C:/cygwin/lib/dri/swrast_dri.so #7 0x5e3697d0 in gallium_dri!__driDriverGetExtensions_swrast () from C:/cygwin/lib/dri/swrast_dri.so #8 0x5e344ea7 in gallium_dri!__driDriverGetExtensions_swrast () from C:/cygwin/lib/dri/swrast_dri.so #9 0x5e20cf7e in gallium_dri!__driDriverGetExtensions_swrast () from C:/cygwin/lib/dri/swrast_dri.so #10 0x5e220edc in gallium_dri!__driDriverGetExtensions_swrast () from C:/cygwin/lib/dri/swrast_dri.so #11 0x00401396 in draw () at /usr/src/debug/mesa-demos-8.3.0-1/src/xdemos/glxgears.c:264 #12 0x0040315e in draw_gears () at /usr/src/debug/mesa-demos-8.3.0-1/src/xdemos/glxgears.c:316 #13 draw_frame (ctx=0x20052e98, win=14680066, dpy=0x2003c330) at /usr/src/debug/mesa-demos-8.3.0-1/src/xdemos/glxgears.c:341 #14 event_loop (ctx=0x20052e98, win=14680066, dpy=0x2003c330) at /usr/src/debug/mesa-demos-8.3.0-1/src/xdemos/glxgears.c:706 #15 main (argc=1, argv=0x60cc5c) at /usr/src/debug/mesa-demos-8.3.0-1/src/xdemos/glxgears.c:801 (gdb) -- 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: FFTW + OpenMP
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 errors for the latter. I fixed this in 3.3.4-1, which will be > available soon. thx, it looks working! Peace, -- 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: FFTW + OpenMP
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: http://cygwin.com/ml/#unsubscribe-simple
Re: __STRICT_ANSI__ and stdio.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/freebsd/freebsd/blob/master/include/stdio.h >> https://github.com/freebsd/freebsd/blob/master/sys/sys/cdefs.h >> >> it looks very different to newlib's. > > Yes, it does. Newlib has a long history diverging from the BSDs to > support embedded systems in the first place, and compatibility checking > macros other than __STRICT_ANSI__ and __POSIX_SOURCE weren't much of a > concern for a long time. > >> FreeBSD has visibility for popen()/pclose() if __POSIX_VISIBLE >= 199209, >> it looks no checking about __STRICT_ANSI__ in their cdefs.h. > > Yeah, that's history as described above. popen gets declared in newlib > if __STRICT_ANSI__ is not defined right now. > >> only one thing i worried about is _ANSI_SOURCE in their cdefs.h, >> (b/c i don't understand where _ANSI_SOURCE comes from...) >> but it looks _POSIX_C_SOURCE wins anyway. >> for ease to see, i'd attach simplified their cdefs.h for their >> visibility handling. > > I don't see the difference, see below. The big differences in newlib > are the additional handling of _GNU_SOURCE and the old usage of > __STRICT_ANSI__ in some circumstances which haven't been replaced by another > usage of compatibility macros yet. > > But here's the deal: Newlib is a volunteer-driven project. If the > compatiblity checking macros are not correct or not correctly used in > all circumstances, newlib is happily open to patches. Just send them > to the newlib AT sourceware DOT org mailing list. > >> #if defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE == 1 >> #undef _POSIX_C_SOURCE >> #define _POSIX_C_SOURCE 199009 >> #endif > > Same in Newlib's sys/cdefs.h. > > [SNIP] ah, i didn't check newlib's sys/cdefs.h. thank you for correcting my misunderstanding. apart from standard compliance correctness, it's good to hear newlib can deal it. if i had more spare time to dive its source, i'd like to do it. Peace, -- 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: __STRICT_ANSI__ and stdio.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/freebsd/freebsd/blob/master/include/stdio.h https://github.com/freebsd/freebsd/blob/master/sys/sys/cdefs.h it looks very different to newlib's. FreeBSD has visibility for popen()/pclose() if __POSIX_VISIBLE >= 199209, it looks no checking about __STRICT_ANSI__ in their cdefs.h. only one thing i worried about is _ANSI_SOURCE in their cdefs.h, (b/c i don't understand where _ANSI_SOURCE comes from...) but it looks _POSIX_C_SOURCE wins anyway. for ease to see, i'd attach simplified their cdefs.h for their visibility handling. anyway, IIUC, newlib's behavior in regard this point looks not equivalent to FreeBSD's... Peace, #if defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE == 1 #undef _POSIX_C_SOURCE #define _POSIX_C_SOURCE 199009 #endif #if defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE == 2 #undef _POSIX_C_SOURCE #define _POSIX_C_SOURCE 199209 #endif #ifdef _XOPEN_SOURCE #if _XOPEN_SOURCE - 0 >= 700 #define __XSI_VISIBLE 700 #undef _POSIX_C_SOURCE #define _POSIX_C_SOURCE 200809 #elif _XOPEN_SOURCE - 0 >= 600 #define __XSI_VISIBLE 600 #undef _POSIX_C_SOURCE #define _POSIX_C_SOURCE 200112 #elif _XOPEN_SOURCE - 0 >= 500 #define __XSI_VISIBLE 500 #undef _POSIX_C_SOURCE #define _POSIX_C_SOURCE 199506 #endif #endif #if defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE) #define _POSIX_C_SOURCE 198808 #endif #ifdef _POSIX_C_SOURCE #if _POSIX_C_SOURCE >= 200809 #define __POSIX_VISIBLE 200809 #define __ISO_C_VISIBLE 1999 #elif _POSIX_C_SOURCE >= 200112 #define __POSIX_VISIBLE 200112 #define __ISO_C_VISIBLE 1999 #elif _POSIX_C_SOURCE >= 199506 #define __POSIX_VISIBLE 199506 #define __ISO_C_VISIBLE 1990 #elif _POSIX_C_SOURCE >= 199309 #define __POSIX_VISIBLE 199309 #define __ISO_C_VISIBLE 1990 #elif _POSIX_C_SOURCE >= 199209 #define __POSIX_VISIBLE 199209 #define __ISO_C_VISIBLE 1990 #elif _POSIX_C_SOURCE >= 199009 #define __POSIX_VISIBLE 199009 #define __ISO_C_VISIBLE 1990 #else #define __POSIX_VISIBLE 198808 #define __ISO_C_VISIBLE 0 #endif #else #if defined(_ANSI_SOURCE) #define __POSIX_VISIBLE 0 #define __XSI_VISIBLE 0 #define __BSD_VISIBLE 0 #define __ISO_C_VISIBLE 1990 #elif defined(_C99_SOURCE) #define __POSIX_VISIBLE 0 #define __XSI_VISIBLE 0 #define __BSD_VISIBLE 0 #define __ISO_C_VISIBLE 1999 #elif defined(_C11_SOURCE) #define __POSIX_VISIBLE 0 #define __XSI_VISIBLE 0 #define __BSD_VISIBLE 0 #define __ISO_C_VISIBLE 2011 #else #define __POSIX_VISIBLE 200809 #define __XSI_VISIBLE 700 #define __BSD_VISIBLE 1 #define __ISO_C_VISIBLE 2011 #endif #endif -- 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: __STRICT_ANSI__ and stdio.h
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.
>>>
>>
>> Cygwin isn't wrong. __STRICT_ANSI__ doesn't mix with POSIX.
>> __STRICT_ANSI__ definitions is what you should look at for the defined
>> API; not POSIX 1003.1:2001.
>
> then why does glibc look accepting -std=c99 -D_POSIX_C_SOURCE=200809L?
> so you mean linux (maybe glibc?) is wrong and cygwin (maybe newlib?) is right?
>
> w/ attached source that uses popen()/pclose() via gcc -std=c99,
>
> on cygwin (maybe newlib?), i got,
> p.c: In function ‘main’:
> p.c:5:2: warning: implicit declaration of function ‘popen’
> [-Wimplicit-function-declaration]
> FILE *pp = popen("cat", "w");
> ^
> p.c:5:13: warning: initialization makes pointer from integer without a cast
> FILE *pp = popen("cat", "w");
> ^
> p.c:12:3: warning: implicit declaration of function ‘pclose’
> [-Wimplicit-function-declaration]
>int err = pclose(pp);
>^
>
> on linux (maybe glibc?), i got,
> p.c: In function 'main':
> p.c:4:14: warning: unused parameter 'argc' [-Wunused-parameter]
> int main(int argc, char *argv[]) {
> ^
> p.c:4:26: warning: unused parameter 'argv' [-Wunused-parameter]
> int main(int argc, char *argv[]) {
>
> ^ ^
>
> Peace,
#define _POSIX_C_SOURCE 200809L
#include
#include
int main(int argc, char *argv[]) {
FILE *pp = popen("cat", "w");
assert(pp != NULL);
{
int n = fprintf(pp, "foo\n");
assert(n >= 0);
}
{
int err = pclose(pp);
assert(err != -1);
}
return 0;
}
--
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: __STRICT_ANSI__ and stdio.h
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.
> __STRICT_ANSI__ definitions is what you should look at for the defined
> API; not POSIX 1003.1:2001.
then why does glibc look accepting -std=c99 -D_POSIX_C_SOURCE=200809L?
so you mean linux (maybe glibc?) is wrong and cygwin (maybe newlib?) is right?
w/ attached source that uses popen()/pclose() via gcc -std=c99,
on cygwin (maybe newlib?), i got,
p.c: In function ‘main’:
p.c:5:2: warning: implicit declaration of function ‘popen’
[-Wimplicit-function-declaration]
FILE *pp = popen("cat", "w");
^
p.c:5:13: warning: initialization makes pointer from integer without a cast
FILE *pp = popen("cat", "w");
^
p.c:12:3: warning: implicit declaration of function ‘pclose’
[-Wimplicit-function-declaration]
int err = pclose(pp);
^
on linux (maybe glibc?), i got,
p.c: In function 'main':
p.c:4:14: warning: unused parameter 'argc' [-Wunused-parameter]
int main(int argc, char *argv[]) {
^
p.c:4:26: warning: unused parameter 'argv' [-Wunused-parameter]
int main(int argc, char *argv[]) {
^ ^
Peace,
--
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
__STRICT_ANSI__ and stdio.h
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 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
bump libusb packages?
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 Information Package Version libusb1.01.0.19-1 libusb1.0-devel 1.0.19-1 $ cd ~/git-repos $ git clone https://github.com/libusb/libusb.git $ cd libusb $ git log v1.0.19... | grep -e 'Windows:' Windows: Fix potential memory leak Windows: Regenerate libusb-1.0.def file from latest DLL Windows: Fix some build warnings/link issues Windows: Close HID handles when closing composite devices Windows: Remove redundant check in windows_claim_interface() Windows: Destroy autoclaim_lock during cleanup Windows: Check for "calloc" allocation failure. Windows: Remove erroneous call to CloseHandle and add comments Windows: Improve monotonic clock_gettime() implementation Windows: Fix wIndex in setup packet for config descriptor request Windows: Fix broken build caused by missing rename in 63a440f1 Windows: Free all WinUSB handles when closing a device Windows: Direct control requests to a specific interface when possible Windows: fix 2 bugs in windows_handle_events() Windows: Silence VS2013 code analysis warnings Windows: Fix cygwin64 build Windows: Define WINVER to fix building on MinGW -- 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: FFTW + OpenMP
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://cygwin.com/ml/#unsubscribe-simple
FFTW + OpenMP
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 Package Version fftw33.3.4-1 libfftw3-devel 3.3.4-1 hiyuh@lynx ~ $ pkg-config --cflags --libs fftw3 -lfftw3 -lm hiyuh@lynx ~ $ ls -l /usr/lib/libfftw3* -rwxr-xr-x 1 hiyuh None 448850 Apr 13 2014 /usr/lib/libfftw3.dll.a -rwxr-xr-x 1 hiyuh None885 Apr 13 2014 /usr/lib/libfftw3.la -rwxr-xr-x 1 hiyuh None 16652 Apr 13 2014 /usr/lib/libfftw3_threads.dll.a -rwxr-xr-x 1 hiyuh None938 Apr 13 2014 /usr/lib/libfftw3_threads.la -rwxr-xr-x 1 hiyuh None 452876 Apr 13 2014 /usr/lib/libfftw3f.dll.a -rwxr-xr-x 1 hiyuh None889 Apr 13 2014 /usr/lib/libfftw3f.la -rwxr-xr-x 1 hiyuh None 16768 Apr 13 2014 /usr/lib/libfftw3f_threads.dll.a -rwxr-xr-x 1 hiyuh None943 Apr 13 2014 /usr/lib/libfftw3f_threads.la -- 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: Too many mailing lists
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 composed subject can split them in local box. filtering announcement and other unintended info at local is also easy. splitting non-massive flow to many MLs looks totally meaningless. it only help bluffing "our project is big." just my 2 cents. -- 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: Cygwin needs a man-db port
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. Breisch schreef op 2014-04-17 20:32: > >> Erwin Waterlander wrote: >>> >>> Hi, >>> >>> The major linux distributions have switched for their man system to >>> 'man-db' (http://man-db.nongnu.org/) in favour of the classic man. >>> >>> I think that Cygwin should also switch to man-db. man-db is much better >>> in handling man pages in different encoding. >>> >>> Before man-db, libpipeline (http://libpipeline.nongnu.org/) needs to be >>> ported, because man-db uses it. >>> >>> I have tried to port man-db to Cygwin, but I did not succeed. I got >>> stuck in libpipeline. Did anyone else succeed? >>> >> >> Yes. And I agree this is a good idea. >> >> Dependencies: gdbm, libpipeline >> >> Build dependencies: pkgconfig, check, and the typical build stuff >> (make, gcc, etc.) >> >> As I indicated earlier, I believe the current version of check is not >> working properly. >> >> Check-0.9.12 seems to work out-of-the-box. Configure with --prefix=/usr. > > > > Hi Yaakov, > > Would you like to update check to version 0.9.12? > > best regards, > > Erwin > > > >> >> "make check" on check reports all tests passed, despite what appear to >> be some failures. The CHANGELOG says that this version should pass all >> tests on Cygwin. I've just subscribed to the mailing list and will >> check on whether these failures can be ignored or not. Still, it >> definitely appears to work better than the version we have now, which >> only passes 1 test in the test suite. >> >> Libpipeline-1.3.0 seems to work out-of-the-box. Configure with >> --prefix=/usr. >> >> Oddly a "make check" for libpipeline-1.3.0 doesn't appear to actually >> do anything. This was not the case for earlier versions of >> libpipeline. Well, that's one way of getting rid of the test failures, >> I guess. >> >> Man-db-2.6.7 appears to work out-of-the-box. >> >> Configuring man-db is a little harder than the other two. >> >> ../man-db-2.6.7/configure --prefix=/usr --disable-setuid >> --docdir=/usr/share/doc/man-db >> >> If you don't add the --disable-setuid, you'll need to add a "man" user >> to your system. If you're not using Corinna's snapshots, you'll need >> to add the user to /etc/passwd as well. >> >> I'm not sure about the --docdir switch. That seemed to be consistent >> with Cygwin, but an actual package maintainer would be a better source >> of info on this. >> >> A couple of warnings are generated: >> >> *** Warning: This system can not link to static lib archive >> /usr/lib/libpipeline.la. >> *** I have the capability to make that library automatically link in when >> *** you link to this library. But I can only do this if you have a >> *** shared version of the library, which you do not appear to have. >> >> and a similar one for libman.la. >> >> I do have shared versions of these libraries, so I'm not sure why the >> warnings appear. I seem to recall a thread about something similar >> recently in the Cygwin mailing lists. I may go back and check. >> >> Once installed, you'll want to do a 'mandb -c' to create the database. >> It will report numerous warnings which can generally be ignored. See >> the manpage on mandb. This takes a while. >> >> When new packages are added or updated on your system, you should run >> 'mandb -c' again. This seems like something that should be part of >> postinstall. >> >> My 32-bit Cygwin install has a lot of gzipped files and the >> uncompressed versions under /usr/share/man. mandb didn't like that at >> all. That is probably something I did and not a Cygwin problem. >> >> Note that I've done only the most minimal of testing. make check >> passes for man-db and I've opened a few man pages. They seem to work. >> >> Obviously, someone with decision making power should decide if this is >> something we want to add to Cygwin. My vote is yes, but that's just >> one vote. Or maybe even zero. I'm not sure I get a vote. :) >> >> Also obviously, if the decision is to go forward, these three items >> need to be packaged up appropriately and a package maintainer >> assigned. Check is already a Cygwin package, but needs updating. >> >> Somehow I have a feeling about who will be nominated for this task. >> >> What minimal testing I have done has been on both 32-bit and 64-bit >> Cygwin 1.7.29. > > > -- > Erwin Waterlander > http://waterlan.home.xs4all.nl/ > > > -- > 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 > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubs
Re: patch for (clang) problem on Cygwin 1.7.28(0.271/5/3) i686
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/include/ncursesw conftest.c 1>&5
> In file included from configure:9497:
> In file included from /usr/include/ncursesw/curses.h:147:
> In file included from /usr/include/stdio.h:35:
> In file included from /usr/include/sys/cdefs.h:43:
> /usr/include/machine/_default_types.h:28:9: error: unknown type name
> /'__UINT8_TYPE__'
> typedef __UINT8_TYPE__ __uint8_t;
> ^
> /usr/include/machine/_default_types.h:38:9: error: unknown type name
> '__UINT16_TYPE__'
> typedef __UINT16_TYPE__ __uint16_t;
> ^
> /usr/include/machine/_default_types.h:56:9: error: unknown type name
> '__UINT32_TYPE__'
> typedef __UINT32_TYPE__ __uint32_t;
> ^
> /usr/include/machine/_default_types.h:78:9: error: unknown type name
> '__UINT64_TYPE__'
> typedef __UINT64_TYPE__ __uint64_t;
> ^
> configure:9499:12: warning: implicit declaration of function 'tgoto' is
> invalid in C99 [-Wimplicit-function-declaration]
> initscr(); tgoto("?", 0,0)
>^
> 1 warning and 4 errors generated.
> configure: failed program was:
> #line 9496 "configure"
> #include "confdefs.h"
> #include
> int main() {
> initscr(); tgoto("?", 0,0)
> ; return 0; }
>
>
> After applying the attched patch, configure runs as expected. I'm not sure
> if it's the right approach to fix the issue. IIRC the issue was not present
> in cygwin 1.7.27.
SAME HERE(TM)
# im also waiting llvm/clang bump, 3.1 looks too old...
# at least current 3.1-3 packages should be fixed w/ following patch...
# http://sourceforge.net/p/cygwin-ports/mailman/message/31716912/
--
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: about cygwin_stackdump()
> 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 just > provided the error message that you were getting from fopen(). > > i.e., http://cygwin.com/problems.html sorry for bother you about this. > Exporting this function is an ancient mistake but we are stuck with > keeping it around to maintain backwards compatibility. There is > no guarantee that the stackdump you get from this is correct and > we have no plans on augmenting it further. > > That said, however, I've made changes to cause the file handle of > the stackdump file to be closed. It will be in today's snapshot when > it shows up. > > http://cygwin.com/snapshots/ ACK, thanks. -- 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: about cygwin_stackdump()
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
>
> I rewrote your example slightly to make it work with any executable name
> by calculating the stackdump name like this:
>
> char *fname = (char *)malloc(strlen(*__argv) + sizeof (".exe.stackdump"));
> sprintf(fname, "%s.exe.stackdump", *__argv);
> printf("fname = %s\n", fname);
thanks, ill look into this later.
> And compiled it as:
>
> gcc -g -DUSE_CYGWIN_STACKDUMP -DUSE_FORK_WAITPID cygwin_stackdump.c -o
> cygwin_stackdump.exe
>
> That worked fine for me on the most recent Cygwin snapshot: 32/64 bit.
>
> Possibly you have BLODA:
>
> http://cygwin.com/acronyms#BLODA
i may have one of BLODA, but could you mind to recheck followings for me?
* i wrote "signle process" that means w/o fork() + waitpid().
you looks compiling w/ -DUSE_FORK_WAITPID that will use fork() + waitpid().
we are discussing fork() + waitpid() is really required or not.
https://github.com/nickg/nvc/pull/25
* correct following my understanding:
cygwin_stackdump() is in src/winsup/cygwin/exceptions.cc of cygwin.
according to this code,
+ cygwin_exception::dumpstack() opens stack dump file by using
open_stackdumpfile().
there is no configuration for stack dump file name.
+ maximum stack trace depth is 16.
there is no configuration for this depth.
+ after calling cygwin_exception::dumpstack(), cygwin_stackdump() ends.
after printing stack trace contents, cygwin_exception::dumpstack() ends.
thus, cygwin_stackdump() looks having no stack dump file closing.
+ cygwin_stackdump() is exported, but the implementation status looks WIP.
--
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
about cygwin_stackdump()
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: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
making llvm-3.1-4.cygport w/o --enable-shared?
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-simple
Re: tgmath.h and fftw3l
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: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
tgmath.h and fftw3l
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_SWS -O3 -march=native -o preamble preamble.c $(pkg-config --cflags --libs fftw3f) preamble.c: In function ‘main’: preamble.c:86:6: warning: implicit declaration of function ‘csqrtl’ [-Wimplicit-function-declaration] preamble.c:86:19: warning: incompatible implicit declaration of built-in function ‘csqrtl’ [enabled by default] preamble.c:86:6: warning: implicit declaration of function ‘sqrtl’ [-Wimplicit-function-declaration] preamble.c:86:19: warning: incompatible implicit declaration of built-in function ‘sqrtl’ [enabled by default] preamble.c:211:4: warning: implicit declaration of function ‘creall’ [-Wimplicit-function-declaration] preamble.c:211:4: warning: incompatible implicit declaration of built-in function ‘creall’ [enabled by default] preamble.c:212:4: warning: implicit declaration of function ‘cimagl’ [-Wimplicit-function-declaration] preamble.c:212:4: warning: incompatible implicit declaration of built-in function ‘cimagl’ [enabled by default] hiyuh@lynx /tmp $ gcc -std=gnu11 -Wall -DUSE_DOUBLE -DUSE_SWS -O3 -march=native -o preamble preamble.c $(pkg-config --cflags --libs fftw3) preamble.c: In function ‘main’: preamble.c:86:6: warning: implicit declaration of function ‘csqrtl’ [-Wimplicit-function-declaration] preamble.c:86:19: warning: incompatible implicit declaration of built-in function ‘csqrtl’ [enabled by default] preamble.c:86:6: warning: implicit declaration of function ‘sqrtl’ [-Wimplicit-function-declaration] preamble.c:86:19: warning: incompatible implicit declaration of built-in function ‘sqrtl’ [enabled by default] preamble.c:211:4: warning: implicit declaration of function ‘creall’ [-Wimplicit-function-declaration] preamble.c:211:4: warning: incompatible implicit declaration of built-in function ‘creall’ [enabled by default] preamble.c:212:4: warning: implicit declaration of function ‘cimagl’ [-Wimplicit-function-declaration] preamble.c:212:4: warning: incompatible implicit declaration of built-in function ‘cimagl’ [enabled by default] hiyuh@lynx /tmp $ gcc -std=gnu11 -Wall -DUSE_LONG_DOUBLE -DUSE_SWS -O3 -march=native -o preamble preamble.c $(pkg-config --cflags --libs fftw3l) Package fftw3l was not found in the pkg-config search path. Perhaps you should add the directory containing `fftw3l.pc' to the PKG_CONFIG_PATH environment variable No package 'fftw3l' found preamble.c: In function ‘main’: preamble.c:86:6: warning: implicit declaration of function ‘csqrtl’ [-Wimplicit-function-declaration] preamble.c:86:19: warning: incompatible implicit declaration of built-in function ‘csqrtl’ [enabled by default] preamble.c:86:6: warning: implicit declaration of function ‘sqrtl’ [-Wimplicit-function-declaration] preamble.c:86:19: warning: incompatible implicit declaration of built-in function ‘sqrtl’ [enabled by default] preamble.c:211:4: warning: implicit declaration of function ‘creall’ [-Wimplicit-function-declaration] preamble.c:211:4: warning: incompatible implicit declaration of built-in function ‘creall’ [enabled by default] preamble.c:212:4: warning: implicit declaration of function ‘cimagl’ [-Wimplicit-function-declaration] preamble.c:212:4: warning: incompatible implicit declaration of built-in function ‘cimagl’ [enabled by default] /tmp/ccC2hDZs.o:preamble.c:(.text.startup+0x19): undefined reference to `fftwl_malloc' /tmp/ccC2hDZs.o:preamble.c:(.text.startup+0x27): undefined reference to `fftwl_malloc' /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../i686-pc-cygwin/bin/ld: /tmp/ccC2hDZs.o: bad reloc address 0x27 in section `.text.startup' /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../i686-pc-cygwin/bin/ld: final link failed: Invalid operation collect2: error: ld returned 1 exit status #include #include #include #include #include #if defined(USE_LONG_DOUBLE) typedef long double real_t; typedef long double complex complex_t; typedef fftwl_complex fftw_complex_t; typedef fftwl_plan fftw_plan_t; #define MACHINE_EPSILON LDBL_EPSILON #define REAL_C(x) x ## l #define PRIr"Lf" #define SCNr"Lf" #define FFTW_MALLOC(size)fftwl_malloc(size) #define FFTW_PLAN_DFT_1D(n, in, out, sign, flag) fftwl_plan_dft_1d(n, in, out, sign, flag) #define FFTW_EXECUTE(plan) fftwl_execute(plan) #define FFTW_DESTROY_PLAN(plan) fftwl_destroy_plan(plan) #define FFTW_FREE(p) fftwl_free(p) #elif defined(USE_DOUBLE) typedef double real_t; typedef double complex complex_t; typedef fftw_complex fftw_complex_t; typedef fftw_plan fftw_plan_t; #define MACHINE_EPSILON DBL_EPSILON #define REAL_C(x) x #define PRIr"f" #define SCN
dvipdfmx fails to call rungs
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:07.43750 +0900 @@ -149,7 +149,7 @@ %% extant. You can find the one that is active by running: %% kpsewhich -progname=dvipdfmx -format='other text files' dvipdfmx.cfg %% -D "rungs -q -dNOPAUSE -dBATCH -sPAPERSIZE=a0 -sDEVICE=pdfwrite -dCompatibilityLevel=%v -dAutoFilterGrayImages=false -dGrayImageFilter=/FlateEncode -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -sOutputFile='%o' '%i' -c quit" +D "gs -q -dNOPAUSE -dBATCH -sPAPERSIZE=a0 -sDEVICE=pdfwrite -dCompatibilityLevel=%v -dAutoFilterGrayImages=false -dGrayImageFilter=/FlateEncode -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -sOutputFile='%o' '%i' -c quit" %% Frank Siegert's PStill: %D "/usr/local/bin/pstill -c -o '%o' '%i'" this fix is pointed by blog posts by [1] and [2]. or, including rungs properly is the way to fix? Peace, - [1] http://d.hatena.ne.jp/tsntsumi/20120514/DvipdfmxInTexLiveOnCygwinFailed [2] http://d.hatena.ne.jp/tsntsumi/20120515/DvipdfmxInTeXLiveOnCygwinSucceeded -- 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: LLVM ERROR: Program used external function '...' which could not be resolved!
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 loaded DLL. If the symbol is in the .EXE file > > then the symbol doesn't get found. Since LLI links in things like > > printf, strcat, and some other fundamental functions, they don't get > > found on Cygwin. A similar thing happens on MacOS but for a much > > smaller set of files for which we hand code a workaround. The set > > of functions on Cygwin is basically a large fraction of glibc, too > > much to do by hand. > > But this is back in 2005, I don't know this is still correct in 2012, > LLVM-3.0 and Cygwin-1.7. I've tried to build nvc w/ stub DLL, the errors are gone and it works fine. I guess this issue still stands. (maybe upstream WONTFIX?) anyway, thank you to marco for trying help. and sorry for noise again. Peace, -- 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: LLVM ERROR: Program used external function '...' which could not be resolved!
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
>> run
>
> I see no meaningful output, and the test time seems too short
well, only passing "all" to test/run_regr.sh means "analyze, elaborate
and run w/ no unit" atm.
but this is my bad, sorry for no explanation, could you mind to try
them after "make" on top dir?:
$ cd test
$ ./run_regr.sh analyze all
$ ./run_regr.sh elaborate all
$ ./run_regr.sh run all
note, test/run_regr.sh is WIP:
* test/run_regr.sh should run in test dir.
b/c it uses relative path to src/nvc.exe and lib/{std,ieee}.
* if you'd like to check "make check" on top dir again, you should
remove test/work manually which is automatically created by
test/run_regr.sh.
b/c "make check" implicitly expected no test/work for library
functionalities test.
2nd, 3rd command shows you some internal command and log, it looks OK
to me. but I guess 4th command shows you LLVM ERROR like this:
> run
>> run agg1
NVC_LIBPATH=../lib/std:../lib/ieee ../src/nvc -r agg1
LLVM ERROR: Program used external function '_array_copy' which could
not be resolved!
[you can see more internal command and log w/ LLVM ERROR here.]
--
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: LLVM ERROR: Program used external function '...' which could not be resolved!
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/ieee it will be nice to add the download of > the vhdl files in the autogen.sh . Sorry for your bother, but I imagine: * These files have long copyright notice by IEEE. * NVC's author will license it under GPLv3. * Automatically fetch them implicitly includes these file as a part of NVC. * NVC works w/o these files, if design doesn't need them. > About the error, my log reports: > -- > make[2]: Entering directory `/tmp/prova/nvc/test' > Running suite(s): lib > [gc: freed 0 trees; 35 allocated] > 100%: Checks: 3, Failures: 0, Errors: 0 > PASS: test_lib.exe > Running suite(s): ident > 100%: Checks: 9, Failures: 0, Errors: 0 > PASS: test_ident.exe > Running suite(s): parse > 100%: Checks: 19, Failures: 0, Errors: 0 > PASS: test_parse.exe > Running suite(s): sem > 100%: Checks: 16, Failures: 0, Errors: 0 > PASS: test_sem.exe > Running suite(s): simplify > 100%: Checks: 2, Failures: 0, Errors: 0 > PASS: test_simp.exe > Running suite(s): elab > 100%: Checks: 3, Failures: 0, Errors: 0 > PASS: test_elab.exe > Running suite(s): heap > 100%: Checks: 3, Failures: 0, Errors: 0 > PASS: test_heap.exe > ./run_regr.rb:3:in `require': no such file to load -- rubygems (LoadError) > from ./run_regr.rb:3 > FAIL: run_regr.rb > == > 1 of 8 tests failed > - > > So I see that rubygems is missing as expected. > There is none between cygwin packages > > So or you have also installed by yourself rubygems > and it does not work, or your ruby is broken > eventually a rebaseall is neede. Yes, rubygems is not packaged by cygwin. I'll try do a rebaseall you said. > By the way, I noticed that after installing rubygems > and than colorize, "make check" hangs on require > > PASS: test_heap.exe > /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in > `gem_original_require': no such file to load -- getopt/std (LoadError) > from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in > `require' > from ./run_regr.rb:7 > FAIL: run_regr.rb > > > probably the check for std "require" is broken > > > Regards > Marco > > PS: it seems non a problem of llvm at all Hmm..., could you mind to try test/run_regr.sh too? I think you can see same error that I wrote my TODO.txt. 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 loaded DLL. If the symbol is in the .EXE file > then the symbol doesn't get found. Since LLI links in things like > printf, strcat, and some other fundamental functions, they don't get > found on Cygwin. A similar thing happens on MacOS but for a much > smaller set of files for which we hand code a workaround. The set > of functions on Cygwin is basically a large fraction of glibc, too > much to do by hand. But this is back in 2005, I don't know this is still correct in 2012, LLVM-3.0 and Cygwin-1.7. -- 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
LLVM ERROR: Program used external function '...' which could not be resolved!
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 this error is. I'd also attached my current TODO (added .txt for tard gmail's MIME recognizor) for the record. Peace, - [1] http://cygwin.com/ml/cygwin/2012-02/msg00459.html [2] https://github.com/hiyuh/nvc/blob/master/TODO - Fix "make check" failures - On my fork (nickg's also), I can get nvc.exe but "make check" fails. Symptoms of "make check" faiulres look not deterministic, if I use test/run_regr.rb. This problem is caused by fsckin' resident anti-virus software, or? I've tried to disable my anti-virus software, but no joy. I use AVG Internet Security 2012 at this moment. See more detail: $ unmae -a CYGWIN_NT-5.1 jabberwocky 1.7.10(0.259/5/3) 2012-02-05 12:36 i686 Cygwin (LLVM which I used is packaged by official cygwin devs.) $ llvm-config --version 3.0 $ git clone g...@github.com:hiyuh/nvc.git $ cd ~/git-repos/nvc $ ./autogen.sh && ./configure [SNIP] (prepare lib/ieee, see lib/ieee/README.) $ make check [SNIP] make[2]: Entering directory `/home/hiyuh/git-repos/nvc/test' Running suite(s): lib [gc: freed 0 trees; 35 allocated] 100%: Checks: 3, Failures: 0, Errors: 0 PASS: test_lib.exe Running suite(s): ident 100%: Checks: 9, Failures: 0, Errors: 0 PASS: test_ident.exe Running suite(s): parse 100%: Checks: 19, Failures: 0, Errors: 0 PASS: test_parse.exe Running suite(s): sem 100%: Checks: 16, Failures: 0, Errors: 0 PASS: test_sem.exe Running suite(s): simplify 100%: Checks: 2, Failures: 0, Errors: 0 PASS: test_simp.exe Running suite(s): elab 100%: Checks: 3, Failures: 0, Errors: 0 PASS: test_elab.exe Running suite(s): heap 100%: Checks: 3, Failures: 0, Errors: 0 PASS: test_heap.exe wait1 : failed (timeout) assert1 : failed /home/hiyuh/git-repos/nvc/src/nvc -a /home/hiyuh/git-repos/nvc/test/regress/assert1.vhd assign1 : failed (timeout) wait2 : failed (timeout) arith1 : failed /home/hiyuh/git-repos/nvc/src/nvc -a /home/hiyuh/git-repos/nvc/test/regress/arith1.vhd signal1 : failed /home/hiyuh/git-repos/nvc/src/nvc -a /home/hiyuh/git-repos/nvc/test/regress/signal1.vhd /home/hiyuh/git-repos/nvc/src/nvc -e signal1 attr1 : ./run_regr.rb:51:in `kill': Invalid argument (Errno::EINVAL) from ./run_regr.rb:51:in `run_cmd' from ./run_regr.rb:57:in `analyse' from ./run_regr.rb:112 from ./run_regr.rb:109:in `chdir' from ./run_regr.rb:109 from ./run_regr.rb:106:in `each' from ./run_regr.rb:106 FAIL: run_regr.rb == 1 of 8 tests failed Please report to Nick Gasson == Makefile:391: recipe for target `check-TESTS' failed make[2]: *** [check-TESTS] Error 1 make[2]: Leaving directory `/home/hiyuh/git-repos/nvc/test' [SNIP] To be sure, on my fork, I added test/run_regr.sh as a replacement of test/run_regr.rb. Using test/run_regr.sh, analyze and elaborate look OK to me, but run vomits LLVM ERROR for all regressions. LLVM has had similar bug when it was 2.5: http://llvm.org/bugs/show_bug.cgi?id=3897 Just enbug this at 3.0? Or, src/cgen.c requires more trick to get functions from src/rt/rtkern.c on cygwin? See more detail: $ cd test $ ./run_regr.sh analyze all [SNIP] $ ./run_regr.sh elaborate all [SNIP] $ ./run_regr.sh run all > run >> run agg1 NVC_LIBPATH=../lib/std:../lib/ieee ../src/nvc -r agg1 LLVM ERROR: Program used external function '_array_copy' which could not be resolved! >> run agg2 NVC_LIBPATH=../lib/std:../lib/ieee ../src/nvc -r agg2 LLVM ERROR: Program used external function '_array_copy' which could not be resolved! >> run alias1 NVC_LIBPATH=../lib/std:../lib/ieee ../src/nvc -r alias1 LLVM ERROR: Program used external function '_array_copy' which could not be resolved! >> run alias2 NVC_LIBPATH=../lib/std:../lib/ieee ../src/nvc -r alias2 LLVM ERROR: Program used external function '_array_copy' which could not be resolved! >> run arith1 NVC_LIBPATH=../lib/std:../lib/ieee ../src/nvc -r arith1 LLVM ERROR: Program used external function '_sched_process' which could not be resolved! >> run array1 NVC_LIBPATH=../lib/std:../lib/ieee ../src/nvc -r array1 LLVM ERROR: Program used external function '_image' which could not be resolved! >> run assert1 NVC_LIBPATH=../lib/std:../lib/ieee ../src/nvc -r assert1 LLVM ERROR: Program used external function '_sched_process' which could not be resolved! >> run assign1 NVC_LIBPATH=../lib/std:../lib/ieee ../src/nvc -r assign1 LLVM ERROR: Program used external function '_sched_process' which could not be resolve
Re: porting problem triggered by gcc include search order
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: * on cygwin env 1. src/rt/slave.c is coded to #include 2. gcc picks /usr/include/poll.h 3. /usr/include/poll.h is coded to #include 4. gcc picks /usr/include/sys/poll.h 5. /usr/include/sys/poll.h is coded to #include 6. gcc picks src/rt/signal.h, not /usr/include/signal.h b/c -I. * on linux box 1. src/rt/slave.c is coded to #include 2. gcc picks /usr/include/poll.h 3. /usr/include/poll.h is coded to #include 4. gcc picks /usr/include/sys/poll.h 5. /usr/include/sys/poll.h is not coded to #include 6. gcc doesn'y picks src/rt/signal.h, b/c there is no #include even if w/ -I. and I got one of google result: http://www.mingw.org/wiki/IncludePathHOWTO maybe, this can be fixed in nvc itself and not so cygwin-related. sorry for noise. Peace, -- 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
porting problem triggered by gcc include search order
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/blob/port-cygwin/TODO -- 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
