Re: sed strips CRs
On 02/13/2012 03:12 PM, Eric Blake wrote: But fixing this should be done upstream, and not in cygwin. As long as it's consistent with coreutils I'll certainly do the change. Paolo -- 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: sed strips CRs
On 02/13/2012 03:56 PM, Corinna Vinschen wrote: As long as it's consistent with coreutils I'll certainly do the change. Thanks! Would you mind to CC the cygwin list when the next upstream sed release is available? Sure, it should be real soon now since a new release has been long overdue. By the way, I'm still opening the script file with rt. I cannot think of any case when you would want to keep CRs there. Paolo -- 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: sed strips CRs
On 02/13/2012 04:43 PM, Earnie Boyd wrote: By the way, I'm still opening the script file with rt. I cannot think of any case when you would want to keep CRs there. The case of sed -e 's/something/nothing/g' myfile myfile2 as it works in Cygwin today would mean that in the case of the OP's drive settings myfile2 would not contain the CR. Treating CR as white space is the more proper thing to do, IMO. myfile is not the script file. The script file is the one that you pass to -f. Using rt was introduced in both cases for Cygwin, so regressions on other systems shouldn't be a problem. Paolo -- 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: sed strips CRs
On 02/13/2012 08:42 PM, John Cowan wrote: By the way, I'm still opening the script file with rt. I cannot think of any case when you would want to keep CRs there. You wouldn't, but the point is that rt isn't defined on Posix systems. If it happens to be the same as r, good, but that isn't guaranteed. Yes, I added a configure-time check too. I assume that if rt works, it can be used instead of r. And the only time rt does anything different from r on a Win32 system is when you have: 1) linked your executable with the system-supplied 'binmode.obj' file 2) set the global variable _fmode to O_BINARY 3) invoked _set_fmode(O_BINARY) all of which make r synonymous with rb. Programs which don't do any of these should use r rather than rt, as it is guaranteed to do the right thing for text on both Win32 and Posix systems. No, rt also does something different than r on Cygwin with binary-mounts. If you meant that rt should be restricted to cygwin, that's also fine by me but in general I prefer feature tests to OS tests. Paolo -- 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: Windows Server 2008 64-bit setup.exe/bash problem - Amazon Cloud
On 11/04/2010 05:24 AM, Michael March wrote: Anyone find a work-around for this issue yet? You could try patching Cygwin so that it doesn't muck with %fs and %gs. However, there is no workaround that those not require modifying the source. Paolo -- 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: Windows Server 2008 64-bit setup.exe/bash problem - Amazon Cloud
On 08/12/2010 01:45 PM, Corinna Vinschen wrote: http://dch.posterous.com/cygwin-dumps-core-on-windows-2008-r1sp2-on-ec So, this muse-ing of yours is not correct. To me this implies that the Amazon Cloud VMs have some BLODA installed by default. I'm not going to check this voluntarily. I suggest that somebody who wants to run Cygwin on such a machine investigates this further, or just asks Amazon to fix this and hope for the best. I'm not into Cygwin development enough to know what a BLODA is, but you may like to know the bug is in the Xen hypervisor used by Amazon. I don't know exactly what releases or Xen are affected, but for sure all RHEL5 (and CentOS 5) hypervisors are. The reason why you see it only on 64-bit Windows, is that the bug is about Xen mishandling the SWAPGS instruction which, well, is only present in 64-bit processors and in 64-bit mode. https://bugzilla.redhat.com/show_bug.cgi?id=613187 Paolo ps: KVM was also affected until last February. I haven't checked if RHEL/CentOS KVM has the bug, but I'll ask fellow developers around about it. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Combined tree fails to build -- libtool version mismatch?
On 01/09/2010 12:16 PM, Steven Bosscher wrote: This is with gcc SVN revision 155740, and src checked out yesterday (top of src/Changelog is the fix from Kaveh and FX for gcc PR42424). Not knowing a thing about libtool, I hope someone can tell me what's wrong here;-) src and gcc's libtool are out-of-sync (2.2.6 vs. 2.2.7a respectively). Since gcc's files dominate, you have ltmain.sh from GCC but bfd's configure uses src's libtool configuration. Binutils should adopt GCC's libtool.m4, ltmain.sh, lt~obsolete.m4, ltoptions.m4, ltsugar.m4, ltversion.m4 and src should rerun autoconf on all of its scripts (CCing gdb, newlib and cygwin mailing lists). DJ, can you add these files to the list that we get email about? Paolo -- 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: Combined tree fails to build -- libtool version mismatch?
On 01/09/2010 04:48 PM, H.J. Lu wrote: On Sat, Jan 9, 2010 at 6:26 AM, Paolo Bonzinibonz...@gnu.org wrote: On 01/09/2010 12:16 PM, Steven Bosscher wrote: This is with gcc SVN revision 155740, and src checked out yesterday (top of src/Changelog is the fix from Kaveh and FX for gcc PR42424). Not knowing a thing about libtool, I hope someone can tell me what's wrong here;-) src and gcc's libtool are out-of-sync (2.2.6 vs. 2.2.7a respectively). Since gcc's files dominate, you have ltmain.sh from GCC but bfd's configure uses src's libtool configuration. Binutils should adopt GCC's libtool.m4, ltmain.sh, lt~obsolete.m4, ltoptions.m4, ltsugar.m4, ltversion.m4 and src should rerun autoconf on all of its scripts (CCing gdb, newlib and cygwin mailing lists). DJ, can you add these files to the list that we get email about? Many files in the top directories between gcc and src are out of sync. You can do a diff on them to check it out. I know (as hinted above build maintainers get emails about out-of-sync email), but they do not break the build... Paolo -- 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: [PATCH] Build system cleanups 1/4
Andreas Schwab wrote: Paolo Bonzini [EMAIL PROTECTED] writes: This one removes the PICFLAG variables, which are never set, as well as the makefile fragments that used to set PICFLAG *at the time of Cygnus configure*. Committed to gcc and (shortly) to src. AFAICS this is used by libiberty when --enable-shared. Also, considering that libstdc++ compiles its own cp-demangle.c, and has always done so since it started using the libiberty demangler (r78553): cp-demangle.c: rm -f $@ $(LN_S) $(toplevel_srcdir)/libiberty/cp-demangle.c $@ cp-demangle.lo: cp-demangle.c $(LTCOMPILE) -DIN_GLIBCPP_V3 -Wno-error -c $ cp-demangle.o: cp-demangle.c $(C_COMPILE) -DIN_GLIBCPP_V3 -Wno-error -c $ I wonder why we still compile libiberty for the target at all. Neither it nor libobjc needs it, which would leave only all-target-fastjar (which is a bogus target anyway) and all-target-winsup. Cygwin people, does winsup actually need a target libiberty? If so, were you aware that the target libiberty is not compiled as PIC? Paolo -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [PATCH] Build system cleanups 1/4
Andreas Schwab wrote:
Paolo Bonzini [EMAIL PROTECTED] writes:
If so, were you aware that the target libiberty is not compiled as
PIC?
This is not true.
Here is the patch I'll test. I'll commit this as build system
maintainer; of course any other patch to convert libiberty to libtool
will have to be approved by the libiberty maintainers.
Paolo
2008-03-27 Paolo Bonzini [EMAIL PROTECTED]
* configure.ac (frags): Don't set, use frag instead.
(PICFLAG): Set here and substitute.
* Makefile.in: Substitute from autoconf.
* configure: Regenerate.
Index: configure.ac
===
--- configure.ac(revision 132479)
+++ configure.ac(working copy)
@@ -187,9 +187,7 @@ case ${host} in
esac
if [[ -n ${frag} ]]; then
- frags=${libiberty_topdir}/libiberty/config/$frag
-else
- frags=
+ frag=${libiberty_topdir}/libiberty/config/$frag
fi
# If they didn't specify --enable-shared, don't generate shared libs.
@@ -200,34 +198,34 @@ case ${enable_shared} in
*) shared=yes ;;
esac
if [[ ${shared} = yes ]]; then
- frag=
case ${host} in
*-*-cygwin*) ;;
-alpha*-*-linux*) frag=mh-elfalphapic ;;
-arm*-*-*) frag=mh-armpic ;;
-hppa*-*-*) frag=mh-papic ;;
+alpha*-*-linux*) PICFLAG=-fPIC ;;
+arm*-*-*) PICFLAG=-fPIC ;;
+hppa*-*-*) PICFLAG=-fPIC ;;
+i370-*-*) PICFLAG=-fPIC ;;
+ia64-*-*) PICFLAG=-fpic ;;
i[[34567]]86-*-* | x86_64-*-*)
- frag=mh-x86pic ;;
+ PICFLAG=-fpic ;;
+m68k-*-*) PICFLAG=-fpic ;;
powerpc*-*-aix*) ;;
-powerpc*-*-*) frag=mh-ppcpic ;;
-sparc*-*-*)frag=mh-sparcpic ;;
-s390*-*-*) frag=mh-s390pic ;;
-*) frag=mh-${host_cpu}pic ;;
+powerpc*-*-*) PICFLAG=-fPIC ;;
+sparc*-*-*)case ${CFLAGS} in
+ *-fpic* ) PICFLAG=-fpic ;;
+ * ) PICFLAG=-fPIC ;;
+ esac ;;
+s390*-*-*) PICFLAG=-fpic ;;
esac
- if [[ -n ${frag} ]]; then
-frags=${frags} ${libiberty_topdir}/config/${frag}
- fi
fi
+AC_SUBST(PICFLAG)
echo # Warning: this fragment is automatically generated temp-frag
-for frag in ${frags}; do
- if [[ -f ${frag} ]]; then
-echo Appending ${frag} to xhost-mkfrag
-echo # Following fragment copied from ${frag} temp-frag
-cat ${frag} temp-frag
- fi
-done
+if [[ -n ${frag} ]] [[ -f ${frag} ]]; then
+ echo Appending ${frag} to xhost-mkfrag
+ echo # Following fragment copied from ${frag} temp-frag
+ cat ${frag} temp-frag
+fi
# record if we want to build shared libs.
if [[ ${shared} = yes ]]; then
Index: Makefile.in
===
--- Makefile.in (revision 132479)
+++ Makefile.in (working copy)
@@ -60,7 +60,7 @@ RANLIB = @RANLIB@
MAKEINFO = @MAKEINFO@
PERL = @PERL@
-PICFLAG =
+PICFLAG = @PICFLAG@
MAKEOVERRIDES =
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [PATCH] Build system cleanups 1/4
FWIW, Cygwin's reliance on libiberty, so: Duh. Try again. Cygwin no longer relies on libiberty, so... You should have disabled it in Makefile.def, but no big deal -- I'll take care of it when I'll post a patch to remove target libiberty. Paolo -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Non-blocking I/O
How do I set-up non-blocking I/O with SIGIO or SIGURG notifications under Cygwin? The various Unices I know of use either F_SETFL+F_SETOWN (BSD-ish), I_SETSIG (STREAMS-ish), FIOASYNC+SIOCSPGRP, or FIOASYNC (but does this send signals?). Does any of these work with Cygwin or do I need another one? Also, what kinds of file handlers will it work on? Does it work on sockets and tty's at least? Thanks in advance, Paolo Bonzini -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
