Re: rebase db perms seem too restrictive
Greetings, Shaddy Baddah! > I expect that there wasn't any explicit reasoning behind this, but > rebase creates a db with permissions that are too restrictive. To me > anyway, as I cannot see any danger in the db being readable by all. > This snippet describes it: > > $ whoami > sbaddah > $ od -c /etc/rebase.db.x86_64 > od: /etc/rebase.db.x86_64: Permission denied > $ ls -l /etc/rebase.db.x86_64 > -rw-rw 1 portapps None 86020 Nov 11 15:34 /etc/rebase.db.x86_64 > > I've attached an untested patch that would allow at least world readable > perms. It would be appreciated if it was applied :-) There's no reason or need for this file to be world readable. Even more, I think the fact that there's group access perms is a consequence of shallow translation of ACLs to POSIX permissions, given the group name and the fact you're unable to access the file. -- WBR, Andrey Repin (anrdae...@yandex.ru) 17.11.2014, <11:16> 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
Question about having msvcrt*.dll and cygwin1.dll in one process
Hi all,
Cygwin FAQ 6.15 says that I cannot link with both MSVCRT*.dll and
cygwin1.dll since they are mutually exclusive. However, I can successfully
run a simple Windows console application which dynamically loads a dll
(compiled in Cygwin, thus linking to cygwin1.dll). The Windows console
application is built with Multi-threaded DLL (/MD). So what's the problem
of linking to both MSVCRT*.dll and cygwin1.dll. Am I missing anything?
// test.cpp, DLL code compiled in Cygwin
#include
int hello(void)
{
printf ("welcome to linux world\n");
return 777;
}
This is the code to produce dll
$ gcc -g -O2 -c test.cpp
$ gcc -shared -o test.dll test.o
// main application compiled in MSVC, with /MD
#include
#include
int main()
{
char padding[32768];
memset(padding, 0, sizeof(padding));
HMODULE h = LoadLibrary(TEXT("C:\\cygwin64\\bin\\cygwin1.dll"));
if (!h)
{
DWORD code = GetLastError();
printf ("can't load cygwin1.dll, code %d\n", code);
return 0;
}
typedef void (WINAPI *INITFUC)();
INITFUC init = NULL;
init = (INITFUC) GetProcAddress(h, "cygwin_dll_init");
if (!init)
{
printf ("can't find cygwin_dll_init()\n");
return 0;
}
init();
h = LoadLibrary(TEXT("E:\\opensource\\Cygwin\\test\\test.dll"));
if (!h)
{
DWORD code = GetLastError();
printf ("can't load test.dll, code %d\n", code);
return 0;
}
typedef int (*MYFUNC)(void);
MYFUNC f = NULL;
f = (MYFUNC) GetProcAddress(h, "_Z5hellov");
if (!f)
{
printf ("can't find hello()\n");
return 0;
}
int res = (*f)();
printf ("res: %d\n", res);
printf ("it's over\n");
getchar();
return 0;
}
The outputs:
welcome to linux world
res: 777
it's over
So everything look fine. According to the FAQ 6.15, is there anything
that's potentially dangerous that I should be aware of, when linking both
msvcrt.dll and cygwin1.dll? Thanks a lot!
Thanks,
Jing Zhao @ Shanghai
Ext. 3273
8+ 7023273
--
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: rebase db perms seem too restrictive
On Nov 17 14:14, Shaddy Baddah wrote:
> Hi,
>
> I expect that there wasn't any explicit reasoning behind this, but
> rebase creates a db with permissions that are too restrictive. To me
> anyway, as I cannot see any danger in the db being readable by all.
>
> This snippet describes it:
>
>
> $ whoami
> sbaddah
> $ od -c /etc/rebase.db.x86_64
> od: /etc/rebase.db.x86_64: Permission denied
> $ ls -l /etc/rebase.db.x86_64
> -rw-rw 1 portapps None 86020 Nov 11 15:34 /etc/rebase.db.x86_64
>
>
> I've attached an untested patch that would allow at least world readable
> perms. It would be appreciated if it was applied :-)
>
> --
> Regards,
> Shaddy
> diff --git a/rebase.c b/rebase.c
> index 9504a48..a078e1d 100644
> --- a/rebase.c
> +++ b/rebase.c
> @@ -288,7 +288,7 @@ mkstemp (char *name)
> {
>return _open (mktemp (name),
>O_RDWR | O_BINARY | O_CREAT | O_EXCL | O_TRUNC | _O_SHORT_LIVED,
> - _S_IREAD|_S_IWRITE);
> + _S_IREAD|_S_IWRITE|S_IRGRP|S_IROTH);
> }
> #endif
That won't work. Check the surroundng #ifdef's. The mkstemp
replacement function is only called when building rebase for Mingw. If
it's called on Cygwin, it uses Cygwin's implementation of mkstemp,
which follows the (security) lead of other POSIX systems and creates
the files with 0600 permissions. After the file got written, the
permissions are changed, see lines 358ff.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpDvwhKnr9LK.pgp
Description: PGP signature
Re: Question about having msvcrt*.dll and cygwin1.dll in one process
2014-11-17 9:47 GMT+01:00 Jing Zhao : > The outputs: > welcome to linux world > res: 777 > it's over > > So everything look fine. According to the FAQ 6.15, is there anything > that's potentially dangerous that I should be aware of, when linking both > msvcrt.dll and cygwin1.dll? Thanks a lot! If it works, then you are simply lucky. Some pitfalls I know off: - when using stdin/stdout/stderr, msvcrt and cygwin1.dll have their own implementation, which might conflict: locking over multiple threads works differently, buffering is different. So if both your application and the dll write to stdout, the order in which both outputs are intermixed is not guaranteed. - exception handling is different. Don't expect an exception being thrown in the dll to be handled gracefully in the application. - threading functions are different, same story. - dll initialization is different (recently a bug was fixed regarding this, in a pre-fix version of cygwin1.dll your current example might simply crash) That are just 3 pitfalls I know of, I'm sure there are more. So in stead of stating that it doesn't work, a better formulation would be that it is unsupported. But don't expect any fundamental help here, it's tricky stuff (apart from the question who really would want this ...) Regards, Jan Nijtmans -- 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.6
On Nov 15 15:45, Christian Franke wrote:
> Corinna Vinschen wrote:
> >>The actual test scripts & tools from this use case pass local usernames
> >>from/to non-Cygwin programs and rely on the fact that Cygwin and Windows
> >>username match.
> >>
> >>For the long term, have some cyguser, cyggroup tools (similar to cygpath)
> >>which convert the names would be helpful.
> >Feel free to provide them. I'm not quite sure what kind of conversion
> >you're thinking about. Cygwin->Windows? If so, you can get that
> >with simple scripts:
> >
> > pwd_entry=$(/usr/bin/getent passwd "$username")
> > # Extract Windows username and domain
> > tmp="${pwd_entry#*:*:*:*U-}"
> > tmp="${pwd_entry%%,*}"
> > domain="${tmp%\\*}"
> > username="${tmp#*\\}"
>
> Works, except when Cygwin does not provide a "U-*\NAME," in the gecos field.
> This is the case for Local Service, Network Service and Administrators.
This can be fixed easily.
> Tested in db-only mode with 1.7.34-001:
>
> $ getent passwd localservice
> localservice:*:19:19:,S-1-5-19:/:/sbin/nologin
>
>
> BTW, TrustedInstaller is not found by getent:
>
> $ getent passwd TrustedInstaller ; echo $?
> 2
>
> $ getent passwd 328384 ; echo $?
> 2
Oh, right. This affects all "NT SERVICE" accounts. However, this
also shows another problem. Every service has its own SID under
the NT SERVICE scheme. This allows to print any service as a passwd
or group entry. To avoid collisions I think the right thing to do
here is to always prefix NT SERVICE accounts, including TrustedInstaller:
NT SERVICE+TrustedInstaller:*:328384:328384:U-NT
SERVICE\TrustedInstaller,S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464:/:/sbin/nologin
I applied a patch for both of the above to CVS.
> What will be the future 'official' way for the opposite Windows->Cygwin
> conversion? Some tool that uses CW_CYGNAME_FROM_WINNAME ?
In theory, the right tool for this would be... getent. Just as I
added a way to use the S- syntax, I can add a way to use the
U-domain\username syntax. This allows to use the same tool for both
directions and then simply filter out the account name you need.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpNbidIX5DVL.pgp
Description: PGP signature
Re: Changed syntax for rename
On Nov 15 06:13, Fergus Daly wrote: > Following (I think) the recent update of the dll cygwin1.dll it seems that > rename old new * > no longer works and the cause is the wildcard. You have to use something like > rename old new f* > and the command might need several invocations with minor variants to achieve > all the required changes. > Is this change intended? > Was the update to cygwin1.dll the cause? Certainly not. There were no changes in globbing. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpWdD6v1prh8.pgp Description: PGP signature
Re: Bug Report on Patcher for KSP
On Nov 14 22:22, Ian Hawkins wrote: > 1 [main] rsync 1176 find_fast_cwd: WARNING: Couldn't compute FAST_CWD > pointer. Please report this problem to Old Cygwin version, please update. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpG7jgHlD6Z6.pgp Description: PGP signature
getent extra output
$ uname -svr CYGWIN_NT-6.1-WOW64 1.7.33-2(0.280/5/3) 2014-11-13 15:45 $ uname -svr CYGWIN_NT-6.1 1.7.33-2(0.280/5/3) 2014-11-13 15:47 on both there is an extra output line $ getent passwd SYSTEM:*:18:544:,S-1-5-18:: LocalService:*:19:544:U-NT AUTHORITY\LocalService,S-1-5-19:: NetworkService:*:20:544:U-NT AUTHORITY\NetworkService,S-1-5-20:: Administrators:*:544:544:,S-1-5-32-544:: [cut] :*:4294967295:4294967295::: $ cat /etc/passwd |wc -l 12 $ getent passwd |wc -l 13 Regards Marco -- 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: Poco test using clock_gettime() and gettimeofday()
Hi David, On Nov 15 16:56, David Stacey wrote: > I'm trying to get the (rather extensive) testsuite for poco-1.4.7 passing - > or at least satisfying myself that any failures are not due to a Cygwin > problem. The last test I have to worry about is 'testDequeue' from the > Foundation testsuite. > > The Poco code uses two clock classes, one that uses clock_getttime() and the > other uses gettimeofday(). The test creates two timestamps using the two > clock classes, both 0.1 seconds in the future. clock_gettime() is polled > repeatedly until the timestamp is reached. Then the other timestamp is > checked (using gettimeofday()) to ensure that 0.1 seconds has elapsed on > this clock also. > > I've managed to condense this down into the sample programme attached. This > always passes in Fedora 20, but passes or fails randomly in Cygwin. > > I'm not convinced that the test is valid. Poco seems to be making > assumptions about clock_gettime() and gettimeofday() that simply aren't > guaranteed to hold - but obviously do in Fedora at least. For instance, the > test must be assuming that either the accuracy of the two routines is > identical, or be making assumptions about rounding in the less accurate > routine. > > I think it would be better to patch the test so that it uses clock_gettime() > exclusively (and not gettimeofday() at all), and then this problem will > disappear. But I thought I would submit it here to see what you thought > before raising a ticket with the Poco developers. > > What do you think? Same as you. One problem is that CLOCK_REALTIME (which is the one used by gettimeofday) is not monotonic by definition, see for instance the Linux man page: This clock is affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the clock), and by the incremental adjustments performed by adjtime(3) and NTP. The second problem, and that's the one affecting this testcase mostly, is the accuracy of the timer (see clock_getres function). Implemenation details: For the monotonic clock, Cygwin uses the Windows performance counters, which have a pretty high accuracy. Up to Windows 7, Cygwin uses the values returned by GetSystemTimeAsFileTime as system time. The accuracy of this clock is rather on the low side. Starting with Windows 8, Cygwin's realtime clock uses the new function GetSystemTimePreciseAsFileTime, which returns the system time with an accuracy < 1 µs. I tried your testcase under Windows 8.1, and it never fails. On Windows 7 it's as you said, it fails a lot. Still, I think the testcase is flawed, because it makes assumtions about the accuracy of two different clock sources, which is invalid. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpyTJBrE9GGQ.pgp Description: PGP signature
RE: gfortran netcdf version mismatch
Thanks Marco! > -Original Message- > From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On > Behalf Of Marco Atzeri > Sent: November-15-14 11:39 AM > To: cygwin@cygwin.com > Subject: Re: gfortran netcdf version mismatch > > On 11/14/2014 9:32 AM, Marco Atzeri wrote: > > On 11/13/2014 4:46 PM, Marco Atzeri wrote: > >> On 11/13/2014 4:35 PM, DeTracey, Brendan wrote: > >>> Hi, > >>> > >>> Trying to compile using gfortran and netcdf I get: > >>> Fatal Error: Cannot read module file 'netcdf.mod' opened at (1), > >>> because it was created by a different version of GNU Fortran > >>> > > rebuilt all with gcc-4.8.3 compilers. > It seems gfortran version must be same for netcdf and netcdf-gfortran > > Let me know if you have further problem > Regards > Marco > > > -- > 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
Re: getent extra output
On Nov 17 11:41, Marco Atzeri wrote: > $ uname -svr > CYGWIN_NT-6.1-WOW64 1.7.33-2(0.280/5/3) 2014-11-13 15:45 > > $ uname -svr > CYGWIN_NT-6.1 1.7.33-2(0.280/5/3) 2014-11-13 15:47 > > on both there is an extra output line > > $ getent passwd > SYSTEM:*:18:544:,S-1-5-18:: > LocalService:*:19:544:U-NT AUTHORITY\LocalService,S-1-5-19:: > NetworkService:*:20:544:U-NT AUTHORITY\NetworkService,S-1-5-20:: > Administrators:*:544:544:,S-1-5-32-544:: > [cut] > :*:4294967295:4294967295::: Heh. Yeah. That's a bit... unfortunate. This won't happen under 1.7.34, but there's not a lot I can do now to fix this for 1.7.33, except tweaking getent itself to drop the entry hardcoded. I guess I have to change getent anyway to support the U-domain\username option, I'll look into doing that one, too. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpDCIW9Te99z.pgp Description: PGP signature
Re: [REQUEST] Please upgrade irssi (0.8.17)
On Sun, Nov 16, 2014 at 5:26 AM, Alive wrote: > On 11/15/2014 5:50 AM, Marco Atzeri wrote: >> uploaded irssi-0.8.17-2 with SSL3 disabled >> >> Regards >> Marco > > Currently running irssi-0.8.17-2 with no problem. > Successfully connected to freenode and oftc through TLS with no problem. > > Still no crash so far. Installed irssi-0.8.17-2 with latest version of cygwin and have been using it all weekend with zero issues. Thank you for the update. Stay safe. -Sean -- 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: Question about having msvcrt*.dll and cygwin1.dll in one process
On Mon, Nov 17, 2014 at 4:48 AM, Jan Nijtmanswrote: > 2014-11-17 9:47 GMT+01:00 Jing Zhao : >> The outputs: >> welcome to linux world >> res: 777 >> it's over >> >> So everything look fine. According to the FAQ 6.15, is there anything >> that's potentially dangerous that I should be aware of, when linking both >> msvcrt.dll and cygwin1.dll? Thanks a lot! > > If it works, then you are simply lucky. Some pitfalls I know off: > Certainly lucky and usually won't work on all systems or even the same system consistently. > - when using stdin/stdout/stderr, msvcrt and cygwin1.dll have > their own implementation, which might conflict: locking over > multiple threads works differently, buffering is different. So > if both your application and the dll write to stdout, the > order in which both outputs are intermixed is not guaranteed. > - exception handling is different. Don't expect an exception being > thrown in the dll to be handled gracefully in the application. > - threading functions are different, same story. > - dll initialization is different (recently a bug was fixed > regarding this, in a pre-fix version of cygwin1.dll your > current example might simply crash) > Memory control is the biggest issue. Two different runtimes controlling the same memory segments will not work! -- cyg 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
Re: /usr/local, /var and */tmp in c:\Users\Public
On Sat, Nov 15, 2014 at 1:41 PM, Lee wrote: > On 11/15/14, Jeffrey Altman wrote: >> On 11/15/2014 12:55 PM, Lee wrote: >> So, just because I installed Cygwin with my regular user account, >>> >>> You're doing it wrong. Install Cygwin using an admin account and >>> regular user accounts are not allowed write access to system >>> files/directories: >> >> This feels really wrong to me. If installing Cygwin under a non-admin >> account results in a potential security vulnerability, then the >> installer should be taking that into account. > > I would argue that no, the installer should _not_ take that into > account. If someone wants to install cygwin under their regular > userid, why should the installer try to work around that? The files > are installed with the "correct" permissions if the windows admin has > an administrator account for doing admin chores & a regular user > account for doing day to day user tasks. Because a user who is using a corporate laptop with administrator accounts locked down would not be able to install Cygwin. Because a user who is used to having ownership of the files he installs would become frustrated that he could not remove Cygwin by simply opening the Windows explorer, picking his way to the Cygwin root folder, right clicking it and saying Delete. Because this list would become overrun with queries of why can't I add a program from an archive to the /usr/bin directory or remove or ... An install "Only for the user" should not create such locked down control of the system without asking. Some users tend to know what to do and what not to do and do not want the extra measures to protect themselves. -- cyg 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
32-bit/64-bit sharing of Local Package Directories
I currently maintain separate 32-bit and 64-bit versions of Cygwin. I have separate "Local Package Directory"s for them, but that seems unnecessary since almost everything is maintained separately: The setup binaries have different names and the mirror folders contain different subfolder names (x86 or x86_64). The exceptions are the setup log files. It would be nice if the setup.log and setup.log.full files would also be named (or placed in different folders) to distinguish between 32-bit and 64-bit versions. Then we could have the two versions of Cygwin share the same Local Package Directory without conflict. Indeed, this is a low-priority item, so not worth arguing about. --Ken Nellis -- 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: 32-bit/64-bit sharing of Local Package Directories
Greetings, Nellis, Kenneth!
> I currently maintain separate 32-bit and 64-bit versions of Cygwin.
> I have separate "Local Package Directory"s for them, but that seems
> unnecessary since almost everything is maintained separately: The
> setup binaries have different names and the mirror folders contain
> different subfolder names (x86 or x86_64). The exceptions are the
> setup log files.
> It would be nice if the setup.log and setup.log.full files would
> also be named (or placed in different folders) to distinguish
> between 32-bit and 64-bit versions. Then we could have the two
> versions of Cygwin share the same Local Package Directory without
> conflict.
> Indeed, this is a low-priority item, so not worth arguing about.
I think you've used your current installation directory a little too long. :)
Delete the setup.log{,.full}, they are no longer placed along the Cygwin setup
executable. Mine's not been changed since september.
--
WBR,
Andrey Repin (anrdae...@yandex.ru) 17.11.2014, <19:02>
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] New package: getent-2.18.90-3
Hi folks, I just uploaded getent-2.18.90-3. getent is a Glibc tool which allows to fetch host, passwd, group, protocol, and service information via a simple tool. The -3 version introduces the ability to ask for passwd and group entries via Windows username/groupname, using the "U-" prefix as in Cygwin's pw_gecos field: $ getent passwd U-BUILTIN\\Administrator Administrators:*:544:544:,S-1-5-32-544:: You can skip the domain name. In this case getent relies on the default account name resolution order of the underlying LookupAccountName(*) function $ getent passwd U-Administrator Administrators:*:544:544:,S-1-5-32-544:: This release also fixes the problem that under current versions of Cygwin an entry for the user/group name "" is printed when enumerating user or group accounts. = IMPORTANT (not only) FOR CYGWIN PACKAGE MAINTAINERS = The most important aspect for Cygwin for the near future is this: With the new passwd/group code just in testing (see https://cygwin.com/preliminary-ntsec.html for lots and lots of information), tools and scripts must not rely anymore on being able to grep user and group information from /etc/passwd and /etc/group! The new way to read passwd and group information from, for instance, service installation helper scripts, is to use the getent tool for this purpose. I'd like to urge all maintainers which provide such scripts to look into their packages and fix them to use the getent tool, rather than grep'ing /etc/passwd and /etc/group directly. = (*) http://msdn.microsoft.com/en-us/library/windows/desktop/aa379159%28v=vs.85%29.aspx Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: getent extra output
On Nov 17 13:45, Corinna Vinschen wrote: > On Nov 17 11:41, Marco Atzeri wrote: > > $ uname -svr > > CYGWIN_NT-6.1-WOW64 1.7.33-2(0.280/5/3) 2014-11-13 15:45 > > > > $ uname -svr > > CYGWIN_NT-6.1 1.7.33-2(0.280/5/3) 2014-11-13 15:47 > > > > on both there is an extra output line > > > > $ getent passwd > > SYSTEM:*:18:544:,S-1-5-18:: > > LocalService:*:19:544:U-NT AUTHORITY\LocalService,S-1-5-19:: > > NetworkService:*:20:544:U-NT AUTHORITY\NetworkService,S-1-5-20:: > > Administrators:*:544:544:,S-1-5-32-544:: > > [cut] > > :*:4294967295:4294967295::: > > Heh. Yeah. That's a bit... unfortunate. This won't happen under > 1.7.34, but there's not a lot I can do now to fix this for 1.7.33, > except tweaking getent itself to drop the entry hardcoded. I guess > I have to change getent anyway to support the U-domain\username > option, I'll look into doing that one, too. https://cygwin.com/ml/cygwin-announce/2014-11/msg00032.html HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpmzRsr2bsmi.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6
On Nov 17 11:11, Corinna Vinschen wrote: > On Nov 15 15:45, Christian Franke wrote: > > What will be the future 'official' way for the opposite Windows->Cygwin > > conversion? Some tool that uses CW_CYGNAME_FROM_WINNAME ? > > In theory, the right tool for this would be... getent. Just as I > added a way to use the S- syntax, I can add a way to use the > U-domain\username syntax. This allows to use the same tool for both > directions and then simply filter out the account name you need. https://cygwin.com/ml/cygwin-announce/2014-11/msg00032.html HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp9_sFeQeheF.pgp Description: PGP signature
Re: Poco test using clock_gettime() and gettimeofday()
On 17/11/14 12:41, Corinna Vinschen wrote: On Nov 15 16:56, David Stacey wrote: I'm not convinced that the test is valid. Poco seems to be making assumptions about clock_gettime() and gettimeofday() that simply aren't guaranteed to hold - but obviously do in Fedora at least. For instance, the test must be assuming that either the accuracy of the two routines is identical, or be making assumptions about rounding in the less accurate routine. I think it would be better to patch the test so that it uses clock_gettime() exclusively (and not gettimeofday() at all), and then this problem will disappear. But I thought I would submit it here to see what you thought before raising a ticket with the Poco developers. What do you think? Same as you. One problem is that CLOCK_REALTIME (which is the one used by gettimeofday) is not monotonic by definition, see for instance the Linux man page: This clock is affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the clock), and by the incremental adjustments performed by adjtime(3) and NTP. The second problem, and that's the one affecting this testcase mostly, is the accuracy of the timer (see clock_getres function). Thank you for confirming my suspicions. I'll patch the test and roll a poco-1.4.7 later in the week. I'll also raise a ticket and get this fixed upstream. Thanks once again, Dave. -- 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: 32-bit/64-bit sharing of Local Package Directories
> From: Andrey Repin
>
> I think you've used your current installation directory a little too long.
> :) Delete the setup.log{,.full}, they are no longer placed along the
> Cygwin setup executable. Mine's not been changed since september.
Hmm... Okay, I see that. Deleted! Thanx for that.
I also see like-named files in /var/log.
$ find /cygdrive/c/cygwin* -name 'setup.log*'
/cygdrive/c/cygwin/var/log/setup.log
/cygdrive/c/cygwin/var/log/setup.log.full
/cygdrive/c/cygwin64/var/log/setup.log
/cygdrive/c/cygwin64/var/log/setup.log.full
$
But I also notice that like-named files are also occasionally created
in my now-shared folder where my two setup-x86*.exe files reside:
$ ls -ld setup.log*
-rw-r--r-- 1 knellis Domain Users 374 Nov 17 13:04 setup.log
-rw-r--r-- 1 knellis Domain Users 374 Nov 17 13:04 setup.log.full
$ cat setup.log
2014/11/17 13:04:41 Starting cygwin install, version 2.852
2014/11/17 13:04:41 User has backup/restore rights
2014/11/17 13:04:41 Current Directory:
C:\Users\knellis\Documents\Installers\Cygwin
2014/11/17 13:04:41 Could not open service McShield for query, start and stop.
McAfee may not be installed, or we don't have access.
2014/11/17 13:04:46 Ending cygwin install
$
(setup.log.full is identical.)
But, experimenting, I've hidden these files and rerun Setup, and they don't
always get recreated, so I'm curious as to what's going on.
So, it seems there is still a name conflict between the 32-bit and
64-bit versions of these files as first reported.
--Ken Nellis
--
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: Ruby on Rails 4.0.12
The following packages have been updated in the Cygwin distribution: * ruby-actionmailer-4.0.12-1 * ruby-actionpack-4.0.12-1 * ruby-activemodel-4.0.12-1 * ruby-activerecord-4.0.12-1 * ruby-activesupport-4.0.12-1 * ruby-rails-4.0.12-1 * ruby-railties-4.0.12-1 Rails is a web application development framework written in the Ruby language. It is designed to make programming web applications easier by making assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks. These releases represent the latest upstream patch release of Rails 4.0, including security fixes: http://weblog.rubyonrails.org/2014/11/17/Rails-3-2-21-4-0-12-and-4-1-8-have-been-released/ Installing the 'ruby-rails' package and its dependencies should provide the gems required for an application in the default configuration; optional dependencies also available need to be selected separately for installation. Because of how gem dependencies work, in order to assure that you use these versions, the following steps must be followed when creating a new Rails application: $ rails new testapp1 --skip-bundle (files are installed) $ cd testapp1 $ bundle install --local (this will show that existing gems are being used) $ rails server (then point browser to http://localhost:3000/, or install rails-unicorn and...) $ unicorn_rails (then point browser to http://localhost:8080/) And to upgrade existing apps to this version of Rails: $ $EDITOR Gemfile (and update the gem 'rails' version number) $ bundle update --local (Existing gems should be found and used.) $ rake rails:update (and follow the prompts to update files) If you do not use the --local flags as indicated above, then other versions of these gems may end up being installed, which may break things either then or down the road. As always, you get to keep both pieces. :-) -- 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
[ANNOUNCEMENT] Updated: poco-1.4.6p4-2
The following packages have been updated: - poco-1.4.6p4-2 - libpoco-devel-1.4.6p4-2 - libpoco-doc-1.4.6p4-2 - libpoco16-1.4.6p4-2 - poco-debuginfo-1.4.6p4-2 PORT NOTES == The previous build of poco-1.4.6p4 contained an incomplete documentation package. This was due to a packaging error upstream, which has since been fixed. This rebuild of 1.4.6p4 picks up the complete documentation package. DESCRIPTION === Poco is a collection of modern, powerful open source C++ class libraries and frameworks for building network- and internet-based applications that run on desktop, server, mobile and embedded systems. They simplify and accelerate the development of network-centric, portable applications in C++. CHANGE LOG == https://raw.github.com/pocoproject/poco/poco-1.4.6p4-release/CHANGELOG Release 1.4.6p4 (2014-04-18) - no longer use reverse DNS lookups for cert hostname validation - cert hostname validation is case insensitive and more strict - HTMLForm: in URL encoding, percent-encode more special characters - fixed thread priority issues on POSIX platforms with non-standard scheduling policy - XMLWriter no longer escapes apostrophe character - fixed GH# 316: Poco::DateTimeFormatter::append() gives wrong result for Poco::LocalDateTime - fixed GH# 305 (memcpy in Poco::Buffer uses wrong size if type != char) - Zip: fixed a crash caused by an I/O error (e.g., full disk) while creating a Zip archive HOMEPAGE http://pocoproject.org/ Cheers, Dave. If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: perl-Text-CSV_XS-1.12-1
Version 1.12-1 of perl-Text-CSV_XS has been uploaded. CHANGE LOG == 1.12- 2014-11-01, H.Merijn Brand * Add field number to error_diag * Fixed non-IO parsing multi-byte EOL * Fixed a possible missed multi-byte EOL * Allow hashref for csv ()'s headers attribute * Allow encoding on all output handles in csv () * Include doc changes as ticketed in the Text::CSV queue * Fix parallel testing issue * Allow csv as method call (not using the object) * Rename quote_null to escape_null * Give meaning to keep_meta_info on output DESCRIPTION === Text::CSV_XS provides facilities for the composition and decomposition of comma-separated values. An instance of the Text::CSV_XS class will combine fields into a CSV string and parse a CSV string into fields. The module accepts either strings or files as input and support the use of user-specified characters for delimiters, separators, and escapes. CPAN http://search.cpan.org/~hmbrand/Text-CSV_XS/CSV_XS.pm Cheers, Dave. If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: perl-Text-CSV_XS-1.12-2 [TEST]
Version 1.12-2 of perl-Text-CSV_XS has been uploaded. This is a test release, built against the test version of perl 5.18.2, and is only available for x86 at this time. CHANGE LOG == 1.12- 2014-11-01, H.Merijn Brand * Add field number to error_diag * Fixed non-IO parsing multi-byte EOL * Fixed a possible missed multi-byte EOL * Allow hashref for csv ()'s headers attribute * Allow encoding on all output handles in csv () * Include doc changes as ticketed in the Text::CSV queue * Fix parallel testing issue * Allow csv as method call (not using the object) * Rename quote_null to escape_null * Give meaning to keep_meta_info on output DESCRIPTION === Text::CSV_XS provides facilities for the composition and decomposition of comma-separated values. An instance of the Text::CSV_XS class will combine fields into a CSV string and parse a CSV string into fields. The module accepts either strings or files as input and support the use of user-specified characters for delimiters, separators, and escapes. CPAN http://search.cpan.org/~hmbrand/Text-CSV_XS/CSV_XS.pm Cheers, Dave. If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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 and cygstdc++-6.dll account for over 70% of application runtime cost
According to the AMD CodeXL profiler, the modules cygwin1.dll and cygstdc++-6.dll account for 65.67% and 5.13% respectively of the runtime of my code. The breakdown is shown below: Function ModuleTimer samples Timer samples percent shmat cygwin1.dll36357 37.7186 ZN4muto7releaseEP7_cygtls cygwin1.dll19539 20.2708 ZN4muto7acquireEm cygwin1.dll16843 17.4738 memmove cygwin1.dll7906 8.2021 operator new(unsigned int)cygstdc++-6.dll6470 6.71231 dlfreecygwin1.dll3350 3.47546 dlmalloc cygwin1.dll2519 2.61334 malloccygwin1.dll1159 1.20241 free cygwin1.dll799 0.828924 _gcclibcxx_demangle_callback cygstdc++-6.dll277 0.287374 __wrap__ZdlPv cygwin1.dll260 0.269738 __wrap__Znwj cygwin1.dll239 0.247951 operator delete(void*)cygstdc++-6.dll236 0.244839 malloccygwin1.dll216 0.22409 free cygwin1.dll213 0.220977 tmalloc_small(malloc_state*,..) cygwin1.dll7 0.00726216 As the the performance bottlenecks are shmat, ZN4muto7releaseEP7_cygtls and ZN4muto7acquireEm. What do these functions do? I cannot find any information about them online. More importantly how might I prevent these functions from being called? My guess is that the latter two are are lock/unlocking functions associated with memory requests (my guess would be the stack, because there are fewer timer samples associated with malloc/free etc. Thanks, - Olumide If it matters, my (C++) application is recursive and contains -- 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: cygwin1.dll and cygstdc++-6.dll account for over 70% of application runtime cost
On 18/11/2014 00:45, Olumide wrote: According to the AMD CodeXL profiler, the modules cygwin1.dll and cygstdc++-6.dll account for 65.67% and 5.13% respectively of the runtime of my code. The breakdown is shown below: Reposting breakdown (hopefully will be less mangled this time) FunctionModule Timer samples Timer samples percent shmat cygwin1.dll 36357 37.7186 ZN4muto7releaseEP7_cygtls cygwin1.dll 19539 20.2708 ZN4muto7acquireEm cygwin1.dll 16843 17.4738 memmove cygwin1.dll 7906 8.2021 operator new(unsigned int) cygstdc++-6.dll 6470 6.71231 dlfree cygwin1.dll 3350 3.47546 dlmalloccygwin1.dll 2519 2.61334 malloc cygwin1.dll 1159 1.20241 freecygwin1.dll 7990.828924 _gcclibcxx_demangle_callbackcygstdc++-6.dll 2770.287374 __wrap__ZdlPv cygwin1.dll 2600.269738 __wrap__Znwjcygwin1.dll 2390.247951 operator delete(void*) cygstdc++-6.dll 2360.244839 malloc cygwin1.dll 2160.22409 freecygwin1.dll 2130.220977 tmalloc_small(malloc_state*,..) cygwin1.dll 7 0.00726216 -- 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 Run Excel From A Cron Job Under Windows 7
>>> Try starting cron in terminal session and see if anything comes up. > > Stop (don't kill! Everyone, who use -KILL, must be -KILL'ed) the cron service, > then start cron in terminal, using `runas /user:... ...'. So it would run > under proper user, and see if anything come up, when it execute your excel > job. I was unable to find how to use runas from a terminal. I can simply type runas and it does nothing and I can't find --help or /help. I did find a suggestion to use cygstart so I tried this: $ cygstart --action=runas '/bin/cygrunsrv --start cron' Unable to start 'C:\cygwin64\bin\cygrunsrv --start cron': The specified file was not found. So that didn't work. I did try starting the cron service (cygrunsrv) from a terminal session run as administrator and I tried starting the cron service from the Windows services.msc. Nothing has worked for running an Excel program with my run.excel script. I created a "null" .xls file that does nothing when run by Excel. I can run my script (run.excel c:/Shared/Bin/null.xls) from a bash prompt and it does nothing (as expected) and terminates but when I run this same script from a cron job Excel starts but never terminates. Running a ps command I see this: $ ps PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 518811845188 4928 ? 1000 19:00:01 /usr/bin/sh 604058205188 4428 ? 1000 19:00:02 /cygdrive/c/Windows/System32/wscript <-- runs vb script that starts Excel 180844641808 5704 ? 1000 18:24:25 /usr/sbin/cron 518455405184 6048 pty11000 21:13:03 /usr/bin/bash 336851843368 5560 pty11000 19:00:25 /usr/bin/ps 582051885188 5820 ? 1000 19:00:02 /usr/bin/sh 4464 14464 4464 ? 1000 18:24:25 /usr/bin/cygrunsrv 118418081808 1184 ? 1000 19:00:01 /usr/sbin/cron 5540 15540 5540 ? 1000 21:13:03 /usr/bin/mintty $ And I see the Excel.Exe *32 in the process list of Task Manager so I know Excel was started. Note the above ps command shows the wscript command running which is the command that executes the vb script that runs Excel. Also note that all of these processes including the wscript command show the 1000 UID which is the Upar2 login UID in the /etc/passwd file. I also look in the services.msc window and the cron service properties shows Login As .\Upar2. I see the same on the WinXP PC where I can run Excel successfully from a cron job. Denis -- 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: rebase db perms seem too restrictive
Hi,
On 17/11/14 20:26, Corinna Vinschen wrote:
On Nov 17 14:14, Shaddy Baddah wrote:
Hi,
I expect that there wasn't any explicit reasoning behind this, but
rebase creates a db with permissions that are too restrictive. To me
anyway, as I cannot see any danger in the db being readable by all.
This snippet describes it:
$ whoami
sbaddah
$ od -c /etc/rebase.db.x86_64
od: /etc/rebase.db.x86_64: Permission denied
$ ls -l /etc/rebase.db.x86_64
-rw-rw 1 portapps None 86020 Nov 11 15:34 /etc/rebase.db.x86_64
I've attached an untested patch that would allow at least world readable
perms. It would be appreciated if it was applied :-)
--
Regards,
Shaddy
diff --git a/rebase.c b/rebase.c
index 9504a48..a078e1d 100644
--- a/rebase.c
+++ b/rebase.c
@@ -288,7 +288,7 @@ mkstemp (char *name)
{
return _open (mktemp (name),
O_RDWR | O_BINARY | O_CREAT | O_EXCL | O_TRUNC | _O_SHORT_LIVED,
- _S_IREAD|_S_IWRITE);
+ _S_IREAD|_S_IWRITE|S_IRGRP|S_IROTH);
}
#endif
That won't work. Check the surroundng #ifdef's. The mkstemp
replacement function is only called when building rebase for Mingw. If
it's called on Cygwin, it uses Cygwin's implementation of mkstemp,
which follows the (security) lead of other POSIX systems and creates
the files with 0600 permissions. After the file got written, the
permissions are changed, see lines 358ff.
Sorry, yes I missed that. In any case, I withdraw the patch.
The initial trigger for my request was that the
/usr/lib/perl5/5.14/ExtUtils/MM_Cygwin.pm distributed with perl causes a
cpan/MakeMaker installation to run rebase -s against a built shared
library.
Now I use Perl/cpan local::lib
(http://search.cpan.org/~haarg/local-lib-2.14/lib/local/lib.pm).
That means my modules get built under my user, which is distinct from
the "software administrator" user (portapps), who owns the db file.
So initially, the rebase command was failing on the rebase on read
perms. However, even with that corrected, rebase -s will want to update
the db, which requires write perms.
The db file location isn't really configurable, and even if it was,
imagining an optimal setup for an installation with the potential for
multiple users building and running their own shared libraries is a
complex mess. There is no perfect world with rebase.
To that end, it is better that the db file is just writeable by the
"software administrator" so that "rebase" services are only sorted out
for the actual Cygwin install. Users would then be required to go it
alone if they need to rebase their built executables/shared libs.
And in any case, subsequent MM_Cygwin.pm modules no longer include
rebase. Suggesting to me that someone's perhaps come to the same
conclusion. If you build your own stuff, you sort out rebasing.
--
Regards,
Shaddy
--
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: cygwin1.dll and cygstdc++-6.dll account for over 70% of application runtime cost
Just a guess : http://linux.die.net/man/2/shmat Maybe your code needs to optimize around memory abit. On Mon, Nov 17, 2014 at 5:05 PM, Olumide <50...@web.de> wrote: > > On 18/11/2014 00:45, Olumide wrote: >> >> According to the AMD CodeXL profiler, the modules cygwin1.dll and >> cygstdc++-6.dll account for 65.67% and 5.13% respectively of the runtime >> of my code. The breakdown is shown below: > > > Reposting breakdown (hopefully will be less mangled this time) > > FunctionModule Timer samples Timer samples > percent > shmat cygwin1.dll 36357 37.7186 > ZN4muto7releaseEP7_cygtls cygwin1.dll 19539 20.2708 > ZN4muto7acquireEm cygwin1.dll 16843 17.4738 > memmove cygwin1.dll 7906 8.2021 > operator new(unsigned int) cygstdc++-6.dll 6470 6.71231 > dlfree cygwin1.dll 3350 3.47546 > dlmalloccygwin1.dll 2519 2.61334 > malloc cygwin1.dll 1159 1.20241 > freecygwin1.dll 7990.828924 > _gcclibcxx_demangle_callbackcygstdc++-6.dll 2770.287374 > __wrap__ZdlPv cygwin1.dll 2600.269738 > __wrap__Znwjcygwin1.dll 2390.247951 > operator delete(void*) cygstdc++-6.dll 2360.244839 > malloc cygwin1.dll 2160.22409 > freecygwin1.dll 2130.220977 > tmalloc_small(malloc_state*,..) cygwin1.dll 7 0.00726216 > > -- > 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
Re: [ANNOUNCEMENT] New package: getent-2.18.90-3
Corinna Vinschen wrote: Hi folks, I just uploaded getent-2.18.90-3. getent is a Glibc tool which allows to fetch host, passwd, group, protocol, and service information via a simple tool. The -3 version introduces the ability to ask for passwd and group entries via Windows username/groupname, using the "U-" prefix as in Cygwin's pw_gecos field: $ getent passwd U-BUILTIN\\Administrator Administrators:*:544:544:,S-1-5-32-544:: You can skip the domain name. In this case getent relies on the default account name resolution order of the underlying LookupAccountName(*) function $ getent passwd U-Administrator Administrators:*:544:544:,S-1-5-32-544:: Looks good. What is the future way to map cygwin group names to windows group names? Unlike struct passwd, the windows name does not appear in struct group. "getent wingroup CYGGROUP" with some help of a new cygwin_internal function? Christian -- 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.3-5 (x86_64)
JonY <10walls gmail.com> writes: > gcc-4.8.3-5 has been uploaded for 64bit Cygwin. It contains some fixes > for the libgcc unload handler. The -4 release was an accident that did > not contain the fix. Can you please check the setup.hint files? I think that gcc-core should require windows-default-manifest, both on x86 and x86_64. 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: [ANNOUNCEMENT] Updated: gcc-4.8.3-5 (x86_64)
On 2014-11-18 01:36, Achim Gratz wrote: JonY <10walls gmail.com> writes: gcc-4.8.3-5 has been uploaded for 64bit Cygwin. It contains some fixes for the libgcc unload handler. The -4 release was an accident that did not contain the fix. Can you please check the setup.hint files? I think that gcc-core should require windows-default-manifest, both on x86 and x86_64. Fixed on sourceware. Jon, please add this to gcc.cygport:gcc_core_REQUIRES. -- 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
