Re: Problem with FAQ heading
On Jun 20 03:30, Buchbinder, Barry (NIH/NIAID) [E] wrote: > http://cygwin.com/faq/faq.html#faq.programming.msvs-mingw > > 6.19. How do I use cygwin1.dll with Visual Studio or MinGW? > > This section doesn't actually mention MinGW except in its heading. Thanks for the heads up. There's also the later chapter faq.programming.win32-no-cygwin which mentions the old mingw.org but not the more modern mingw-w64 toolchain. I try to look into that, but I would be very grateful if somebody else could take a heart and update these chapters a bit. Patches most welcome! 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: Bug with Cygwin's 'quilt' is actually in 'patch'
On Jun 19 23:31, Matt D. wrote: > I've been looking further into this and it appears as though the > problem is in 'patch' not 'quilt'. quilt is actually a collection of > bash scripts and calls patch to do the actual patching. > > Using the same example I provided earlier in the thread, the same > error occurs when calling patch directly: > > $ patch Imakefile patches/test.patch > > Running dos2unix on test.patch will allow the patch to apply > successfully. However, this is WRONG. Imakefile and the initially > created test.patch both use CRLF line endings. The patch should > definitely NOT apply by introducing actual disparity. > > To summarize, the patch to Imakefile (CRLF) will apply if it is > converted to LF line endings. Using the '--binary' switch seems to > be a workaround for this issue. I can reproduce this problem on 32 bit Cygwin but not on 64 bit Cygwin. The 64 bit version has a newer patch version 2.7.1, while I so far neglected to update the 32 bit version which is still on 2.6.1. I'll build a new patch 2.7.1 for 32 bit today. I hope that fixes it for 32 bit as well. Stay tuned for the announcement. 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
Different Result using ps -efW (Manual & Cron)
Hi, I made a simple script that should detect if a certain service is running or not. Said script will run via cron. When I tested it and executed it manually in the command prompt, it list all Cygwin and Windows processes. But when I put it in cron, the number of services detected were not the same. Account used is the same during manual execution and also on cron. To get the list of services, I use this command /usr/bin/ps -efW. Do you have any idea why such behavior? Help is very much appreciated. Thanks. Regards, Jun Result via manual run UID PID PPID TTY STIME COMMAND jvi3147 5804 2192 pty2 16:12:50 /usr/bin/ps cyg_serv 4304 4844 ? 17:53:46 /usr/sbin/sshd cyg_serv 5964 4304 ? 10:16:27 /usr/sbin/sshd jvi3147 2192 5964 pty2 10:16:41 /usr/bin/bash jvi3147 5204 1 ? 11:41:02 /usr/bin/mintty jvi3147 4880 5204 pty0 11:41:02 /usr/bin/bash cyg_serv 4024 4304 ? 15:09:27 /usr/sbin/sshd cyg_serv 1652 4304 ? 09:08:35 /usr/sbin/sshd cyg_serv 2108 6088 ? 17:55:14 /usr/sbin/cron cyg_serv 4844 1 ? 17:53:46 /usr/bin/cygrunsrv cyg_serv 6088 1 ? 17:55:14 /usr/bin/cygrunsrv 0 4 0 ? Mar 28 System 0 412 0 ? Mar 28 C:\Windows\System32\smss.exe 0 480 0 ? Mar 28 C:\Windows\System32\csrss.exe 0 532 0 ? Mar 28 C:\Windows\System32\wininit.exe 0 608 0 ? Mar 28 C:\Windows\System32\services.exe 0 620 0 ? Mar 28 C:\Windows\System32\lsass.exe 0 628 0 ? Mar 28 C:\Windows\System32\lsm.exe 0 788 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 852 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 932 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 984 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 1000 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 1024 0 ? Mar 28 C:\Windows\System32\SLsvc.exe 0 1068 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 1128 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 1484 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 1628 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 1728 0 ? Mar 28 C:\Windows\System32\spoolsv.exe 0 2008 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 2020 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 300 0 ? Mar 28 C:\Program Files\Sophos\Remote Management System\ManagementAgentNT.exe 0 424 0 ? Mar 28 C:\Program Files\Sophos\AutoUpdate\ALsvc.exe 0 796 0 ? Mar 28 C:\Program Files\Sophos\Remote Management System\RouterNT.exe 0 680 0 ? Mar 28 C:\Windows\System32\taskeng.exe 0 2060 0 ? Mar 28 C:\Program Files\VMware\VMware Tools\vmtoolsd.exe 0 2184 0 ? Mar 28 C:\Program Files\VERITAS\VxPBX\bin\pbx_exchange.exe 0 2260 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 2296 0 ? Mar 28 C:\Program Files\VERITAS\NetBackup\bin\vnetd.exe 0 2500 0 ? Mar 28 C:\Program Files\VMware\VMware Tools\VMUpgradeHelper.exe 0 2532 0 ? Mar 28 C:\Program Files\VERITAS\NetBackup\bin\bpinetd.exe 0 2704 0 ? Mar 28 C:\Program Files\VERITAS\NetBackup\bin\bpcd.exe 0 2928 0 ? Mar 28 C:\Windows\System32\dllhost.exe 0 3028 0 ? Mar 28 C:\Windows\System32\msdtc.exe 0 3360 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 3700 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 2224 0 ? Apr 1 C:\Windows\System32\csrss.exe 0 1956 0 ? Apr 1 C:\Windows\System32\winlogon.exe 0 944 0 ? Apr 1 C:\Windows\System32\LogonUI.exe 0 3292 0 ? Jun 4 C:\Program Files\OCS Inventory Agent\OcsService.exe 0 4856 0 ? Jun 12 C:\Program Files\Sophos\Sophos Anti-Virus\SavService.exe 0 6120 0 ? Jun 12 C:\Program Files\Sophos\Sophos Anti-Virus\SAVAdminService.exe 0 4372 0 ? Jun 12 C:\Program Files\Sophos\Sophos Anti-Virus\sdcservice.exe 0 4400 0 ? Jun 12 C:\Program Files\Sophos\Sophos Anti-Virus\Web Intelligence\swi_service.exe 0 4424 0 ? 18:10:12 C:\Windows\System32\csrss.exe 0 2440 0 ? 18:10:12 C:\Windows\System3
[ANNOUNCEMENT] Updated: patch-2.7.1-1
I just updated the patch utility to upstream version 2.7.1. To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leadercygwin 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: git svn fork() problems on cygwin 1.7.20
Hi, I also noticed the perl package errors and did a reinstall of all perl packages with setup.exe. Did not help. Then in desperation I did a few reboots and rebaseall's and suddenly the problem is gone. Sigh. Somehow this is triggered by Windows 7 security updates but now again everything with cygwin is working. -Mikko -- 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: Different Result using ps -efW (Manual & Cron)
On Jun 20 01:22, Jun Iriola wrote: > Hi, > > I made a simple script that should detect if a certain service is running or > not. Said script will run via cron. > > When I tested it and executed it manually in the command prompt, it list all > Cygwin and Windows processes. But when I put it in cron, the number of > services detected were not the same. Account used is the same during manual > execution and also on cron. > > To get the list of services, I use this command /usr/bin/ps -efW. > > Do you have any idea why such behavior? Help is very much appreciated. > Thanks. It's probably related to your user token's permissions. See http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview Try using method 3, it should give full, equivalent access as in interactive mode. 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: Adding MSYS functionality to Cygwin
On Wed, Jun 19, 2013 at 4:25 PM, Charles Wilson wrote: > > I assume that, eventually and as-needed, a *small* number of additional > "hooks" could be added to other code paths than exec/spawn/etc -- such as > the aforementioned uname(3) thing. (One of the "deltas" between cygwin and > msys was msys used a really stupid ownership/permission model -- pretend > current user owns everything; check the DOS R/O bit for +w; check the file > extension for +x; -- but this can be approximated with existing $CYGWIN > entries or mount options. I think. So reimplementing that "feature" of MSYS > would not require any additional hooks). IIRC that "stupid ownership/permission model" was a part of the original Cygwin 1.3 and was not modified. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: Adding MSYS functionality to Cygwin
On Jun 20 09:07, Earnie Boyd wrote: > On Wed, Jun 19, 2013 at 4:25 PM, Charles Wilson wrote: > > > > I assume that, eventually and as-needed, a *small* number of additional > > "hooks" could be added to other code paths than exec/spawn/etc -- such as > > the aforementioned uname(3) thing. (One of the "deltas" between cygwin and > > msys was msys used a really stupid ownership/permission model -- pretend > > current user owns everything; check the DOS R/O bit for +w; check the file > > extension for +x; -- but this can be approximated with existing $CYGWIN > > entries or mount options. I think. So reimplementing that "feature" of MSYS > > would not require any additional hooks). > > IIRC that "stupid ownership/permission model" was a part of the > original Cygwin 1.3 and was not modified. CYGWIN=ntsec ruled way back when... 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: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"
On 6/14/2013 5:39 PM, Nogin, Aleksey wrote: > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug1: Authentications that can continue: publickey,gssapi-with-mic,password > debug1: Next authentication method: gssapi-with-mic > debug1: Miscellaneous failure (see text) > unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10 > > debug1: Delegating credentials > debug1: Delegating credentials > debug1: Enabling compression at level 6. > debug1: Authentication succeeded (gssapi-with-mic). > Authenticated to XXXhostXXX ([IP.IP.IP.IP]:22). I'm not sure what the issue is here. The authentication succeeded. MechType 1.3.6.1.4.1.311.2.2.10 is Microsoft's NTLM SSP. The sshd does not support NTLM and so rejects it. The next GSS mechanism is negotiated within the gssapi-with-mic exchange. That is probably Kerberos5 and it succeeds. Jeffrey Altman -- 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: cygport limitations (was: Adding MSYS functionality to Cygwin)
On 6/19/2013 12:38, Yaakov (Cygwin/X) wrote: On 2013-06-19 12:57, Warren Young wrote: You're not talking about anything different than the sort of thing Cygwin package maintainers go through, sometimes needing to arm-twist odd build systems to behave according to cygport's expectations? I think you mean Cygwin's expectations? Not really, no. I'm assuming everyone is using cygport now to create packages, or can't because of one of these violated expectations. My ctags package is one of the latter, because although it ships with a configure script, it isn't an autoconf configure script. When I tried migrating the package to cygport 3.5 years ago, cygport failed to DTRT because the ctags build system doesn't know how to configure and build outside the source tree. I ended up falling back on my custom build script, which simply builds in-tree, then overrides some make(!) variables to force it to install into a temp directory, which I then pack up by hand. This is tolerable because ctags is a relatively simple package. I think I see how to get cygport to build this package now, but it wouldn't buy me much, because I'd be overriding so much of its default behavior. All I'd be doing is pushing it into this next category. That second category of packages are those that are built using cygport despite the fact that it requires a highly customized .cygport file. The more customizations you add, the more of cygport's base assumptions you are violating with your package. The last doxygen package I shipped was a good example of this: 1. I had to pass "--platform linux-g++" to configure to get it to build correctly. (It might have been one of those cases where it saw #if WINDOWS == true and did the wrong thing.) I don't know if CYGCONF_ARGS didn't exist when I wrote that, but for some reason I felt compelled to override the src_compile rule to pass this flag. 2. Though I now know about CYGCONF_ARGS, if I picked the package back up for some reason, I don't think I could get rid of my src_compile() override because of a second build problem: Doxygen's own documentation has a primitive and completely separate build system. Not only does "make" at the top level not "cd doc && make", but doc/Makefile also doesn't understand things like DESTDIR. I ended up needing to override src_install(), too. I don't mean to impugn cygport's capabilities, or yours, Yaakov. I prefer to use cygport, and don't like it when I can't. My point is, cygport's default assumptions about how software gets built and installed aren't always correct. Sometimes it has enough flexibility to cope with those differences (e.g. my doxygen case) and other times it's just not worth the bother (e.g. my ctags case). -- 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: cygport limitations (was: Adding MSYS functionality to Cygwin)
On Jun 20 11:43, Warren Young wrote: > On 6/19/2013 12:38, Yaakov (Cygwin/X) wrote: > >On 2013-06-19 12:57, Warren Young wrote: > >>You're not talking about anything different than the sort of thing > >>Cygwin package maintainers go through, sometimes needing to arm-twist > >>odd build systems to behave according to cygport's expectations? > > > >I think you mean Cygwin's expectations? > > Not really, no. > [...] > My point is, cygport's default assumptions about how software gets > built and installed aren't always correct. Sometimes it has enough > flexibility to cope with those differences (e.g. my doxygen case) > and other times it's just not worth the bother (e.g. my ctags case). My point is, it's always worth to switch packages to cygport: - cygport is the closest we have to a unified build system (like rpm). If every maintainer would use cygport, it would allow us to change the build method to one along the lines of most Linux distros. In Linux distros, the maintainer provides only the spec file and the source archive. The actual build for all supported platforms could be done on a machine which creates the distro from there. - Cygport does cope with most problems you can come up with and if it doesn't, you can tweak it. Your ctags problem could have been easily solved by the lndirs method, for instance. And if cygport still doesn't cope, there's an active maintainer and a cygwin-apps mailing list for questions. - Cygport is pretty easy to use and other people can easily pick up your package and build another version using your Cygwin build settings, or even take over maintainership should the need arise. Of course, the better is the foe of the good, but unless somebody comes up with another build system which integrates nicely into Cygwin and is easier to use than cygport, cygport is the best system we have and I advocate for using it throughout. 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: cygport limitations
On 2013-06-20 12:43, Warren Young wrote:
I'm assuming everyone is using cygport now to create packages, or can't
because of one of these violated expectations.
My ctags package is one of the latter, because although it ships with a
configure script, it isn't an autoconf configure script. When I tried
migrating the package to cygport 3.5 years ago, cygport failed to DTRT
because the ctags build system doesn't know how to configure and build
outside the source tree. I ended up falling back on my custom build
script, which simply builds in-tree, then overrides some make(!)
variables to force it to install into a temp directory, which I then
pack up by hand. This is tolerable because ctags is a relatively simple
package.
This is explained in the manual wrt cygconf:
* cygconf is intended for configure scripts generated by, or compatible
with, autoconf. Packages with handwritten configure scripts may not
accept allthe flags used by cygconf, in which case a direct call to
the configure script is in order.
In this case, not having looked at ctags, you'll probably need something
along the lines of:
src_compile() {
lndirs
cd ${B}
./configure --prefix=/usr || error "configure failed"
cygmake
}
That second category of packages are those that are built using cygport
despite the fact that it requires a highly customized .cygport file. The
more customizations you add, the more of cygport's base assumptions you
are violating with your package.
The last doxygen package I shipped was a good example of this:
1. I had to pass "--platform linux-g++" to configure to get it to build
correctly. (It might have been one of those cases where it saw #if
WINDOWS == true and did the wrong thing.) I don't know if CYGCONF_ARGS
didn't exist when I wrote that, but for some reason I felt compelled to
override the src_compile rule to pass this flag.
FWIW, CYGCONF_ARGS has been around for a *long* time.
2. Though I now know about CYGCONF_ARGS, if I picked the package back up
for some reason, I don't think I could get rid of my src_compile()
override because of a second build problem: Doxygen's own documentation
has a primitive and completely separate build system. Not only does
"make" at the top level not "cd doc && make", but doc/Makefile also
doesn't understand things like DESTDIR. I ended up needing to override
src_install(), too.
There's nothing wrong with that. src_compile(), src_test(), and
src_install() are intended to be provided by cygport(5)s; the provided
*defaults* of those are NOT opaque APIs (hence they are actually shown
in the docs) and are meant to be overridden whenever necessary.
I don't mean to impugn cygport's capabilities, or yours, Yaakov. I
prefer to use cygport, and don't like it when I can't.
There should NEVER be a reason that you can't use cygport for your
packages. If you're having an issue, just provide your (draft)
cygport(5) and ask.
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: subversion-1.8.0-1
NEWS: = See CHANGES (URL below) for more information about the differences between 1.8.0 and previous Subversion releases. IMPORTANT: Please read the release notes (URL below) before upgrading from a previous major release. 1.8 includes a new working copy format with a manual upgrade operation. This will render your working copy unusable with previous major releases. Furthermore, there are some issues trying to upgrade corrupt working copies. Please see the release notes http://subversion.apache.org/docs/release-notes/1.8.html for more details about the changes in Subversion. See http://svn.apache.org/repos/asf/subversion/tags/1.8.0/CHANGES for more details about the changes in 1.8.0. DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/nightly/en/index.html for the latest official release of the Subversion Book. DOWNLOAD: = Note that downloads from sourceware.org (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to 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. -- David Rothenbergerspammer? -> s...@daveroth.dyndns.org GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734 Karmageddon: It's like, when everybody is sending off all these really bad vibes, right? And then, like, the Earth explodes and it's like, a serious bummer. -- 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: cygport limitations
On 20/06/13 18:43, Warren Young wrote: The last doxygen package I shipped was a good example of this: 1. I had to pass "--platform linux-g++" to configure to get it to build correctly. (It might have been one of those cases where it saw #if WINDOWS == true and did the wrong thing.) I don't know if CYGCONF_ARGS didn't exist when I wrote that, but for some reason I felt compelled to override the src_compile rule to pass this flag. 2. Though I now know about CYGCONF_ARGS, if I picked the package back up for some reason, I don't think I could get rid of my src_compile() override because of a second build problem: Doxygen's own documentation has a primitive and completely separate build system. Not only does "make" at the top level not "cd doc && make", but doc/Makefile also doesn't understand things like DESTDIR. I ended up needing to override src_install(), too. In defence of cygport, it does a great job of subscribing to the Alan Kay principle: simple things are simple, and hard things are possible. If you think about just how many software packages there are in the Linux world, there are also a great many different techniques for building them. Cygport is really easy for most modern packages that adhere to (or are fairly close to) a "standard" install, and at least the packages that have, ahem, specialist installation mechanisms can be built with cygport too. The other great thing about cygport is that it has become the standard for building Cygwin packages, so all (or at least most of) the Cygwin maintainers can read and understand cygport files. This means it's much easier when the time comes to hand a package on to a new maintainer. Maybe this is straying into the "[RFC] cygport documentation" thread from the apps ML, but perhaps we could do with a cygport gallery: a selection of cygport files ranging from the deliciously simple three or four line affairs through to the more stubborn and difficult cases. I know that I've picked up some handy techniques by looking at other maintainers' cygport files. Dave. PS: As the current doxygen maintainer, I am sad to report that the cygport file isn't any smaller now that I'm building doxywizard, doing a test for libclang-devel (so that I can enable or disable clang assisted parsing), and forcing it to make a debuginfo package :-) -- 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: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"
Jeffrey Altman wrote: >> debug1: SSH2_MSG_SERVICE_REQUEST sent >> debug1: SSH2_MSG_SERVICE_ACCEPT received >> debug1: Authentications that can continue: >> publickey,gssapi-with-mic,password >> debug1: Next authentication method: gssapi-with-mic >> debug1: Miscellaneous failure (see text) unknown mech-code 2529639054 for >> mech 1 3 6 1 4 1 311 2 2 10 >> >> debug1: Delegating credentials >> debug1: Delegating credentials >> debug1: Enabling compression at level 6. >> debug1: Authentication succeeded (gssapi-with-mic). >> Authenticated to XXXhostXXX ([IP.IP.IP.IP]:22). > > I'm not sure what the issue is here. The authentication succeeded. The issue that despite the "Delegating credentials" message, credentials are not being delegated. Aleksey
Broken MPIR 2.6.0 on Cygwin64
Dear all,
First thanks a lot for your hard work on the Cygwin project and the
Cygwin64 project.
I've begun to try to build Sage (http://www.sagemath.org) on Cygwin64
to provide some Windows support without the need of a virtual machine
running Linux and now have some trouble compiling a working MPIR 2.6.0
(http://www.mpir.org) library.
Note that I have no problems building a proper static or shared
version of GMP 5.1.2 with the GCC 4.8.1 toolchain currently provided
with Cygwin64, and it passes its complete testsuite.
At some point we should be able to switch to GMP, but we still have
some dependencies relying on MPIR's internals, so we have (and want,
even in the future by default) to stick with MPIR.
Also note we have no problem using MPIR on 32 bit Cygwin.
So my problem with MPIR are as follow:
* the ./configfsf.[guess|sub] and yasm/config/config.[guess|sub] file
within the upstream tarball are too old and failed to recognize
Cygwin64, replacing them with up-to-date version easily solves that,
* I have no problem building a static lib, but running make check
fails when linking any test executable, e.g. the first one
"t-bswap.exe":
{{{
/bin/sh ../libtool --tag=CC--mode=link gcc -std=gnu99 -m64 -O2
-march=corei7-avx -mtune=corei7-avx-o t-bswap.exe t-bswap.o
libtests.la ../libmpir.la
libtool: link: gcc -std=gnu99 -m64 -O2 -march=corei7-avx
-mtune=corei7-avx -o t-bswap.exe t-bswap.o ./.libs/libtests.a
/home/jp/mpir-2.6.0/.libs/libmpir.a ../.libs/libmpir.a
collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped
Makefile:503: recipe for target `t-bswap.exe' failed
}}}
A 0 byte t-bswap.exe is created and the content of the stackdump is
{{{
$ cat tests/ld.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at rip=03E
rax=0001004C3FA0 rbx=00060018DCB0 rcx=00060018DCB0
rdx=00060018ECA8 rsi=00C2A580 rdi=0025
r8 =00C2A590 r9 =BFFF r10=00C3
r11=0001004B111E r12=0001 r13=00060018ECA9
r14=000100534780 r15=00060018ECA8
rbp=00C2A590 rsp=00C2A528
program=C:\cygwin64\usr\x86_64-pc-cygwin\bin\ld.exe, pid 6744, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
FrameFunctionArgs
0C2A590 03E (000, 0130001, 00100512180, 000)
0C2A590 00100493B54 (000, 006000F4B30, 023, 000)
0C2A650 00100433783 (00100534780, 00600057550, 001800C0C2C, 000)
000 0010040E82C (00600022D10, 00600023CF8, 00100436389, 000)
001 0010040F2E0 (001802DE300, 00600019870, 001800C0C2C, 00600017A30)
001004DDD08 001004113FB (00100520580, 000, 001802E3E9D, 001802DF658)
001004DDD08 001004BF4C0 (0C2A9B0, 0C2AA46, 001801691B1, 000)
0C2AB80 0018004836E (000, 000, 000, 000)
000 0018004618B (000, 000, 000, 000)
000 0018004634F (000, 000, 000, 000)
000 001004BDD31 (000, 000, 000, 000)
000 00100401010 (000, 000, 000, 000)
000 00076B7652D (000, 000, 000, 00076BF9300)
000 0007726C521 (000, 000, 000, 00076BF9300)
End of stack trace
}}}
* I have no problem building a shared lib, nor the test programs in
that case, but many (but not all) of them segfaults when they are run.
In the two above cases, I was not able to retrieve useful information
when attaching gdb to the segfaulting process.
I just saw that three threads were launched and the backtrace only
involved Cygwin/Windows dlls.
Did anyone among the Cygwin folk tried to build MPIR on Cygwin64 and
got more success than I had?
Or has any advice to solve these issues?
Thanks in advance for your help,
Best,
--
Jean-Pierre Flori
--
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: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"
On 6/20/2013 6:31 PM, Nogin, Aleksey wrote: > Jeffrey Altman wrote: > >>> debug1: SSH2_MSG_SERVICE_REQUEST sent >>> debug1: SSH2_MSG_SERVICE_ACCEPT received >>> debug1: Authentications that can continue: >>> publickey,gssapi-with-mic,password >>> debug1: Next authentication method: gssapi-with-mic >>> debug1: Miscellaneous failure (see text) unknown mech-code 2529639054 for >>> mech 1 3 6 1 4 1 311 2 2 10 >>> >>> debug1: Delegating credentials >>> debug1: Delegating credentials >>> debug1: Enabling compression at level 6. >>> debug1: Authentication succeeded (gssapi-with-mic). >>> Authenticated to XXXhostXXX ([IP.IP.IP.IP]:22). >> >> I'm not sure what the issue is here. The authentication succeeded. > > The issue that despite the "Delegating credentials" message, credentials are > not being delegated. > > Aleksey I still do not understand what does that has to do with the subject of this message? The credentials that will be deleted are the credentials of the type that was accepted by the ssh gssapi-with-mic mechanism. At the verbosity level that you are using it does not state what that is. In any case, I am quite sure that if your ssh client states that it has delegated credentials that it has done so. You need to debug the server side to determine where the sshd environment or gssapi library has determined the credentials have been stored. For Kerberos it will need to be a credential cache. Heimdal defaults to using a non-FILE based cache but I suspect that Cygwin does not provide a non-FILE based cache implementation. Jeffrey Altman -- 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: cygport limitations (was: Adding MSYS functionality to Cygwin)
> If every maintainer would use cygport, it would allow us to change > the build method to one along the lines of most Linux distros. > In Linux distros, the maintainer provides only the spec file and > the source archive. The actual build for all supported platforms > could be done on a machine which creates the distro from there. That would be cool. Let's do it! -- 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: cygport limitations
On 6/20/2013 12:44, Yaakov (Cygwin/X) wrote: There should NEVER be a reason that you can't use cygport for your packages. If you're having an issue, just provide your (draft) cygport(5) and ask. Thanks for the offer. I've left myself a note to try this again for the next ctags release. I have no idea if there ever will be a new Exuberant Ctags. The last release came out 4 years ago, and activity to the ctags-devel list has been under 1 post per month[*] for the past 6 months. I'd be willing to convert 5.8 to cygport if this plan of Corinna's for an automated build server goes through. [*] http://sourceforge.net/mailarchive/forum.php?forum_name=ctags-devel -- 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
