Re: Problem about installing PGI on Cygwin
On 4/2/2020 9:14 AM, Andrew Schulman via Cygwin wrote: >> I tried to install PGI (Linux version) on Cygwin, however, Cygwin told me >> that PGI can only be installed under Linux operator system. So is there any >> method to install PGI on Cygwin? > > What is PGI? Where do you get it? > > -- Cygwin never aimed to be a binary compatible linux emulator. I have run the PGI for windows Of course, Visual Studio compatible tools aren't link compatible with any cygwin tools, other than possibly, if not depending on run time library compatibility, the mingw ones. A few years ago, Lahey attempted to market commercial support for gfortran under cygwin, but I don't think it was successful, beyond implementing some important improvements in gfortran. -- 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: Strange errors running gcc tests on Cygwin
On 3/9/2017 6:51 PM, Brian Inglis wrote: > On 2017-03-09 15:53, Daniel Santos wrote: > >>> If you are running a lot of Cygwin services, cron or Scheduled Tasks, >>> and/or background processes, you may want to look at running cygserver >>> to cache process info and common system info (including SAM/AD). >> I'm only running sshd -- no cron or "at" jobs (except whatever >> Windows installs by its self). However, gcc's make check spawns a LOT >> of processes. > Which was why I suggested it. Even on linux, I don't find it satisfactory to run make check without limiting processes to number of cores. On cygwin and wsl, make check seems to run into deadlocks or at least disastrous timeouts when running multiple processes. With a single process, cygwin runs it more reliably than wsl does. Conversely, sometimes (rarely) wsl can run make check-c and make check-fortran simultaneously. So it takes typically 2 full days to build and make check on cygwin. -- Tim Prince -- 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: [ANNOUNCEMENT] Updated: xorg-server-1.19.0-1 (TEST)
On 11/19/2016 1:49 PM, Ken Brown wrote: > On 11/19/2016 10:50 AM, Tim Prince wrote: >> >> >> On 11/19/2016 9:41 AM, Ken Brown wrote: >>> [Please keep the discussion on the mailing list.] >>> >>> On 11/19/2016 9:19 AM, Tim Prince wrote: >>>> >>>> >>>> On 11/19/2016 8:42 AM, Ken Brown wrote: >>>>> On 11/18/2016 6:52 PM, Tim Prince wrote: >>>>>> >>>>>> >>>>>> On 11/18/2016 2:21 PM, Ken Brown wrote: >>>>>>> On 11/18/2016 1:35 PM, Tim Prince wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 11/18/2016 10:31 AM, Jon Turney wrote: >>>>>>>>> >>>>>>>>> The following packages have been updated in the Cygwin >>>>>>>>> distribution: >>>>>>>>> >>>>>>>>> *** xorg-server-*1.19.0-1 >>>>>>>>> >>>>>>>>> >>>>>>>> I still haven't learned how to make it start on Win8.1 or 10: >>>>>>> [...] >>>>>>>> But I don't see it opening an X display, and the taskbar icon >>>>>>>> disappears >>>>>>>> after a few seconds. May be missing the important user advice. >>>>>>> >>>>>>> Have you looked for the xwin-xdg-icon in your hidden icons? It's a >>>>>>> black C superimposed over a green X. >>>>>>> >>>>>>> Ken >>>>>>> >>>>>> The icon stays up in the hidden icons. but seems to have little use. >>>>> >>>>> Don't you get a menu when you click on it? >>>>> >>>> That menu has the option to shut down xserver or view documentation >>>> but >>>> not to open an xterm. >>> >>> I don't think we're talking about the same icon. The one I referred >>> to is a black C superimposed over a green X, and it has many options >>> to start programs, including XTerm (under System Tools). It's started >>> by the xwin-xdg-icon program, which in turn is started by >>> /etc/X11/xinit/startxwinrc (unless you have a ~/.startxwinrc that >>> overrides it). Does 'ps' show that xwin-xdg-icon is running? >>> >>> >> I have occasionally got the xdg icon from which xterm can be started, >> but I haven't found a reproducible way to bring it up. > > Sorry, but I'm confused now. When you say "xdg icon", are you talking > about the one I described? Your previous message said you've never > seen that icon. Are you now saying that it does appear, but only > occasionally? Do you shut down the X server and retry when it doesn't > appear? > It seems necessary to reboot to get a clean start with no related processes, unless there's a magic cleanup command. I agree it may be necessary to try it from clean start. -- Tim Prince -- 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: [ANNOUNCEMENT] Updated: xorg-server-1.19.0-1 (TEST)
On 11/19/2016 9:41 AM, Ken Brown wrote: > [Please keep the discussion on the mailing list.] > > On 11/19/2016 9:19 AM, Tim Prince wrote: >> >> >> On 11/19/2016 8:42 AM, Ken Brown wrote: >>> On 11/18/2016 6:52 PM, Tim Prince wrote: >>>> >>>> >>>> On 11/18/2016 2:21 PM, Ken Brown wrote: >>>>> On 11/18/2016 1:35 PM, Tim Prince wrote: >>>>>> >>>>>> >>>>>> On 11/18/2016 10:31 AM, Jon Turney wrote: >>>>>>> >>>>>>> The following packages have been updated in the Cygwin >>>>>>> distribution: >>>>>>> >>>>>>> *** xorg-server-*1.19.0-1 >>>>>>> >>>>>>> >>>>>> I still haven't learned how to make it start on Win8.1 or 10: >>>>> [...] >>>>>> But I don't see it opening an X display, and the taskbar icon >>>>>> disappears >>>>>> after a few seconds. May be missing the important user advice. >>>>> >>>>> Have you looked for the xwin-xdg-icon in your hidden icons? It's a >>>>> black C superimposed over a green X. >>>>> >>>>> Ken >>>>> >>>> The icon stays up in the hidden icons. but seems to have little use. >>> >>> Don't you get a menu when you click on it? >>> >> That menu has the option to shut down xserver or view documentation but >> not to open an xterm. > > I don't think we're talking about the same icon. The one I referred > to is a black C superimposed over a green X, and it has many options > to start programs, including XTerm (under System Tools). It's started > by the xwin-xdg-icon program, which in turn is started by > /etc/X11/xinit/startxwinrc (unless you have a ~/.startxwinrc that > overrides it). Does 'ps' show that xwin-xdg-icon is running? > > I have occasionally got the xdg icon from which xterm can be started, but I haven't found a reproducible way to bring it up. -- Tim Prince -- 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: [ANNOUNCEMENT] Updated: xorg-server-1.19.0-1 (TEST)
On 11/19/2016 9:41 AM, Ken Brown wrote: > [Please keep the discussion on the mailing list.] > > On 11/19/2016 9:19 AM, Tim Prince wrote: >> >> >> On 11/19/2016 8:42 AM, Ken Brown wrote: >>> On 11/18/2016 6:52 PM, Tim Prince wrote: >>>> >>>> >>>> On 11/18/2016 2:21 PM, Ken Brown wrote: >>>>> On 11/18/2016 1:35 PM, Tim Prince wrote: >>>>>> >>>>>> >>>>>> On 11/18/2016 10:31 AM, Jon Turney wrote: >>>>>>> >>>>>>> The following packages have been updated in the Cygwin >>>>>>> distribution: >>>>>>> >>>>>>> *** xorg-server-*1.19.0-1 >>>>>>> >>>>>>> >>>>>> I still haven't learned how to make it start on Win8.1 or 10: >>>>> [...] >>>>>> But I don't see it opening an X display, and the taskbar icon >>>>>> disappears >>>>>> after a few seconds. May be missing the important user advice. >>>>> >>>>> Have you looked for the xwin-xdg-icon in your hidden icons? It's a >>>>> black C superimposed over a green X. >>>>> >>>>> Ken >>>>> >>>> The icon stays up in the hidden icons. but seems to have little use. >>> >>> Don't you get a menu when you click on it? >>> >> That menu has the option to shut down xserver or view documentation but >> not to open an xterm. > > I don't think we're talking about the same icon. The one I referred > to is a black C superimposed over a green X, and it has many options > to start programs, including XTerm (under System Tools). It's started > by the xwin-xdg-icon program, which in turn is started by > /etc/X11/xinit/startxwinrc (unless you have a ~/.startxwinrc that > overrides it). Does 'ps' show that xwin-xdg-icon is running? > > Ken > I've never seen that icon. xwin-xdg-menu shows up in ps (mulitiple copies if I keep trying) but not xdg-icon. -- Tim Prince -- 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: [ANNOUNCEMENT] Updated: xorg-server-1.19.0-1 (TEST)
On 11/18/2016 2:21 PM, Ken Brown wrote: > On 11/18/2016 1:35 PM, Tim Prince wrote: >> >> >> On 11/18/2016 10:31 AM, Jon Turney wrote: >>> >>> The following packages have been updated in the Cygwin distribution: >>> >>> *** xorg-server-*1.19.0-1 >>> >>> >> I still haven't learned how to make it start on Win8.1 or 10: > [...] >> But I don't see it opening an X display, and the taskbar icon disappears >> after a few seconds. May be missing the important user advice. > > Have you looked for the xwin-xdg-icon in your hidden icons? It's a > black C superimposed over a green X. > > Ken > The icon stays up in the hidden icons. but seems to have little use. After several more attempts, from the Start Menu Xterm shortcut, I get an icon on the task bar which lasts long enough to click on and open an Xterm. So it looks like it's basically working. Thanks. -- Tim Prince -- 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: [ANNOUNCEMENT] Updated: xorg-server-1.19.0-1 (TEST)
On 11/18/2016 10:31 AM, Jon Turney wrote: > > The following packages have been updated in the Cygwin distribution: > > *** xorg-server-*1.19.0-1 > > I still haven't learned how to make it start on Win8.1 or 10: $ startxwin Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.19.0.0 OS: CYGWIN_NT-6.3 Timlaptop 2.6.0(0.304/5/3) 2016-08-31 14:32 x86_64 OS: Windows 8.1 [Windows NT 6.3 build 9600] (Win64) Package: version 1.19.0-1 built 2016-11-17 XWin was started with the following command line: /usr/bin/XWin :0 -multiwindow -auth /home/Tim/.serverauth.3028 (II) xorg.conf is not supported (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information LoadPreferences: /home/Tim/.XWinrc not found LoadPreferences: /etc/X11/system.XWinrc not found LoadPreferences: See "man XWinrc" to customize the XWin menu. LoadPreferences: Loading built-in default winDetectSupportedEngines - RemoteSession: no winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL winDetectSupportedEngines - Returning, supported engines 0005 winSetEngine - Multi Window or Rootless => ShadowGDI winScreenInit - Using Windows display depth of 32 bits per pixel winAllocateFBShadowGDI - Creating DIB with width: 1920 height: 1080 depth: 32 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll' (II) AIGLX: Testing pixelFormatIndex 1 GL_VERSION: 4.3.0 - Build 10.18.14.4264 GL_VENDOR: Intel GL_RENDERER:Intel(R) HD Graphics 4400 (II) GLX: enabled GLX_SGI_make_current_read (II) GLX: enabled GLX_SGI_swap_control (II) GLX: enabled GLX_MESA_swap_control (II) GLX: enabled GLX_SGIX_pbuffer (II) GLX: enabled GLX_ARB_multisample (II) GLX: enabled GLX_SGIS_multisample (II) GLX: enabled GLX_ARB_fbconfig_float (II) GLX: enabled GLX_EXT_fbconfig_packed_float (II) GLX: enabled GLX_ARB_create_context (II) GLX: enabled GLX_ARB_create_context_profile (II) GLX: enabled GLX_ARB_create_context_robustness (II) GLX: enabled GLX_EXT_create_context_es2_profile (II) GLX: enabled GLX_ARB_framebuffer_sRGB (II) AIGLX: enabled GLX_MESA_copy_sub_buffer (II) 80 pixel formats reported by wglGetPixelFormatAttribivARB (II) 44 fbConfigs (II) ignored pixel formats: 0 not OpenGL, 0 unknown pixel type, 36 unaccelerated (II) GLX: Initialized Win32 native WGL GL provider for screen 0 winPointerWarpCursor - Discarding first warp: 960 540 (--) 3 mouse buttons found (--) Setting autorepeat to delay=500, rate=31 (--) Windows keyboard layout: "0409" (0409) "US", type 4 (--) Found matching XKB configuration "English (USA)" (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none" Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none" winInitMultiWindowWM - DISPLAY=:0.0 winMultiWindowXMsgProc - DISPLAY=:0.0 winInitMultiWindowWM - xcb_connect () returned and successfully opened the display. winProcEstablishConnection - winInitClipboard returned. winClipboardThreadProc - DISPLAY=:0.0 winMultiWindowXMsgProc - xcb_connect() returned and successfully opened the display. Using Composite redirection OS maintains clipboard viewer chain: yes winClipboardProc - XOpenDisplay () returned and successfully opened the display. ______ But I don't see it opening an X display, and the taskbar icon disappears after a few seconds. May be missing the important user advice. --0r 1 Tim Prince -- 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: Advice for debugging heap mismatches? (Win10 Insider build 14926)
On 10/3/2016 2:39 AM, Mark Geisert wrote: Tony Kelman wrote: I see what you've been saying about different insider builds of Windows 10 but I don't think anybody here is beating up on these releases. Win10 anniversary with a single cygwin64 installation is sufficiently difficult for me. Unscheduled Microsoft update reboots, inability to bootstrap gcc (where it works on win8.1)... -- Tim Prince -- 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: Windows Subsystem For Linux
On 8/29/2016 7:15 AM, Ray Donnelly wrote: > On Mon, Aug 29, 2016 at 12:00 PM, Schwarz, Konrad > <konrad.schw...@siemens.com> wrote: >> So I was wondering if the Windows Subsystem For Linux, apparently part of >> Windows 10 Anniversary Update, obsoletes Cygwin. >> > That seems a *little* inflammatory to me. Since Windows Subsystem for > Linux can't inter-operate with Windows very well, no it doesn't. Although the Ubuntu subsystem doesn't provide a current gcc, it's possible to build one now in the Anniversary version. Attempting to run the g++ testsuite hangs the subsystem, requiring a reboot. It is possible to run other individual test suites in parallel in separate bash sessions, unlike under cygwin. I've been wondering whether any conclusions might be drawn from the relative performance of cygwin and linux subsystem. Disk and internet access appear slow in the subsystem, but math functions and OpenMP seem to perform better under linux. As Win10 works on only one of my 3 Windows installations (the oldest box), it doesn't look to be a replacement any time soon. For just one example, the Ubuntu vim isn't nearly as convenient as I've become used to. > Tim Prince -- 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 2.5.0-0.12 questions, vim and nextafterl()
On 4/7/2016 8:31 AM, Corinna Vinschen wrote:
> On Apr 7 05:25, Tim Prince wrote:
>>
>> On 4/6/2016 1:31 PM, Corinna Vinschen wrote:
>>> On Apr 6 13:07, Tim Prince wrote:
>>>> 1) vim usually hangs if run under bash, but works fine under mintty
>>>> (same in previous snapshot)
>>> There's a patch in git master which seems to fix this problem. I'll
>>> release a 0.13 RSN.
>>>
>>>> 2) gcc testsuite cases which attempt to link nextafterl() have continued
>>>> failing as before.
>>> Did you update the cygwin-devel package as well? This:
>>>
>>> #include
>>>
>>> int
>>> main ()
>>> {
>>> nextafterl (1.0L, 2.0L);
>>> }
>>>
>>> works with cygwin-devel-2.5.0-0.12.
>>>
>>>
>>> Corinna
>>>
>> vim is working well now. Thanks.
> Good to know, thanks.
>
>> You were right about cygwin-devel, but it appears to require a full
>> rebuild of gcc, so that will be another 2 days to build and run test
>> suite. Wouldn't it be great if make check parallel could work on cygwin?
> I can't interpret the last sentence. `make -jX' works on Cygwin.
> Is that what you mean?
>
>
> Corinna
In my experience, running multiple threads in make check by make -j 2
results in the individual sessions make check-c, make check-c++ ...
crashing and restarting endlessly. Even when I run make -k check-c
,check-c++, check-fortran in separate bash windows, they usually die
before completion. I haven't tried for a while.
--
Tim Prince
--
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 2.5.0-0.12 questions, vim and nextafterl()
On 4/6/2016 1:31 PM, Corinna Vinschen wrote:
> On Apr 6 13:07, Tim Prince wrote:
>> 1) vim usually hangs if run under bash, but works fine under mintty
>> (same in previous snapshot)
> There's a patch in git master which seems to fix this problem. I'll
> release a 0.13 RSN.
>
>> 2) gcc testsuite cases which attempt to link nextafterl() have continued
>> failing as before.
> Did you update the cygwin-devel package as well? This:
>
> #include
>
> int
> main ()
> {
> nextafterl (1.0L, 2.0L);
> }
>
> works with cygwin-devel-2.5.0-0.12.
>
>
> Corinna
>
vim is working well now. Thanks.
You were right about cygwin-devel, but it appears to require a full
rebuild of gcc, so that will be another 2 days to build and run test
suite. Wouldn't it be great if make check parallel could work on cygwin?
--
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
cygwin 2.5.0-0.12 questions, vim and nextafterl()
1) vim usually hangs if run under bash, but works fine under mintty (same in previous snapshot) 2) gcc testsuite cases which attempt to link nextafterl() have continued failing as before. -- 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: missing libcilkrts.spec
On 2/20/2016 8:55 AM, Achim Gratz wrote: > Tim Prince writes: >> libcilkrts.spec > The package search says it is in gcc-cilkplus-5.3.0-2: > https://cygwin.com/cgi-bin2/package-grep.cgi?grep=libcilkrts.spec=x86_64 > > > Regards, > Achim. Yes, the gcc-cilkplus selection works, and allows execution to start, and a few cases run correctly. There are too many additional problems to proceed. I'm trying a gcc trunk build with enable-cilkrts so as to see if any gcc testsuite cases will run. -- Tim Prince -- 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
missing libcilkrts.spec
After putting in 6 cases of #if __INTEL_COMPILER ... cilkplus code #else plain C code #endif to avoid cilkplus internal errors, at link time I get $ gcc -fcilkplus -fopenmp -g3 -gdwarf-2 -o lcd_cean mains.o loopscean.o f90_cputime.o -Wl,--stack,9 -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: /cygdrive/i/szsz/tmpp/gcc/gcc-5.3.0-2.x86_64/src/gcc-5.3.0/conf igure --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-5.3.0-2.x86_64/src/gcc-5.3.0 --pref ix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/ share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --ho st=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --withou t-libintl-prefix --libexecdir=/usr/lib --enable-shared --enable-shared-libgcc -- enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable -__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=ada,c,c++,for tran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomi c --enable-libcilkrts --enable-libgomp --enable-libitm --enable-libquadmath --en able-libquadmath-support --enable-libssp --enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --w ith-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-l ibiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build -id --with-default-libstdcxx-abi=gcc4-compatible Thread model: posix gcc version 5.3.0 (GCC) COMPILER_PATH=/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/:/usr/lib/gcc/x86_64-pc-cygwin /5.3.0/:/usr/lib/gcc/x86_64-pc-cygwin/:/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/:/usr /lib/gcc/x86_64-pc-cygwin/:/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/../../../../x86_6 4-pc-cygwin/bin/ LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/:/usr/lib/gcc/x86_64-pc-cygwin/ 5.3.0/../../../../x86_64-pc-cygwin/lib/../lib/:/usr/lib/gcc/x86_64-pc-cygwin/5.3 .0/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-cygwin/ 5.3.0/../../../../x86_64-pc-cygwin/lib/:/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/../. ./../:/lib/:/usr/lib/ Reading specs from /usr/lib/gcc/x86_64-pc-cygwin/5.3.0/libgomp.spec Reading specs from libcilkrts.spec gcc: error: libcilkrts.spec: No such file or directory libcilkrts was not installed automatically with the gcc upgrade, but even after I selected it in the setup-x86_64 menu, it is still missing. -- 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: redistributing a part of cygwin
On 2/4/2016 8:59 AM, Fabio wrote: > Hi, > > we have compiled a parallel program for Windows using cygwin. > In order to make the program work on any computer we have to include > in the package some parts of cygwin (some .dll and some .exe). > > Since we want to distribute our package and make it freely available > for downloading from our website, which requirements do we need to > fulfil to respect cygwin licence? > Can we redistribute some cygwin files in our package? > > Thank you, > > Fabio and Chiara > > Right at the top of https://cygwin.com/licensing.html there are requirements about distributing sources both for the cygwin and you own bits, if I understand it. -- Tim Prince -- 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: gfortran segfaults on "Hello world"
On 11/18/2015 5:26 PM, Thomas Koenig wrote: Hi, gfortran appears to be broken (segfault) with the newest cygwin version I just downloaded. It segfaults on a "Hello, world" program. gcc works fine. The warnings on the GMP and MPFR headers make me suspect that some dependency may be broken. Here's what happens: $ gfortran.exe hello.f : internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. $ which gfortran /usr/bin/gfortran $ ldd /usr/lib/gcc/x86_64-pc-cygwin/4.9.3/f951.exe ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7ff96d54) KERNEL32.DLL => /cygdrive/c/Windows/system32/KERNEL32.DLL (0x7ff96b8d) KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll (0x7ff96a76) cygcloog-isl-4.dll => /usr/bin/cygcloog-isl-4.dll (0x3fc70) cygwin1.dll => /usr/bin/cygwin1.dll (0x18004) cyggmp-10.dll => /usr/bin/cyggmp-10.dll (0x3fb61) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3fa2f) cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3f69d) cygisl-10.dll => /usr/bin/cygisl-10.dll (0x3f68e) cygmpc-3.dll => /usr/bin/cygmpc-3.dll (0x3f63f) cygmpfr-4.dll => /usr/bin/cygmpfr-4.dll (0x3f639) cygz.dll => /usr/bin/cygz.dll (0x3f493) cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3fbc5) $ gfortran -v hello.f Driving: gfortran -v hello.f -l gfortran -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: /cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.x86_64/src/gcc-4.9.3/configure --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.x86_64/src/gcc-4.9.3 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id Thread model: posix gcc version 4.9.3 (GCC) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-cygwin/4.9.3/f951.exe hello.f -ffixed-form -quiet -dumpbase hello.f -mtune=generic -march=x86-64 -auxbase hello -version -fintrinsic-modules-path /usr/lib/gcc/x86_64-pc-cygwin/4.9.3/finclude -o /tmp/ccsadurw.s GNU Fortran (GCC) version 4.9.3 (x86_64-pc-cygwin) compiled by GNU C version 4.9.3, GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.3 warning: GMP header version 6.0.0 differs from library version 6.1.0. warning: MPFR header version 3.1.2-p11 differs from library version 3.1.3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.9.3 (x86_64-pc-cygwin) compiled by GNU C version 4.9.3, GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.3 warning: GMP header version 6.0.0 differs from library version 6.1.0. warning: MPFR header version 3.1.2-p11 differs from library version 3.1.3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 : internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Any ideas? upgrade gmp and mpfr to current versions. I prefer the gfortran 5.2 binary, or a 6.0 bootstrapped from 5.2, all using those current cygwin gmp and mpfr releases. -- Tim Prince -- 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 32bit: Can't use gcc -mfpmath=sse
On 9/11/2015 8:03 AM, HK wrote: > On Fri, 11 Sep 2015 10:16:56 +0200, Evgeny Grin <k...@yandex.ru> wrote: > >> 10.09.2015, 23:52, "HK" <hk1...@t-online.de>: >>> On Thu, 10 Sep 2015 13:19:04 +0200, V?clav_Haisman wrote: >>>> On 10 September 2015 at 01:30, HK wrote: >>>>> hello.c:1:0: warning: SSE instruction set disabled, using 387 >>>>> arithmetics >>>> >>>> Does it help to use `-march=native`? My hunch is that this is because >>>> the default CPU type is set to such that does not have SSE. >>> >>> Yep, that did the trick. Thanks for the suggestion. Now, is this a gcc >>> build >>> build problem? The 64bit version doesn't need -march=native and that >>> is on >>> the same computer. >> >> It's not a problem as by default GCC generate code compatible with >> maximum number of CPU models. >> If you need to generate an SSE instructions, you have to use at lest >> -march=pentium3. >> For x86-64 version, SSE is always enabled as all x86-64 CPUs support >> SSE and SSE2. >> See http://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#x86-Options > > Thanks. While I don't quite agree with the choice of defaults it makes > sense. > So does my 32bit window next to the 64bit window on the same computer > really > have a different instruction set? Anyway, case closed. Intel compilers made SSE2 the default even for 32-bit mode, subsequent to all CPUs which supported 387 but not SSE3 going out of production. There's still a lot of interest in 387 mode, however. You might argue for making SSE3 the default, but it's generally important nowadays to set an appropriate option for the target platforms. -- Tim Prince -- 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: From Microsoft: Windows 10 Console and Cygwin
On 4/29/2015 3:01 PM, Rich Eizenhoefer wrote: Hi, I'm the Program Manager at Microsoft for the updated Windows 10 console. I searched the Cygwin FAQ and mailing list archives for issues related to Windows 10 and found an item about multiple windows which should already be fixed. We have received a couple reports about crashes when running on Windows 10 with the new console enabled. For example: cygwin is dying when i run a bunch of the git tools. For example: grep -rin log .\ 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x6857, RegionSize 0x3A, State 0x1 C:\Program Files (x86)\Git\bin\grep.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0 Please let me know if there are other problems you are experiencing with the W10 console that are a regression from previous versions. We are a small team, but we want to help where possible to ensure that Cygwin continues to run well in Windows 10. Thanks, Rich -- Windows 10 has given me satisfactory results with cygwin64 (although I'm more likely to run git under 8.1). This is a welcome change from the days when Microsoft personnel stated that bugs reported primarily by cygwin users would not be fixed even when they could be reproduced outside cygwin. -- Tim Prince -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.8
On 11/7/2014 4:11 AM, Corinna Vinschen wrote: - GCC 4.9.2-1 DLLs accidentally call __cxa_atexit with the wrong DSO handle value. This Cygwin update allows this scenario throughout. It now understands *any* DSO handle value, as long as it's a pointer into the DSO's address space. This fixes: https://cygwin.com/ml/cygwin/2014-11/msg00122.html If you don't build applications or DLLs with Cygwin, you can safely ignore this change. If you want to help testing this new release (which I seriously hope for), you can find it in your setup-x86.exe or setup-x86_64.exe as test release. I take it from now on it should be OK to take the default for __cxa_atexit when configuring to build gcc. Thanks for explanation. I'm repeating some tests with 1.7.33-0.8 and gcc/gfortran 4.9.2-1 no surprises, thanks (following segfault apparently unchanged, running with AV and Defender disabled, but failure not seen with gfortran 5.0): Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: 1181925 [main] profile_omp 3684 fixup_mmaps_after_fork: ReadProcessMemory failed for MAP_PRIVATE address 0x6FE5FC6, Win32 error 998 2248013 [main] profile_omp 3684 C:\users\tim\tim\tim\src\campbell\Profile_send_3 Nov14\profile_omp.exe: *** fatal error in forked process - recreate_mmaps_after_ fork_failed 3891395 [main] profile_omp 3684 cygwin_exception::open_stackdumpfile: Dumping st ack trace to profile_omp.exe.stackdump 6 [main] profile_omp 1992 fork: child -1 - forked process 3684 died unexpe ctedly, retry 0, exit code 0x100, errno 11 11849 [main] profile_omp 1992 cygwin_exception::open_stackdumpfile: Dumping st ack trace to profile_omp.exe.stackdump -- Tim Prince -- 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
gfortran 4.9.2-1
My own benchmarks work fine (gcc/g++ also). In John Campbell's test, among 5 run-time failures, there is (twice): Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: 1 [main] profile_omp 5664 fixup_mmaps_after_fork: ReadProcessMemory failed for MAP_PRIVATE address 0x6FE5FC6, Win32 error 998 357 [main] profile_omp 5664 C:\users\tim\tim\tim\src\campbell\Profile_send_3 Nov14\profile_omp.exe: *** fatal error in forked process - recreate_mmaps_after_fork_failed 690131 [main] profile_omp 5664 cygwin_exception::open_stackdumpfile: Dumping stack trace to profile_omp.exe.stackdump 3 [main] profile_omp 4644 fork: child -1 - forked process 5664 died unexpectedly, retry 0, exit code 0x100, errno 11 28628 [main] profile_omp 4644 cygwin_exception::open_stackdumpfile: Dumping stack trace to profile_omp.exe.stackdump In spite of the remaining failures, it looks like progress. As I'm lazy, I'll continue using gcc-5.0 trunk builds unless there is interest (suggestion what should be done) in this one. I guess this 4.9.2-1 is more aggressive with build options than I've been able to make work. -- Tim Prince -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.4
On 10/29/2014 1:37 PM, Denis Excoffier wrote: On 2014-10-29 13:08, Corinna Vinschen wrote: I just released a 4th TEST version of the next upcoming Cygwin release, 1.7.33-0.4. Changes compared to the former test version 1.7.33-0.3: -0.3 has come up on the nearby mirror. I'm updating gcc trunk from svn, starting a rebuild of gcc/g++/gfortran -- Tim Prince -- 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: ShellShock and Latest Version Problem
On 10/4/2014 6:56 PM, René Berber wrote: On 10/4/2014 4:38 PM, Dennis Putnam wrote: On 10/4/2014 4:38 PM, René Berber wrote: On 10/4/2014 2:55 PM, Dennis Putnam wrote: According to the cygwin web site the latest version that contains the shellshock patch is 1.7.32. I ran setup-x86_64.exe to get the latest patches but I wind up with version 1.7.16 and nothing later is found. My cygwin test indicates it is still vulnerable. How do I get 1.7.32 if not through setup? TIA. Shellshock is related to the bash version, not the Cygwin version. If you updated Cygwin and think you still have an older version (of Cygwin), that probably means that you didn't stop all processes that use the Cygwin dll. Updating Bash doesn't affect, or depend, on the Cygwin dll. Thanks for the reply. I assumed that since bash was part of basic Cygin, if I updated everything, bash would be included. I had Cygwin completely down when I updated with setup. Why did I not get the latest bash with the other updates? How to I get the right version of bash other than with setup? Use setup. Don't assume it doesn't work, it does work fine. Check the version available shown in setup, it its not (as of today) 4.1.16 then the _mirror_ you are using is stale (which would explain why you didn't get the latest version of Cygwin). Slightly off topic, I tend to put off updating from setup due to the default of rolling gcc back to an earlier (buggier, in my tests) version. There are about 6 selections which have to be set to Keep to avoid breaking it. -- Tim Prince -- 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: suggestion about math.h
On 8/7/2014 1:41 PM, Denis Excoffier wrote: Hello, Perhaps the values of some constants are not as accurate as they should be? See also M_LN2LO and M_LN2HI. diff -uNr cygwin-snapshot-20140807-1-original/newlib/libc/include/math.h cygwin-snapshot-20140807-1-patched/newlib/libc/include/math.h --- cygwin-snapshot-20140807-1-original/newlib/libc/include/math.h 2014-08-07 18:26:21.0 +0200 +++ cygwin-snapshot-20140807-1-patched/newlib/libc/include/math.h 2014-08-07 19:31:51.0 +0200 @@ -569,14 +569,14 @@ #ifndef __STRICT_ANSI__ #define M_TWOPI (M_PI * 2.0) -#define M_3PI_42.3561944901923448370E0 -#define M_SQRTPI1.77245385090551602792981 +#define M_3PI_42.3561944901923449288E0 +#define M_SQRTPI1.77245385090551602729817 #define M_LN2LO 1.9082149292705877000E-10 #define M_LN2HI 6.9314718036912381649E-1 -#define M_SQRT31.73205080756887719000 +#define M_SQRT31.73205080756887729353 #define M_IVLN100.43429448190325182765 /* 1 / log(10) */ #define M_LOG2_E_M_LN2 -#define M_INVLN21.4426950408889633870E0 /* 1 / log(2) */ +#define M_INVLN21.4426950408889634074E0 /* 1 / log(2) */ /* Global control over fdlibm error handling. */ Without the L suffix, it doesn't look like it matters. I just noticed this week the M_LN2LO and HI. They should add up to a long double accurate constant. I've been using a similar pair in implementation of exp() for 20 years. -- 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
gcc-4.9 option
Excellent, once I realized that all the component updates must be selected individually on the setup menu (no automatic dependency resolution). -- 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: [ANNOUNCEMENT] Updated: gcc-4.9.0-1 experimental (x86_64)
On 5/18/2014 10:13 AM, JonY wrote: gcc-4.9.0-1 for 64-bit Cygwin is now uploaded as experimental, no serious testing has been done yet, you may use it for not-so-important work. I'm not having much luck with this, on OpenMP source code which was working with 4.9 native Cygwin builds I made myself. 4.9 should work (at -O2, even with gfortran at -O3) much more reliably than 4.8 when avx2 option is set. -- Tim Prince -- 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: configure errors for xclock
On 5/9/2014 11:22 AM, Philip Schneider wrote: Greetings - Very long-time X user/programmer, complete n00b using it in cygwin… I have what should be an up-to-date cygwin install on a Windows 7 box. Used the setup application to retrieve the source code for xclock (tried both the 6 and 7 versions). Trying to run “configure”, I get errors: No package ‘xaw7’ found No package ‘xmu’ found http://x.cygwin.com/docs/ug/setup-cygwin-x-installing.html installing xinit should have installed xclock and all its dependencies. -- Tim Prince -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Issues with Cygwin on Windows 8.1
On 5/7/2014 10:11 PM, Dato wrote: I just set up Cygwin for x86 on my Windows 8.1 (64-bit) machine, and have been seeing the following issues: ... 2. When invoking python, I don't get the python's prompt back: datod_000@Q9450 ~/sandbox $ which python /usr/bin/python datod_000@Q9450 ~/sandbox $ python It basically just hangs there. I have to ^C to get the shell prompt back. I've run python without seeing such problems. Outgoing scp completes the transfer but requires follow-up by ctrl-C or it will require closing the shell. Incoming scp doesn't exhibit this problem. Delays in returning to shell prompt after running a .exe built under cygwin (thus requiring several cygwin dlls) seemed to be caused partly by spyware and anti-spyware activity. Win8.x seems to be spyware playground (some of that came pre-installed by Acer). -- Tim Prince -- 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: 64-bit vs. 32-bit
On 4/25/2014 1:38 PM, Christopher Faylor wrote: On Fri, Apr 25, 2014 at 01:26:22PM -0400, Tom Szczesny wrote: I have a 64-bit Windows laptop, and installed Cygwin several years ago. I wish to verify that I did install the 64-bit installation. I get the following results: cygcheck -V cygcheck (cygwin) 1.7.15 uname CYGWIN_NT-6.1-WOW64 If I did install the 64-bit version, when I rebuild my Linux app on Cygwin, do I automatically get a 64-bit executable (that will not run on a 32-bit Windows computer)? 1) No, you didn't install a 64-bit version of Cygwin. uname -a should make that clear. You'll need to instal a 64-bit version if that's what you want. 2) Cygwin doesn't build Linux apps. If you have a cross-compiler then it won't automatically decide to build 64-bit Linux apps because you are on a 64-bit sytem. There are cygwin 64- and 32-bit native compilers and mingw 32- and 64-bit compilers on the setup.exe menu in case you mean to build for one of those targets. -- Tim Prince -- 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 kill utility //Was: cgwin_internal(): difference b/w CW_CYGWIN_PID_TO_WINPID and CW_GETPINFO_FULL for taking only dwProcessId ?
On 4/8/2014 11:21 AM, Christopher Faylor wrote: Non-sarcastic translation: Don't expect us to know about your s**t. We have standard expectations for this free software project and the expectations are do not include keeping a mental map of the rules of every email domain that sends messages here so that we can avoid asking for a patch. I'm with Corinna in wondering how you can use GPLed software at all if you are so limited. Now that I'm retired, if I thought there were any point in figuring out why gcc test suite fails to kill the hung tests, I'd be happy to send any patch. This comment appears to imply there is no point. Meanwhile, I go to Windows task manager and kill them manually, so they report XPASS. My former employer permitted only employees with a job description including support of open source software to submit patches, even though we all had to take the annual quiz about GPL etc. That employer has products which run under cygwin bash (not linked against cygwin1.dll), some so intended, more of them not. -- Tim Prince -- 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: Some Problems about gcc 4.8.2 on cygwin
On 3/14/2014 8:42 AM, rexdf Rexdf wrote: 2.It's about OpenMP elided stuff which doesn't quote legibly Is there a cygwin related question here? Questions on OpenMP and clock() might be tolerated on gcc-help. Advice on how to make meaningful benchmarks is definitely off topic. With cygwin g++ 4.9 at -O or -O3 on win8.1 I get time: 0 as evidently the compiler can shortcut your test loop (is that what you wished?). For the -O0 -fopenmp build, time: 2484(1 thread) time: 2547(2 threads) time: 2828(3 t) time: 3187(4 t) Much as would be expected, as you are asking for the total time spent among all threads (usual interpretation of clock()). The bash time command shows real time decreasing with number of threads (close to total clock time divided by number of threads). OpenMP provides the function omp_get_wtime() for performance measurement (possibly a wrapper for gettimeofday()). The cygwin library evidently doesn't treat clock() as equivalent to omp_get_wtime(). Speculation on how you could find a non-cygwin library which treats them as equivalent is probably off topic here. Anyway, I think your problem is not with the cygwin gcc, unless you are looking for the more aggressive optimization of version 4.9. -- Tim Prince -- 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: g77 on cygwin64
On 2/12/2014 12:59 PM, David Conrad wrote: On Wed, Feb 12, 2014 at 12:16 PM, Andrey Repin wrote: The strange thing is that gfortran does compile the code, but once compiled, the executables have strange behavior mainly involving problems reading in data files. ... And this is finally the information, that we can work with. My wild guess is that your colleagues making certain assumptions about files, that not always true on other systems. I.e. opening a file in text mode, and then treating [its] data as binary ... Since the problem occurs going from 32-bit to 64-bit Cygwin, it sounds to me like all-the-world's-a-VAX syndrome. I bet there are places where it reads from files and assumes that if it reads N words into integers, that is N 32-bit quantities, or something like t:hat. I haven't written any Fortran since the 1980s, but I bet there are types that have changed size due to the switch to 64-bit and that results in reading incorrect values from files, including reading some of them from the wrong file offsets, and hitting end-of-file at a different point. Are there any switches to gfortran that control this? ifort still has switches for selecting the VAX convention of measuring RECL in 32-bit words vs. the f2003 recommended convention of byte size. gfortran (and afaik g77) used byte lengths only. Note that 32-bit g77 unformatted direct access files were never intended to work with any 64-bit mode compiler (not even the buggy 64-bit g77) and can't be expected to work with gfortran (you would need to make those data files from scratch): http://gcc.gnu.org/onlinedocs/gcc-3.4.4/g77/Portable-Unformatted-Files.html Also important is the point made above that g77 may have allowed indiscriminate switching between formatted and unformatted or direct and sequential access files, or read after write, but the run-time errors should shed light on that, and you would need to watch for unsuspected problems if g77 let it through. -- Tim Prince -- 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: Is there someone who have a same problem ?
On 1/22/2014 3:35 AM, kou1okada wrote:
2014/1/22 Yaakov (Cygwin/X) yselkow...@users.sourceforge.net:
On 2014-01-21 22:18, kou1okada wrote:
If you are using the cygwin64 under the Windows 8, please check a
following command sequence and please tell me a result.
#--
uname -srvmp
cygcheck -c | grep ca-certificates
ls -lnG /etc/setup/ca-certificates.lst.gz
find /etc/pki/ca-trust/extracted/ -mindepth 1 -type f -not -iname
README -exec ls -lnG {} +
wget -O /dev/null https://google.com
#--
$ uname -srvmp
CYGWIN_NT-6.3 1.7.27(0.271/5/3) 2013-12-09 11:54 x86_64 unknown
...
$ wget -O /dev/null https://google.com
--2014-01-22 07:10:00-- https://google.com/
Resolving google.com... 2607:f8b0:4009:804::1006, 74.125.225.7,
74.125.225.8, ..
.
Connecting to google.com|2607:f8b0:4009:804::1006|:443... failed:
Connection tim
ed out.
Connecting to google.com|74.125.225.7|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.google.com/ [following]
--2014-01-22 07:10:21-- https://www.google.com/
Resolving www.google.com... 2607:f8b0:4009:802::1014, 74.125.225.112,
74.125.225
.113, ...
Connecting to www.google.com|2607:f8b0:4009:802::1014|:443... failed:
Connection
timed out.
Connecting to www.google.com|74.125.225.112|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `/dev/null'
[ = ] 10,876 --.-K/s in 0.001s
2014-01-22 07:10:42 (9.74 MB/s) - `/dev/null' saved [10876]
--
Tim Prince
--
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: cannot execute binary file
On 12/17/2013 4:32 AM, Andrey Repin wrote: Greetings, Gerry Reno! I just got finished installing Cygwin on another machine and this time the -c does work. So I went back and looked at the original machine. There are 2 cygwin installations on that machine in different directories. I had forgotten that Cygwin got installed a while back on this machine to support some app that needed it. So somehow having 2 different installations breaks this mintty -e capability. Does this qualify as a bug? Is Cygwin supporting 2 independent installations? It do support two _independent_ installations. This means, each of them have no way to find out about existence of the other, barring the full disk search. Yours were not that independent. Likely, them both were listed in $PATH. This thread reminded me that I faced the similar problem. Being lazy and not figuring out how to include the path to cygwin1.dll when running Intel VTune profiler, I copied the .dll to the existing PATH, thus breaking the installation when next running setup. -- Tim Prince -- 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
cygwin1.dll update
1.27.7 from sourceware mirror not working with gcc nor gfortran for me. Tried 3 closer mirrors first which delivered the previous bad version. -- Tim Prince -- 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 1.7.26-1 causes Too many open files error in squid
On 12/4/2013 2:28 PM, Scuzuliak wrote: I'm running squid on cygwin64 under Windows 7. All packages on my system are at the latest versions. After upgrading the cygwin package to 1.7.26-1, I started getting errors in squid which causes it to abort. Rolling the cygwin package back to 1.7.25-1 resolves the issue. I was able to resume use of gcc and gfortran after similar rollback. The update produced immediate segfault on the most trivial test compilation cases. -- Tim Prince -- 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: compress / ncompress package for Cygwin
On 08/23/2013 10:11 AM, Hubert Garavel wrote: Contrary to most Unix-like operating systems, Cygwin does not have the /bin/compress command installed by default and has no package to install it on demand. Cygwin has an uncompress command (that relies on gunzip), but no compress command to make genuine .Z files. This would be certainly easy to solve, using the work of the Ncompress project at http://ncompress.sourceforge.net/ My experience is that the code of ncompress-4.2.4.4 compiled perfectly using a GCC 3 cross-compiler targeted to Mingw: $CC_WIN32-gcc -DDOS -D_IBMR2 compress42.c -o compress.exe It is likely that compiling with Cygwin would be even easier. Interesting reading about how compress returned to public domain 9 years ago after being restricted in in various ways for 20 years (and there remain some hidden restrictions). I think it's an exaggeration to say most unix-like systems ignored those restrictions. -- Tim Prince -- 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: An issue with Matlab for a mex file compiled with GNU CYGWIN g++
On 6/30/2013 10:27 PM, Emad Gad wrote: Is there a way to make the CYGWIN g++ linker choose the Windows 64 bit system libraries instead of the 32 bit? cygwin64. If you mean to link against Microsoft X64 libraries in place of cygwin ones, x86_64-w64-mingw32. -- Tim Prince -- 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: What is a good profiling tool ? - problem with gprof
On 06/17/2013 12:19 PM, J.B.W.Webber wrote:
Hi, I am trying to find in which function call the most time is being spent.
I am using gcc and trying to compile and link with -g and -pg.
i.e. for a trivial test :
$ cat helloworld.c
/* Hello World program */
#includestdio.h
main()
{
printf(Hello World\n);
}
$ gcc -g -pg -c helloworld.c
$ gcc -pg helloworld.o
helloworld.o: In function `main':
helloworld.c:6: undefined reference to `_mcount'
collect2: ld returned 1 exit status
Any ideas ? Am I missing a .h call ? Or do I need to link to something ?
I have just updated cygwin. I attach cygcheck.out
Or any suggestions for another profiling tool that actually reports times ?
Cheers,
Beau
If the gprof section of binutils is properly built and installed, it
should satisfy the mcount reference.
It's a bit strange to make a .o with -g -pg together, particularly when
you don't link with the same options.
FWIW, latest version of Intel VTune works with cygwin builds with -g3
-gdwarf-2 (and of course PATH considerations).
--
Tim Prince
--
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: Error building crossgcc on cygwin
On 05/14/2013 10:04 AM, Josef Wolf wrote: Hello, I am trying to compile gcc on cygwin under 64bit win7 To configure gcc, I use the following command: /var/tmp/builds/crossgcc/src/gcc-4.7.2/configure \ --prefix=/usr/local/crossgcc \ --with-gmp=/usr/x86_64-pc-cygwin/sys-root/usr \ --with-mpc=/usr/x86_64-pc-cygwin/sys-root/usr \ --with-mpfr=/usr/x86_64-pc-cygwin/sys-root/usr \ --enable-install-libbfd \ --enable-languages=c \ --with-gnu-ld \ --with-gnu-as \ --with-newlib \ --enable-commonbfdlib \ --enable-multilib \ --enable-interwork \ --disable-libssp \ --nfp \ --gas \ -v \ --target=arm-none-eabi \ --with-cpu=cortex-m3 \ --with-tune=cortex-m3 \ --with-mode=thumb \ --with-float=soft \ --disable-nls \ --without-headers But configure complains that it can't find gmp, mpc and mpfr. Here is the relevant part of the config.log file. Any ideas? The whole cponfig.log is appended at the end of this mail. cygwin native installations of those tools won't help with a non-cygwin target. Maybe this would be more suitable for gcc-help. In particular, you might give attention to the download-prerequisites. -- Tim Prince -- 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: Cygwin64: c++11 thread support
On 05/09/2013 12:03 PM, 张皛闶 wrote: Hi, i'm curios why there's no c++11 thread support in current g++? which do you consider current? g++ -v 4.5 is still supported for 32-bit (but I think not 64-bit) cygwin. You can't expect much c++11 in 4.5. 4.8 versions are available on a trial basis. -- Tim Prince -- 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: Stack Overflow versus the Cygwin mailing lists (Was: prefork error : couldn't create pipe process trackerWin32 error 161)
On 04/29/2013 04:28 PM, Warren Young wrote: On 4/29/2013 11:26, Christopher Faylor wrote: The net is full of bad and outdated advice about Cygwin. Stack Overflow gives you the tools to fix that. Post comments, post better answers, edit incorrect answers, downvote bad answers, vote to delete unhelpful answers, and gain reputation to get moderator fu. Mailing lists give you only some of those abilities, and the powers that do exist are weaker here: Then please keep SO and its public posts off the search engines. If the people with rep there are intent on misleading outsiders, it's not the thing to replace other resources. -- Tim Prince -- 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: Shouldn't gcc-4 depend on libmpfr4 ?
On 3/4/2013 10:26 AM, Achim Gratz wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: No, the dependency is correct, but, oh well, that's something which shouldn't happen. cc1 is linked against libmpc1, which in turn is linked against libmpfr1, while cc1 is directly linked against libmpfr4. Ah. Thanks for catching that. David? Any chance to create a new mpclib package which fixes this dependency problem? I have preliminary new-style cygport files for gmp, mpfr and mpc if it helps anybody. Still fighting with some autotools issue (should be solved, fingers crossed) on gmp and I need to look into a test build failure for mpfr. It looks like libmfpr1 could be made obsolete after the new package has been deployed. One of my posted applications https://sites.google.com/site/tprincesite/levine-callahan-dongarra-vectors is working for C and Fortran 77, but not for C++ nor Fortran 90, with the 4.7.2 download. I'll have another go when some of the issues already discussed are reported fixed. The installation is difficult when each component tries every time to revert to the stable release, producing a broken installation of mixed releases. -- Tim Prince -- 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: Intel FORTRAN time_and_date function returns UTC instead of local time
On 1/24/2013 5:01 AM, Marten Jan de Ruiter wrote:
I wrote a FORTRAN program using the time_and_date function. The source follows
below. The time_and_date function returns the wrong time: I am not in UTC, so
czone should be +0100.
In the following output, the lines ctime:... to milliseconds... are based
on time_and_date. The line 15:54:49 is the correct time obtained by the time function, and the line
23-JAN-13 is the correct date obtained by the date function.
ctime: 20130123
cdate: 145449.947
czone: -
@ 2013-01-23 14:54:49.947
year 2013
month 1
day23
diff wrt UTC0 minutes
hours 14
minutes54
seconds49
milliseconds 947
15:54:49
23-JAN-13
I have done some experiments to narrow down the problem:
* compiling with gfortran: time_gfortran.exe gives correct result in Cygwin
* compiling with g95: time_g95.exe gives the correct result in Cygwin
* compiling with ifort: time_ifort.exe gives the wrong time in Cygwin
After copying cygwin1.dll, cyggfortran-3.dll and cyggcc_s-1.dll to the working
directory, I get correct results
using the three executables in c:\windows\system32\cmd.exe.
I suspect that the intel compiler does a different system call for
time_and_date than for date and time, that the system call is intercepted by
Cygwin, and not properly handled. I am still baffled why the same source runs
fine for gfortran and g95. Notice however that for these compilers, the _date_
and _time_ functions are not defined. Hence the preprocessor exclusion in the
source.
Does anyone know how I can trace the system calls of my executables?
Regards,
Marten Jan
The following example comes from the documentation of Intel:
Consider the following
example executed on 2000 March 28 at 11:04:14.5: INTEGER DATE_TIME (8) CHARACTER
(LEN = 12) REAL_CLOCK (3) CALL DATE_AND_TIME (REAL_CLOCK (1), REAL_CLOCK (2),
REAL_CLOCK (3), DATE_TIME)
This assigns the value
2328 to REAL_CLOCK (1), the value 110414.500 to REAL_CLOCK (2), and the
value -0500 to REAL_CLOCK (3). The following values are assigned to DATE_TIME:
2000, 3, 28, -300, 11, 4, 14, and 500.
The following is the source of my program:
program time_and_date
implicit none
character (len=8) cdate
character (len=10) ctime
character (len=5) czone
integer(4) ival(8)
integer(4) yr,mon,day,hr,min,sec,ms
call date_and_time(cdate,ctime,czone,ival)
read (cdate(1:4),*) yr
read (cdate(5:6),*) mon
read (cdate(7:8),*) day
read (ctime(1:2),*) hr
read (ctime(3:4),*) min
read (ctime(5:6),*) sec
read (ctime(8:10),*) ms
print *,'cdate',cdate
print *,'ctime',ctime
print *,'czone',czone
print ('@ ',i4,'-',i2.2,'-',i2.2,' ',i2.2,':',i2.2,':',i2.2,'.',i3.3),
yr,mon,day,hr,min,sec,ms
print *,'year ',ival(1)
print *,'month',ival(2)
print *,'day ',ival(3)
print *,'diff wrt UTC ',ival(4),' minutes'
print *,'hours',ival(5)
print *,'minutes ',ival(6)
print *,'seconds ',ival(7)
print *,'milliseconds ',ival(8)
print *
#ifdef IFORT
call time(ctime)
print *,ctime
call date(ctime)
print *,ctime
#endif
print *,'done'
end program
For what little it's worth, the documentation of the ifort legacy time()
and date() functions states that they aren't reliable for dates beyond
year 1999 and the Fortran standard date_and_time should be used. There
is no documented time_and_date(). As others hinted, ifort bypasses
cygwin .dll entirely, so the question has no relationship to cygwin,
although it could be related to your calendar clock settings and the way
Windows date setting is incompatible with practices accepted outside
Windows.
-- Tim Prince
--
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: How to rsh in windows using cygwin
On 1/16/2013 6:52 AM, Andrew DeFaria wrote: On 01/16/2013 04:14 AM, Divakar wrote: We used rsh (from third party tool) in our script. so we are planning to use the same rsh functionality using cygwin. it needs lot of work in the machine side as well as in the script site if we implement something new like ssh. In my experience, after setting up ssh to work, it's pretty much a drop in replacement for rsh. By that I mean I've found that, again once set up, if I simply change rsh - ssh everything else works without a change. And I believe that many more people know and use ssh than rsh meaning you'd probably get more support by using ssh. Maybe you could describe exactly what you are doing with rsh... I still remember the occasion 15 years ago when I entered rsh tim and found myself logged in as the head of corporate IT with root privilege. That was about the time when the big push to substitute ssh began. I'm old enough to think of ssh as something new but this stretches the term. -- Tim Prince -- 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: Is the Latest Release of Cygwin supported on Windows Server 8/2012
On 5/27/2012 3:30 AM, Linda Walsh wrote: It Could be if it is done in a way that removes all the 32-bit speed probs (alignment issues being only 1), but ALOT of what computers do is move data around -- large amounts -- strings, buffers, etc. 64-bit archs can move a native 8-bytes/cycle, 32-bits only 4... that's a 100% increase in 32-bit instructions for something that has been measured to dominate many programs. Maybe there could be callouts to convert those calls to native 8-byte moves, This has little to do with choice between 32- and 64-bit OS, unless you write programs which spend their time moving data blocks which are too big for cygwin. gcc -m32 defaults to generation of in-line memcpy code optimized for short strings, while gcc -m64 uses glibc functions (too big to inline), but that's only indirectly a consequence of the OS. CPUs have been adding microcode continually for better optimization of the gcc -m32 string moves, even though new CPUs are designed primarily for 64-bit OS. The same data move instructions are present in either OS. It took years for glibc to implement efficient string moves for x86_64, and those still bump up against the question whether they always use code which runs on the CPUs of a decade ago. CPU designers spend lots of cycles simulating runs of future CPUs on instruction traces of current applications. There's a lot more quantitative analysis there then in any assertions I've seen about the future of cygwin. -- Tim Prince -- 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: Is the Latest Release of Cygwin supported on Windows Server 8/2012
On 05/26/2012 07:40 PM, Linda Walsh wrote: Every time you fetch a word or instruction that is not 8-byte aligned, you force a fatal (but caught by the processor and/or OS) signal for unaligned data. That forces execution out of the pipeline (though not likely out of cache, sadly, due to frequency of occurrence). That's not counting the extra cycles to fetch the rest of the data. On some machines that can easily amount to several dozen instructions worth. There have been compilers for 32-bit Windows for 20 years which gave 8-byte alignments by default. cygwin changed the default configure parameter in binutils so as to support alignment about 8 years ago. It was tolerable to some before then as it matters only for 64-bit and larger objects (doubles, and SSE, after that was introduced). The characteristics of the worst compiler (with respect to alignment) available outside of cygwin don't have a bearing on this list. If the powers that be have decided that 64-bit mode should be supported on cygwin setup.exe only by mingw cross compilers, I'll accept that. -- Tim Prince -- 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: Documentation on -mno-cygwin Accuracy
On 2/6/2012 2:29 PM, Charles D. Russell wrote: i686-w64-mingw32-gfortran.exe hello.f -o hello cdr@dell03 ~/mingtest $ ./hello /home/cdr/mingtest/hello.exe: error while loading shared libraries: libgfortran- 3.dll: cannot open shared object file: No such file or directory The cygwin distribution of mingw puts the support dlls in their own directories. You must act yourself to get them on PATH. This is a consequence of their not being cygwin compilers and giving you a mongrel combination of cygwin and Windows setup. However, cygwin provides useful tools like find and export: export PATH=/usr/x86_64-w64-mingw32/sys-root/mingw/bin/:$PATH -- Tim Prince -- 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: Documentation on -mno-cygwin Accuracy
On 2/7/2012 3:10 PM, carolus wrote: On 2/7/2012 1:51 PM, Tim Prince wrote: On 2/6/2012 2:29 PM, Charles D. Russell wrote: i686-w64-mingw32-gfortran.exe hello.f -o hello cdr@dell03 ~/mingtest $ ./hello /home/cdr/mingtest/hello.exe: error while loading shared libraries: libgfortran- 3.dll: cannot open shared object file: No such file or directory The cygwin distribution of mingw puts the support dlls in their own directories. You must act yourself to get them on PATH. This is a consequence of their not being cygwin compilers and giving you a mongrel combination of cygwin and Windows setup. However, cygwin provides useful tools like find and export: export PATH=/usr/x86_64-w64-mingw32/sys-root/mingw/bin/:$PATH The old -mno-cygwin yielded a standalone executable that I could give to a colleague and it would just work on a Windows machine without cygwin. It appears that now one must bundle at least one dll. From a licensing standpoint, are these dll's any different from cygwin1.dll? Can they be distributed freely without bundling the source code? If not, I might as well forget about mingw and just supply cygwin1.dll. Seems off-topic here. Does http://www.mingw.org/license begin to answer your question? How about the recent suggestion of -static? -- Tim Prince -- 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: Windows 7 x64 - Postinstall script errors - Cygwin V 1.7.9-1
On 02/03/2012 12:39 PM, Carbonera, Carlos wrote: Problem 1. I am not able to install Cygwin on Windows 7 x64. I get the following errors at the end of the installation: Postinstall script errors Upon finishing the installation, I do not obtain the CYGWIN icon on my desktop as I requested, and the only two applications that appear on my All Programs/Cygwin folder are related to the application urxvtc-X.exe. Problem 2: I cannot find the application that starts the X-Server. I found the CYGWIN.bat file and created a shortcut on my desktop. The CYGWIN bash application seems to be working. I am using startxwin to start the X-Server; is this the the recommended method? Did you use the current startup.exe recommended on cygwin.com? startxwin works for me, but it's messy with lots of warnings. The new installation should give you an xwin icon on the startup menu. which puts a menu icon in the hidden icons, with xserver among the selections. -- Tim Prince -- 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: MinGW gfortran and OpenMP issues...
On 2/1/2012 7:03 PM, Nick Chilton wrote: Hi, I'm still having problems with OpenMP and the x86_64 MinGW compilers - code which can run fine on Linux with any number of threads (mapped to different cores) still will only use one core on an i5 quad core windows box. Is this a windows limitation or a compiler one? Compile with: x86_64-w64-mingw32-gfortran.exe -o a.exe -mno-cygwin -static -O3 -fopenmp -cpp -Domp $(SOURCES) -L/home/Nick/lib/ -llapack -lblas According to my understanding, mingw compiler versions aren't supported on this list, notwithstanding that cygwin install is probably the best way to get them. However, that compiler gives me good OpenMP performance on 6 of 10 test cases, running on an early core I7 with HyperThread disabled, Win7SP1. GOMP_AFFINITY setting as well as avoiding Hyper-Threading are likely more important on Windows than linux. Win7SP1 is particularly important when using Hyper-Threading. -- Tim Prince -- 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: 1.7.9 : date command fails for year 1900
On 01/24/2012 06:51 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote: $ date -d '500 years ago' Now use cal to get a calendar of that month. Do days of the week correspond? Another experiment on your SL box: $ date -d 1752-09-10 This should give an error message, since (in Britain and its Dependencies) this date did not exist. Does it? $ date -d 1900-02-29 This date didn't exist in the Gregorian calendar. (No leap year in years divisible by 100 unless they are also divisible by 400.) Did date give an error? Only the last one produces invalid date on RedHat 6.0. As you suggested, the dates produced don't appear in the corresponding months of cal. -- Tim Prince -- 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: GCC, '-pg' option and 'mcount' undefined
On 1/3/2012 12:45 PM, Angelo Graziosi wrote:
For the sake of completeness, I want to flag the following issue I have
found on Cygwin.
I have an application that doesn't build on Cygwin (gcc-4.5.3) because
undefined reference to `_mcount' etc... I have tried to reproduce it
with this simple example:
$ cat hello.c
#include stdio.h
int main()
{
printf(Hello World\n);
}
$ gcc -c -pg hello.c
$ gcc hello.o -o hello
hello.o:hello.c:(.text+0xa): undefined reference to `_mcount'
hello.o:hello.c:(.text+0xf): undefined reference to `__monstartup'
collect2: ld returned 1 exit status
If I try the same above example (and the true application) on Mac OS X
Lion with gcc-4.5.3 or on GNU Linux distributions like Fedora14 (gcc
4.5.1), Kubuntu (gcc-4.6.1), Ubuntu (i386, gcc-4.6.1), it works just fine,
$ ./hello
Hello World
If I want to build the above example on Cygwin, I need to link using the
same option '-pg',
$ gcc -pg hello.o -o hello
$ ./hello
Hello World
Yes, I can patch my true application to use '-pg' option when it needs,
but I would know if you (Dave?) have other ideas here.
It's entirely normal to require the -pg option for linking pg
compilations. You may even get a version of some libraries with pg
profiling enabled.
--
Tim Prince
--
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: fortran open mpi - getting mpif77 and mpif90 to work
On 12/13/2011 8:41 AM, Stitchz wrote: Is it possible to have a mpif90 command (mpi fortran 90 compiler) working under cygwin? I've tried to download several packages (open mpi, mpich2, ...) but the configure scripts always fail. OpenMPI list indicated recently that cygwin support is a work in progress. I recall it depending on mingw cross compilation, but I may be wrong. mpich2 is pre-packaged, and works in a Visual Studio framework, as does current OpenMPI. Since a fresh install of cygwin includes the mpif77 command (even though it just points to a missing ifort.exe in the path), should mean that it SHOULD be able to work... This doesn't make sense, nor to I see any evidence of it. When ifort is supported, it's by an mpiifort wrapper, so as to avoid confusion with gfortran. This would be a cross compilation, not using cygwin facilities, and would not be supported specifically by anyone, as far as I know. -- Tim Prince -- 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: Problems with updating nearly any package meant for Cygwin or using packages such as libtool
On 11/16/2011 3:04 PM, Jesse Ziser wrote: On 11/16/2011 1:34 PM, viper_88 wrote: Larry Hall (Cygwin) wrote: On 11/15/2011 2:28 PM, viper_88 wrote: The avalanche of my problems has started when I wanted to install compat-libstdc++ 33-3.2.3. The installation failed due to the following dependencies errors: error: Failed dependencies: /sbin/ldconfig is needed by compat-libstdc++-33-3.2.3-55.fc5 libc.so.6 is needed by compat-libstdc++-33-3.2.3-55.fc5 libc.so.6(GLIBC_2.0) is needed by compat-libstdc++-33-3.2.3-55.fc5 libc.so.6(GLIBC_2.1) is needed by compat-libstdc++-33-3.2.3-55.fc5 libc.so.6(GLIBC_2.1.3) is needed by compat-libstdc++-33-3.2.3-55.fc5 libc.so.6(GLIBC_2.2) is needed by compat-libstdc++-33-3.2.3-55.fc5 libc.so.6(GLIBC_2.3) is needed by compat-libstdc++-33-3.2.3-55.fc5 libgcc_s.so.1 is needed by compat-libstdc++-33-3.2.3-55.fc5 libgcc_s.so.1(GCC_3.0) is needed by compat-libstdc++-33-3.2.3-55.fc5 libgcc_s.so.1(GCC_3.3) is needed by compat-libstdc++-33-3.2.3-55.fc5 libgcc_s.so.1(GLIBC_2.0) is needed by compat-libstdc++-33-3.2.3-55.fc5 libm.so.6 is needed by compat-libstdc++-33-3.2.3-55.fc5 Hm. This looks to me like output of rpm or yum on a Linux system. If you're trying to install Linux binary RPMs onto Cygwin, you're in for a world of hurt. Cygwin != Linux. You need to build from source on Cygwin. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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 Hello there, Larry, and thank you for your reply. You were right, I indeed tried to install compat-libstdc++ using an RPM file. I am still learning Cygwin, so I wasn't sure whether it supports them or not (and the RPM's were the first to pop when searching for any sources). It's not an issue of whether Cygwin supports RPMs. It's an issue of trying to install a Linux executable on Cygwin. It doesn't matter whether it's packaged in an RPM, it's still a Linux binary, not a Cygwin binary. It seems, however, that now I have faced a problem with GLIBC, which is required to update GCC, that I won't be able to deal with (and I haven't updated libstdc++ due to this yet)... From the Cygwin FAQ (which I strongly recommend reading): Where is glibc? Cygwin does not provide glibc. It uses newlib instead, which provides much (but not all) of the same functionality. Porting glibc to Cygwin would be difficult. THC-Hydra claims that it builds fine on Cygwin. Does it not? As thc was stated to use mingw for Windows support, it would seem that it should work with the mingw cross compilers, although uwin was recommended. If you want native cygwin, or even if the purpose is only to gain a more recent version of g++ cross compiler (without all the language support of the cross compilers on the cygwin install menu) it seems you should consider whether the gain is worth the effort, when your original question was how to get a gfortran for Windows. -- Tim Prince -- 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: shared Libary problems
On 11/15/2011 4:31 PM, Jim Harsh wrote: If you're depending on a specific C++ mangling to match what you've put in your build, bear in mind that no g++ will match any Visual Studio compatible C++ compiler. Normal procedure is to use extern C on the C++ side and iso_c_interop on the Fortran side so as to remove mangling on both sides. You may have better chances with the linux build procedure under cygwin, hoping that cygwin g++ may match linux g++. If you normally embed options such as -O2 in your alias for the compiler name when using Intel compilers, you could do the same with gnu compilers. -- Tim Prince -- 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: unexpected token error (cygwin 2.738 make)
On 9/12/2011 5:24 AM, Gwen Morse wrote:
I installed cygwin 2.738 on a new Windows 7 system and tried to build
a project from source. I have been able to do this in the past, I
wanted to check if there's any problems with this newer version of
cygwin.
when I type make I get an error message about an unexpected token with
an open parenthesis.
$ make
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `cd src; PATH=/usr/local/bin:/usr/bin:/
cygdrive/c/Program F
iles (x86)/Windows Resource Kits/Tools:/cygdrive/c/Windows/system32:/cygdrive/c/
Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPo
werShell/v1.0:/cygdrive/c/Program Files/WIDCOMM/Bluetooth Software:/cygdrive/c/P
rogram Files/WIDCOMM/Bluetooth Software/syswow64:/cygdrive/c/Program Files (x86)
/Common Files/Roxio Shared/DLLShared:/cygdrive/c/Program Files (x86)/Calibre2:/c
ygdrive/c/Program Files (x86)/HMA! Pro VPN/bin:/usr/lib/lapack:@PATH@ make files
'
This looks like problems with failing to quote paths with embedded
spaces, lack of escapes on wild card characters, items on path which one
would hope have no relevance to your build,
Difficult to believe it is a cygwin version problem.
--
Tim Prince
--
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: compiling with visual studio
On 07/01/2011 09:22 AM, Kraus Philipp wrote: Hello, I'm new with cygwin and hope my question is not off topic. I try to port a C++ framwork to Windows. The framework uses Atlas and LAPack, libxml (with libiconv and zlib) and GiNaC with CLN. Some libs like zlib can I build with the Visual Studio nmake command, but other can be build with configure, make, make install only. I have setup the Cygwin.bat with Visual Studio (the Atlas developer describe this on http://math-atlas.sourceforge.net/errata.html#WinComp) but do I understand it in a correct way, that after setting the environmental variables, I can use the VS compiler under Cygwin? I have installed the gcc, g++, gfortran and make tools under Cygwin and can compile my libraries, but the configure script determine the ld linker. If I have compiled a library under cygwin, can I link the binary in Visual Studio? Thanks If you want to link gnu compiled objects under Visual Studio, the mingw cross compilers would be more suitable than the cygwin compiler. This quickly gets off topic. If you want to use standard Makefiles, gnu make (including, but not restricted to, the cygwin one) is a better bet than nmake. There's no law against using mingw or even CL with gnu make. -- Tim Prince -- 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: startxwin not found; solution
On 6/4/2011 7:06 PM, Dave Matthews wrote: I've tried to install Cygwin/X several time over the last two months and always it only installed Cygwin, no X at all. startxwin not found and nothing relevant in /usr/bin. The problem was that the Default setting of the installer http://cygwin.com/setup.exe for the X11 package is Skip. So when you've stepped through the intaller to the Select Packages screen, click X11 and set it to Install. As the documents tell you, xinit is required for startxwin, and that rquires setup to bring in the necessary X11 dependencies. How could you spend 2 months on this without looking it up? Answered earlier from Blackberry, but the spam filter here doesn't permit that. -- Tim Prince -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Problem compiling with SSE intrinsics and -O3
On 5/13/2011 12:15 PM, Morris, Philip wrote: (third try, wow you guys really don't want to receive emails !) Please submit a full bug report, with preprocessed source if appropriate. SeeURL:http://cygwin.com/problems.html for instructions. Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple They probably don't like to see e-mails which ignore the instructions contained in them. How many people will be curious enough to try several of the compilers provided currently or in the past by cygwin setup.exe, not even knowing whether you're running one of those? -- Tim Prince -- 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: windows cmd for ./configure
On 4/30/2011 7:50 AM, Sayth Renshaw wrote: Hi I am haaving trouble locating the answer to this question due to the amount of results configure brings in the archives and google. I am trying to use ./configure make on the command line however the '.' in ./configure causes an error. I know my make works as I have used it already. What is the cygwin version of ./configure make for building programs on windows. I am trying to build 'auctex' If the application is set up to be installed via configure, it should provide its own specific configure script, as it seems auctex has done. Note that many applications require use of configure in the gnu standard way (make a new clean directory and cd into it, run the application's configure script from there). I'm sure there is plenty of bad advice about configure for other applications available by web search. I note that the search string configure auctex shows that there apparently is a mail list devoted to auctex, where questions (after checking the instructions) might better be answered. Even though this list is frequented by a few people active in the past on that list, I have probably gone well beyond the tolerance of this list for generalities about applications not specifically supported here. -- Tim Prince -- 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: newlib and long-double question
On 4/10/2011 4:28 AM, Sisyphus wrote: - Original Message - From: Hugh Myers The OP is trying to build Perl itself, not use it; hence the need for long double support functions... You don't need long double support functions to build perl ... unless you want to build a perl whose NV is a long double (instead of a double). Presumably the op wants to build a perl whose NV is a long double so that he can make use of that extra precision. Given that he can't build such a perl, the next best way of accessing that extra precision he wants is, imo, to use Math::MPFR. I never did see a clear description of OP's goals. Performance was among them, so it was unclear why typical mathlinline.h content would have been rejected e.g. __inline_mathcode_ (long double, __sqrtl, __x, return __builtin_sqrtl (__x)) As OP indicated, the functions might not have been difficult to write, perhaps not as difficult as settling requirements. If the requirement was for sqrtl to perform faster than sqrt, the expectation was misguided. -- Tim Prince -- 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: 1.7.8: Fortran I/O rounding inaccuracy
On 3/7/2011 4:17 AM, Thomas Henlich wrote: I doubt our compiler is Fortran 2008 compliant, as at maximum it will be Fortran 2003 An identical phrase appears in Fortran 2003. Have you tested gfortran 4.3 on other platform ? Due to unavailability, I was not able to test this particular version on other platforms. Tested ok: gfortran 4.4 on Debian gfortran snapshot 20101129 on mingw32 Bug confirmed: gfortran snapshot 20100408 (unofficial Cygwin build) You haven't shown how you tested rounding modes UP or DOWN, which may not be implemented in gfortran, as those (I believe) require the IEEE_arithmetic module, which is still under development. Doesn't the wording you quote apply to the binary value resulting from READ conversion? In the default (without IEEE_arithmetic settings), it's not clear to me that f2003 or 2008 standards impose requirements beyond those of IEEE754, which allow the decimal representation to truncate after 17 correct digits. As Corinna said, the place to ask about progress in this area of gfortran is fort...@gcc.org. Corinna is more of an expert on newlib than are we; the differences you quote between linux implementation on glibc and cygwin which you quote appear to be within newlib. -- Tim Prince -- 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: PATH with spaces
On 1/30/2011 6:34 AM, Sunoki wrote: $ make cygwin warning: MS-DOS style path detected: /usr/local/bin/C:\Program Preferred POSIX equivalent is: /usr/local/bin/C:/Program CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames Can't find C:\Program on PATH. I suppose you will meet reluctance, as it will be difficult to help until you have read the advice and formed a clearer idea of what you are trying to do. Yes, the warning comes about in part due to the use of an unquoted path with spaces. The primary purpose of cygwin is not for the use of native Windows applications. In case you do want that, a useful possibility is to set up the paths correctly in a command prompt window for the Windows applications, then run the cygwin.bat so as to superimpose the cygwin environment. -- Tim Prince -- 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: Hyperthreading problem creates a hang
On 11/18/2010 2:25 AM, paritosh chandragupta wrote: Hi folks , I am hitting the following problem while using gmake :- 617 [exiting thread] gmake 9576 cygthread::stub: erroneous thread activation , name is NULL . Now I am indeed using an old cygwin version and can not update it due to dependency issues . Do you have a workaround for this problem ? As per my understanding this problem will not be seen if we limit the maximum number of threads for a process on cygwin (this will of course make it slower , but that is fine ) . Am I Correct ? If yes , how can we do it for cygwin ? I have been using make -j 4 in cygwin for 10 years on the 4 hyperthread Pentium D. Is that not a solution for you? I never expected a performance improvement beyond that number of threads. If you don't mean make which comes with cygwin, I don't see how you will get help without explaining your question. -- Tim Prince -- 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 c compiler and c99
On 10/31/2010 6:21 AM, David wrote:
Does Cygwin c compiler not support c99?
or does c99 not support?:
#include stdio.h
#include stdlib.h
int main(void) {
bool f=true;
for(int i=0; i10; i++) {
if (f)
printf(%d\n,i);
}
puts(Hello World!!!); /* prints Hello World!!! */
return EXIT_SUCCESS;
}
Here the bool declaration fails and so do the for statement. The
compiler doesn't like that I use the iteration variable inside the
for-loop.
Neither I nor the compiler see a declaration of bool there. Is this
example what you intended?
After defining bool and true in terms of _Bool
gcc -O -Wall -pedantic -std=c99 djb.c
$ ./a
0
1
2
3
4
5
6
7
8
9
Hello World!!!
--
Tim Prince
--
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: modification time disorder: touch-related?
On 10/29/2010 12:24 AM, Oleksandr Gavenko wrote: On 28.10.2010 20:10, Robert McDougall wrote: In running Make, I find targets being remade that shouldn't have to be remade; being considered younger than the prerequisites from which they've just been made. It seems to happen especially with prerequisites created by `touch`: e.g.: $ cat Makefile all : bar baz bar baz : foo cp $ $@ foo : touch $@ $ rm foo bar baz $ make touch foo cp foo bar cp foo baz $ make cp foo bar cp foo baz $ make cp foo bar cp foo baz $ make cp foo bar cp foo baz $ make cp foo bar cp foo baz $ make cp foo bar $ make make: Nothing to be done for `all'. Sleeping helps, but you have to sleep for quite a while; even 2 seconds may not be enough: do you build on FAT fs? It knows by lesser time precision (exactly 2 sec). Try example on NTFS. If your files are on a server, of course, you need synchronization between the server and local system clocks, at least daily. -- Tim Prince -- 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: Possible Windows 7 issue? cc1.exe: error while loading shared libraries: ?
On 10/4/2010 10:35 AM, Taggart Ashby wrote: This issue started when I upgraded my operating system to Windows 7 64-bit. Anytime I attempt to compile a C or C++ program (cc1plus.exe in that case), I get the above error. I only get the error if I attempt to compile from the windows command prompt. If I run gcc in the Cygwin shell I have no problems. When you install the new OS, the non-standard paths you once set up don't get replicated by magic. It's probably better that they don't. -- 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 instabilities
On 9/13/2010 12:34 PM, Dave Korn wrote: Even when I submit make check-c make check-fortran and make check-c++ in separate windows, occasionally an instance of expect will hang and fail to time out, so has to be killed to complete the check. More often than not, it's possible to complete the whole 3 day series without such a hang. Anyway, it's not specific to -jN. -- Tim Prince -- 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 speed difference on multiple cores -vs- single-core?
On 8/13/2010 5:37 PM, Andy Nicholas wrote: Hi Folks, When using cygwin, I've noticed that there seems to be a large speed difference when I boot my windows 7 (32-bit) machine in single-core mode versus the regular number of cores (4, Core i7-930). I've read through the FAQ and didn't notice anything about this issue. Normally, I would expect nearly no speed difference based on the Windows environment... but after some extensive timing tests it seems like the single- core machine is usually at least 2x faster than using the same machine setup in multi-core mode. I limit the number of cores using MSCONFIG, advanced boot options. We have some simple script and more complex scripts which show this behavior. The simple scripts do straightforward things like rm -rf over some directory trees. Even the simple scripts run slowly when the PC is booted with multiple cores. Is this known behavior? Is there some way to work around it so I can boot my PC, use all the cores with other apps, and continue run cygwin 2x faster? Several possibilities which you haven't addressed may affect this. Are you comparing the performance of a single thread when locked to a single core, compared to when it is permitted to rotate among cores, with or without HyperThread enabled? I've never run into anyone running win7 32-bit; it may have more such issues than the more common 64-bit. -- Tim Prince -- 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: startxwin/XWin won't start properly
On 6/30/2010 10:15 AM, Christopher Faylor wrote: OTOH, why not use putty if you don't know linux? You haven't been mean enough. ssh is easier to use than putty, regardless of knowledge of linux. -- Tim Prince -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: rsh issue on cygwin
On 6/19/2010 1:24 PM, ANUP DHAMALE wrote: I have configured cygwin on my windows box I am unable to rsh to my Linux box from windows. Error message - Permission denied. Probably on the linux side; rsh server not installed/started/account enabled, firewall not open. rsh never open by default as it's considered highly vulnerable. -- Tim Prince -- 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: bug in NINT() in gfortran
On 6/12/2010 12:07 AM, Hans Jørgen Aagaard Jensen wrote: The NINT() intrinsic in current gfortran under cygwin has a bug. Below follows: 1) small test program 2) output from this program 3) output from gfortran -v (I am not submitting this to the gcc bugzilla, because the test worked OK on all the linux systems I tested.) (I found the error becaus our quantum chemistry softward dirac (http://dirac.chem.sdu.dk) failed a few of the internal tests.) -- Hans Jørgen Aa. Jensen === 1) small test program program test double precision xval xval = 132843.61283756854D0 do i = 1,7 ipoint = nint(xval) write (6,*), xval, ipoint xval = 10.0d0*xval end do return end === 1) output = 132843.61283756854 132844 1328436.1283756853 -1596096578 Try the following replacement for nint(): ipoint = xval+.5 which leads me to believe the lround function from newlib is buggy. If you wished to handle negative as well as positive, the work-around ipoint = xval+sign(.5,xval) would take it a little further. This short-cuts the distinction between ieee_nearest and legacy Fortran rounding style, but I don't see that gfortran was making the distinction. -- Tim Prince -- 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: How to run bash shell script in cygwin?
On 5/25/2010 12:29 AM, Vinoth Manimaran wrote: Hai, Soln : type the following bash batchjob.sh you will get the results comments are invites to mvinot...@yahoo.com myuser01 wrote: I have a script called batchjob that looks like this: #!/bin/bash echo 'I was here' -rwxr-xr-x 1 c10066 mkpasswd 48 Jul 19 09:30 batchjob But when I try to execute it from the cygwin shell I get this: $ batchjob bash: batchjob: command not found How do i execute a bash shell script from within cygwin? Thanks or consult any basic doc about bash default paths, e.g. http://www.linuxfromscratch.org/blfs/view/6.3/postlfs/profile.html -- Tim Prince -- 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: How to compile Fortran 90 subroutine under CYGWIN
On 5/21/2010 5:37 AM, bo yu wrote:
.c.o : $(H_SOURCES)
$(CC) -c $(CFLAGS) $
.f.o:
${F77} -c ${FFLAGS} $
Here is the code of ‘Testfor90.f90’
--
make noticed that you didn't supply a rule for .f90.o
Why wouldn't you use gfortran? If you are trying to use a cygwin
installation from several years ago, it's time to update.
--
Tim Prince
--
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: Desperately seeking rename
On 5/21/2010 6:37 AM, Fergus wrote: How does this work, exactly? I'm looking for rename as it's not in Base. I go to http://cygwin.com/packages/ and institute a search for rename It's interesting that the FAQ mentions rename many times, and even implies a distinction between rename and move, but never says whether mv is meant. If you want something other than mv, you may need to explain what you want. -- Tim Prince -- 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: How to compile Fortran 90 subroutine under CYGWIN
On 5/21/2010 8:21 AM, bo yu wrote:
Tim,
Thanks for your reply.
I have the new version of cygwin installed in my computer, in which the g77,
g++, gcc, gfortran, C++ compiler are in C:\cygwin\bin.
Firstly, I use cygwin build C programs and For77 programs. It works very well.
Now, I add two For90 programs and want to build following program together in
cygwin:
Fortran 77 program: runslhg.f , intrface.f
Fortran 90 program: swan_init.f90 , swan_loopstep.f90
C Program:slosh2.c , cstart.c etc.
Step 1: I replace g77 with gfortran in 'makefile',
#!/bin/make
SHELL = /bin/sh
CC = gcc
F77 = gfortran
STRIP = strip
STD_FLAGS = -O3 -Wall -pedantic -ansi
FFLAGS =
LD_FLAGS = -Wl,--stack,800
STD_DEF = -D_WINDOWS_ -D_GCC_
STD_INC = -I.
STD_LIB = -lg2c -L/usr/lib -lm
PRJ_NAME = sloshDos
TARGETS = $(PRJ_NAME)
CFLAGS = $(STD_FLAGS) $(STD_DEF) $(STD_INC)
# FILES
H_SOURCES = slosh2.h \
pack.h \
myassert.h \
myutil.h \
savellx.h \
complex.h \
clock.h \
tendian.h \
tio3.h
C_OBJECTS = slosh2.o \
pack.o \
myassert.o \
myutil.o \
savellx.o \
complex.o \
clock.o \
tendian.o \
tio3.o
F_OBJECTS = runslhg.o \
intrface.o \
swan_init.o \
swan_loopstep.o
C_MAIN = cstart.c
# TARGETS
all: $(TARGETS)
@echo
$(PRJ_NAME): $(C_OBJECTS) $(F_OBJECTS) $(C_MAIN) $(LIB_DEPENDS) $(H_SOURCES)
$(CC) $(C_MAIN) $(CFLAGS) $(LD_FLAGS) $(C_OBJECTS) $(F_OBJECTS) $(STD_LIB) -o
$(PRJ_NAME)
$(STRIP) -s $(PRJ_NAME).exe
install:
cp *.exe ../../bin
clean:
rm -f *.o *.bak *.BAK
# SUFFIXES
.c.o : $(H_SOURCES)
$(CC) -c $(CFLAGS) $
.f.o:
${F77} -c ${FFLAGS} $
Step 2: in cygwin, I ran makefile, The error message is
gcc –c runslhg.f
gcc –c intrface.f
make: *** No rule to make target ‘swan_init.o’, needed by ‘sloshDos’. Stop
Step 3: To test if gfortran compiler wotk for For77 program, I try to build C
program and For70 programs only using gfortran, I ran makefile, The error
message is
runslhg.o:runslhg.f:,.text+0x4f: undefined reference to '__gfortran_st_read'
runslhg.o:runslhg.f:,.text+0x6d: undefined reference to
'__gfortran_transfer_character'
runslhg.o:runslhg.f:,.text+0x7b: undefined reference to
'__gfortran_st_read_done'
My Questions are
(1) Does gfortran work for fortran 90 program only?
(2) g77 compiler works for fortran 77 programs. Does g77 work for fortran 90
programs?
(3) How to build C, FOR77 and For 90 programs together in cygwin? How to set
the makefile, use seperate command for for77 and for 99?
gfortran is intended to be a full replacement for g77, as well as
supporting f95 and some f2003.
g77 might work for f77 code in .f90 source format, if you figured out
the correct free form options. It won't handle much f90 syntax. It
hasn't been maintained for about 5 years.
If you have set gfortran as your compiler, the .f90.o rule would look
just like the .f.o rule.
You should persuade the Makefile to use the Fortran compiler rather than
gcc for compiling and linking Fortran source code. g77 and gfortran can
handle .c files automatically.
--
Tim Prince
--
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: How to compile Fortran 90 subroutine under CYGWIN
On 5/21/2010 1:55 PM, bo yu wrote: (5) Tim mentioned that 'You should persuade the Makefile to use the Fortran compiler rather than gcc for compiling and linking Fortran source code. g77 and gfortran can handle .c files automatically'. From the original makefile, which works well as shown in Case 1, gcc will compile C program and g77 will compile fortran program. Both of us reminded you to make a .f90.o rule which can be a copy of the .f.o rule with only that single change. You should make both rules use gfortran as the compiler. -- Tim Prince -- 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: Text editor with shell integration
On 5/6/2010 5:07 AM, Jason Pyeron wrote: I am assuming that notepad++ does not understand paths like /cygdrive/c/filename.txt and /proc/cpuinfo (it has no hope on this one) mkdir /cygdrive/c/proc cat /proc/cpuinfo /cygdrive/c/proc then your windows app (running from C:) can open /proc/cpuinfo -- Tim Prince -- 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: sh.exe: *** fatal error - couldn't allocate heap, Win32 error 487
On 4/23/2010 9:10 AM, Lee Maschmeyer wrote: I have Symantec Endpoint on my machine and so far haven't had any trouble. My guess is that there's some kind of configuration difference, but since I've never been bothered by it I haven't had to learn anything about it. Running without AV scares the stuffing out of me though. My neighbor recently told me they had discovered 167 viruses on his machine. He's now a bit wiser and not that much poorer. :-) Many people this week have been wishing they used an open source virus checker: http://www.betanews.com/article/One-very-false-positive-McAfee-in-full-damage-control-mode/12720406 -- Tim Prince -- 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 problem make Linux c++ app in windows
On 3/23/2010 10:27 PM, crmpteltd wrote: from the first few error log, it seems there is a problem recognizing pthread.h the Linux lib used are: #includesys/socket.h #includearpa/inet.h #includenetdb.h #includepthread.h #includesys/stat.h The make command was g++ -c -Wall main.cpp http_client.cpp string.cpp g++ -lpthread main.o http_client.o string.o -o main You do need to specify your options in order, same as you would require for static libraries on linux. It's the same gnu ld, which doesn't go back and repeat library searches after you add new references, unless you give the keywords which make that happen. You had no unsatisfied references at the point where you issued -lpthread, and there is no dynamic libpthread. If you were able to satisfy all those headers, you already got lucky; don't push your luck. -- Tim Prince -- 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__ with -std=c99
On 3/22/2010 6:03 AM, Oleksandr Gavenko wrote: Current workaround is undefine __STRICT_ANSI__: $ gcc -std=c99 -U__STRICT_ANSI__ -c -o grid.o grid.c Where is proper place to report issue? If you want c99 plus gcc extensions without warnings, how about -std=gnu99? It seems this may become the default soon. -- Tim Prince -- 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: build DLL that can be used by MinGW
On 2/8/2010 12:50 AM, Martin Henne wrote: But I need to compile the DLL on cygwin and the rest on MinGW, and this does not work. The reason is, that I need a dll that uses the cygwin-posix-layer. What can I do? Why should it work? If your .exe needs cygwin dll, don't build any part of it with 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: Can't start X after upgrading to cygwin1.7
On 2/3/10 12:43 PM, Jon TURNEY wrote: On 23/01/2010 15:37, Jeff Spirko wrote: On Sat, Jan 16, 2010 at 12:56 PM, Andrew Seniora...@andrewsenior.com wrote: I've had cygwin installed for a year on my Thinkpad T61, running Windows XP professional, and just ran the latest setup.exe from cygwin.com. I now can't run X with startxwin.exe (no process appears, no icon in the system tray, clients won't start) No /var/log/Xwin.0.log is written, nor anywhere else I can see in /var/log I think the original poster had a broken installation, there's no other reason for it to get fixed by a reinstall :-) Maybe there was a reboot in there somewhere. On my XP32 on T61 (configuration determined by my employer) it was frequently necessary and sufficient to reboot before running startxwin. Now I have to take it back as it's failing to perform the first mount during Windows boot. -- Tim Prince -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: problem running f77 and g77
Reza Salem wrote: . There is a g77 in the gcc-3 package; g77 hasn't been maintained since then. It's generally advisable to use gfortran. A strong effort has been made to support all sane g77 extensions, as well as all of f77. -- 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: help with error?
Afflictedd2 wrote:
It complains on this line of code:
while ( context-holder != '' ) {
/usr/bin/g++ -c-g -o Debug/prodcon.o prodcon.c
prodcon.c:129:32: error: empty character constant
prodcon.c: In function ‘void* producer(void*)’:
prodcon.c:103: error: expected `;' before ‘sizeof’
prodcon.c:103: error: expected `)' before ‘;’ token
prodcon.c:103: error: expected `;' before ‘)’ token
How do I fix this?
Which aspect of it? Unsuitable LANG environment variable setting, or
comparison of unspecified pointer target with string of 0 length?
Looks like primarily a C syntax issue rather than a cygwin one.
--
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: Appropriate expectation on the degree of cygwin and MS interoperability
neil.mowb...@calgacus.com wrote: For the most part the cygwin tools interoperate with MS artifacts but it does break down, especially, with 64bit artifacts. For example, nm can work with 32bit object files created by MS cl.exe but it cannot work with 64bit MS object files (unrecognised file format). The question is: how far should I expect the interoperability to go? For example, is the fact that nm cannot handle 64bit MS object files a (1) defeat in cygwin/nm or (2) I should be grateful that it works with 32bit files and otherwise lower my expectation? cygwin binutils doesn't set or understand /machine tags, which are required for 64-bit targets. The mingw32-64 project is a partial solution. I, too, would be grateful for a satisfactory solution which persuades cygwin make to use a 64-bit alternative to ar when needed. -- 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: MyC Compiled can't compile {}
Paul McFerrin wrote:
Well, after all of this discussion, my C compiler IS BROKEN. I.E.:
echo main{} test.c
/usr/local/mysql-5/mysql-5.1.41.$ cc -O test.c
test.c:1: error: expected =, ,, ;, asm or __attribute__ before { token
/usr/local/mysql-5/mysql-5.1.41.$ echo main(){} test.c
/usr/local/mysql-5/mysql-5.1.41.$ cc -O test.c
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld:
crt0.o: No such file: No such file or directory
collect2: ld returned 1 exit status
My suggestion is to completely UNINSTALL C Compiler packages and
restalled then. If others agree, could someome tell me which packages
to uninstall? Your installation may be working, but mine isn't.
If I haven't been confused by the abysmal quoting style, you've
neglected the package find tool on the cygwin home page. This indicates
that the base cygwin runtime includes crt0.o (which appears in /usr/lib).
--
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: RAM requirements for Cygwin/x
WALLACE, ANDREW F (ATTLABS) wrote: I have a laptop with 2 GB of RAM running Window XP Professional Version 2002. Do I need more RAM for Cygwin/x to work effectively? That seems unlikely. All problems I have with it, on a less powerful machine, go away upon reboot. This is Windows, after all. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: nasm -- what format does cygwin use?
Linda Walsh wrote: I am trying to compile a program that use nasm and it thought that gnuwin32 was a format for nasm (don't know if it used to be, but it's not now). Does cygwin use standard linux format now 'elf', or is it using win32?..or something else)? If running inside cygwin, you let the cygwin developers make the choice, which the binutils as will select automatically (PE-i386?). nasm might be used, I suppose, with mingw, as your comment almost implies, so becomes off topic for this list, if you refer to development for non-cygwin targets. -- 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 error
baseball07 wrote: Hi everyone I am getting this error when I try and locally access the Linux machines in my department and try and run a program called Cadence. Does anyone know what this means? Thank you. I am running Windows Vista home premium. http://old.nabble.com/file/p26408410/Untitled.jpg How about connecting by ssh -Y in your xterm? I only drive past Cadence, don't run their apps, but it should be the same for any app which wants to open an X window on your terminal. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Statistical anlysis of cygwin1.dll
Thomas Werner wrote: i need to analyse the cygwin1.dlls assembler code for statistical purpose. but therefor i need to know which compiler is used and its version. every pe tool i used said compiler unknown, so can anyone help me? If a guess that it may have been done with a gcc cross compiler of similar version to one of those included in your version of cygwin isn't good enough, you could rebuild it yourself. -- 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: coredump when compiling gettext from source
Vincent R. wrote: I have installed a fresh install of cygwin 1.7 and I wanted to compile gettext-0.17 from source so I entered: Did you apply the patch which is provided with the source when you get it via the cygwin-1.7 setup.exe? ./configure make Did I miss an instruction indicating that configure and make could run in the source directory, contrary to normal practice? If I see a failure, I'll let you know. -- 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: coredump when compiling gettext from source
Tim Prince wrote: Vincent R. wrote: I have installed a fresh install of cygwin 1.7 and I wanted to compile gettext-0.17 from source so I entered: Did you apply the patch which is provided with the source when you get it via the cygwin-1.7 setup.exe? ./configure make Did I miss an instruction indicating that configure and make could run in the source directory, contrary to normal practice? If I see a failure, I'll let you know. In my case, with no additional options, it stops on account of missing $(top_srcdir)/gnulib-m4/extensions.m4. The intl subdirectory build does throw an ld segfault at the point you indicated, with the additional message 6 [main] ld 2024 _cygtls::handle_exceptions: Error while dumping state(probably corrupted stack) -- 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: Fwd: vista+cygwin+openmpi
Jeff Brown wrote: -- Forwarded message -- From: Jeff Brown j...@loup.net Date: Sat, Sep 5, 2009 at 6:30 PM Subject: vista+cygwin+openmpi To: cygwin@cygwin.com, us...@open-mpi.org I'm trying to install openmpi under cygwin on windows vista, 32 bit version. Is there a version of openmpi that works under cygwin on windows vista? Is there a version of openmpi that works under windows vista in some other environment? Surely, such a thing would be covered in openmpi FAQ. -- 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@cygwin.com
leena21 wrote: I would appriciaite if some can tell me which floating point format is used in Cygwin environment ? If I understand your question, this depends on the your selection on the compiler command line. gcc defaults to 387 (80387) format. Normally, if you care, you would set something like -march=pentium-m, and, if you wish, -mfpmath=sse . All the usual data types are present (float, double, long double) and the storage is little-endian, same as any other compiler for the same CPU. -- 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
[Fwd: Re: cygwin gcc compatibility with MSVC numerics]
leena.padgaon...@patni.com wrote: My basic problem is that the cygwin floating addition is giving different results than VS 2008 for certain float values .Both the environments are on the same PC. So I was wondering about the floating point format used in cygwin. Btw, the makefile which I am using are having following options OPTFLAGS= -I . -O3 -funroll-loops -mtune=pentium3 -ffast-math -mfancy-math-387 Only 64-bit Windows passes the same settings of x87 precision mode (53-bit) and SSE abrupt underflow mode to both gcc and MSVC built .exe. -ffast-math would not be recommended for similarity to MSVC build, where none of the aggressive options would normally be in use. Only the abrupt underflow setting matches MSVC. If /Ox is set for MSVC, similar optimization should be obtained with gcc -O3. If you are looking for full performance, and don't need compatibility with 10-year-old CPUs, you would normally set /fp:fast /arch:SSE2 in MSVC, and corresponding -march=pentium-m -mfpmath=sse (or newer -march) in gcc. If you don't set /arch:SSE2 /fp:fast in MSVC, you imply KR style promotion of certain float expressions to double, such as you get with 387 math in gcc. ---BeginMessage--- leena.padgaon...@patni.com wrote: My basic problem is that the cygwin floating addition is giving different results than VS 2008 for certain float values .Both the environments are on the same PC. So I was wondering about the floating point format used in cygwin. Btw, the makefile which I am using are having following options OPTFLAGS= -I . -O3 -funroll-loops -mtune=pentium3 -ffast-math -mfancy-math-387 Only 64-bit Windows passes the same settings of x87 precision mode (53-bit) and SSE abrupt underflow mode to both gcc and MSVC built .exe. -ffast-math would not be recommended for similarity to MSVC build, where none of the aggressive options would normally be in use. Only the abrupt underflow setting matches MSVC. If /Ox is set for MSVC, similar optimization should be obtained with gcc -O3. If you are looking for full performance, and don't need compatibility with 10-year-old CPUs, you would normally set /fp:fast /arch:SSE2 in MSVC, and corresponding -march=pentium-m -mfpmath=sse (or newer -march) in gcc. If you don't set /arch:SSE2 /fp:fast in MSVC, you imply KR style promotion of certain float expressions to double, such as you get with 387 math in gcc. ---End Message--- -- 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
[Fwd: [Fwd: Re: cygwin gcc compatibility with MSVC numerics]]
leena.padgaon...@patni.com wrote: My basic problem is that the cygwin floating addition is giving different results than VS 2008 for certain float values .Both the environments are on the same PC. So I was wondering about the floating point format used in cygwin. Btw, the makefile which I am using are having following options OPTFLAGS= -I . -O3 -funroll-loops -mtune=pentium3 -ffast-math -mfancy-math-387 Only 64-bit Windows passes the same settings of x87 precision mode (53-bit) and SSE abrupt underflow mode to both gcc and MSVC built .exe. -ffast-math would not be recommended for similarity to MSVC build, where none of the aggressive options would normally be in use. Only the abrupt underflow setting matches MSVC. If /Ox is set for MSVC, similar optimization should be obtained with gcc -O3. If you are looking for full performance, and don't need compatibility with 10-year-old CPUs, you would normally set /fp:fast /arch:SSE2 in MSVC, and corresponding -march=pentium-m -mfpmath=sse (or newer -march) in gcc. If you don't set /arch:SSE2 /fp:fast in MSVC, you imply KR style promotion of certain float expressions to double, such as you get with 387 math in gcc. ---BeginMessage--- leena.padgaon...@patni.com wrote: My basic problem is that the cygwin floating addition is giving different results than VS 2008 for certain float values .Both the environments are on the same PC. So I was wondering about the floating point format used in cygwin. Btw, the makefile which I am using are having following options OPTFLAGS= -I . -O3 -funroll-loops -mtune=pentium3 -ffast-math -mfancy-math-387 Only 64-bit Windows passes the same settings of x87 precision mode (53-bit) and SSE abrupt underflow mode to both gcc and MSVC built .exe. -ffast-math would not be recommended for similarity to MSVC build, where none of the aggressive options would normally be in use. Only the abrupt underflow setting matches MSVC. If /Ox is set for MSVC, similar optimization should be obtained with gcc -O3. If you are looking for full performance, and don't need compatibility with 10-year-old CPUs, you would normally set /fp:fast /arch:SSE2 in MSVC, and corresponding -march=pentium-m -mfpmath=sse (or newer -march) in gcc. If you don't set /arch:SSE2 /fp:fast in MSVC, you imply KR style promotion of certain float expressions to double, such as you get with 387 math in gcc. ---BeginMessage--- leena.padgaon...@patni.com wrote: My basic problem is that the cygwin floating addition is giving different results than VS 2008 for certain float values .Both the environments are on the same PC. So I was wondering about the floating point format used in cygwin. Btw, the makefile which I am using are having following options OPTFLAGS= -I . -O3 -funroll-loops -mtune=pentium3 -ffast-math -mfancy-math-387 Only 64-bit Windows passes the same settings of x87 precision mode (53-bit) and SSE abrupt underflow mode to both gcc and MSVC built .exe. -ffast-math would not be recommended for similarity to MSVC build, where none of the aggressive options would normally be in use. Only the abrupt underflow setting matches MSVC. If /Ox is set for MSVC, similar optimization should be obtained with gcc -O3. If you are looking for full performance, and don't need compatibility with 10-year-old CPUs, you would normally set /fp:fast /arch:SSE2 in MSVC, and corresponding -march=pentium-m -mfpmath=sse (or newer -march) in gcc. If you don't set /arch:SSE2 /fp:fast in MSVC, you imply KR style promotion of certain float expressions to double, such as you get with 387 math in gcc. ---End Message--- -- 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 ---End Message--- -- 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
libgfortran using .h files from libstdc++
When I built libgfortran from the current gcc-4.5 snapshot, with cygwin 1.7 updated as of yesterday, headers were required from the libstdc++ #include bits/*.h but the path wasn't active. Is this to be expected? -- 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: To boost maintainer
Reini Urban wrote: 2009/7/1 Eray Ozkural examach...@gmail.com: xemacs is also broken I bet it's the same dynamic linking error. I recompile the testing xemacs package (xemacs-21.5-b28) frequently with gcc-4 cygwin-1.7 and it works fine. And I'm satisfied with how gfortran works if I remove the offending dynamic libraries. -- 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.
Vladimir A. Petrov wrote: I've faced with strange static linking issue in Cygwin environment. Trivial C program can not be linked against PostgreSQL libpq with the following diagnostics: $ gcc -Wall -I /cygdrive/c/Program\ Files/PostgreSQL/8.2/include/ -L /cygdrive/c/Program\ Files/PostgreSQL/8.2/lib -lpq -o pgtest.exe pgtest.c /cygdrive/c/DOCUME~1/vap/LOCALS~1/Temp/cclXAlCk.o:pgtest.c:(.text+0x33): undefined reference to `_PQconnectdb' Not strange, when gnu ld depends on order of libraries for static linking. ld doesn't rescan libraries when new references are added after the scan. It's strange enough to attempt to link libraries installed under Program Files -- 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/
