RE: setup in cvs head by early june 2013 does not run on xp
You need to build with the newest version of mingw from the mingw64-i686 package. It seems like yours is out of date. Corinna and I build with the i686-w64-mingw32 target. It appears I have the latest version (gcc, g++, 4.5.3-6, runtime runtime-3.0b_svn5747-1, headers-3.0b_svn5747-1) offered by mirrors.kernel.org (checked prior to this email via setup against then current, and installed /var/log/setup.log), which is listed at http://cygwin.com/mirrors.html as an up-to-date mirror. 1)Please advise what pkg version, mirror, or ? can provide appropriate build context. 2)Should configure check for and advise of possible problems with 'incorrect' version of mingw64? Thanks.
Re: setup in cvs head by early june 2013 does not run on xp
On Jun 21 09:26, d_h...@hotmail.com wrote: You need to build with the newest version of mingw from the mingw64-i686 package. It seems like yours is out of date. Corinna and I build with the i686-w64-mingw32 target. It appears I have the latest version (gcc, g++, 4.5.3-6, runtime runtime-3.0b_svn5747-1, headers-3.0b_svn5747-1) offered by mirrors.kernel.org (checked prior to this email via setup against then current, and installed /var/log/setup.log), which is listed at http://cygwin.com/mirrors.html as an up-to-date mirror. 1)Please advise what pkg version, mirror, or ? can provide appropriate build context. 2)Should configure check for and advise of possible problems with 'incorrect' version of mingw64? I really don't know what you mean. Just make sure you have the latest mingw64 packages installed, create a separate build dir, for instanmce parallel to the setup source dir, and call configure make: cd checked out setup sources dir cd .. mkdir build cd build ../configure --host=i686-w64-mingw32 --target=i686-w64-mingw32 make And that's it. I tested to build setup HEAD from scratch for 32 and 64 bit, and both versions worked fine. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
RE: setup in cvs head by early june 2013 does not run on xp
I really don't know what you mean. on 32bit XP SP3, With cygwin installation of the latest packages currently (well as of 2013/06/03 or so) available from mirrors.kernel.org, a 32bit build of setup retrieved from cvs as -D20130619 will not run on XPSP3 (and I'm guessing not on W2K3 server either.) And that's it. I tested to build setup HEAD from scratch for 32 and 64 bit, and both versions worked fine. Did 32bit version work fine on XP (sp3)? fails for me trying to reference non-existent vswprintf from ntdll.dll...
setup patch - simplistic --include-source for download/installed pkgs
A patch for setup providing command line switches (-I, --include-source) to
automatically include source packages associated with any selected binary
packages when downloading/installing.
The first version is targeted at source revision 2.774 (can obtain as
-D20120430) from cvs, which seems to match the binary setup.exe available for
download at cygwin.com in early June 2013.
It will almost apply to head around 20130619, but a second version is provided
to do that cleanly.
It may not be suitable for release, but am sending here in case it would be
found and useful to others.
=
file: include_source_D20120430_R2.774.patch.diff
=
Index: install.cc
===
RCS file: /cvs/cygwin-apps/setup/install.cc,v
retrieving revision 2.101
diff -u -r2.101 install.cc
--- install.cc 25 Jul 2011 14:36:24 - 2.101
+++ install.cc 10 Jun 2013 08:45:50 -
@@ -68,6 +68,8 @@
extern ThreeBarProgressPage Progress;
+extern BoolOption IncludeSource ;
+
static int total_bytes = 0;
static int total_bytes_sofar = 0;
static int package_bytes = 0;
@@ -675,8 +677,9 @@
}
}
- if (pkg.desired.sourcePackage ().picked())
+ if (pkg.desired.sourcePackage ().picked() || IncludeSource)
{
+ bool skiprequested = false ;
try
{
md5_one (*pkg.desired.sourcePackage ().source ());
@@ -684,9 +687,12 @@
catch (Exception *e)
{
if (yesno (owner, IDS_SKIP_PACKAGE, e-what()) == IDYES)
+ {
+ skiprequested = true ; //(err occurred,) skip pkg desired
pkg.desired.sourcePackage ().pick (false, pkg);
+ }
}
- if (pkg.desired.sourcePackage().picked())
+ if (pkg.desired.sourcePackage().picked() || (IncludeSource
!skiprequested) )
{
md5sum_total_bytes_sofar += pkg.desired.sourcePackage
().source()-size;
total_bytes += pkg.desired.sourcePackage ().source()-size;
Index: download.cc
===
RCS file: /cvs/cygwin-apps/setup/download.cc,v
retrieving revision 2.55
diff -u -r2.55 download.cc
--- download.cc 29 Apr 2011 12:43:59 - 2.55
+++ download.cc 10 Jun 2013 08:45:50 -
@@ -57,6 +57,8 @@
extern ThreeBarProgressPage Progress;
+BoolOption IncludeSource (false, 'I', include-source, Automatically include
source download);
+
static bool
validateCachedPackage (const std::string fullname, packagesource pkgsource)
{
@@ -223,7 +225,7 @@
if (!check_for_cached (*i))
total_download_bytes += i-size;
}
- if (sourceversion.picked ())
+ if (sourceversion.picked () || IncludeSource)
{
for (vectorpackagesource::iterator i =
sourceversion.sources ()-begin();
@@ -262,7 +264,7 @@
i != version.sources ()-end(); ++i)
e += download_one (*i, owner);
}
- if (sourceversion sourceversion.picked())
+ if (sourceversion (sourceversion.picked() || IncludeSource) )
{
for (vectorpackagesource::iterator i =
sourceversion.sources ()-begin();
===
file: include_source_patch_HEAD_circa20130612.diff
===
Index: install.cc
===
RCS file: /cvs/cygwin-apps/setup/install.cc,v
retrieving revision 2.106
diff -u -r2.106 install.cc
--- install.cc 14 Mar 2013 09:21:06 - 2.106
+++ install.cc 12 Jun 2013 11:00:58 -
@@ -73,6 +73,7 @@
static long long int total_bytes_sofar = 0;
static int package_bytes = 0;
+extern BoolOption IncludeSource ;
static BoolOption NoReplaceOnReboot (false, 'r', no-replaceonreboot,
Disable replacing in-use files on next
reboot.);
@@ -704,8 +705,9 @@
}
}
- if (pkg.desired.sourcePackage ().picked())
+ if (pkg.desired.sourcePackage ().picked() || IncludeSource)
{
+ bool skiprequested = false ;
try
{
md5_one (*pkg.desired.sourcePackage ().source ());
@@ -713,9 +715,12 @@
catch (Exception *e)
{
if (yesno (owner, IDS_SKIP_PACKAGE, e-what()) == IDYES)
+ {
+ skiprequested = true ; //(err occurred,) skip pkg desired
pkg.desired.sourcePackage ().pick (false, pkg);
+ }
}
- if (pkg.desired.sourcePackage().picked())
+ if (pkg.desired.sourcePackage().picked() || (IncludeSource
!skiprequested) )
{
md5sum_total_bytes_sofar += pkg.desired.sourcePackage
().source()-size;
total_bytes += pkg.desired.sourcePackage ().source()-size;
Index: download.cc
Re: setup in cvs head by early june 2013 does not run on xp
On Jun 21 10:40, d_h...@hotmail.com wrote: I really don't know what you mean. on 32bit XP SP3, With cygwin installation of the latest packages currently (well as of 2013/06/03 or so) available from mirrors.kernel.org, a 32bit build of setup retrieved from cvs as -D20130619 will not run on XPSP3 (and I'm guessing not on W2K3 server either.) And that's it. I tested to build setup HEAD from scratch for 32 and 64 bit, and both versions worked fine. Did 32bit version work fine on XP (sp3)? fails for me trying to reference non-existent vswprintf from ntdll.dll... Yes. Due to your report I tested on 32 bit XP SP3 and XP64 SP2, of course. I don't even know where you get your vswprintf symbol from. My version of setup doesn't ever use this function, and there's only a symbol __mingw_vswprintf pulled in since, apparently, multiple XXXprintf entry points are exported by the same file. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFU] TeX Live 2013
Hi Ken, On Jun 20 21:16, Corinna Vinschen wrote: On Jun 20 15:07, Ken Brown wrote: On 6/20/2013 2:42 PM, Corinna Vinschen wrote: On Jun 20 12:10, Ken Brown wrote: I'm giving four separate wget commands below to make it clear what's happening: The first is for noarch packages that are already in the 64bit distro; you can simply copy them from the 64bit release area instead of using wget if that's easier. The second is for arch-dependent packages. The third makes a bunch of packages obsolete, due to upstream reorganization. Please check one or two to make sure I've done it right. And the fourth is to remove the obsolescent texlive-collection-texinfo from the dependencies of some already obsolete tetex packages (see http://cygwin.com/ml/cygwin-apps/2013-05/msg00113.html). texlive-collection-texinfo should also be removed from the dependencies of lyx. Gosh. Ken, would you like to have upload privileges? The list of TexLive packages always give me a mild stroke. If you fill out http://sourceware.org/cgi-bin/pdw/ps_form.cgi with me as approver, you can upload your packages as you see fit (and maybe help uploading other maintainer's packages once in a while...) OK, I'll do that. What email address should I use for you? The one in the Cygwin ChangeLogs? Yep. And is there a document with guidelines for uploading packages? Something has gone wrong with your TexLive update. Upset produces thie following report every five minutes: upset: *** setup.ini: warning - package texlive-collection-documentation-polish requires non-existent package texlive-collection- upset: *** setup.ini: warning - package texlive-collection-documentation-portuguese requires non-existent package texlive-collection-langportugese upset: *** setup.ini: warning - package texlive-collection-langtibetan requires non-existent package omega Can you fix that, please? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFU] TeX Live 2013
On 6/21/2013 7:02 AM, Corinna Vinschen wrote: Hi Ken, On Jun 20 21:16, Corinna Vinschen wrote: On Jun 20 15:07, Ken Brown wrote: On 6/20/2013 2:42 PM, Corinna Vinschen wrote: On Jun 20 12:10, Ken Brown wrote: I'm giving four separate wget commands below to make it clear what's happening: The first is for noarch packages that are already in the 64bit distro; you can simply copy them from the 64bit release area instead of using wget if that's easier. The second is for arch-dependent packages. The third makes a bunch of packages obsolete, due to upstream reorganization. Please check one or two to make sure I've done it right. And the fourth is to remove the obsolescent texlive-collection-texinfo from the dependencies of some already obsolete tetex packages (see http://cygwin.com/ml/cygwin-apps/2013-05/msg00113.html). texlive-collection-texinfo should also be removed from the dependencies of lyx. Gosh. Ken, would you like to have upload privileges? The list of TexLive packages always give me a mild stroke. If you fill out http://sourceware.org/cgi-bin/pdw/ps_form.cgi with me as approver, you can upload your packages as you see fit (and maybe help uploading other maintainer's packages once in a while...) OK, I'll do that. What email address should I use for you? The one in the Cygwin ChangeLogs? Yep. And is there a document with guidelines for uploading packages? Something has gone wrong with your TexLive update. Upset produces thie following report every five minutes: upset: *** setup.ini: warning - package texlive-collection-documentation-polish requires non-existent package texlive-collection- upset: *** setup.ini: warning - package texlive-collection-documentation-portuguese requires non-existent package texlive-collection-langportugese upset: *** setup.ini: warning - package texlive-collection-langtibetan requires non-existent package omega Can you fix that, please? Sorry about that. It should be fixed now. Ken
Re: [RFU] TeX Live 2013
On Jun 21 07:49, Ken Brown wrote: On 6/21/2013 7:02 AM, Corinna Vinschen wrote: Hi Ken, Something has gone wrong with your TexLive update. Upset produces thie following report every five minutes: upset: *** setup.ini: warning - package texlive-collection-documentation-polish requires non-existent package texlive-collection- upset: *** setup.ini: warning - package texlive-collection-documentation-portuguese requires non-existent package texlive-collection-langportugese upset: *** setup.ini: warning - package texlive-collection-langtibetan requires non-existent package omega Can you fix that, please? Sorry about that. It should be fixed now. Yep, looks good. No more nagging upset messages in my inbox :) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFU] TeX Live 2013
On 6/21/2013 7:49 AM, Ken Brown wrote: On 6/21/2013 7:02 AM, Corinna Vinschen wrote: Hi Ken, On Jun 20 21:16, Corinna Vinschen wrote: On Jun 20 15:07, Ken Brown wrote: On 6/20/2013 2:42 PM, Corinna Vinschen wrote: On Jun 20 12:10, Ken Brown wrote: I'm giving four separate wget commands below to make it clear what's happening: The first is for noarch packages that are already in the 64bit distro; you can simply copy them from the 64bit release area instead of using wget if that's easier. The second is for arch-dependent packages. The third makes a bunch of packages obsolete, due to upstream reorganization. Please check one or two to make sure I've done it right. And the fourth is to remove the obsolescent texlive-collection-texinfo from the dependencies of some already obsolete tetex packages (see http://cygwin.com/ml/cygwin-apps/2013-05/msg00113.html). texlive-collection-texinfo should also be removed from the dependencies of lyx. Gosh. Ken, would you like to have upload privileges? The list of TexLive packages always give me a mild stroke. If you fill out http://sourceware.org/cgi-bin/pdw/ps_form.cgi with me as approver, you can upload your packages as you see fit (and maybe help uploading other maintainer's packages once in a while...) OK, I'll do that. What email address should I use for you? The one in the Cygwin ChangeLogs? Yep. And is there a document with guidelines for uploading packages? Something has gone wrong with your TexLive update. Upset produces thie following report every five minutes: upset: *** setup.ini: warning - package texlive-collection-documentation-polish requires non-existent package texlive-collection- upset: *** setup.ini: warning - package texlive-collection-documentation-portuguese requires non-existent package texlive-collection-langportugese upset: *** setup.ini: warning - package texlive-collection-langtibetan requires non-existent package omega Can you fix that, please? Sorry about that. It should be fixed now. For future reference, is the upset log accessible? That way I could check for errors myself after an upload. Ken
Re: setup in cvs head by early june 2013 does not run on xp
On Fri, Jun 21, 2013 at 09:26:38AM +, d_h...@hotmail.com wrote: You need to build with the newest version of mingw from the mingw64-i686 package. It seems like yours is out of date. Corinna and I build with the i686-w64-mingw32 target. It appears I have the latest version (gcc, g++, 4.5.3-6, runtime runtime-3.0b_svn5747-1, headers-3.0b_svn5747-1) offered by mirrors.kernel.org (checked prior to this email via setup against then current, and installed /var/log/setup.log), which is listed at http://cygwin.com/mirrors.html as an up-to-date mirror. 1)Please advise what pkg version, mirror, or ? can provide appropriate build context. The package is ming264-i686. That's why I mentioned it. There is no specific mirror that you need to get proper packages. That's why they're called mirrors. 2)Should configure check for and advise of possible problems with 'incorrect' version of mingw64? Since the builders of setup.exe are supposed to be people who understand the process there doesn't seem to be a whole lot of need to make configure foolproof. However, we certainly wouldn't object to patches.
[64bit] Wrong permissions on emacs-auctex directory
Marco, I'm trying to update emacs-auctex, but you're the owner of /sourceware/ftp/pub/cygwin/64bit/release/TeX/emacs-auctex, and the cygwin group doesn't have write permission on the directory or its files. Could you fix this? Thanks. Ken
Re: [64bit] Wrong permissions on emacs-auctex directory
Il 6/21/2013 4:26 PM, Ken Brown ha scritto: Marco, I'm trying to update emacs-auctex, but you're the owner of /sourceware/ftp/pub/cygwin/64bit/release/TeX/emacs-auctex, and the cygwin group doesn't have write permission on the directory or its files. Could you fix this? Thanks. Ken changed
Re: fltk / gl rendering problem
On 17/06/2013 07:48, marco atzeri wrote: Il 6/16/2013 4:51 PM, marco atzeri ha scritto: testing a octave/fltk graphics issue, I noticed that also the demo of fltk with GL interface has a similar issue. Thanks for reporting this and thanks for providing the test binaries. On http://matzeri.altervista.org/works/fltk_gl/ I uploaded the before and after apperance of gl_overlay demo. It is enough to move the window to loose the geometrical image while the bars are correctly re-drawn. Running Xwin with -wgl does not show such defect, but it is terribly slow. So I assume it is not a fltk defect but of GL or XServer. I guess this should read with -nowgl, in which case, this is a limitation of the current implementation of -wgl mode, which will require lots of work to fix. I wrote a bit about these limitations at [1] [1] http://www.cygwin.com/ml/cygwin-xfree/2012-10/msg9.html further experiment showed that the defect is present when the integrate windows manager is used. With external window manager (fvwm, openbox,.. ) that defect does not apper. With external window manager another defect appears, the upper bar effect is not shown at all; while it is present on the integrated window manager. When I tested this, it looks like the solid area controlled by the sides slider didn't get rendered into a separate layer when using software rendering (either -nowgl or X server in windowed mode), so this is possibly some bug or limitation in the software renderer, or possibly in a bug in the demo not recognizing the lack of capabilities of the software renderer. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 64-bit Clipboard troubles
On 10/06/2013 22:39, David Stacey wrote: On 10/06/13 14:30, Jon TURNEY wrote: On 09/06/2013 19:59, David Stacey wrote: I am trying to package keepassx for 64-bit Cygwin, and have noticed a difference between the way the clipboard functions under 32-bit and 64-bit Cygwin/X. Essentially, keepassx is an encrypted password database that copies your username and password to the clipboard. Then, you can paste these into a web site (say) to log in. When I run keepassx (both 32-bit and 64-bit builds) using the 32-bit version of XWin, keepassx copies the username and password to the clipboard, and these can be pasted into a native Windows web browser (e.g. Firefox). However, when I run keepassx (again, both 32-bit and 64-bit builds) using the 64-bit version of XWin, the procedure breaks: I instruct keepassx to copy to the clipboard, but when I paste in the web browser, no text is pasted. Sorry, integration between the native and X clipboards is broken in 64-bit XWin. Unfortunately, this is rather complex to fix and I haven't found the time to do so yet. Thank you for your reply. I've sent an RFU for keepassx along with a link to your reply. If and when you tie the two clipboards together, keepassx should just start working - there shouldn't be a need to rebuild it, but I'll do that if necessary. This should be working as of xserver 1.14.1-2. Please test if you can and let me know if there are any problems. On 10/06/2013 14:30, Jon TURNEY wrote: I mentioned that my testcase programme doesn't quite work as I intended: writing to the clipboard using Qt4 and reading it back by reading /dev/clipboard fails when using both 32-bit and 64-bit XWin. I don't understand why, but this is probably down to my own limited understanding of the clipboard in X. Thanks for writing this useful testcase. From a brief glance, the test looks well formed, so I'll also try to take a look at why test 2 always fails, I guess this indicates some bug in the clipboard integration. Looking again, I think maybe that the problem with test 2 is that it's necessary for Qt's main event loop to be running for pastes from the X clipboard to work. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: cygwin and xwin and super and hyper
Jon TURNEY jon.tur...@dronecode.org.uk writes:
On 19/06/2013 22:27, J. David Boyd wrote:
I can get my capslock key to be super with the command line 'setxkbmap
-option
caps:super', but I can't get 'setxkbmap -option altwin:hyper_win' to do
anything.
Running 'setxkbmap -print' shows both options as being set, but the win keys
still act as the win key.
Is there something else I need to do so windows lets go of these keys?
Yes.
Again, let me refer you to [1]. The operative sentence is:
(Note that mapping the Windows keys to hyper also requires the -keyhook
option, so that the X server sees those keys before the Windows shell)
One thing I failed to mention there is that without any keymap options the
keymap should give you super on the windows keys, but you will still need
-keyhook X server option to enable the X server to see the key.
[1] http://cygwin.com/ml/cygwin/2012-03/msg00427.html
I can get everything working up to the point I start emacs.
The output from 'setxkbmap -print' is:
xkb_keymap {
xkb_keycodes { include xfree86+aliases(qwerty) };
xkb_types { include complete };
xkb_compat{ include complete };
xkb_symbols { include
pc+us+inet(pc105)+altwin(alt_super_win)+capslock(hyper) };
xkb_geometry { include pc(pc105) };
};
and if I run XEV, and press capslock I get:
KeyPress event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8145997, (504,324), root:(2162,400),
state 0x0, keycode 66 (keysym 0xffed, Hyper_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8146122, (504,324), root:(2162,400),
state 0x40, keycode 66 (keysym 0xffed, Hyper_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
and if I press Left Windows key I get:
KeyPress event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8148993, (504,324), root:(2162,400),
state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8149102, (504,324), root:(2162,400),
state 0x40, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
All perfect so far.
So, when I start up emacs, and press C-h k, then, for example, Capslock-d,
(hyper-d) I get 'H-d is undefined'. Yeah.
Then I press C-h k, then Left-Win-d, (super-d), I get 'H-d is undefined', and
not 's-d is undefined', which is what I expected to see.
Any ideas how I might resolve this?
Dave
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: 64-bit Clipboard troubles
On 21/06/13 13:33, Jon TURNEY wrote: On 10/06/2013 22:39, David Stacey wrote: On 10/06/13 14:30, Jon TURNEY wrote: On 09/06/2013 19:59, David Stacey wrote: I am trying to package keepassx for 64-bit Cygwin, and have noticed a difference between the way the clipboard functions under 32-bit and 64-bit Cygwin/X. Essentially, keepassx is an encrypted password database that copies your username and password to the clipboard. Then, you can paste these into a web site (say) to log in. When I run keepassx (both 32-bit and 64-bit builds) using the 32-bit version of XWin, keepassx copies the username and password to the clipboard, and these can be pasted into a native Windows web browser (e.g. Firefox). However, when I run keepassx (again, both 32-bit and 64-bit builds) using the 64-bit version of XWin, the procedure breaks: I instruct keepassx to copy to the clipboard, but when I paste in the web browser, no text is pasted. Sorry, integration between the native and X clipboards is broken in 64-bit XWin. Unfortunately, this is rather complex to fix and I haven't found the time to do so yet. Thank you for your reply. I've sent an RFU for keepassx along with a link to your reply. If and when you tie the two clipboards together, keepassx should just start working - there shouldn't be a need to rebuild it, but I'll do that if necessary. This should be working as of xserver 1.14.1-2. Please test if you can and let me know if there are any problems. Thank you for implementing this functionality. I have tested xserver 1.14.1-2 and can confirm that this is working - keepassx can copy URLs, usernames and passwords into the Windows clipboard. Many thanks once again, Dave. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog path.cc path.sgml
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2013-06-21 08:14:26 Modified files: winsup/cygwin : ChangeLog path.cc path.sgml Log message: * path.cc (cygwin_conv_path): Handle NULL from path gracefully. * path.sgml (func-cygwin-conv-path): Document returning EINVAL if from is NULL. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6172r2=1.6173 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.679r2=1.680 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.sgml.diff?cvsroot=srcr1=1.10r2=1.11
Failed assertion in path.cc (path_conv::check)
The following statement: char * tmp_path = (char *) cygwin_create_path (CCP_POSIX_TO_WIN_A, newargz[0]); Results in this error popup (and a coredump), when newargz[0] is NULL. Sure, it's a bug in my program to do that...but shouldn't it be handled more gracefully? Like...return a NULL, rather than SIGABRT? Failed assertion src at line 675 of file /home/corinna/src/cygwin/cygwin-1.7.21/64/cygwin-1.7.21-5/src /src/winsup/cygwin/path.cc in function void path_conv::check(const char*, unsigned int, const suffix_info*) -- Chuck -- 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 Jun 20 18:56, Jeffrey Altman wrote: 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. Guys, whatever the problem here is, it needs to be investigated and potentially implemented by somebody who knows this kerberos/gss-api stuff. Openssh is built against these libraries and that's it from my side. If something's missing in openssh to support this correctly on Cygwin, or if the Cygwin DLL to support this authentication model, I simply don't know what it is. I appreciate any coding help. 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 (was: Adding MSYS functionality to Cygwin)
On Jun 20 22:38, Andrew Schulman wrote: 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! Uhm, that was a projection into the ideal future. No provisions have been made yet. We need to set up a central repository like Yaakov's cygwinports git repo and a central build mechanism. The first we can probably shamelessly copy from Yaakov and set up over the next few months, the second needs a bit of hacking. 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
Problems with file permissions during a build
Hello, I have been experiencing problems with building several unrelated projects on Cygwin/Windows 7. One of them is GCC 4.8.1, another is a project that uses CMake to create the Makefiles. The problems occur either during the configuration (the CMake-based project) or during the make itself (GCC). What happens is that during the build files are created that have a file permission of -, which makes them unusable by the next step in the build. According to the FAQ this could be caused by the translation between POSIX permissions and the Windows ACE information. To get around that, I tried to turn off ACL for the disk I am working on, but that failed. Obviously I am doing something wrong. But I can not find the information to solve this issue. Do you have any suggestions? I have attached the result of cygcheck, as suggested in the reporting guidelines. Regards, Arjen cygcheck.out Description: Binary data -- 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: Failed assertion in path.cc (path_conv::check)
On Jun 21 03:26, Charles Wilson wrote: The following statement: char * tmp_path = (char *) cygwin_create_path (CCP_POSIX_TO_WIN_A, newargz[0]); Results in this error popup (and a coredump), when newargz[0] is NULL. Sure, it's a bug in my program to do that...but shouldn't it be handled more gracefully? Like...return a NULL, rather than SIGABRT? I changed the underlying cygwin_conv_path to handle NULL gracefully by returning -1 and setting errno to EINVAL. This results in a NULL return from cygwin_create_path. HTH, 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: Broken MPIR 2.6.0 on Cygwin64
On Jun 21 00:39, Jean-Pierre Flori wrote: 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. [...] /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 Uhm, are you sure this arch and tune options aren't the problem here? 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. The function addresses on the top of the stack (starting with 0x0010...) are well within ld. The Cygwin DLL seems to be involved only in so much as the application's (ld's) main routine has been called. Of course, a call stack doesn't show the actual problem, which could easily be a weird value returned from a POSIX function inside Cygwin. But this looks pretty much like a border case, given how many packages we already created for 64 bit Cygwin. 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? Is building the binutils package yourself and without optimization, but with all debug symbols available an option for you? This should help to track down the problem. 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: Problems with file permissions during a build
On Jun 21 10:05, Arjen Markus wrote: Hello, I have been experiencing problems with building several unrelated projects on Cygwin/Windows 7. One of them is GCC 4.8.1, another is a project that uses CMake to create the Makefiles. The problems occur either during the configuration (the CMake-based project) or during the make itself (GCC). What happens is that during the build files are created that have a file permission of -, which makes them unusable by the next step in the build. According to the FAQ this could be caused by the translation between POSIX permissions and the Windows ACE information. To get around that, I tried to turn off ACL for the disk I am working on, but that failed. Obviously I am doing something wrong. But I can not find the information to solve this issue. Do you have any suggestions? A reproducible, minimal testcase extracted from your project might help. 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: Broken MPIR 2.6.0 on Cygwin64
On Jun 21 10:30, Corinna Vinschen wrote: On Jun 21 00:39, Jean-Pierre Flori wrote: [...] /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 Uhm, are you sure this arch and tune options aren't the problem here? 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. The function addresses on the top of the stack (starting with 0x0010...) are well within ld. The Cygwin DLL seems to be involved only in so much as the application's (ld's) main routine has been called. Btw., if you install the binutils-debuginfo package, you can also evaluate the addresses within ld on the top of the stack: $ addr2line -e /usr/lib/debug/usr/bin/ld.exe.dbg 00100493B54 00100433783 0010040E82C 0010040F2E0 001004113FB 001004BF4C0 /usr/src/debug/binutils-2.23.52-5/bfd/cofflink.c:219 /usr/src/debug/binutils-2.23.52-5/bfd/linker.c:1132 /usr/src/debug/binutils-2.23.52-5/ld/ldlang.c:2795 /usr/src/debug/binutils-2.23.52-5/ld/ldlang.c:3257 /usr/src/debug/binutils-2.23.52-5/ld/ldlang.c:6606 /usr/src/debug/binutils-2.23.52-5/ld/ldmain.c:415 But I admit this doesn;'t help a lot either, if you don't know why it crashed at this point. 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: Broken MPIR 2.6.0 on Cygwin64
Hey, Thanks for the quick reply. Le Fri, 21 Jun 2013 10:30:39 +0200, Corinna Vinschen a écrit : /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 Uhm, are you sure this arch and tune options aren't the problem here? This is automatically determined by the configure script, I get the same for GMP, it actually corresponds to my CPU, and works fine on Linux. Anyway, I've also tried with only -m64 -O0 -g and got similar results. Is building the binutils package yourself and without optimization, but with all debug symbols available an option for you? This should help to track down the problem. It's an option. I'll try to do that today. Best, JP -- 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: Broken MPIR 2.6.0 on Cygwin64
On Jun 21 09:27, Jean-Pierre Flori wrote: Hey, Thanks for the quick reply. Le Fri, 21 Jun 2013 10:30:39 +0200, Corinna Vinschen a écrit : /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 Uhm, are you sure this arch and tune options aren't the problem here? This is automatically determined by the configure script, I get the same for GMP, it actually corresponds to my CPU, and works fine on Linux. Anyway, I've also tried with only -m64 -O0 -g and got similar results. Is building the binutils package yourself and without optimization, but with all debug symbols available an option for you? This should help to track down the problem. It's an option. I'll try to do that today. The easiest way to do that is to fetch the binutils-2.23.52-5 source package from a Cygwin mirror and to use cygport for building. Just tweak the cygport file to set MAKEOPTS to 'CFLAGS=-g'. 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
[ANNOUNCEMENT] Updated: TeX Live 2013
Cygwin's TeX Live packages have been updated to the latest upstream release, TeX Live 2013. TeX Live provides a comprehensive, cross-platform TeX system. It includes all the major TeX-related programs, macro packages, and fonts that are free software, including support for many languages around the world. For more information, see http://www.tug.org/texlive/ The TeX Live executables and supporting libraries are contained in the following Cygwin packages: *** texlive-20130529-1 *** libkpathsea6-20130529-1 *** libkpathsea-devel-20130529-1 libkpathsea is a TeX file and path search library. *** libptexenc1-20130529-1 *** libptexenc-devel-20130529-1 libptexenc is a TeX Unicode encoding library. *** asymptote-2.23-1 Asymptote is a powerful descriptive vector graphics language for technical drawing, inspired by MetaPost but with an improved C++-like syntax. Asymptote provides for figures the same high-quality typesetting that LaTeX does for scientific text. In addition, upstream TeX Live provides thousands of packages, grouped into collections. There is a Cygwin package for each upstream collection; there are also Cygwin packages containing documentation for some of the collections. *** texlive-collection-basic-20130529-1 *** texlive-collection-basic-doc-20130529-1 *** texlive-collection-bibtexextra-20130529-1 *** texlive-collection-bibtexextra-doc-20130529-1 *** texlive-collection-binextra-20130529-1 *** texlive-collection-binextra-doc-20130529-1 *** texlive-collection-context-20130529-1 *** texlive-collection-context-doc-20130529-1 *** texlive-collection-fontsextra-20130529-1 *** texlive-collection-fontsextra-doc-20130529-1 *** texlive-collection-fontsrecommended-20130529-1 *** texlive-collection-fontsrecommended-doc-20130529-1 *** texlive-collection-fontutils-20130529-1 *** texlive-collection-fontutils-doc-20130529-1 *** texlive-collection-formatsextra-20130529-1 *** texlive-collection-games-20130529-1 *** texlive-collection-genericextra-20130529-1 *** texlive-collection-genericextra-doc-20130529-1 *** texlive-collection-genericrecommended-20130529-1 *** texlive-collection-genericrecommended-doc-20130529-1 *** texlive-collection-htmlxml-20130529-1 *** texlive-collection-humanities-20130529-1 *** texlive-collection-humanities-doc-20130529-1 *** texlive-collection-langafrican-20130529-1 *** texlive-collection-langarabic-20130529-1 *** texlive-collection-langcjk-20130529-1 *** texlive-collection-langcyrillic-20130529-1 *** texlive-collection-langczechslovak-20130529-1 *** texlive-collection-langenglish-20130529-1 *** texlive-collection-langeuropean-20130529-1 *** texlive-collection-langfrench-20130529-1 *** texlive-collection-langgerman-20130529-1 *** texlive-collection-langgreek-20130529-1 *** texlive-collection-langindic-20130529-1 *** texlive-collection-langitalian-20130529-1 *** texlive-collection-langother-20130529-1 *** texlive-collection-langpolish-20130529-1 *** texlive-collection-langportuguese-20130529-1 *** texlive-collection-langspanish-20130529-1 *** texlive-collection-latex-20130529-1 *** texlive-collection-latex-doc-20130529-1 *** texlive-collection-latexextra-20130529-1 *** texlive-collection-latexextra-doc-20130529-1 *** texlive-collection-latexrecommended-20130529-1 *** texlive-collection-latexrecommended-doc-20130529-1 *** texlive-collection-luatex-20130529-1 *** texlive-collection-luatex-doc-20130529-1 *** texlive-collection-mathextra-20130529-1 *** texlive-collection-mathextra-doc-20130529-1 *** texlive-collection-metapost-20130529-1 *** texlive-collection-metapost-doc-20130529-1 *** texlive-collection-music-20130529-1 *** texlive-collection-music-doc-20130529-1 *** texlive-collection-omega-20130529-1 *** texlive-collection-pictures-20130529-1 *** texlive-collection-pictures-doc-20130529-1 *** texlive-collection-plainextra-20130529-1 *** texlive-collection-pstricks-20130529-1 *** texlive-collection-pstricks-doc-20130529-1 *** texlive-collection-publishers-20130529-1 *** texlive-collection-publishers-doc-20130529-1 *** texlive-collection-science-20130529-1 *** texlive-collection-science-doc-20130529-1 *** texlive-collection-xetex-20130529-1 *** texlive-collection-xetex-doc-20130529-1 Due to upstream reorganization of the collections, the following Cygwin packages are now obsolete: *** texlive-collection-documentation-arabic *** texlive-collection-documentation-base *** texlive-collection-documentation-bulgarian *** texlive-collection-documentation-chinese *** texlive-collection-documentation-czechslovak *** texlive-collection-documentation-dutch *** texlive-collection-documentation-english *** texlive-collection-documentation-finnish *** texlive-collection-documentation-french *** texlive-collection-documentation-german *** texlive-collection-documentation-italian *** texlive-collection-documentation-japanese *** texlive-collection-documentation-korean *** texlive-collection-documentation-mongolian *** texlive-collection-documentation-polish ***
Re: Problems with file permissions during a build
I have a small testcase, but my replies are consistently refused. How do I solve that? Regards, Arjen -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problems with file permissions during a build
On Jun 21 13:00, Arjen Markus wrote: I have a small testcase, but my replies are consistently refused. How do I solve that? The reason should be given in the reply you get. Basically, don't use raw email addresses in your body, don't use html. 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: Problems with file permissions during a build
Well, I got a message back about using too many keywords that made it look like an off-topic reply. But without an indication (of course) of what these keywords are. Regards, Arjen -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problems with file permissions during a build
Trying again: - Unpack the tar file in a separate directory, say, and create a work directory in which to configure and build it, something like: src/ - contents of the tar-file work/ - directory to work in CMakeLists.txt - the main CMake file - Run CMake in the work directory: cmake -G Cygwin Makefiles ../src This should complete without problems. - Examine the contents of the directory src/include in the working directory. The file permissions for the file gnulliver.h are - This is the result on my machine: $ ls -l total 13 -rw-r--r-- 1 markus Unit DSC 1802 Jun 21 10:48 cmake_install.cmake drwxr-xr-x+ 1 markus Unit DSC0 Jun 21 10:48 CMakeFiles -- 1 markus Unit DSC 41 Jun 21 10:48 gnulliver.h -rw-r--r-- 1 markus Unit DSC 5759 Jun 21 10:48 Makefile Regards, Arjen -- 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
libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)
Hi Chuck, Hi Yaakov,
as our resident autotools/libtool experts, could you please have a
look here?
On Jun 21 11:43, Corinna Vinschen wrote:
On Jun 21 09:27, Jean-Pierre Flori wrote:
Hey,
Thanks for the quick reply.
Le Fri, 21 Jun 2013 10:30:39 +0200, Corinna Vinschen a écrit :
/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
Uhm, are you sure this arch and tune options aren't the problem here?
This is automatically determined by the configure script, I get the same
for GMP, it actually corresponds to my CPU, and works fine on Linux.
Anyway, I've also tried with only -m64 -O0 -g and got similar results.
Is building the binutils package yourself and without optimization, but
with all debug symbols available an option for you? This should help to
track down the problem.
It's an option.
I'll try to do that today.
The easiest way to do that is to fetch the binutils-2.23.52-5 source
package from a Cygwin mirror and to use cygport for building. Just
tweak the cygport file to set MAKEOPTS to 'CFLAGS=-g'.
For testing I created a simple cygport file to build mpir 2.6.0:
NAME=mpir
VERSION=2.6.0
RELEASE=1
CATEGORY=Math
SUMMARY=MPIR
DESCRIPTION=MPIR
SRC_URI=http://www.mpir.org/${P}.tar.bz2;
Then I tried to build it. Of course, cygport autoreconfs and our
libtool version 2.4.2 is installed. Configure runs fine.
When building, first it failed to build in the mpn subdir, because it
accidentally calls yasm with the -f elf64 flag. I fixed that locally by
tweaking mpn/Makefile by setting OBJECT_FORMAT from -f elf64 to -f
win64. There's also the problem that libtool adds the -DPIC flag and
this leads to using the wrong code path in mpn/modexact_1c_odd.as.
Change lines 107ff to
;%ifdef PIC
;mov r9, [mod_table wrt rip wrt ..gotpcrel]
;%else
lea r9, [mod_table wrt rip]
;%endif
effectively disabling the GOT table access, then it builds.
But that's just a minor inconvenience, the real problem comes in the
final link stage. When trying to link libmpir.la, something weird happens.
The libtool command line is basically this:
/bin/sh ./libtool --tag=CC--mode=link gcc -std=gnu99 \
-ggdb -O2 -pipe -fdebug-prefix-map=[...] -fdebug-prefix-map=[...] \
-no-undefined -Wl,--export-all-symbols \
-Wl,--output-def,.libs/libmpir-3.dll.def \
-version-info 11:0 :5 \
-o libmpir.la -rpath \
[loong list of .lo files]
This gets converted by libtool into the following calls:
libtool: link: /usr/x86_64-pc-cygwin/bin/ld.exe -r -o .libs/libmpir.la-1.o \
[long list of .o files]
libtool: link: /usr/x86_64-pc-cygwin/bin/ld.exe -r -o .libs/libmpir.la-2.o \
[second long list of .o files]
libtool: link: rm -f .libs/libmpir.la-1.o
libtool: link: gcc -std=gnu99 -shared .libs/libmpir.la-2.o -O2 \
-Wl,--export-all-symbols -Wl,--output-def -Wl,.libs/libmpir-3.dll.def \
-o .libs/libmpir-11.dll \ # Problem 2
-Wl,--enable-auto-image-base \
-Xlinker --out-implib -Xlinker .libs/libmpir-11.dll # Problem 1
This result has two big problems I never encountered with libtool before,
and one problem which is probably just a followup issue:
Problem 1:
The final call fails with
Can't open .lib file: .libs/libmpir-11.dll
The reason is the final -Xlinker option, which uses the wrong filename for
the import lib. That should be .libs/libmpir-11.dll.a. I have found no
way to tweak the libtool command line so that the -Xlinker option is
either omitted, or so that it uses the correct filename.
How can this be fixed?
Problem 2:
Even when running the last stage of the build by hand, replacing
.libs/libmpir-11.dll with .libs/libmpir-11.dll.a, the fact remains
that the result will be called libmpir-11.dll, rather than the
usual cygmpir-11.dll.
Why does libtool generate the wrong filename here?
Problem 3:
Even when running the last stage of the build by hand as described
above, the final result will NOT have generated a libmpir.la file.
This in turn disallows to run the testsuite, which requires the .la
file to exist.
What's missing to create the .la file here?
Thanks for any help,
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: Problems with file permissions during a build
On Jun 21 13:18, Arjen Markus wrote: Trying again: - Unpack the tar file in a separate directory, say, and create a work directory in which to configure and build it, something like: src/ - contents of the tar-file work/ - directory to work in CMakeLists.txt - the main CMake file - Run CMake in the work directory: cmake -G Cygwin Makefiles ../src This should complete without problems. - Examine the contents of the directory src/include in the working directory. The file permissions for the file gnulliver.h are - This is the result on my machine: $ ls -l total 13 -rw-r--r-- 1 markus Unit DSC 1802 Jun 21 10:48 cmake_install.cmake drwxr-xr-x+ 1 markus Unit DSC0 Jun 21 10:48 CMakeFiles -- 1 markus Unit DSC 41 Jun 21 10:48 gnulliver.h -rw-r--r-- 1 markus Unit DSC 5759 Jun 21 10:48 Makefile Thanks, but... the tar file is missing... 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: Problems with file permissions during a build
Here it is. Regards, Arjen problem-cygwin.tgz Description: GNU Zip compressed data -- 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 20 09:46, Corinna Vinschen wrote: 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. Matt? Ping? Does the new patch 2.7.1 help? Thanks, 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: Problems with file permissions during a build
On Jun 21 13:40, Arjen Markus wrote: Here it is. Regards, Arjen Is the tar file broken? $ tar xvzf problem-cygwin.tgz src/ src/CMakeLists.txt src/include/ src/include/CMakeLists.txt src/include/gnulliver.h.in CMakeLists.txt tar: A lone zero block at 11 $ mkdir work $ cd work $ cmake --G Cygwin Makefiles ../src CMake Error: Could not create named generator Cygwin Makefiles 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: Problems with file permissions during a build
Oops, my mistake. The correct invocation of CMake is: cmake -G Unix Makefiles ../ (These generators are part of CMake, not of the tar file) Regards, Arjen -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problems with file permissions during a build
On Jun 21 14:18, Arjen Markus wrote: Oops, my mistake. The correct invocation of CMake is: cmake -G Unix Makefiles ../ (These generators are part of CMake, not of the tar file) Ok, thank you. I never used cmake before so I didn't notice. Other than that, I have not the problem you're reporting: $ cmake -G Unix Makefiles ../ -- The C compiler identification is GNU 4.5.3 CMake Warning at /usr/share/cmake-2.8.9/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-2.8.9/Modules/CMakeSystemSpecificInformation.cmake:36 (INCLUDE) CMakeLists.txt:3 (project) -- Check for working C compiler: /usr/bin/gcc.exe -- Check for working C compiler: /usr/bin/gcc.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- CMake version = 2.8.9 -- Configuring done -- Generating done -- Build files have been written to: /home/corinna/tmp/cmake/work $ ls -l src/include total 13 -rw-r--r-- 1 corinna vinschen 1788 Jun 21 14:24 cmake_install.cmake drwxr-xr-x+ 1 corinna vinschen0 Jun 21 14:24 CMakeFiles -rw-r--r-- 1 corinna vinschen 41 Jun 21 14:24 gnulliver.h -rw-r--r-- 1 corinna vinschen 5675 Jun 21 14:24 Makefile Are you using all the latest Cygwin packages? Are you running this in a directory under the /cygdrive prefix or under a remote share? If so, what if you build under a path within the normal POSIX directory structure? Running this call under strace might help to see if this is a problem in Cygwin or cmake. 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: Problems with file permissions during a build
I noticed that if I use noacl, then I get the correct looking POSIX permissions, but the Windows permissions make it impossible to use the file. Try: cat gnulliver.h I have had the same problem with a package built via autotools, so it is more general than CMake. (I first reported this on the CMake list, but they did not know the solution) I run it on /cygdrive/d, which is my Windows d-disk. Regards, Arjen -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problems with file permissions during a build
On Jun 21 14:38, Arjen Markus wrote: I noticed that if I use noacl, then I get the correct looking POSIX permissions, but the Windows permissions make it impossible to use the file. I always use acl as mount option. Try: cat gnulliver.h $ pwd /home/corinna/tmp/cmake/work $ cat src/include/gnulliver.h #define GNULLIVER_HOST_FLOAT32_DOUBLE64 I have had the same problem with a package built via autotools, so it is more general than CMake. (I first reported this on the CMake list, but they did not know the solution) I run it on /cygdrive/d, which is my Windows d-disk. Ok, so I tried under /cygdrive/c and the result is the same, then I tried under an explicit noacl mount point and the result is still the same. The file has always enough permissions and reading it is no problem at all. But the default Windows permissions on the parent dir of your build dir could explain that behavior when using the noacl mount option. Noacl means, just let Windows do what it always does and fake the permissions rather than evaluating them from the given ACL. Remount again with acl, and change the permissions explicitely: $ chown -R you.your-group . $ chmod -R u+rw,go+r . Also, make sure your umask is set to a useful value: $ umask 22 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: Problems with file permissions during a build
Hi Corinna, you seem to have hit the right spot. The parent directories had the permission -- according to Cygwin, but I could still enter them via cd. Things go wrong if under Cygwin a file gets _copied_ via cp or something similar that takes the file permissions according to POSIX from the parent file. Then the copy gets the same unuseable permissions, but this time for real (that is: Windows agrees that they should not be readable!) The build is still running, but I have good hopes this time it can complete. Regards, Arjen -- 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: Broken MPIR 2.6.0 on Cygwin64
Le Fri, 21 Jun 2013 11:43:44 +0200, Corinna Vinschen a écrit : On Jun 21 09:27, Jean-Pierre Flori wrote: Hey, Thanks for the quick reply. Le Fri, 21 Jun 2013 10:30:39 +0200, Corinna Vinschen a écrit : /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 The easiest way to do that is to fetch the binutils-2.23.52-5 source package from a Cygwin mirror and to use cygport for building. Just tweak the cygport file to set MAKEOPTS to 'CFLAGS=-g'. I did it using configure/make/make install directly. Here is the backtrace I got (when trying to build a static library, first of the unsolved problems I reported): Program received signal SIGSEGV, Segmentation fault. 0x003e in ?? () (gdb) bt #0 0x003e in ?? () #1 0x000100499ece in coff_link_check_ar_symbols (abfd=0x60013d1c0, info=0x10058a720 link_info, pneeded=0xc2a6fc, subsbfd=0xc2a6d0) at cofflink.c:217 #2 0x00010049a08f in coff_link_check_archive_element (abfd=0x60013d1c0, info=0x10058a720 link_info, pneeded=0xc2a6fc) at cofflink.c:279 #3 0x00010044cced in _bfd_generic_link_add_archive_symbols ( abfd=0x600081170, info=0x10058a720 link_info, checkfn=0x10049a03e coff_link_check_archive_element) at linker.c:1132 #4 0x000100499daf in _bfd_coff_link_add_symbols (abfd=0x600081170, info=0x10058a720 link_info) at cofflink.c:169 #5 0x00010040fe6f in load_symbols (entry=0x60003ac00, place=0xc2a880) at ldlang.c:2795 #6 0x000100410b66 in open_input_bfds (s=0x60003ac00, mode=OPEN_BFD_NORMAL) at ldlang.c:3257 #7 0x000100416ee9 in lang_process () at ldlang.c:6603 #8 0x00010041b2d3 in main (argc=7, argv=0xc2aa60) at ./ldmain.c:411 Best, JP -- 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/21/2013 3:43 AM, Corinna Vinschen wrote: Guys, whatever the problem here is, it needs to be investigated and potentially implemented by somebody who knows this kerberos/gss-api stuff. Openssh is built against these libraries and that's it from my side. If something's missing in openssh to support this correctly on Cygwin, or if the Cygwin DLL to support this authentication model, I simply don't know what it is. I appreciate any coding help. Corinna Corinna, To the best of my knowledge the Heimdal developers have not been contacted by the Cygwin Heimdal package maintainer. One of my companies, Secure Endpoints, maintains the native Windows distribution of Heimdal. http://www.secure-endpoints.com/heimdal/ Please ask the Heimdal package maintainer for Cygwin to contact me so I can understand how it is being built. 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: Heimdal 1.5.2: unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
On Jun 21 09:39, Jeffrey Altman wrote: On 6/21/2013 3:43 AM, Corinna Vinschen wrote: Guys, whatever the problem here is, it needs to be investigated and potentially implemented by somebody who knows this kerberos/gss-api stuff. Openssh is built against these libraries and that's it from my side. If something's missing in openssh to support this correctly on Cygwin, or if the Cygwin DLL to support this authentication model, I simply don't know what it is. I appreciate any coding help. Corinna Corinna, To the best of my knowledge the Heimdal developers have not been contacted by the Cygwin Heimdal package maintainer. Well, if it builds... One of my companies, Secure Endpoints, maintains the native Windows distribution of Heimdal. http://www.secure-endpoints.com/heimdal/ Please ask the Heimdal package maintainer for Cygwin to contact me so I can understand how it is being built. You can look it up in the source archive really simply: ftp://cygwin.com/pub/cygwin/release/heimdal/heimdal-1.5.2-4-src.tar.bz2 From what I gather from the heimdal.cygport file, there's nothing special in this build, except for four patch files which fix minor build problems and a signal handling bug. 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
[ANNOUNCEMENT] Updated: emacs-auctex-11.87-2
The following package has been updated in the 32-bit Cygwin distribution, and a 64-bit update will follow shortly: *** emacs-auctex-11.87-2 AUCTeX is an extensible package for writing and formatting TeX files in GNU Emacs and XEmacs. It supports many different TeX macro packages, including AMS-TeX, LaTeX, Texinfo, ConTeXt, and DocTeX (dtx files). AUCTeX includes preview-latex which makes LaTeX a tightly integrated component of your editing workflow by visualizing selected source chunks (such as single formulas or graphics) directly as images in the source buffer. This is a rebuild of 11.87-1 to take into account a change in the TeX Live directory structure as of TeX Live 2013. Ken Brown Cygwin's emacs-auctex maintainer *** 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 the above 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
Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
On Fri, Jun 21, 2013 at 09:49:34AM +0200, Corinna Vinschen wrote: On Jun 20 22:38, Andrew Schulman wrote: 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! Uhm, that was a projection into the ideal future. No provisions have been made yet. We need to set up a central repository like Yaakov's cygwinports git repo and a central build mechanism. The first we can probably shamelessly copy from Yaakov and set up over the next few months, the second needs a bit of hacking. I'm not sure if this reminder is needed but, I'm not switching to cygport and I believe there are also a couple of other people using non-cygport packagers as well. -- 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
Unable to delegate credentials from Cygwin ssh client was 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: I am experiencing the same error that Corinna Vinschen have reported on cygwin-apps mailing list about a year ago without any obvious resolution(*), and I was wondering whether somebody was able to resolve it since. I am running Heimdal's kinit (as came with MobaXterm 6.2) under Windows 7 to get a ticket from a Windows AD, and then ssh'ing into RHEL 5 and 6 boxes set up to use pam_krb to authenticate against the same Windows AD. gssapi-with-mic authentication succeeds, but credential delegation does not, and I see the same unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10 error(**) previously reported. This is an issue in my environment, where Kerberos-secured NFS is used to provide access to home directories. One thing I did notice is that when I ssh into an RHEL box, afterwards kinit on the client (Cygwin) side shows a ticket for the RHEL host (as expected), yet it shows that the ticket lacks the forwardable flag, which would probably explain the failure to delegate credentials. So perhaps this is a problem with the SSH client on the Cygwin end (ssh -V reports OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012), rather than Heimdal's? The libdefaults section in krb5.conf on Cygwin does contain forwardable = yes and in contract to how it happens on Cygwin, the Linux-Linux ssh that does delegate credentials correctly also does obtain a forwardable ticket on the client side. TIA for any help. Going back to the original posting. The Heimdal that is being used is MobaXTerm's kinit. What Heimdal is it? Is it a native Windows build? The Secure Endpoints distribution which Microsoft LSA support and MIT credential cache support? Or the Heimdal that is packaged for Cygwin? The Heimdal distribution matters because it will determine where the krb5.conf configuration file is going to be stored. If you aren't sure, use SysInternals Process Monitor to trace the kinit.exe process and see what files it accesses. When kinit is executed, is the -f parameter provided requesting a forwardable ticket granting ticket? If the ticket granting ticket (TGT) is not forwardable, then none of the derived tickets will be. When delegating credentials it is the TGT that is forwarded to the remote host, not the host/hostname@REALM service ticket which is used solely for authentication. 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: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)
Hi all, Here is my experience with a shared version of the library after taking Corinna's message into account, starting from a clean MPIR tarball (except for updating the FSF config.sub/guess) without autoreconfing, and using the Cygwin shipped yasm rather than the one included in MPIR (in case the Cygwin one has patches). Le Fri, 21 Jun 2013 13:33:57 +0200, Corinna Vinschen a écrit : Then I tried to build it. Of course, cygport autoreconfs and our libtool version 2.4.2 is installed. Configure runs fine. When building, first it failed to build in the mpn subdir, because it accidentally calls yasm with the -f elf64 flag. I fixed that locally by tweaking mpn/Makefile by setting OBJECT_FORMAT from -f elf64 to -f The -f elf64 did not make the build fail, but as this suggests I changed it to -f win64... win64. There's also the problem that libtool adds the -DPIC flag and this leads to using the wrong code path in mpn/modexact_1c_odd.as. Change lines 107ff to ;%ifdef PIC ;mov r9, [mod_table wrt rip wrt ..gotpcrel] ;%else lea r9, [mod_table wrt rip] ;%endif ...what make compiling modexact_1c_odd.as fail (which it did not with -f elf64). Same workaround solves the problem. effectively disabling the GOT table access, then it builds. But that's just a minor inconvenience, the real problem comes in the final link stage. When trying to link libmpir.la, something weird happens. The libtool command line is basically this: /bin/sh ./libtool --tag=CC--mode=link gcc -std=gnu99 \ -ggdb -O2 -pipe -fdebug-prefix-map=[...] -fdebug-prefix-map=[...] \ -no-undefined -Wl,--export-all-symbols \ -Wl,--output-def,.libs/libmpir-3.dll.def \ -version-info 11:0 :5 \ -o libmpir.la -rpath \ [loong list of .lo files] This gets converted by libtool into the following calls: libtool: link: /usr/x86_64-pc-cygwin/bin/ld.exe -r -o .libs/libmpir.la-1.o \ [long list of .o files] libtool: link: /usr/x86_64-pc-cygwin/bin/ld.exe -r -o .libs/libmpir.la-2.o \ [second long list of .o files] libtool: link: rm -f .libs/libmpir.la-1.o libtool: link: gcc -std=gnu99 -shared .libs/libmpir.la-2.o -O2 \ -Wl,--export-all-symbols -Wl,--output-def -Wl,.libs/libmpir-3.dll.def \ -o .libs/libmpir-11.dll \# Problem 2 -Wl,--enable-auto-image-base \ -Xlinker --out-implib -Xlinker .libs/libmpir-11.dll # Problem 1 As before I don't have these two problems (not autoreconf in my case) and get correct cygmpir.dll and libmpir.dll.a. I also corrected elf64 to win64 in tests/Makefile as yasm is used there as well. And the bad news is: tests still segfault. I'll also check with the static library now. I'll also check without assembly optimizations, or lowering gcc optimization level, etc. Best and thanks for the help! Hopefully you can come up with proper fixes to the build system (to use -f win64 and no -DPIC) and the rest will follow. JP -- 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'
Thank you. I took the time to make certain that I couldn't find any other lingering problems. The update to 2.7.1 corrects the test case I submitted previously. Thanks! :) On 6/21/2013 8:11 AM, Corinna Vinschen wrote: On Jun 20 09:46, Corinna Vinschen wrote: 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. Matt? Ping? Does the new patch 2.7.1 help? Thanks, Corinna -- 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: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)
Le Fri, 21 Jun 2013 16:56:23 +, Jean-Pierre Flori a écrit : And the bad news is: tests still segfault. I'll also check with the static library now. With the same changes but trying a static lib I get to the same point as for the shared one: * ld doesn't segfault anymore, so tests executables are built, * but the same tests as in the shared library setting segfault. I'll also check without assembly optimizations, or lowering gcc optimization level, etc. So I'm going to try that now. -- 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: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)
Le Fri, 21 Jun 2013 17:06:03 +, Jean-Pierre Flori a écrit : I'll also check without assembly optimizations, or lowering gcc optimization level, etc. So I'm going to try that now. If i disable ASM routines by passing MPN_PATH=generic to configure, then (in the static setting at least) most tests now pass. -- 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
Packaging Heimdal for Cygwin was Re: Heimdal 1.5.2: unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
On 6/21/2013 10:07 AM, Corinna Vinschen wrote: To the best of my knowledge the Heimdal developers have not been contacted by the Cygwin Heimdal package maintainer. Well, if it builds... We are discussing security software that must integrate with the native environment. When MIT or Heimdal Kerberos is built for OSX it is built with specific knowledge of the OSX keychain. When XYZ Kerberos is built for Windows natively it has specific knowledge of the Microsoft LSA Kerberos cache (readonly) and provides a secure credential cache implementation into which credentials can be stored and accessed via the MIT credential cache api. The goal of Kerberos is single sign-on so if the user obtains Kerberos credentials as part of the OS logon they should be accessible to the applications that the user executes without requiring that the user enter their password again. On Linux the kernel's keyring support is often used to store Kerberos credentials because it is more secure than plain files. I suspect that functionality is not emulated by cygwin1.dll since it could not in fact be secure unless it was backed by a kernel driver. Since Cygwin Heimdal is built as Linux without any platform specific credential cache support it will be restricted to using FILE: caches as a ticket store. Microsoft Kerberos never uses FILE: based caches and native MIT and Heimdal distributions use them only when explicitly configured to. The preferred location of a krb5.conf file on Windows is %ALLUSERSPROFILE%\Kerberos\krb5.conf By reading the DOS formatted file stored at that location any configuration applied to native Kerberos library distributions will also be used by Cygwin applications. If Cygwin's /etc/krb5.conf is used the system administrator (often an end user without knowledge that Kerberos is even being used) must ensure that the two configuration files are synchronized to avoid inconsistent application behavior. I guess that cygwin1.dll could special case /etc/krb5.conf and have it shadow %ALLUSERSPROFILE%\Kerberos\krb5.conf with appropriate end-of-line translations. You can look it up in the source archive really simply: ftp://cygwin.com/pub/cygwin/release/heimdal/heimdal-1.5.2-4-src.tar.bz2 From what I gather from the heimdal.cygport file, there's nothing special in this build, except for four patch files which fix minor build problems and a signal handling bug. Of the four patches included in the tar ball all but the lib/roken/signal.c patch are specific to the Cygwin build and installation. The lib/roken/signal.c patch could be submitted upstream via a github.com pull request against https://github.com/heimdal/heimdal. 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
Recent Cygwin problems
I've had Cygwin installed on this computer for over two years without any problems but recently I've started seeing a few problems and my installation seems corrupted. 1. Starting several weeks ago, whenever I run setup.exe I get this pop-up message part way through the process. Cygwin Setup - Running postinstall scripts Postinstall script errors These do not necessarily mean that affected packages will fail to function properly, but please check /var/log/setup.log.full and report any problems. Package: Unknown package pango1.0.sh exit code 1 The relevant lines from /var/log/setup.log.full (following a reinstall of the mutt package) seem to be these at the end: 2013/06/21 10:05:29 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/mutt.sh 2013/06/21 10:05:30 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/pango1.0.sh /etc/postinstall/pango1.0.sh: line 1: /etc/pango/pango.modules: No such file or directory 2013/06/21 10:05:30 abnormal exit: exit code=1 2013/06/21 10:05:30 Changing gid to Administrators 2013/06/21 10:07:23 note: Installation Complete 2013/06/21 10:07:23 Ending cygwin install 2. I installed the ttrack time tracking tool from https://github.com/Cartroo/ttrack. It initially worked fine. Following the running of setup.exe on Wednesday to bring my installation up to date, ttrack now generates these errors when started, but it seems to run fine. $ ttrack TimeTrack 1.1.0 Type 'help' to list commands. ttrack Exception in thread Thread-1: Traceback (most recent call last): File /usr/lib/python2.7/threading.py, line 551, in __bootstrap_inner self.run() File /usr/lib/python2.7/site-packages/ttrack-1.1.0-py2.7.egg/EGG-INFO/scripts/ttrack, line 288, in run updater = tracklib.LastSeenUpdater(self.__db) File /usr/lib/python2.7/site-packages/ttrack-1.1.0-py2.7.egg/tracklib.py, line 380, in __init__ self.conn = sqlite3.connect(db.filename) OperationalError: disk I/O error 3. I ran cygcheck -c today to see what it might tell me. It showed mutt 1.5.20-1 Incomplete so I ran setup.exe to reinstall the mutt package. The package is still incomplete: $ cygcheck -cv mutt Cygwin Package Information Last downloaded files to: C:\Documents and Settings\gajohnso\Application Data\Cygwin Last downloaded files from: http://mirrors.kernel.org/sourceware/cygwin/ Package VersionStatus Missing file: /etc/Muttrc.setupnew from package mutt Missing file: /etc/mime.types.setupnew from package mutt mutt 1.5.20-1 Incomplete 4. I ran cygcheck -srv which indicated several problems, including Not found: gcc, so I tried reinstalling gcc but cygcheck still shows the same message. Would someone please take a look at the attached output of cygcheck -srv (including the messages to stderr) and let me know how I might fix this mess? (I sanitized it only to the extent of changing some names to MY) I had been installing packages from kernel.org but changed to osuosl.org in case the kernel.org repository had become corrupted, but I didn't see any difference. Regards, Gary Cygwin Configuration Diagnostics Current System Time: Fri Jun 21 17:58:05 2013 Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\Program Files\Windows Resource Kits\Tools C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Files\Common Files\Roxio Shared\DLLShared C:\Program Files\Common Files\Roxio Shared\10.0\DLLShared C:\Program Files\Windows Imaging C:\Program Files\Intel\WiFi\bin C:\Program Files\Common Files\Intel\WirelessCommon C:\Program Files\vim\vim73 C:\Program Files\Common Files\Hitachi ID C:\Program Files\Perforce C:\Program Files\QuickTime\QTSystem Output from C:\cygwin\bin\id.exe UID: 825534(gajohnso)GID: 10513(Domain Users) 10513(Domain Users) 0(root) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'gajohnso' PWD = '/home/gajohnso' HOME = '/home/gajohnso' HOMEPATH = '\' MANPATH = '/usr/local/man:/usr/share/man:/usr/man:' APPDATA = 'C:\Documents and Settings\gajohnso\Application Data' HOSTNAME = 'MYHOSTNAME' SHELL = '/bin/bash' TERM = 'xterm' RoxioCentral = 'C:\Program Files\Common Files\Roxio Shared\10.0\Roxio Central36\' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 37 Stepping 2, GenuineIntel' WINDIR = 'C:\WINDOWS' EMC_AUTOPLAY = 'C:\Program Files\Common Files\Roxio Shared\' OLDPWD =
Re: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)
On 2013-06-21 06:33, Corinna Vinschen wrote: as our resident autotools/libtool experts, could you please have a look here? The problem is, as a fork of GMP, it too tries to be too clever with libtool in an attempt to shorten configure times by avoiding the CXX/F77 checks. Those hacks are not only unnecessary with libtool 2.x, they are incompatible with it. Run the following to remove the offending 25 lines of configure: sed -i -e '/# Enable CXX/,/AC_PROVIDE/d' configure.in Then you still need to teach configure.in about Cygwin wrt -f win32/win64 and which asm sources to use before running (cyg)autoreconf. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygport limitations
On 6/20/2013 12:10, Corinna Vinschen wrote: 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. With cygport, you wouldn't even need to provide sources. We could email in the new cygport file instead of an RFU. -- 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: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)
Le Fri, 21 Jun 2013 17:27:22 +, Jean-Pierre Flori a écrit : Le Fri, 21 Jun 2013 17:06:03 +, Jean-Pierre Flori a écrit : I'll also check without assembly optimizations, or lowering gcc optimization level, etc. So I'm going to try that now. If i disable ASM routines by passing MPN_PATH=generic to configure, then (in the static setting at least) most tests now pass. Using the default MPN_PATH I get x86_64/sandybridge x86_64 generic, the first segfault I get is in the first test in the mpn dir: t-addadd_n.c. GDB points to the loop1() function: jp@napoleon-7 ~/mpir-2.6.0/tests/mpn $ gdb t-addadd_n.exe GNU gdb (GDB) 7.6.50.20130320-cvs Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/ gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-unknown-cygwin. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/jp/mpir-2.6.0/tests/mpn/t-addadd_n.exe...done. (gdb) r Starting program: /home/jp/mpir-2.6.0/tests/mpn/t-addadd_n.exe [New Thread 2576.0x9b8] [New Thread 2576.0x398] Program received signal SIGSEGV, Segmentation fault. 0x0001004020ae in loop1 () (gdb) bt #0 0x0001004020ae in loop1 () #1 0x000100401fe7 in __gmpn_addadd_n (t=0x1c8fc0, x=optimized out, y=optimized out, z=optimized out, n=1) at addadd_n.c:50 #2 0x000100425fb6 in main () at t-addadd_n.c:58 apparently coming from add_n.as. If someone sees something wrong in the asm files, I have no experience with 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: cygport limitations
On 6/21/2013 12:05, Warren Young wrote: On 6/20/2013 12:10, Corinna Vinschen wrote: 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. With cygport, you wouldn't even need to provide sources. We could email in the new cygport file instead of an RFU. ...and patches. ...and customized .hint files, if needed. Yeah, I guess sending the .src.tar.bz2 probably is effectively required. -- 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
dosfilewarning
I have a BAT file that calls a bash script that generates the following (edited): cygwin warning: MS-DOS style path detected: XXX Preferred POSIX equivalent is: XXX CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames If I rerun the script, I don't get the message a second time, which makes debugging the problem a problem. How can I have this message show up on every invocation? I tried closing all Cygwin processes and tried setting CYGWIN=dosfilewarning, but it seemed to want something more. --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: cygport limitations
On 2013-06-21 13:10, Warren Young wrote: On 6/21/2013 12:05, Warren Young wrote: With cygport, you wouldn't even need to provide sources. We could email in the new cygport file instead of an RFU. ...and patches. ...and customized .hint files, if needed. Yeah, I guess sending the .src.tar.bz2 probably is effectively required. No, it's not. IIUC, the eventual goal should be something that looks like Ports git: http://cygwin-ports.git.sourceforge.net/ together with a buildbot. Package maintainers would then commit their changes to a package's repo, which would then trigger a post-commit hook that would cause the package to be built with those changes. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dosfilewarning
On 6/21/2013 2:38 PM, Nellis, Kenneth wrote: I have a BAT file that calls a bash script that generates the following (edited): cygwin warning: MS-DOS style path detected: XXX Preferred POSIX equivalent is: XXX CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames If I rerun the script, I don't get the message a second time, which makes debugging the problem a problem. How can I have this message show up on every invocation? I tried closing all Cygwin processes and tried setting CYGWIN=dosfilewarning, but it seemed to want something more. It's not designed to do that. It will show up once per Cygwin DLL session only. If you want to see something different, you'll need to patch the Cygwin source. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: dosfilewarning
From: Larry Hall (Cygwin) On 6/21/2013 2:38 PM, Nellis, Kenneth wrote: I have a BAT file that calls a bash script that generates the following (edited): cygwin warning: MS-DOS style path detected: XXX Preferred POSIX equivalent is: XXX CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames If I rerun the script, I don't get the message a second time, which makes debugging the problem a problem. How can I have this message show up on every invocation? I tried closing all Cygwin processes and tried setting CYGWIN=dosfilewarning, but it seemed to want something more. It's not designed to do that. It will show up once per Cygwin DLL session only. If you want to see something different, you'll need to patch the Cygwin source. Thanx, but isn't the end of a Cygwin DLL session when all processes that use the Cygwin DLL have terminated? --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: cygport limitations (was: Adding MSYS functionality to Cygwin)
On Fri, Jun 21, 2013 at 09:49:34AM +0200, Corinna Vinschen wrote: On Jun 20 22:38, Andrew Schulman wrote: 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! Uhm, that was a projection into the ideal future. No provisions have been made yet. We need to set up a central repository like Yaakov's cygwinports git repo and a central build mechanism. The first we can probably shamelessly copy from Yaakov and set up over the next few months, the second needs a bit of hacking. I'm not sure if this reminder is needed but, I'm not switching to cygport and I believe there are also a couple of other people using non-cygport packagers as well. I guess there will always be some maintainers who don't want to use cygport, but I don't think that should be a reason to keep all of the rest of us from moving from the current labor-intensive manual build process, to a more labor-efficient automated process. This vision seems like the future to me. More people will maintain more packages if they can spend less of their time babysitting manual build and upload processes. The distro maintainers should ultimately see a decrease in their labor too. For packages that don't work well with cygport, maybe it would be worthwhile to still support the current manual upload method. The number of those packages would apparently be small. But if a maintainer just doesn't want to use cygport, then I think we should ask whether the project should spend its resources accomodating that preference. I understand that the project doesn't seem ready to take on this task yet, but when there's a need for development or system administration effort to make that vision happen, I'd like to help. Andrew -- 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 Fri, Jun 21, 2013 at 04:03:46PM -0400, Andrew Schulman wrote: On Fri, Jun 21, 2013 at 09:49:34AM +0200, Corinna Vinschen wrote: On Jun 20 22:38, Andrew Schulman wrote: 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! Uhm, that was a projection into the ideal future. No provisions have been made yet. We need to set up a central repository like Yaakov's cygwinports git repo and a central build mechanism. The first we can probably shamelessly copy from Yaakov and set up over the next few months, the second needs a bit of hacking. I'm not sure if this reminder is needed but, I'm not switching to cygport and I believe there are also a couple of other people using non-cygport packagers as well. I guess there will always be some maintainers who don't want to use cygport, but I don't think that should be a reason to keep all of the rest of us from moving from the current labor-intensive manual build process, to a more labor-efficient automated process. You've introduced a false dilemma. There is no reason to assume that any build system will be so limited as to be able to only run one type of build mechanism. The one that I use could easily be dropped into any automated build. Also, while I'm happy to help set up some kind of central repository, please don't anyone assume that sourceware will be used to build packages. That is not an appropriate use of the system. So, someone (Red Hat?) would have to offer up a system to build everything. I've said repeatedly that I'd like to fix the current upload mechanism that we use for Cygwin. I've tried a couple of different mechanisms but neither was really good enough. For packages that don't work well with cygport, maybe it would be worthwhile to still support the current manual upload method. The number of those packages would apparently be small. But if a maintainer just doesn't want to use cygport, then I think we should ask whether the project should spend its resources accomodating that preference. I don't see any reason to adopt that harsh a stance but again: false dilemma... cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problems with file permissions during a build
On 6/21/2013 9:19 AM, Arjen Markus wrote: Hi Corinna, you seem to have hit the right spot. The parent directories had the permission -- according to Cygwin, but I could still enter them via cd. Things go wrong if under Cygwin a file gets _copied_ via cp or something similar that takes the file permissions according to POSIX from the parent file. Then the copy gets the same unuseable permissions, but this time for real (that is: Windows agrees that they should not be readable!) Windows allows you to traverse directories you don't have access to by default. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dosfilewarning
On 6/21/2013 3:47 PM, Nellis, Kenneth wrote: From: Larry Hall (Cygwin) On 6/21/2013 2:38 PM, Nellis, Kenneth wrote: I have a BAT file that calls a bash script that generates the following (edited): cygwin warning: MS-DOS style path detected: XXX Preferred POSIX equivalent is: XXX CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames If I rerun the script, I don't get the message a second time, which makes debugging the problem a problem. How can I have this message show up on every invocation? I tried closing all Cygwin processes and tried setting CYGWIN=dosfilewarning, but it seemed to want something more. It's not designed to do that. It will show up once per Cygwin DLL session only. If you want to see something different, you'll need to patch the Cygwin source. Thanx, but isn't the end of a Cygwin DLL session when all processes that use the Cygwin DLL have terminated? Yes, that's correct. If you're not getting the message, you still have a process somewhere keeping the DLL in memory. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)
Le Fri, 21 Jun 2013 18:07:00 +, Jean-Pierre Flori a écrit : Le Fri, 21 Jun 2013 17:27:22 +, Jean-Pierre Flori a écrit : Le Fri, 21 Jun 2013 17:06:03 +, Jean-Pierre Flori a écrit : I'll also check without assembly optimizations, or lowering gcc optimization level, etc. So I'm going to try that now. If i disable ASM routines by passing MPN_PATH=generic to configure, then (in the static setting at least) most tests now pass. Using the default MPN_PATH I get x86_64/sandybridge x86_64 generic, the first segfault I get is in the first test in the mpn dir: t-addadd_n.c. GDB points to the loop1() function: jp@napoleon-7 ~/mpir-2.6.0/tests/mpn $ gdb t-addadd_n.exe GNU gdb (GDB) 7.6.50.20130320-cvs Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/ gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-unknown-cygwin. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/jp/mpir-2.6.0/tests/mpn/t-addadd_n.exe...done. (gdb) r Starting program: /home/jp/mpir-2.6.0/tests/mpn/t-addadd_n.exe [New Thread 2576.0x9b8] [New Thread 2576.0x398] Program received signal SIGSEGV, Segmentation fault. 0x0001004020ae in loop1 () (gdb) bt #0 0x0001004020ae in loop1 () #1 0x000100401fe7 in __gmpn_addadd_n (t=0x1c8fc0, x=optimized out, y=optimized out, z=optimized out, n=1) at addadd_n.c:50 #2 0x000100425fb6 in main () at t-addadd_n.c:58 apparently coming from add_n.as. If someone sees something wrong in the asm files, I have no experience with them. Ok, I think I got it. The asm code in the x86_64 dir and subdirs expects System V AMD64 ABI for argument passing (so first int or pointer in rdi and so on), but of course on win64 the convention is different so this is fundamentally incompatible. Now there is also a x86_64w dir for windows assembly but yasm does not like its syntax. I'll be looking into that. -- 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: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)
Le Fri, 21 Jun 2013 22:10:15 +, Jean-Pierre Flori a écrit : Now there is also a x86_64w dir for windows assembly but yasm does not like its syntax. I'll be looking into that. In fact its not yasm which is used I guess. We should indeed use the *w directories and basically do quite everything like for mingw64... -- 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: dosfilewarning
On 06/21/2013 02:11 PM, Larry Hall (Cygwin) wrote: On 6/21/2013 3:47 PM, Nellis, Kenneth wrote: From: Larry Hall (Cygwin) On 6/21/2013 2:38 PM, Nellis, Kenneth wrote: I have a BAT file that calls a bash script that generates the following (edited): cygwin warning: MS-DOS style path detected: XXX Preferred POSIX equivalent is: XXX CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames If I rerun the script, I don't get the message a second time, which makes debugging the problem a problem. How can I have this message show up on every invocation? I tried closing all Cygwin processes and tried setting CYGWIN=dosfilewarning, but it seemed to want something more. It's not designed to do that. It will show up once per Cygwin DLL session only. If you want to see something different, you'll need to patch the Cygwin source. Thanx, but isn't the end of a Cygwin DLL session when all processes that use the Cygwin DLL have terminated? Yes, that's correct. If you're not getting the message, you still have a process somewhere keeping the DLL in memory. Sounds like a job for Process Explorer... -- Andrew DeFaria http://defaria.com Question: Why do people always seem to find things in the last place that they look? Answer: Because most people stop looking after they find 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
Updated: TeX Live 2013
Cygwin's TeX Live packages have been updated to the latest upstream release, TeX Live 2013. TeX Live provides a comprehensive, cross-platform TeX system. It includes all the major TeX-related programs, macro packages, and fonts that are free software, including support for many languages around the world. For more information, see http://www.tug.org/texlive/ The TeX Live executables and supporting libraries are contained in the following Cygwin packages: *** texlive-20130529-1 *** libkpathsea6-20130529-1 *** libkpathsea-devel-20130529-1 libkpathsea is a TeX file and path search library. *** libptexenc1-20130529-1 *** libptexenc-devel-20130529-1 libptexenc is a TeX Unicode encoding library. *** asymptote-2.23-1 Asymptote is a powerful descriptive vector graphics language for technical drawing, inspired by MetaPost but with an improved C++-like syntax. Asymptote provides for figures the same high-quality typesetting that LaTeX does for scientific text. In addition, upstream TeX Live provides thousands of packages, grouped into collections. There is a Cygwin package for each upstream collection; there are also Cygwin packages containing documentation for some of the collections. *** texlive-collection-basic-20130529-1 *** texlive-collection-basic-doc-20130529-1 *** texlive-collection-bibtexextra-20130529-1 *** texlive-collection-bibtexextra-doc-20130529-1 *** texlive-collection-binextra-20130529-1 *** texlive-collection-binextra-doc-20130529-1 *** texlive-collection-context-20130529-1 *** texlive-collection-context-doc-20130529-1 *** texlive-collection-fontsextra-20130529-1 *** texlive-collection-fontsextra-doc-20130529-1 *** texlive-collection-fontsrecommended-20130529-1 *** texlive-collection-fontsrecommended-doc-20130529-1 *** texlive-collection-fontutils-20130529-1 *** texlive-collection-fontutils-doc-20130529-1 *** texlive-collection-formatsextra-20130529-1 *** texlive-collection-games-20130529-1 *** texlive-collection-genericextra-20130529-1 *** texlive-collection-genericextra-doc-20130529-1 *** texlive-collection-genericrecommended-20130529-1 *** texlive-collection-genericrecommended-doc-20130529-1 *** texlive-collection-htmlxml-20130529-1 *** texlive-collection-humanities-20130529-1 *** texlive-collection-humanities-doc-20130529-1 *** texlive-collection-langafrican-20130529-1 *** texlive-collection-langarabic-20130529-1 *** texlive-collection-langcjk-20130529-1 *** texlive-collection-langcyrillic-20130529-1 *** texlive-collection-langczechslovak-20130529-1 *** texlive-collection-langenglish-20130529-1 *** texlive-collection-langeuropean-20130529-1 *** texlive-collection-langfrench-20130529-1 *** texlive-collection-langgerman-20130529-1 *** texlive-collection-langgreek-20130529-1 *** texlive-collection-langindic-20130529-1 *** texlive-collection-langitalian-20130529-1 *** texlive-collection-langother-20130529-1 *** texlive-collection-langpolish-20130529-1 *** texlive-collection-langportuguese-20130529-1 *** texlive-collection-langspanish-20130529-1 *** texlive-collection-latex-20130529-1 *** texlive-collection-latex-doc-20130529-1 *** texlive-collection-latexextra-20130529-1 *** texlive-collection-latexextra-doc-20130529-1 *** texlive-collection-latexrecommended-20130529-1 *** texlive-collection-latexrecommended-doc-20130529-1 *** texlive-collection-luatex-20130529-1 *** texlive-collection-luatex-doc-20130529-1 *** texlive-collection-mathextra-20130529-1 *** texlive-collection-mathextra-doc-20130529-1 *** texlive-collection-metapost-20130529-1 *** texlive-collection-metapost-doc-20130529-1 *** texlive-collection-music-20130529-1 *** texlive-collection-music-doc-20130529-1 *** texlive-collection-omega-20130529-1 *** texlive-collection-pictures-20130529-1 *** texlive-collection-pictures-doc-20130529-1 *** texlive-collection-plainextra-20130529-1 *** texlive-collection-pstricks-20130529-1 *** texlive-collection-pstricks-doc-20130529-1 *** texlive-collection-publishers-20130529-1 *** texlive-collection-publishers-doc-20130529-1 *** texlive-collection-science-20130529-1 *** texlive-collection-science-doc-20130529-1 *** texlive-collection-xetex-20130529-1 *** texlive-collection-xetex-doc-20130529-1 Due to upstream reorganization of the collections, the following Cygwin packages are now obsolete: *** texlive-collection-documentation-arabic *** texlive-collection-documentation-base *** texlive-collection-documentation-bulgarian *** texlive-collection-documentation-chinese *** texlive-collection-documentation-czechslovak *** texlive-collection-documentation-dutch *** texlive-collection-documentation-english *** texlive-collection-documentation-finnish *** texlive-collection-documentation-french *** texlive-collection-documentation-german *** texlive-collection-documentation-italian *** texlive-collection-documentation-japanese *** texlive-collection-documentation-korean *** texlive-collection-documentation-mongolian *** texlive-collection-documentation-polish ***
Updated: emacs-auctex-11.87-2
The following package has been updated in the 32-bit Cygwin distribution, and a 64-bit update will follow shortly: *** emacs-auctex-11.87-2 AUCTeX is an extensible package for writing and formatting TeX files in GNU Emacs and XEmacs. It supports many different TeX macro packages, including AMS-TeX, LaTeX, Texinfo, ConTeXt, and DocTeX (dtx files). AUCTeX includes preview-latex which makes LaTeX a tightly integrated component of your editing workflow by visualizing selected source chunks (such as single formulas or graphics) directly as images in the source buffer. This is a rebuild of 11.87-1 to take into account a change in the TeX Live directory structure as of TeX Live 2013. Ken Brown Cygwin's emacs-auctex maintainer *** 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 the above URL.
