Re: Advice for debugging heap mismatches? (Win10 Insider build 14926)
> No, that looks like I'd expect it to. You need to look at the process > map when you have fork problems, since the problem seems to be > intermittent. How so? Something like for i in `seq 1000`; do cat /proc/self/maps > procselfmaps_`date +%s.%N`.txt; done & before running the problematic command? It does take a variable amount of time to trigger, and sometimes exhibits as a complete freeze instead of an error. What should I be looking for here? > Have you tried to play around with the virus scanner settings? I already have a Windows Defender exclusion for my Cygwin installs. Turning off real-time protection temporarily didn't help. > One sure-fire way to make sure your 32-bit E: installation is not causing > havoc > with your 64-bit C: installation is to temporarily rename E:\cygwin32 to > E:\somethingelse and retry your build. This should not be necessary but I > don't > know what else to suggest. Good idea. Tried it, didn't help. -- 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)
Tony Kelman wrote: You've got two different cygwin1.dll somewhere on your PATH. For more information, I have one cygwin64 installation on C:, one cygwin32 installation on E:, and they're never both on my path at the same time. I'm not sure where that orphan registry entry that was showing up in cygcheck.out came from, but I removed it and it made no difference. With only one Cygwin installation on C: I can only come up with wild guesses. Are you somehow alternating between the C: and E: Cygwin versions, or running them simultaneously from separate windows, or accidentally running 32-bit Cygwin commands from a 64-bit Cygwin terminal window? Unusual stuff like that? One sure-fire way to make sure your 32-bit E: installation is not causing havoc with your 64-bit C: installation is to temporarily rename E:\cygwin32 to E:\somethingelse and retry your build. This should not be necessary but I don't know what else to suggest. I have in the past run 32-bit and 64-bit Cygwin installations simultaneously on the same machine, in order to build 32-bit and 64-bit Cygwin DLLs at the same time. Never had a problem. But that was Windows 7 so probably not applicable. This is absolutely due to a change in Windows itself. 3 updates in a row now, 14926, 14931, and now 14936, it's 100% reproducible just from updating Windows. Downgrading to build 14915 gets everything back working again, but that build is now expired so the only way for me to get back to a supported build of Windows where cygwin works properly is by totally reinstalling Windows. I haven't done that yet, but if we can't identify the problem and a solution soon, I will have to. 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. ..mark -- 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)
Tony Kelman writes: >> Something occupies the heap area for Cygwin, based on the low address. >> What does /proc/self/maps tell you? > > $ cat /proc/self/maps […] > > Hopefully you know what you're looking at there. Anything meaningful in that? No, that looks like I'd expect it to. You need to look at the process map when you have fork problems, since the problem seems to be intermittent. Have you tried to play around with the virus scanner settings? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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: Unknown+User Unix_Group+505 on smb shares in a domian
Wayne Porter wrote: This is how it is currently set up. I can log in to the server via ssh or use the current method, which is to map the network share using my account credentials that they have set up for me. This works just fine in Windows and for the most part in Cygwin. I can read/write from the files but vim opens all files in read-only mode and I have to save using :w! I hate it when that happens! ;-) So the files you are trying to access are from your own local login on those machines? Is there a reason why the login you have on those machines is a machine-local login? I.e. I believe you said earlier, that the machines are joined to the domain. Say your domainname="domain", and you have a domain login "wporter". Can you login (or can anyone login) using domain credentials to those linux machines? OR can you arrange to be able to, then copy your files on those machines to your domain account. If the remote files are owned by you and you are logged into your domain account on your usual cygwin machine, then the permissions should match. There's alot of permissions/privileges on Windows that don't map to anything on Linux or cygwin. So while cygwin can compare the access rights in the things it knows about, it can't begin to know about various windows permissions and controls that might allow you to override the normal file-access controls. If you can't login to the linux machines on your domain account, could you get root access long enough to chown the files over to your domain account? If you can't login to the linux machines w/your dom account, authenticating your login w/the domain server might not be enabled. Might also have to create home directory for your domain account manually. If they need to setup login checks for domain logins on those machines, they need to add some windbind rules to the /etc/pam.d/common-... Just to give you an idea (they should figure out the order by looking at relevant docs): grep winbind /etc/pam.d/common* /etc/pam.d/common-account:account sufficient pam_winbind.so /etc/pam.d/common-auth:auth sufficient pam_winbind.so /etc/pam.d/common-password:password sufficient pam_winbind.so /etc/pam.d/common-session:session sufficient pam_winbind.so -- 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)
>> Still a problem in 14936. Folks, this could be very bad. Anyone at all >> testing the insider builds, or are we going to be blindsided when an >> update goes out to everyone that breaks cygwin? > > How about you start with a sane PATH that doesn#t contain all the > Windows stuff? Set a system variable CYGWIN_NOWINPATH=true and try > again. Didn't help. BTW, that remains undocumented, ref https://cygwin.com/ml/cygwin/2014-08/msg00418.html C:\cygwin64\bin>set CYGWIN_NOWINPATH=true C:\cygwin64\bin>sh -l Tony@LAPTOP-O230JCFF ~ $ cd github/curl Tony@LAPTOP-O230JCFF ~/github/curl $ rm -rf build && mkdir build && cd build Tony@LAPTOP-O230JCFF ~/github/curl/build $ cmake .. && make -j4 && echo ok -- The C compiler identification is GNU 5.4.0 CMake Warning at /usr/share/cmake-3.6.2/Modules/Platform/CYGWIN.cmake:15 (message): CMake no longer defines WIN32 on Cygwin! (1) If you are just trying to build this project, ignore this warning or quiet it by setting CMAKE_LEGACY_CYGWIN_WIN32=0 in your environment or in the CMake cache. If later configuration or build errors occur then this project may have been written under the assumption that Cygwin is WIN32. In that case, set CMAKE_LEGACY_CYGWIN_WIN32=1 instead. (2) If you are developing this project, add the line set(CMAKE_LEGACY_CYGWIN_WIN32 0) # Remove when CMake >= 2.8.4 is required at the top of your top-level CMakeLists.txt file or set the minimum required version of CMake to 2.8.4 or higher. Then teach your project to build on Cygwin without WIN32. Call Stack (most recent call first): /usr/share/cmake-3.6.2/Modules/CMakeSystemSpecificInformation.cmake:36 (include) CMakeLists.txt:47 (project) -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done CMake Warning at CMakeLists.txt:49 (message): the curl cmake build system is poorly maintained. Be aware -- curl version=[7.51.0-DEV] -- Performing Test HAVE_SOCKADDR_IN6_SIN6_ADDR -- Performing Test HAVE_SOCKADDR_IN6_SIN6_ADDR - Success -- Performing Test HAVE_SOCKADDR_IN6_SIN6_SCOPE_ID -- Performing Test HAVE_SOCKADDR_IN6_SIN6_SCOPE_ID - Success Found *nroff option: -- -man -- Looking for dlopen in dl; -- Looking for dlopen in dl; - found -- Looking for connect in socket;dl -- Looking for connect in socket;dl - not found -- Looking for gethostbyname in c -- Looking for gethostbyname in c - found -- Looking for gethostname -- Looking for gethostname - found 0 [main] cmake 1280 child_info_fork::abort: C:\cygwin64\bin\cygintl-8.dll: Loaded to different address: parent(0x3E368) != child(0xC) [1]+ Stopped(SIGSTOP)cmake .. > Something occupies the heap area for Cygwin, based on the low address. > What does /proc/self/maps tell you? $ cat /proc/self/maps 0001-0002 rw-s : 0 [win heap 1 default shared] 0002-00021000 rw-s : 0 0003-00048000 r--s : 0 0005-00054000 r--s : 0 0006-00061000 r--s : 0 0007-00072000 rw-p : 0 0009-00099000 rw-p : 0 [win heap 0 default grow] 00099000-0019 ===p 9000 : 0 [win heap 0 default grow] 0019-00191000 rw-p : 0 [win heap 0 default grow] 00191000-001C2000 ===p 1000 : 0 [win heap 0 default grow] 0020-00352000 ===p : 0 00352000-00353000 rw-p 00152000 : 0 [peb] 00353000-00355000 rw-p 00153000 : 0 [teb (tid 7204)] 00355000-00357000 rw-p 00155000 : 0 [teb (tid 7552)] 00357000-00359000 rw-p 00157000 : 0 [teb (tid 7648)] 00359000-0035B000 rw-p 00159000 : 0 [teb (tid 10468)] 0035B000-0035D000 rw-p 0015B000 : 0 [teb (tid 3876)] 0035D000-0040 ===p 0015D000 : 0 0060-006C1000 r--s C225:5FBC 1407374885978955 /cygdrive/c/Windows/System32/locale.nls 006D-008CB000 ===p : 0 [stack (tid 7552)] 008CB000-008CE000 rw-g 001FB000 : 0 [stack (tid 7552)] 008CE000-008D rw-p 001FE000 : 0 [stack (tid 7552)] 008D-00ACB000 ===p : 0 [stack (tid 7648)] 00ACB000-00ACE000 rw-g 001FB000 : 0 [stack (tid 7648)] 00ACE000-00AD rw-p 001FE000 : 0 [stack (tid 7648)] 00AD-00CCB000 ===p : 0 [stack (tid 10468)] 00CCB000-00CCE000 rw-g 001FB000 : 0 [stack (tid 10468)] 00CCE000-00CD rw-p 001FE000 : 0 [stack (ti
Re: Unknown+User Unix_Group+505 on smb shares in a domian
On Sun, Oct 02, 2016 at 04:43:42PM -0700, Linda Walsh wrote: > Wayne Porter wrote: > > > Essentially you have a bunch of users on different machines that aren't > > > sharing their files under any common (or shared) security authority > > > (like a single domain). Until you persuade the owners of those linux > > > machines > > > to move the linux machines under a common security authority (like a > > > windows > > > domain) and moving the user accounts into the domain. Each local account > > > would have to be moved to a domain account with the files under each > > > machine-local account being moved (or "chown'ed") to the new, > > > corresponding > > > domain account). > > > > The shares are mapped and working just fine in Windows. To IT, there isn't > > anything that needs to be done. It just happens that Cygwin, which I'm the > > only > > one using, maps the Windows mapped drives to an unknown user account and > > makes > > using it difficult. > --- > Working in windows where? What does "working just fine in Windows" > mean? > That people in explorer on your machine have read+write access to the > linux-shares? > > Or do you have domain access to the machines running Windows? > Are those machine in your Domain or are they outside your domain like the > linux > machines? > If I open the W:\ drive in Windows, I have full read/write access. This is established via NET USE commands at boot. Then when I open Cygwin and navigate to the same location, which has been mapped by Cygwin to /cygdrive/w/ the user permissions appear as in my first email. Even though it says I have read-only access, I have full read/write ability. > > > > > > This is an organizational problem that has nothing to do with > > > cygwin, but whether windows and linux machines are using domain or > > > machine-local > > > security. Until your linux machines and their local user become part of > > > the > > > domain, you can't expect any "write" privileges granted to you under the > > > domain to work on the linux machines. > > > > > > > I have write permissions on those machines from Windows. Cygwin thinks I > > don't so > > files are opened in read-only mode but when I force them to be written, it > > works. > > I'm not sure if maybe I left this out of my initial information, but these > > are > > shares that are mapped in Windows on login and there are no issues there, > > but once > > I open Cygwin, I don't appear to have write access even though I do. > --- > If you have write access, then you are saying the permission are not > displaying > properly in Cygwin. So do you have the same, *actual* access in Cygwin as > windows (ignoring what permissions may be displayed)? It could be that you > have domain-admin > access and are overriding listed permissions on remote machines. If it's the > case > that your user doesn't have R+W access, but you are a domain admin, you might > just > be overriding the write-restrictions in windows as well as cygwin. > Yes, I have the same permissions, Cygwin is just displaying the wrong thing. > > > > When mapping the drives in Windows, a username and password are given. Is > > there no > > way to let Cygwin know about that username without joining the servers to > > the domain? > > I know that this setup isn't ideal, which is why I'm trying to find a > > work-around. > --- > Bingo! You need to try something like > "runas [alternate credentials + alternate password] net use W: ..." > > That might work... but is really icky, since you can't easily automate that > without storing the password in clear-text in some file in your profile... > that's > not a good solution. > There are many things currently wrong with our setup and passwords in clear-text wouldn't be anything out of the ordinary, I'm afraid. The script that maps these shares with NET USE already have them in it and load on boot, so I just need to adjust them to use "runas" instead of the current way, which is just to specify the username and password in the command? If you look at the info I provided in my first message, the NET USE script I use is there, with the username and passwords redacted. signature.asc Description: PGP signature
Re: Unknown+User Unix_Group+505 on smb shares in a domian
On Sun, Oct 02, 2016 at 04:35:21PM -0700, Linda Walsh wrote: > Wayne Porter wrote: > > The server that the W: drive is mapped on is not using domain accounts. As > > far as I know, > > all Linux servers we have are running local accounts. Is there something I > > can set in > > my local /etc/passwd to convince Cygwin to map it to my user account? > --- > Let me phrase this differently. > > The linux accounts that are not in your domain and are under > private user-names, are NOT something that you have "write" permission to. > It sounds like those users (users outside your domain -- and not within > your administrative group) have allowed "anyone" to have read access, but > it makes sense that they wouldn't trust "anonymous" (that's you, if you > haven't authenticated against their machine). You seem to be asking > for access to files owned by people outside your group (or maybe outside > your company, for that matter, it's not known). This is correct, the linux machines have local accounts that I have mapped to drive letters in Windows. They are my accounts set up with my username and password and I have full read/write access to the folders in question. Cygwin just thinks I have read-only access and when I attempt to write to the files, I can. > > The Domain is a means to provide common trusted access to a group > of people who have agreed to honor each others' permission settings. Right > now, the linux people are not in a common-trust group, so you can't force > your wanted access upon them. > > Until you and their machines share a common security token (the Domain > token), you can't have shared permission settings. > > Alternatively , you might be able to convince the linux people to > give you an account on each linux machine, and use that login when attaching > to a share on that linux machine -- but that would be a pain. Certainly, > if they agreed to use a common domain and shared things with other domain > users, that would be easier, but until they agree to be in a common domain, > you can't force your desired access upon them. > This is how it is currently set up. I can log in to the server via ssh or use the current method, which is to map the network share using my account credentials that they have set up for me. This works just fine in Windows and for the most part in Cygwin. I can read/write from the files but vim opens all files in read-only mode and I have to save using :w! signature.asc Description: PGP signature
Re: Unknown+User Unix_Group+505 on smb shares in a domian
Wayne Porter wrote: Essentially you have a bunch of users on different machines that aren't sharing their files under any common (or shared) security authority (like a single domain). Until you persuade the owners of those linux machines to move the linux machines under a common security authority (like a windows domain) and moving the user accounts into the domain. Each local account would have to be moved to a domain account with the files under each machine-local account being moved (or "chown'ed") to the new, corresponding domain account). The shares are mapped and working just fine in Windows. To IT, there isn't anything that needs to be done. It just happens that Cygwin, which I'm the only one using, maps the Windows mapped drives to an unknown user account and makes using it difficult. --- Working in windows where? What does "working just fine in Windows" mean? That people in explorer on your machine have read+write access to the linux-shares? Or do you have domain access to the machines running Windows? Are those machine in your Domain or are they outside your domain like the linux machines? This is an organizational problem that has nothing to do with cygwin, but whether windows and linux machines are using domain or machine-local security. Until your linux machines and their local user become part of the domain, you can't expect any "write" privileges granted to you under the domain to work on the linux machines. I have write permissions on those machines from Windows. Cygwin thinks I don't so files are opened in read-only mode but when I force them to be written, it works. I'm not sure if maybe I left this out of my initial information, but these are shares that are mapped in Windows on login and there are no issues there, but once I open Cygwin, I don't appear to have write access even though I do. --- If you have write access, then you are saying the permission are not displaying properly in Cygwin. So do you have the same, *actual* access in Cygwin as windows (ignoring what permissions may be displayed)? It could be that you have domain-admin access and are overriding listed permissions on remote machines. If it's the case that your user doesn't have R+W access, but you are a domain admin, you might just be overriding the write-restrictions in windows as well as cygwin. When mapping the drives in Windows, a username and password are given. Is there no way to let Cygwin know about that username without joining the servers to the domain? I know that this setup isn't ideal, which is why I'm trying to find a work-around. --- Bingo! You need to try something like "runas [alternate credentials + alternate password] net use W: ..." That might work... but is really icky, since you can't easily automate that without storing the password in clear-text in some file in your profile... that's not a good solution. -- 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: Unknown+User Unix_Group+505 on smb shares in a domian
Wayne Porter wrote: The server that the W: drive is mapped on is not using domain accounts. As far as I know, all Linux servers we have are running local accounts. Is there something I can set in my local /etc/passwd to convince Cygwin to map it to my user account? --- Let me phrase this differently. The linux accounts that are not in your domain and are under private user-names, are NOT something that you have "write" permission to. It sounds like those users (users outside your domain -- and not within your administrative group) have allowed "anyone" to have read access, but it makes sense that they wouldn't trust "anonymous" (that's you, if you haven't authenticated against their machine). You seem to be asking for access to files owned by people outside your group (or maybe outside your company, for that matter, it's not known). The Domain is a means to provide common trusted access to a group of people who have agreed to honor each others' permission settings. Right now, the linux people are not in a common-trust group, so you can't force your wanted access upon them. Until you and their machines share a common security token (the Domain token), you can't have shared permission settings. Alternatively , you might be able to convince the linux people to give you an account on each linux machine, and use that login when attaching to a share on that linux machine -- but that would be a pain. Certainly, if they agreed to use a common domain and shared things with other domain users, that would be easier, but until they agree to be in a common domain, you can't force your desired access upon them. -- 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: Native symlinks and setup.exe
Thorsten, That's a great pointer. I've just investigated using the `flex` package as an example. Untarring flex-2.6.1-1.tar.xz, usr/bin/flex++ is extracted as a Cygwin symlink to usr/bin/flex.exe. If I create a native symlink to flex.exe, tar it all up to a new tar archive, then extract it somewhere else, the native symlink is extracted as native, as expected. So, when installing, the type of symlinks doesn't honor the CYGWIN option since they are just unpacked by tar as is. The question I'm proposing now - should `tar` be modified to honor the CYGWIN option and automatically convert symlinks when extracting, if necessary? --Gene On 2 October 2016 at 14:00, Thorsten Kampe wrote: > * Gene Pavlovsky (Sat, 1 Oct 2016 18:52:47 +0300) >> >> I'm installing Cygwin 64-bit on a fresh Win 7 x64 installation. >> Before running setup.exe I've set the system env var >> CYGWIN=winsymlinks:native >> After that I ran setup-x86_64.exe and installed cygwin64. >> The symlinks to .exe files in bin, created by setup, are not native >> symlinks, they are cygwin symlinks. Apparently, setup doesn't honor >> the winsymlinks:native CYGWIN option. Is that intended (why?) or a >> bug? > > Setup does not create symlinks. That's either done by the postinstall > scripts or the contents of the package are simply unpacked to the > folder. So the answer to your question is: the symlinks are not > created but copied, that's why. > > Thorsten > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: svn_load_dirs-1.9.2-2
CYGWIN CHANGES: === Fix compatibility with svn 1.9 as described https://cygwin.com/ml/cygwin/2016-09/msg00205.html Thanks to David Stacey for the information. DESCRIPTION: svn_load_dirs is a Perl script designed to load a number of directories into Subversion. This is useful if you have a number of .zip's or tar.{Z,gz,bz2}'s for a particular package and want to load them into Subversion. CYGWIN NOTES: = svn_load_dirs used to be included in the subversion-tools package, but has been broken out into a separate package as Subversion no longer distributes the contributed tools. QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- David Rothenberger daver...@acm.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: Native symlinks and setup.exe
Greetings, Gene Pavlovsky! > I'm installing Cygwin 64-bit on a fresh Win 7 x64 installation. > Before running setup.exe I've set the system env var CYGWIN=winsymlinks:native > After that I ran setup-x86_64.exe and installed cygwin64. > The symlinks to .exe files in bin, created by setup, are not native > symlinks, they are cygwin symlinks. Apparently, setup doesn't honor > the winsymlinks:native CYGWIN option. Is that intended (why?) or a > bug? If your user is a member of Administrators group, you'd have to run setup in privileged mode to even have a chance for that ability to actually work. If not, you may control it with SeCreateSymlink privilege. -- With best regards, Andrey Repin Sunday, October 2, 2016 21:22:34 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
[ANNOUNCEMENT] Updated: Onigurama 6.1.1-1
Versions 6.1.1-1 of onig (source only) libonig4 (API bump) liboning-devel have been uploaded. DESCRIPTION Oniguruma is a regular expressions library. The characteristics of this library is that different character encoding for every regular expression object can be specified. (supported APIs: GNU regex, POSIX and Oniguruma native) Supported character encodings: ASCII, UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE, EUC-JP, EUC-TW, EUC-KR, EUC-CN, Shift_JIS, Big5, GB18030, KOI8-R, CP1251, ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16 CHANGES New upstream version https://github.com/kkos/oniguruma/releases HOMEPAGE https://github.com/kkos/oniguruma Regards Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . -- 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++0x and locale_t
On 10/1/2016 10:58 AM, Brian Inglis wrote: On 2016-10-01 07:30, Ken Brown wrote: I'm having an issue building icu, which boils down to the following test case: $ cat foo.cc #include locale_t foo; $ g++ -c --std=c++0x foo.cc foo.cc:2:1: error: ‘locale_t’ does not name a type locale_t foo; ^ If I remove '--std=c++0x', the error goes away. I know nothing about C++ standards, so I don't know if this is expected behavior or if it indicates a bug in Cygwin's headers. For C POSIX locale_t support, you have to do one or both of: #define _XOPEN_SOURCE 700 #define _POSIX_C_SOURCE 200809L to support multiple dynamic C locales and related functions. This may be done automatically if you use the default -std=gnu++03, which may have been the intent in ICU and original interpretation by g++. g++ now interprets (and deprecates) c++0x to mean c++11. You could try changing it to explicitly c++03 and see if it works, without the GNU extensions. Otherwise you should change it to explicitly gnu++03, as c++0x is deprecated, and may be dropped; g++ also deprecates c++1y aka c++14 and c++1z which may be c++17, and their gnu++ counterparts. I don't understand why ICU C++ would use C locales, when C is now trying to add a subset of features C++ has supported better, more flexibly in for over a decade; see: https://sourceforge.net/p/msys2/discussion/general/thread/23e1b5ce/ for a similar problem to yours, and the solution in standard C++; and: http://stdcxx.apache.org/doc/stdlibug/24-3.html for an explanation of the differences between C++ and C locales. OTOH ICU comes from IBM, and may be more interested in consistency across languages: how else can you explain C++ methods called createInstance? But you may just be the packager, porter, and builder, so may be unable to fix the implementation. Thanks for the information. I've submitted a patch upstream. Ken -- 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)
Tony Kelman writes: >> Could you paste a complete sample of the error message so we can >> determine where in the Cygwin code it's coming from? > > Still a problem in 14936. Folks, this could be very bad. Anyone at all > testing the insider builds, or are we going to be blindsided when an > update goes out to everyone that breaks cygwin? How about you start with a sane PATH that doesn#t contain all the Windows stuff? Set a system variable CYGWIN_NOWINPATH=true and try again. > Here's one: > > 1 [main] cp (6432) C:\cygwin64\bin\cp.exe: *** fatal error - cygheap > base mismatch detected - 0x180302408/0xD92408. > This problem is probably due to using incompatible versions of the > cygwin DLL. Something occupies the heap area for Cygwin, based on the low address. What does /proc/self/maps tell you? > And another: > > 0 [main] cmake 10384 child_info_fork::abort: > C:\cygwin64\bin\cygintl-8.dll: Loaded to different address: > parent(0x3E368) != child(0x19) Again either an address collision or some BLODA intercepting the DLL, check the memory maps to see what might be going on. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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: Setup problem: no /home/
Matthijs Nescio writes: > I am using Windows 7. During the setup, the install has hung after it > was finished, running some postinstall script for quite some time. It seems you aborted setup or your log files are truncated. Unless you let it finish the postinstall phase, you can't expect Cygwin to work correctly or at all. That said, after over an hour it hasn't got very far into the autorebase based on your logs, so I suspect that the same effect that makes the invocation of ls take so long is at play, most likely some sort of BLODA. It seems the install itself went OK, so if you can temporarily suspend your virus scanner or except the Cygwin install directory from any real-time checking, that would probably help. > One of the links suggests to run cygcheck -csv; the results are copied > below. It sais my PC has multiple cygwin1.dll files. > > -bash-4.3$ find /cygdrive/c/cygwin64 -name "cygwin1.dll" > /cygdrive/c/cygwin64/bin/cygwin1.dll > /cygdrive/c/cygwin64/usr/i686-pc-cygwin/sys-root/usr/bin/cygwin1.dll > ./cygwin1.dll > /cygdrive/c/cygwin64/bin/cygwin1.dll > /cygdrive/c/cygwin64/usr/i686-pc-cygwin/sys-root/usr/bin/cygwin1.dll > -bash-4.3$ Don't put "." in your PATH. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Native symlinks and setup.exe
* Gene Pavlovsky (Sat, 1 Oct 2016 18:52:47 +0300) > > I'm installing Cygwin 64-bit on a fresh Win 7 x64 installation. > Before running setup.exe I've set the system env var CYGWIN=winsymlinks:native > After that I ran setup-x86_64.exe and installed cygwin64. > The symlinks to .exe files in bin, created by setup, are not native > symlinks, they are cygwin symlinks. Apparently, setup doesn't honor > the winsymlinks:native CYGWIN option. Is that intended (why?) or a > bug? Setup does not create symlinks. That's either done by the postinstall scripts or the contents of the package are simply unpacked to the folder. So the answer to your question is: the symlinks are not created but copied, that's why. Thorsten -- 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: Cygwin 2.6.0-1
Am 31.08.2016 um 15:58 schrieb Corinna Vinschen: Hi folks, I uploaded a new Cygwin release 2.6.0-1. ... Somehow the way to setup the default locale has changed; raising problems as described in https://cygwin.com/ml/cygwin/2016-10/msg0.html . This affects also bash (without -l). It is "healed" per /etc/profile. However, in all previous versions since 1.7 UTF-8 was the official default deployed from the cygwin DLL already, so calling cygwin apps from a Windows command line would work as expected, which is a valid use case. I don't think this change was on purpose. - Support for POSIX-1.2008 locale objects and per-thread locales. Maybe it slipped in here? Thomas -- 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)
> You've got two different cygwin1.dll somewhere on your PATH. For more information, I have one cygwin64 installation on C:, one cygwin32 installation on E:, and they're never both on my path at the same time. I'm not sure where that orphan registry entry that was showing up in cygcheck.out came from, but I removed it and it made no difference. This is absolutely due to a change in Windows itself. 3 updates in a row now, 14926, 14931, and now 14936, it's 100% reproducible just from updating Windows. Downgrading to build 14915 gets everything back working again, but that build is now expired so the only way for me to get back to a supported build of Windows where cygwin works properly is by totally reinstalling Windows. I haven't done that yet, but if we can't identify the problem and a solution soon, I will have to. -- 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)
> You've got two different cygwin1.dll somewhere on your PATH. As your builds > proceed, they likely start out using the correct cygwin1.dll but sometimes > load > the wrong cygwin1.dll along the way. The error message tells you how to solve > the problem. But I usually use this method: > - open a Command Prompt running as Administrator > - cd c:\ or wherever the root of your Cygwin installation drive is > - dir /S cygwin1.dll > You might see multiple listings of the same cygwin1.dll due to the crazy WoW > support but these will all have the same date and size. You want to find the > cygwin1.dll that has a different date (probably older) and size. That's the > problematic one; rename it or delete it. And if not? C:\>dir /S cygwin1.dll Volume in drive C is Windows Volume Serial Number is C225-5FBC Directory of C:\cygwin64\bin 08/31/2016 05:32 AM 3,306,962 cygwin1.dll 1 File(s) 3,306,962 bytes Total Files Listed: 1 File(s) 3,306,962 bytes 0 Dir(s) 58,480,676,864 bytes free C:\> -- 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)
Tony Kelman wrote: Could you paste a complete sample of the error message so we can determine where in the Cygwin code it's coming from? Still a problem in 14936. Folks, this could be very bad. Anyone at all testing the insider builds, or are we going to be blindsided when an update goes out to everyone that breaks cygwin? Here's one: 1 [main] cp (6432) C:\cygwin64\bin\cp.exe: *** fatal error - cygheap base mismatch detected - 0x180302408/0xD92408. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start->Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. OK, you're seeing two different problems. Solving the one above is critical. It might help solve the other problem shown below; we'll have to see. You've got two different cygwin1.dll somewhere on your PATH. As your builds proceed, they likely start out using the correct cygwin1.dll but sometimes load the wrong cygwin1.dll along the way. The error message tells you how to solve the problem. But I usually use this method: - open a Command Prompt running as Administrator - cd c:\ or wherever the root of your Cygwin installation drive is - dir /S cygwin1.dll You might see multiple listings of the same cygwin1.dll due to the crazy WoW support but these will all have the same date and size. You want to find the cygwin1.dll that has a different date (probably older) and size. That's the problematic one; rename it or delete it. Then try running your build again. And another: 0 [main] cmake 10384 child_info_fork::abort: C:\cygwin64\bin\cygintl-8.dll: Loaded to different address: parent(0x3E368) != child(0x19) This is a garden-variety fork() failure due to the child having something in its address space at 0x3E368 such that Cygwin can't load cygintl-8.dll at that address where the parent has it. But since you've apparently got two Cygwin installations on your PATH, maybe that's complicating things. See if fixing the first problem above makes this problem go away too. ..mark -- 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