Re: cant access to files more than 128 utf-8 symbol long names
Greetings, Corinna Vinschen! > The problem here is about NAME_MAX. NAME_MAX is per POSIX[1] the > "maximum number of bytes in a filename (not including the terminating > null)." Does this mean that POSIX standard is not compatible with real life? No surprise I was having hard times copying a rather simple directory structure to a UNIX servers. Just 2 levels deep with 4-5 words in each element name. > Note the word *bytes*. Not characters, bytes. UTF-8 chars are 1 to 4 > bytes in length. Thus, the maximum number of UTF-8 chars in a filename > is potentially less than NAME_MAX: > A filename of chars only from the basic latin charset (1 byte in UTF-8) > may consist of NAME_MAX characters, a filename solely constructed from > chars of the latin-1 supplement (2 byte chars) may consist of NAME_MAX / > 2 characters, a filename constructed from emoticons (4 byte chars) only > of NAME_MAX / 4 chars. > Ok, so we all know that Windows is not using a byte representation of > filenames, rather the OS uses UTF-16 to store and handle filenames > internally. Filename on Windows filesystems may consist of 255 UTF-16 > chars[2]. > How do you represent this in a byte-oriented POSIX system? What do you > set NAME_MAX to? You can't get it right due to the unfortunate multibyte > vs. UTF-16 encoding issue. > To cover all UTF-8 chars, NAME_MAX would have to be 1020. But then, > applications relying on NAME_MAX will be surprised by ENAMETOOLONG > errors for perfectly valid POSIX filenames. > If you make it 255, applications will be surprised by ENAMETOOLONG > errors for perfectly valid Windows filenames. > If you make it 255 on the application level but then return filenames > longer than 255 multibyte chars to the application, they will crash > due to buffer overflow issues. After all, NAME_MAX is a contractual > obligation. > There was also the backward compatibility issue. Back in the pre-Cygwin > 1.7 days, when Cygwin used the ANSI file API, NAME_MAX was already 255. > Changing that to a bigger value might have resulted in the > aforementioned application crashes due to buffer overflows as well. > So we decided to keep NAME_MAX at the same value as it always was, 255. > This restricts the actual filename length when using multibyte > characters just as on any other POSIX system with the downside that, > occasionally, a Windows filename will be too long to handle. > Sorry if that is frustrating in your current situation, but this > isn't something we can just change at a whim and go ahead. It would > break compatibility with all existing Cygwin executables. > Corinna > [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html > [2] However, this does *not* cover NFS or other filesystems using a > byte representation for storing filenames. -- WBR, Andrey Repin (anrdae...@yandex.ru) 11.12.2013, <10:55> Sorry for my terrible english... -- 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: Yaakov any hope for a libnss3-debuginfo?
On Wed, Dec 11, 2013 at 12:36:58AM -0600, Yaakov (Cygwin/X) wrote: >On 2013-12-10 21:38, Christopher Faylor wrote: >> The 64-bit version of rpm2cpio is SEGVing in this call: >> >> _nss_ctx = NSS_InitContext(NULL, NULL, NULL, NULL, NULL, flags); >> >> Is there any way that you could release a debuginfo package for nss? > >nss' buildsystem is nonstandard; I'll have to see if I can hack it to >respect custom CFLAGS. But are you sure that the bug is in nss and not >nspr? I wouldn't be surprised if I missed something in either of those >two, but the latter seems more likely, and there is an nspr-debuginfo. I can't tell where the bug is. I don't get a good backtrace. Wouldn't the NSS_InitContext mean it's in nss? cgf -- 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 missing dependency for python-numpy and proposed fix
On 2013-12-10 20:38, Chris LeBlanc wrote: After installing numpy I tried importing it in a Python shell. It raised an ImportError exception when trying to import lapack_lite. Lapack_lite.dll existed in the correct location, but running "cygcheck -c" (as per http://cygwin.com/ml/cygwin/2013-05/msg00361.html) on it revealed that it needed libquadmath0 which had not been installed. Numpy worked fine once I installed the missing libquadmath0 dependency. Is anyone else seeing this problem? Should this dependency be added to the numpy setup.hint? Actually, it was libgfortran3 that was missing a dep on libquadmath0, but only on x86. I fixed that on sourceware. Thanks for the report, Yaakov -- 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: Yaakov any hope for a libnss3-debuginfo?
On 2013-12-10 21:38, Christopher Faylor wrote: The 64-bit version of rpm2cpio is SEGVing in this call: _nss_ctx = NSS_InitContext(NULL, NULL, NULL, NULL, NULL, flags); Is there any way that you could release a debuginfo package for nss? nss' buildsystem is nonstandard; I'll have to see if I can hack it to respect custom CFLAGS. But are you sure that the bug is in nss and not nspr? I wouldn't be surprised if I missed something in either of those two, but the latter seems more likely, and there is an nspr-debuginfo. Yaakov -- 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
Yaakov any hope for a libnss3-debuginfo?
Yaakov, The 64-bit version of rpm2cpio is SEGVing in this call: _nss_ctx = NSS_InitContext(NULL, NULL, NULL, NULL, NULL, flags); Is there any way that you could release a debuginfo package for nss? I could, of course, build it myself but I'd like to avoid that if possible. cgf -- 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
possible missing dependency for python-numpy and proposed fix
Hi, I recently installed a new version of Cygwin on a new Windows 7 machine. I installed a several packages including numpy. The installation worked without any errors. I did this for both 32 and 64 bit versions of Cygwin. After installing numpy I tried importing it in a Python shell. It raised an ImportError exception when trying to import lapack_lite. Lapack_lite.dll existed in the correct location, but running "cygcheck -c" (as per http://cygwin.com/ml/cygwin/2013-05/msg00361.html) on it revealed that it needed libquadmath0 which had not been installed. Numpy worked fine once I installed the missing libquadmath0 dependency. Is anyone else seeing this problem? Should this dependency be added to the numpy setup.hint? Cheers, Chris LeBlanc -- 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: ideas on how to debug an X server crash on Windows 8.1 (x64)?
On Tue, Dec 10, 2013 at 05:08:24PM -0800, Kevin Layer wrote: >For the last few weeks, I've had my X server crash a bunch of times, >taking down all my emacs windows and associated state. > >Usually I'm moving the mouse when the server dies. Today, however, I >was trying to send an email with a specific body and every time I move >to the top (with the keyboard) and move down in the email the server >crashes. > >I'm running emacs 24.3 on Fedora 17 (also x64). > >Since I never had a reproducible case, I didn't know what to report >that would be useful. > >Let me know thanks. Please use the cygwin-xfree mailing list for X related problems. cgf -- 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: ideas on how to debug an X server crash on Windows 8.1 (x64)?
I forgot to attach my XWin.0.log. Here it is: Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.14.4.0 OS: CYGWIN_NT-6.3-WOW64 hobart256 1.7.27(0.271/5/3) 2013-12-07 16:27 i686 OS: Windows 8 [Windows NT 6.2 build 9200] (WoW64) Package: version 1.14.4-1 built 2013-11-11 XWin was started with the following command line: X :0 -multiwindow ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1920 h 1200 winInitializeScreenDefaults - native DPI x 96 y 96 [2371842.187] (--) Windows reports only 2 mouse buttons, defaulting to -emulate3buttons [2371842.187] Initializing built-in extension Generic Event Extension [2371842.187] Initializing built-in extension SHAPE [2371842.187] Initializing built-in extension MIT-SHM [2371842.187] Initializing built-in extension XInputExtension [2371842.187] Initializing built-in extension XTEST [2371842.187] Initializing built-in extension BIG-REQUESTS [2371842.187] Initializing built-in extension SYNC [2371842.187] Initializing built-in extension XKEYBOARD [2371842.187] Initializing built-in extension XC-MISC [2371842.187] Initializing built-in extension XINERAMA [2371842.187] Initializing built-in extension XFIXES [2371842.187] Initializing built-in extension XFree86-Bigfont [2371842.187] Initializing built-in extension RENDER [2371842.187] Initializing built-in extension RANDR [2371842.187] Initializing built-in extension COMPOSITE [2371842.187] Initializing built-in extension DAMAGE [2371842.187] Initializing built-in extension MIT-SCREEN-SAVER [2371842.187] Initializing built-in extension DOUBLE-BUFFER [2371842.187] Initializing built-in extension RECORD [2371842.187] Initializing built-in extension DPMS [2371842.187] Initializing built-in extension X-Resource [2371842.187] Initializing built-in extension GLX [2371842.187] (II) xorg.conf is not supported [2371842.187] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [2371842.187] LoadPreferences: Loading /home/layer/.XWinrc [2371842.187] LoadPreferences: Done parsing the configuration file... [2371842.203] winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD [2371842.203] winDetectSupportedEngines - Windows NT, allowing PrimaryDD [2371842.203] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL [2371842.203] winDetectSupportedEngines - Returning, supported engines 001f [2371842.203] winSetEngine - Multi Window or Rootless => ShadowGDI [2371842.203] winScreenInit - Using Windows display depth of 32 bits per pixel [2371842.234] winAllocateFBShadowGDI - Creating DIB with width: 3840 height: 1200 depth: 32 [2371842.234] winFinishScreenInitFB - Masks: 00ff ff00 00ff [2371842.234] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 [2371842.234] winInitMultiWindowWM - Calling pthread_mutex_lock () [2371842.234] winMultiWindowXMsgProc - Calling pthread_mutex_lock () [2371842.250] MIT-SHM extension disabled due to lack of kernel support [2371842.250] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [2371842.281] GL_VERSION: 1.1.0 [2371842.281] GL_VENDOR: Microsoft Corporation [2371842.281] GL_RENDERER:GDI Generic [2371842.281] wglwrap: Can't resolve "wglGetExtensionsStringARB" [2371842.281] (EE) AIGLX: Won't use generic native renderer as it is not accelerated [2371842.296] (II) AIGLX: enabled GLX_EXT_texture_from_pixmap [2371842.296] (II) AIGLX: Loaded and initialized swrast [2371842.296] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [2371842.312] [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! [2371842.312] [dix] Could not init font path element /usr/share/fonts/Type1/, removing from list! [2371842.406] winPointerWarpCursor - Discarding first warp: 1920 600 [2371842.406] (--) 2 mouse buttons found [2371842.406] (--) Setting autorepeat to delay=500, rate=31 [2371842.406] (--) Windows keyboard layout: "0409" (0409) "US", type 4 [2371842.406] (--) Found matching XKB configuration "English (USA)" [2371842.406] (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none" [2371842.406] Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none" [2371842.406] winBlockHandler - pthread_mutex_unlock() [2371842.406] winInitMultiWindowWM - pthread_mutex_lock () returned. [2371842.406] winInitMultiWindowWM - pthread_mutex_unlock () returned. [2371842.406] winMultiWindowXMsgProc - pthread_mutex_lock () returned. [2371842.406] winInitMultiWindowWM - DISPLAY=:0.0 [2371842.406] winMultiWindowXMsgProc - pthread_mutex_unlock () returned. [2371842.406] winProcEstablishConnection - winInitClipboard returned. [2371842.406] winClipboardThreadProc - DISPLAY=:0.0 [2371842.406] winMultiWindowXMsgProc - DISPLAY=:0.0 [2371842.406] winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. [2371
Re: redirect to /dev/clipboard bug
On Dec 10 12:38, John Bianchi wrote: > I frequently redirect output to the /dev/clipboard for many of my tasks. This > started having strange problems recently: > > 'echo' can re-direct to /dev/clipboard but 'cat' cannot: > > # win8.1 enterprise: > $ uname -a > CYGWIN_NT-6.1-WOW64 hostname1 1.7.27(0.271/5/3) 2013-12-09 11:57 i686 Cygwin > $ echo test1 > /dev/clipboard > $ echo test2 > /tmp/t > $ cat /tmp/t > /dev/clipboard > cat: write error: Permission denied My fault. I removed a call to RegisterClipboardFormatW without realizing that this will break the clipboard after execve. Sorry about that. I just applied a patch which fixes this again. Please test the today's snapshot from http://cygwin.com/snapshots/, which should show up in the next couple of hours. Thanks for report and thanks in advance for testing, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpy1Gmq_XQsW.pgp Description: PGP signature
Re: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)
On 04/12/2013 22:14, Markus Hoenicka wrote: > Around 2013-12-04 16:59 Jon TURNEY was heard to say: >> On 04/12/2013 08:09, Markus Hoenicka wrote: >>> Am 2013-12-03 22:10, schrieb Christopher Faylor: I added an ugly hack to work around this symptom in the latest cygwin. It shouldn't have any big impact on anything but this particular scenario but I would appreciate it if people downloaded today's snapshot and verified that things are still working ok. I plan on addressing the actual problem for Cygwin 1.7.28. >>> >>> the nightly snapshot does not seem to do me any good with regard to the >>> clipboard problem. I performed the following test, and I hope this is what >>> you >>> had in mind: >> >> There is also a bug in xwinclip which needs fixing for this test to work >> reliably, but it was difficult to see what that was without this fix in the >> cygwin DLL. > > I see. Let me know whenever it makes sense to do any further testing. I just uploaded X server 1.14.4-2, which should have this fixed. (With cygwin DLL prior to the nightly snapshot of 2013-12-04, you may see "Spurious wake" recorded in XWin's log, but pasting should still work correctly) -- 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.8.2-2 (x86)
On Dec 10 18:32, Achim Gratz wrote: > Corinna Vinschen writes: > > Does it make sense to remove the libquadmath0gcc-ada package entirely > > for now? > > Yes, the whole libquadmath0gcc-ada directory including the files in it. > Then setup.ini should have the 4.8.2-1 package version of libquadmath as > current until it gets replaced with the -2 or -3 version. Jon? That's ok with you? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpo4v90LQXIq.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated: gcc-4.8.2-2 (x86)
Corinna Vinschen writes: > Does it make sense to remove the libquadmath0gcc-ada package entirely > for now? Yes, the whole libquadmath0gcc-ada directory including the files in it. Then setup.ini should have the 4.8.2-1 package version of libquadmath as current until it gets replaced with the -2 or -3 version. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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.8.2-2 (x86)
On Dec 10 17:49, Achim Gratz wrote: > JonY writes: > >> This update breaks libquadmath0 because the library hasn't been uploaded > >> correctly. > > > > > > OK, I see something called libquadmath0gcc-ada, my cygport file is broken. > > Thanks for looking into it. > > Meanwhile, the earlier libquadmath0 release works, but if someone is > doing a fresh install, then any programs needing this library would > require a manual install via "tar -C / -xf /..."since setup currently > only sees the borked package in the wrong directory. Does it make sense to remove the libquadmath0gcc-ada package entirely for now? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp1hKrtXBkQK.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated: gcc-4.8.2-2 (x86)
JonY writes: >> This update breaks libquadmath0 because the library hasn't been uploaded >> correctly. > > > OK, I see something called libquadmath0gcc-ada, my cygport file is broken. Thanks for looking into it. Meanwhile, the earlier libquadmath0 release works, but if someone is doing a fresh install, then any programs needing this library would require a manual install via "tar -C / -xf /..."since setup currently only sees the borked package in the wrong directory. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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: cant access to files more than 128 utf-8 symbol long names
On Tue, Dec 10, 2013 at 04:32:59PM +0100, Corinna Vinschen wrote: >On Dec 10 16:48, Noel Grandin wrote: >>On 2013-12-10 12:27, Corinna Vinschen wrote: >>>Sorry if that is frustrating in your current situation, but this isn't >>>something we can just change at a whim and go ahead. It would break >>>compatibility with all existing Cygwin executables. >> >>Maybe this is something that could be fixed only in the 64-bit version >>of Cygwin? > >Did you really read my mail? There is no fix. You can handle this >wrongly one way or the other. If in doubt, I prefer the POSIXly >correct way. Also, even if it was something that could be "fixed", since the 64-bit version of Cygwin has been out for some time now, breaking backwards compatibility would still be bad. -- 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, Chris, Corinna - thanks!
On Tue, Dec 10, 2013 at 11:35:35AM +0100, Corinna Vinschen wrote: >On Dec 9 23:13, Christopher Faylor wrote: >> On Tue, Dec 10, 2013 at 03:42:04AM +, Guy Harrison wrote: >> >It has likely been over a decade since Chris blasted me into orbit over >> >something I stuck my head over the parapet for(*). Corinna I don't >> >think I've ever wrangled with. Nevertheless, with the New Year >> >beckoning it is about time I acknowledged just how much easier life has >> >been because of them both. >> > >> >I've had a few beers tonight but even so, am I correct in thinking >> >cygwin has been around since windows2000? >> >> Cygwin has been around since at least 1996, which predates me by a year. > >First ChangeLog entry of all times: Oct 18, 1995, Steve Chamberlain. >First cgf ChangeLog entry: Sep 8, 1997. FWIW, I had someone, (*cough*, Sergey, *cough*), submitting things for me before that time. >> Larry Hall would know, I think. He was here before I was. > >And cgf is a year longer here than I am. First corinna ChangeLog entry: >Sep 23, 1998. No wonder I have to dye my hair... > >> >(*) No can't remember. Something about FreeCiv. I wrote a sound >> >kludge. Chris made me see cygwin "is unix". >> > >> >Anyways, there is no windoze system that I've ever had control of, that >> >I haven't stuck cygwin on. >> > >> >Carry on the good work & Merry Crimbo! >> >> Thanks. > >Yes, thank you very much. It's nice to get no bug report once in a >while :) Especially with a Thursday coming up. cgf -- 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: cant access to files more than 128 utf-8 symbol long names
On Dec 10 16:48, Noel Grandin wrote: > On 2013-12-10 12:27, Corinna Vinschen wrote: > >Sorry if that is frustrating in your current situation, but this > >isn't something we can just change at a whim and go ahead. It > >would break compatibility with all existing Cygwin executables. > > Maybe this is something that could be fixed only in the 64-bit version of > Cygwin? Did you really read my mail? There is no fix. You can handle this wrongly one way or the other. If in doubt, I prefer the POSIXly correct way. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqGlBt0VgjJ.pgp Description: PGP signature
Re: cant access to files more than 128 utf-8 symbol long names
On 2013-12-10 12:27, Corinna Vinschen wrote: Sorry if that is frustrating in your current situation, but this isn't something we can just change at a whim and go ahead. It would break compatibility with all existing Cygwin executables. Maybe this is something that could be fixed only in the 64-bit version of Cygwin? That would limit the compatibility damage. -- 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: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
On Wed, Dec 4, 2013 at 2:18 PM, bartel wrote: > Rebase is fine now; all I get is this harmless (?) message: > > /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll: > skipped because nonexistent. > > Nonexistent is not the whole truth: it's just a dangling symlink. > Sibling cygperl5_14.dll is fine > Is that a bug or my doing? That is a known packaging glitch in perl, yes. You can ignore it. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: clang++ broken by recent GCC update
jojelino gmail.com> writes:
> Clang does use hard-coded include path for using gcc header files.
> Please build your own or you can file bug report to clang.
>
Hardcoding header file locations isn't very clever, esp. if that means
things break even after applying a point update to gcc (4.7.3 to 4.7.x).
Below is a modified version of llvm's 3.1-cygwin-includes.patch that
attempts to address the issue for a certain time. Rather than relying on the
exact version/pathname, it assumes that someone will maintain a symlink as
is customary with shared libraries, e.g. (for current releases)
ln -s 4.8.2 /usr/lib/gcc/i686-pc-cygwin/4.8
Use setup.exe to get the llvm and clang sources and, most importantly,
llvm.cygport. Call cygport llvm.cygport prep inside /usr/src and interrupt
it when it starts patching. Replace the original includes.patch file with
the modified one, call cygport llvm.cygport all (or almostall) and go do
something else.
When this commands finishes, /usr/src/llvm-3.1-3/dist/llvm will contain all
llvm .tar.xz installer packages, which can be installed using
tar -C / -xJf package.tar.xz .
There doesn't appear to be any need to modify the libdirs.patch file.
What also surprises me is that cygwin is so much behind with llvm/clang
versions!
--- cut : 3.1-cygwin-includes.patch
--- origsrc/llvm-3.1.src/tools/clang/lib/Frontend/InitHeaderSearch.cpp
2012-03-25 17:46:17.0 -0500
+++ src/llvm-3.1.src/tools/clang/lib/Frontend/InitHeaderSearch.cpp
2012-07-05 22:02:30.907716300 -0500
@@ -296,7 +296,7 @@ void InitHeaderSearch::AddDefaultCInclud
case llvm::Triple::RTEMS:
break;
case llvm::Triple::Cygwin:
-AddPath("/usr/include/w32api", System, true, false, false);
+AddPath("/usr/lib/gcc/i686-pc-cygwin/4.5.3/include", System, true,
false, false);
break;
case llvm::Triple::MinGW32: {
// mingw-w64 crt include paths
@@ -321,6 +321,10 @@ void InitHeaderSearch::AddDefaultCInclud
if ( os != llvm::Triple::RTEMS )
AddPath("/usr/include", System, false, false, false);
+
+ /* some w32api headers collide (e.g. iODBC/ODBC32, Mesa/OpenGL) */
+ if ( os == llvm::Triple::Cygwin )
+AddPath("/usr/include/w32api", System, true, false, false);
}
void InitHeaderSearch::
@@ -369,9 +373,6 @@ AddDefaultCPlusPlusIncludePaths(const ll
case llvm::Triple::Cygwin:
// Cygwin-1.7
AddMinGWCPlusPlusIncludePaths("/usr/lib/gcc", "i686-pc-cygwin",
"4.5.3");
-AddMinGWCPlusPlusIncludePaths("/usr/lib/gcc", "i686-pc-cygwin",
"4.3.4");
-// g++-4 / Cygwin-1.5
-AddMinGWCPlusPlusIncludePaths("/usr/lib/gcc", "i686-pc-cygwin",
"4.3.2");
break;
case llvm::Triple::MinGW32:
// mingw-w64 C++ include paths (i686-w64-mingw32 and x86_64-w64-
mingw32)
@@ -386,6 +387,7 @@ AddDefaultCPlusPlusIncludePaths(const ll
AddMinGW64CXXPaths(HSOpts.ResourceDir, "4.6.3");
AddMinGW64CXXPaths(HSOpts.ResourceDir, "4.7.0");
// mingw.org C++ include paths
+AddMinGWCPlusPlusIncludePaths("/usr/lib/gcc", "i686-pc-mingw32",
"4.5.3");
AddMinGWCPlusPlusIncludePaths("/mingw/lib/gcc", "mingw32", "4.5.2");
//MSYS
AddMinGWCPlusPlusIncludePaths("c:/MinGW/lib/gcc", "mingw32", "4.6.2");
AddMinGWCPlusPlusIncludePaths("c:/MinGW/lib/gcc", "mingw32", "4.6.1");
--- origsrc/llvm-3.1.src/tools/clang/lib/Driver/ToolChains.cpp 2012-05-11
19:16:02.0 -0500
+++ src/llvm-3.1.src/tools/clang/lib/Driver/ToolChains.cpp 2012-07-04
23:51:09.272480100 -0500
@@ -2288,7 +2290,7 @@ void Linux::AddClangCXXStdlibIncludeArgs
DriverArgs, CC1Args)) {
// Gentoo is weird and places its headers inside the GCC install, so if
the
// first attempt to find the headers fails, try this pattern.
-addLibStdCXXIncludePaths(InstallDir + "/include/g++-v4",
+addLibStdCXXIncludePaths(InstallDir + "/include/c++",
(GCCInstallation.getTriple().str() +
GCCInstallation.getMultiarchSuffix()),
DriverArgs, CC1Args);
--
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.8.2-2 (x86)
On 12/10/2013 18:52, Achim Gratz wrote: > JonY <10walls gmail.com> writes: >> 4.8.2-2 is a rebuilt of -1 with an additional --libexecdir=/usr/lib, >> this should fix reports of spawn failures when called with /bon/gcc. > > This update breaks libquadmath0 because the library hasn't been uploaded > correctly. OK, I see something called libquadmath0gcc-ada, my cygport file is broken. signature.asc Description: OpenPGP digital signature
Re: emacs won't run
On Dec 10 10:34, Andrea Venturoli wrote: > On 12/06/13 17:26, Ken Brown wrote: > > >I don't know if this explains your emacs problem, but the group > >"mkgroup" indicates that /etc/group (and possibly /etc/passwd) should be > >rebuilt Don't you get a message about this when you start a shell? > > I don't get any such message. > > "mkpasswd -l" won't list me, since I'm a domain user. > "mkpasswd -l -D", "mkpasswd -l -D domain", "mkpasswd -l -d" and > "mkpasswd -l -d domain" all end with error 2221. That's weird. I never saw that happen with the -d/-D option. Especialy because mkpasswd -d/-D doesn't rely on any user name, it just asks the domain controller to list the domain accounts using the NetUserEnum function, and NetUserEnum is not documented to be able to return error 2221 (NERR_UserNotFound) at all. Are you running this under a domain account? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpS4TjEEEfRT.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated: gcc-4.8.2-2 (x86)
JonY <10walls gmail.com> writes: > 4.8.2-2 is a rebuilt of -1 with an additional --libexecdir=/usr/lib, > this should fix reports of spawn failures when called with /bon/gcc. This update breaks libquadmath0 because the library hasn't been uploaded correctly. Regards, Achim. -- 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, Chris, Corinna - thanks!
On Dec 9 23:13, Christopher Faylor wrote: > On Tue, Dec 10, 2013 at 03:42:04AM +, Guy Harrison wrote: > >It has likely been over a decade since Chris blasted me into orbit over > >something I stuck my head over the parapet for(*). Corinna I don't > >think I've ever wrangled with. Nevertheless, with the New Year > >beckoning it is about time I acknowledged just how much easier life has > >been because of them both. > > > >I've had a few beers tonight but even so, am I correct in thinking > >cygwin has been around since windows2000? > > Cygwin has been around since at least 1996, which predates me by a year. First ChangeLog entry of all times: Oct 18, 1995, Steve Chamberlain. First cgf ChangeLog entry: Sep 8, 1997. > Larry Hall would know, I think. He was here before I was. And cgf is a year longer here than I am. First corinna ChangeLog entry: Sep 23, 1998. No wonder I have to dye my hair... > >(*) No can't remember. Something about FreeCiv. I wrote a sound > >kludge. Chris made me see cygwin "is unix". > > > >Anyways, there is no windoze system that I've ever had control of, that > >I haven't stuck cygwin on. > > > >Carry on the good work & Merry Crimbo! > > Thanks. > > cgf Yes, thank you very much. It's nice to get no bug report once in a while :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp2y_AbNKkg2.pgp Description: PGP signature
Re: cant access to files more than 128 utf-8 symbol long names
On Dec 10 11:15, Nikolay Ilychev wrote: > Hello! > > When using cygwin, i can't list, copy, remove files and directories > with 128 utf-8 symbol long names. > > useless examples that illustrates the problem: > [...] > same problem with other tools - find, perl, rsync from cygwin repo. > > Please, make the MAX_PATH not for 260 bytes, but 260 utf-8 symbols. Easier said than done. First of all, this is NOT about MAX_PATH. MAX_PATH (260 chars) is the number of characters allowed in the Win32 ANSI file API for a complete path, including the terminating null. Cygwin is using the native NT API and, occasionally, the Win32 UNICODE file API, which allows paths of up to 32767 chars. The problem here is about NAME_MAX. NAME_MAX is per POSIX[1] the "maximum number of bytes in a filename (not including the terminating null)." Note the word *bytes*. Not characters, bytes. UTF-8 chars are 1 to 4 bytes in length. Thus, the maximum number of UTF-8 chars in a filename is potentially less than NAME_MAX: A filename of chars only from the basic latin charset (1 byte in UTF-8) may consist of NAME_MAX characters, a filename solely constructed from chars of the latin-1 supplement (2 byte chars) may consist of NAME_MAX / 2 characters, a filename constructed from emoticons (4 byte chars) only of NAME_MAX / 4 chars. Ok, so we all know that Windows is not using a byte representation of filenames, rather the OS uses UTF-16 to store and handle filenames internally. Filename on Windows filesystems may consist of 255 UTF-16 chars[2]. How do you represent this in a byte-oriented POSIX system? What do you set NAME_MAX to? You can't get it right due to the unfortunate multibyte vs. UTF-16 encoding issue. To cover all UTF-8 chars, NAME_MAX would have to be 1020. But then, applications relying on NAME_MAX will be surprised by ENAMETOOLONG errors for perfectly valid POSIX filenames. If you make it 255, applications will be surprised by ENAMETOOLONG errors for perfectly valid Windows filenames. If you make it 255 on the application level but then return filenames longer than 255 multibyte chars to the application, they will crash due to buffer overflow issues. After all, NAME_MAX is a contractual obligation. There was also the backward compatibility issue. Back in the pre-Cygwin 1.7 days, when Cygwin used the ANSI file API, NAME_MAX was already 255. Changing that to a bigger value might have resulted in the aforementioned application crashes due to buffer overflows as well. So we decided to keep NAME_MAX at the same value as it always was, 255. This restricts the actual filename length when using multibyte characters just as on any other POSIX system with the downside that, occasionally, a Windows filename will be too long to handle. Sorry if that is frustrating in your current situation, but this isn't something we can just change at a whim and go ahead. It would break compatibility with all existing Cygwin executables. Corinna [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html [2] However, this does *not* cover NFS or other filesystems using a byte representation for storing filenames. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp2au0HOT0is.pgp Description: PGP signature
Re: Where can I look for an answer to a problem with Cygwin's Perl‏?
On 12/09/2013 06:54 PM, Jim Cant wrote: Thanks. Unfortunately, this dump() isn't what I need. I need to produce a dump of arbitrary program that has failed somewhere out of my control in the system. The system debugger as specified by the 'AeDebug' registry key needs to get called when the arbitrary programs fails. The system debugger (which I specify in the AeDebug key) get called and passed the PID of the failed program and creates the dump I need by invoking cdb. (cdb.exe is a command line version of WInDbg My problem is the system never invoked the system debugger in cases where the arbitrary program that fails was launched by Cygwin's version of perl. I have only two suggestions: 1) please don't top post on this list 2) run gdb and see what causes perl to (not) coredump But I cannot help wonder if the perl crash on activeperl is intentional. Have you tried other ports? Native linux does not dump. Why would it? Dumping any interpreter sounds like a pretty stupid plan. Your brother might at this very moment be logging a bug against activeperl for that particular behaviour. The only good approach I can think of is to re-define the backticks to explicitely dump. That is straightforward and possibly even portable. -- - Bartels -- 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: cant access to files more than 128 utf-8 symbol long names
Greetings, Nikolay Ilychev! > Please, make the MAX_PATH not for 260 bytes, but 260 utf-8 symbols. You can't just "make MAX_PATH", this is an Operating System (i.e. Windows, not Cygwin) constant. -- WBR, Andrey Repin (anrdae...@yandex.ru) 10.12.2013, <13:37> Sorry for my terrible english... -- 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: emacs won't run
On 12/06/13 17:26, Ken Brown wrote: I don't know if this explains your emacs problem, but the group "mkgroup" indicates that /etc/group (and possibly /etc/passwd) should be rebuilt Don't you get a message about this when you start a shell? I don't get any such message. "mkpasswd -l" won't list me, since I'm a domain user. "mkpasswd -l -D", "mkpasswd -l -D domain", "mkpasswd -l -d" and "mkpasswd -l -d domain" all end with error 2221. "mkgroup -l -D >/etc/group" (run elevated) updated my /etc/group. Still no luck with emacs-x11. bye & Thanks av. -- 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
