Re: [ITP] mingw-w64 Second try
On 9/2/2010 01:35, Charles Wilson wrote:
On 9/1/2010 11:44 AM, JonY wrote:
On 9/1/2010 23:15, Charles Wilson wrote:
On 8/31/2010 11:20 PM, JonY wrote:
On 9/1/2010 10:28, Charles Wilson wrote:
On 8/31/2010 8:52 PM, JonY wrote:
Strange, I'll try a rebuild. The former should be the correct
location.
Errr...no. The *latter* is the correct location (at least, that's where
the sysroot'ed compiler will look for them).
the (buggy) cygport(1) puts them in
usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/
but we really want them to be in
usr/x86_64-w64-mingw32/sys-root/mingw/include/
which is what your cygport(5) does -- when you actually use it to
rebuild.
Right, the latter is correct. I'm misreading it.
Given the results of the thread re: Possible cygport bug with cross
compiles (e.g. there is no bug), it looks like:
1) rebuild the -header package so that the includes end up in the
correct location. The current cygport(5) for that package is fine
(e.g. (a) the extra rule in src_install is needed, and proper, and (b)
it does the right thing)
I am getting a permission denied error that I wasn't aware of before. I
have fixed the mv command, and tested with cygport compile install
list, cyport list does show the correct locations. Tarball reuploaded.
2) fix the setup.hints
Does setup.hint itself (for mingw64-x86_64-gcc-core) need an
external-source link to mingw64-x86_64-gcc?
Well, you'd actually need two setup.hints:
mingw64-x86_64-gcc/
mingw64-x86_64-gcc-4.5.1-1-src.tar.bz2
(1) setup.hint
mingw64-x86_64-gcc-core/
mingw64-x86_64-gcc-core-4.5.1-1.tar.bz2
(2)setup.hint
mingw64-x86_64-gcc-fortran/
mingw64-x86_64-gcc-fortran-4.5.1-1.tar.bz2
setup.hint
mingw64-x86_64-gcc-g++/
mingw64-x86_64-gcc-g++-4.5.1-1.tar.bz2
setup.hint
mingw64-x86_64-gcc-ada/
mingw64-x86_64-gcc-ada-4.5.1-1.tar.bz2
setup.hint
The one marked (1) would not need any requires: or external-source:
marking. The one marked (2) would only need an external-source:
marking. The others would all need both an external-source AND a
requires: mingw64-x86_64-gcc-core marking.
I think this also means you need to modify your cygport(5) from
PKG_NAMES=${PN}-core ${PN}-ada ${PN}-g++ ${PN}-fortran ${PN}-objc
PKG_HINTS=setup ada g++ gfortran objc
to
PKG_NAMES=${PN} ${PN}-core ${PN}-ada ${PN}-g++ ${PN}-fortran ${PN}-objc
PKG_HINTS=setup core ada g++ gfortran objc
where the new core.hint file has the contents of the existing setup.hint
file (as updated above), and the new setup.hint file just says
category: Devel
sdesc: GCC for MinGW-w64 Win64 toolchain (source)
I *think* this means that you'll then get an EMPTY
mingw64-x86_64-gcc-4.5.1-1.tar.bz2
package, but you won't want to include that in the upload set.
--
Chuck
Hi,
sorry for the week long delay, the files have been sitting there for
quite some time (some were corrupt uploads, but I fixed them).
I kind of forgot about this thread.
mingw64-x86_64-headers
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1-src.tar.bz2/download
category: Devel
requires:
sdesc: Mingw-w64 headers for Win64 target.
ldesc: Mingw-w64 headers for Win64 target development.
This package is for the mingw-w64 toolchain that targets 64bit.
mingw64-x86_64-runtime
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1-src.tar.bz2/download
category: Devel
requires: mingw64-x86_64-headers
sdesc: CRT libraries for Win64 target.
ldesc: Mingw-w64 CRT libraries for Win64 target development.
mingw64-x86_64-binutils
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1-src.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1.tar.bz2/download
category: Devel
requires: libgcc1 libintl8 zlib0
sdesc: Binutils for MinGW-w64 Win64 toolchain
ldesc: Mingw-w64 Cross binutils for Win64 target.
mingw64-x86_64-pthreads
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1-src.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1.tar.bz2/download
category: Devel
requires: mingw64-x86_64-runtime
sdesc: libpthread for MinGW-w64 Win64 toolchain
mingw64-x86_64-gcc
Re: [ITA] ocaml 3.12.0
On 2010-09-08, at 11:31, Corinna Vinschen wrote: Cool, thanks. Your packaging looks good, so this package is ok for upload. I was just wondering if you would like me to upload the package as is for now, or if I should wait for the FlexDLL-enabled version? I think you should upload this version for the moment because I have two potential problems with Yaakov's FlexDLL package that I need to investigate: 1. It's based on an old version of FlexDLL, and IIRC OCaml needs some of the recent changes. 2. It mentions gcc4 in the dependencies, but OCaml is compiled with gcc3. I need to determine whether OCaml now works with gcc4 and if not, whether it needs a FlexDLL based on gcc3. -- Damien
Re: [ITA] ocaml 3.12.0
On Sep 9 14:51, Damien Doligez wrote: On 2010-09-08, at 11:31, Corinna Vinschen wrote: Cool, thanks. Your packaging looks good, so this package is ok for upload. I was just wondering if you would like me to upload the package as is for now, or if I should wait for the FlexDLL-enabled version? I think you should upload this version for the moment because I have two potential problems with Yaakov's FlexDLL package that I need to investigate: 1. It's based on an old version of FlexDLL, and IIRC OCaml needs some of the recent changes. 2. It mentions gcc4 in the dependencies, but OCaml is compiled with gcc3. I need to determine whether OCaml now works with gcc4 and if not, whether it needs a FlexDLL based on gcc3. Uploaded. Please announce on the cygwin-announce list according to http://cygwin.com/setup.html#submitting Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] ocaml 3.12.0
Cool, thanks. Your packaging looks good, so this package is ok for upload. I was just wondering if you would like me to upload the package as is for now, or if I should wait for the FlexDLL-enabled version? I think you should upload this version for the moment because I have two potential problems with Yaakov's FlexDLL package that I need to investigate: 1. It's based on an old version of FlexDLL, and IIRC OCaml needs some of the recent changes. 2. It mentions gcc4 in the dependencies, but OCaml is compiled with gcc3. I need to determine whether OCaml now works with gcc4 and if not, whether it needs a FlexDLL based on gcc3. Uploaded. Please announce on the cygwin-announce list according to http://cygwin.com/setup.html#submitting Auto gold star awarded: http://cygwin.com/goldstars/#DD. And a thanks from me - the OCaml package was way out of date, but I tried once to build it for Cygwin and couldn't make it work. Andrew.
Re: [ITP] mingw-w64 Second try
On 9/9/2010 6:10 AM, JonY wrote: OK, we're amost there. binutils and runtime are GTG. gcc, headers, and pthreads are really close. Everything rebuilds from source fine, and the uploaded packages actually match the rebuilt versions (or vice versa). So that's all good. Plus, I was able to build a sample project using these tools (mingw64-x86_86-xz-4.999.9beta-1) with no problems. However, when I tried to install these packages via setup.exe, I ran into problems with the setup.hints. In the first case, genini (*) did not like some of them -- complained about missing fields -- AND, genini couldn't actually parse the package name of mingw64-x86_64-headers. (*) genini is a user script that can be used to generate a setup.ini for a cygwin package repository. On the sourceware server, a different tool -- upset -- is used. Now, maybe -- MAYBE -- upset is smarter than genini, and won't complain. However, it's usually better to make sure that genini is happy; then you are much more likely to NOT cause the upset script on sourceware to send cgf a bunch of nasty warnings via email. That makes cgf angry. You wouldn't like cgf when he's angry. Here are the bad setup.hints: mingw64-x86_64-gcc-core/setup.hint mingw64-x86_64-gcc-fortran/setup.hint mingw64-x86_64-gcc-g++/setup.hint mingw64-x86_64-gcc-objc/setup.hint mingw64-x86_64-gcc-ada/setup.hint mingw64-x86_64-gcc/setup.hint mingw64-x86_64-pthreads/setup.hint Plus there are bigger changes required to the -headers package. We'll talk about that last. In each of the following cases, the setup.hint was missing an ldesc: field. This annoys genini, but upset might be ok with it. mingw64-x86_64-gcc-core/setup.hint mingw64-x86_64-gcc-fortran/setup.hint mingw64-x86_64-gcc-g++/setup.hint mingw64-x86_64-gcc-objc/setup.hint mingw64-x86_64-gcc-ada/setup.hint mingw64-x86_64-pthreads/setup.hint The top gcc setup.hint was missing both an ldesc: and a requires: field (requires was empty, of course). mingw64-x86_64-gcc/setup.hint I've attached the updated setup.hints. Here's what I would suggest we do, for gcc: DON'T bother to rebuild it. Just save these setup.hints, and make sure to fold them in to your NEXT official release's CYGWIN-PATCHES/ directory. When I upload this first version of mingw64-gcc, I'll be sure to use these new hints instead of the ones you pasted inline. Let's call gcc GTG with alternate hint files. For pthreads, I'd suggest you actually rebuild and re-upload it with the attached hint (it doesn't take nearly as long...) but if you want to treat it just like gcc, above, that's fine. Let me know -- we'll call pthreads GTG with alternate hint files, or as rebuilt. Now...headers. Here's the problem: genini requires that the version part of the package name begin with a numeral. I think this is true of upset as well, but I'm not sure (but again, better safe than sorry. You wouldn't like cgf when he's angry). Also, genini and cygport do NOT like having a hyphen in the version number (but upset is ok with it). So, just liike your earlier gendef and libmangle packages -- where we discovered that they had to be named, e.g. gendef-1.0-svn2931-1.tar.bz2 gendef-1.0-svn2931-1-src.tar.bz2 libmangle-1.0-svn2930-1.tar.bz2 libmangle-1.0-svn2930-1-src.tar.bz2 ...the current name of the headers package is no good: mingw64-x86_64-headers-svn3433-1.tar.bz2 mingw64-x86_64-headers-svn3433-1-src.tar.bz2 ^^^ must start with numeral Now, following the gendef/libmangle pattern, I tried mingw64-x86_64-headers-1.0b-svn3433-1.tar.bz2 where 1.0b came from the configure.ac file, but I discovered that genini doesn't like the hyphen between 1.0b and svn3433 -- when you do that, genini (and cygport-0.10.0, for that matter) thinks the package name is mingw64-x86_64-headers-1.0b, and the version is svn3433, and we're right back where we started! Now, upset doesn't care about this -- obviously -- since gendef and libmangle, which use '-' between 1.0 and svn -- have not yet caused cgf to become angry. But...let's also try to keep genini happy. And, it may be a regression in cygport -- I'm not sure (obv. you were able to build gendef and libmangle with an older version of cygport, even with a hyphen in the middle of the version string), but we have to keep cygport happy, too. So, I rebuilt as: mingw64-x86_64-headers-1.0b_svn3433-1.tar.bz2 mingw64-x86_64-headers-1.0b_svn3433-1-src.tar.bz2 And that worked fine (genini was happy, cygport was happy, setup.exe was happy -- and presumably upset will be happy == no angry cgf). I've uploaded the modified version here: http://cygwin.cwilson.fastmail.fm/mingw64-x86_64-headers-1.0b_svn3433-1-src.tar.bz2
Re: [ITP] mingw-w64 Second try
On 9/10/2010 07:09, Charles Wilson wrote: On 9/9/2010 6:10 AM, JonY wrote: OK, we're amost there. binutils and runtime are GTG. gcc, headers, and pthreads are really close. Everything rebuilds from source fine, and the uploaded packages actually match the rebuilt versions (or vice versa). So that's all good. Plus, I was able to build a sample project using these tools (mingw64-x86_86-xz-4.999.9beta-1) with no problems. However, when I tried to install these packages via setup.exe, I ran into problems with the setup.hints. In the first case, genini (*) did not like some of them -- complained about missing fields -- AND, genini couldn't actually parse the package name of mingw64-x86_64-headers. (*) genini is a user script that can be used to generate a setup.ini for a cygwin package repository. On the sourceware server, a different tool -- upset -- is used. Now, maybe -- MAYBE -- upset is smarter than genini, and won't complain. However, it's usually better to make sure that genini is happy; then you are much more likely to NOT cause the upset script on sourceware to send cgf a bunch of nasty warnings via email. That makes cgf angry. You wouldn't like cgf when he's angry. Here are the bad setup.hints: mingw64-x86_64-gcc-core/setup.hint mingw64-x86_64-gcc-fortran/setup.hint mingw64-x86_64-gcc-g++/setup.hint mingw64-x86_64-gcc-objc/setup.hint mingw64-x86_64-gcc-ada/setup.hint mingw64-x86_64-gcc/setup.hint mingw64-x86_64-pthreads/setup.hint Plus there are bigger changes required to the -headers package. We'll talk about that last. In each of the following cases, the setup.hint was missing an ldesc: field. This annoys genini, but upset might be ok with it. mingw64-x86_64-gcc-core/setup.hint mingw64-x86_64-gcc-fortran/setup.hint mingw64-x86_64-gcc-g++/setup.hint mingw64-x86_64-gcc-objc/setup.hint mingw64-x86_64-gcc-ada/setup.hint mingw64-x86_64-pthreads/setup.hint The top gcc setup.hint was missing both an ldesc: and a requires: field (requires was empty, of course). mingw64-x86_64-gcc/setup.hint I've attached the updated setup.hints. Here's what I would suggest we do, for gcc: DON'T bother to rebuild it. Just save these setup.hints, and make sure to fold them in to your NEXT official release's CYGWIN-PATCHES/ directory. When I upload this first version of mingw64-gcc, I'll be sure to use these new hints instead of the ones you pasted inline. Let's call gcc GTG with alternate hint files. For pthreads, I'd suggest you actually rebuild and re-upload it with the attached hint (it doesn't take nearly as long...) but if you want to treat it just like gcc, above, that's fine. Let me know -- we'll call pthreads GTG with alternate hint files, or as rebuilt. Now...headers. Here's the problem: genini requires that the version part of the package name begin with a numeral. I think this is true of upset as well, but I'm not sure (but again, better safe than sorry. You wouldn't like cgf when he's angry). Also, genini and cygport do NOT like having a hyphen in the version number (but upset is ok with it). So, just liike your earlier gendef and libmangle packages -- where we discovered that they had to be named, e.g. gendef-1.0-svn2931-1.tar.bz2 gendef-1.0-svn2931-1-src.tar.bz2 libmangle-1.0-svn2930-1.tar.bz2 libmangle-1.0-svn2930-1-src.tar.bz2 ...the current name of the headers package is no good: mingw64-x86_64-headers-svn3433-1.tar.bz2 mingw64-x86_64-headers-svn3433-1-src.tar.bz2 ^^^ must start with numeral Now, following the gendef/libmangle pattern, I tried mingw64-x86_64-headers-1.0b-svn3433-1.tar.bz2 where 1.0b came from the configure.ac file, but I discovered that genini doesn't like the hyphen between 1.0b and svn3433 -- when you do that, genini (and cygport-0.10.0, for that matter) thinks the package name is mingw64-x86_64-headers-1.0b, and the version is svn3433, and we're right back where we started! Now, upset doesn't care about this -- obviously -- since gendef and libmangle, which use '-' between 1.0 and svn -- have not yet caused cgf to become angry. But...let's also try to keep genini happy. And, it may be a regression in cygport -- I'm not sure (obv. you were able to build gendef and libmangle with an older version of cygport, even with a hyphen in the middle of the version string), but we have to keep cygport happy, too. So, I rebuilt as: mingw64-x86_64-headers-1.0b_svn3433-1.tar.bz2 mingw64-x86_64-headers-1.0b_svn3433-1-src.tar.bz2 OK, this is fine. And that worked fine (genini was happy, cygport was happy, setup.exe was happy -- and presumably upset will be happy == no angry cgf). I've uploaded the modified version here:
odd case of Can't connect to display
I'm doing ssh u...@host -X to get to my linux desktop machine from my laptop running Cygwin under Windows Vista. I've been doing this for several months, and I know the basic setup is fine, because I can run any X program without problems. However, just today, after being logged in for a while, even if I have another X program running (in background - so I'm using the same xterm I used to launch to other X program) I get Error: Can't open display: localhost:10.0 (Yes, DISPLAY is correctly set to localhost:10.0.) If I log out of the ssh session and start a new one, X programs work again, but after a few minutes, it goes back to the error. I am assuming that if the network (wireless from laptop to router, wired from router to switch to desktop) were flaky, the ssh connection would probably be affected, and the other running X program (sometimes emacs, sometimes balsa email client) would also get dropped, but they both continue running with no apparent problems. I'd appreciate any ideas of how to troubleshoot what might be causing this, since it is certainly annoying. I've done a fair amount of searching, but everything I've found so far is a problem with getting either X running at all, or getting ssh to handle X, neither of which is my problem. Thanks for any hints or suggestions. Jack -- 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: Mounting /tmp at TMP or TEMP as a last resort
On Sep 8 15:59, Earl Chew wrote:
On 08/09/2010 3:41 PM, Christopher Faylor wrote:
Thanks for the patch but I don't think this is generally useful. If you
need to mount /tmp somewhere else then it should be fairly trivial to
automatically update /etc/fstab. Corinna may disagree, but I think we
should keep the parsing of /etc/fstab as lean as possible; particularly
when there are alternatives to modifying Cygwin to achieve the desired
result.
Yes, I understand what you're saying.
In our situation, we prefer an out-of-the-box deployment. (We're
essentially trying to get to a untar this and use it state).
That said, I don't think it's possible for /etc/fstab to inspect
environment variables, so manipulation of /etc/fstab would
require the assistance of some other script to edit /etc/fstab on
the fly --- and even then it would be difficult to track changes
to the environment variables.
Apart from changing /etc/fstab or /etc/fstab.d/$USER by some installer
script, why not just add a one-liner profile script along the lines of
/etc/profile.d/tmp-mnt.sh:
mount -f `cygpath -m ${TEMP}` /tmp
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: Mounting /tmp at TMP or TEMP as a last resort
On 08/09/2010 23:41, Christopher Faylor wrote: Corinna may disagree, Needless to say, I'm not Corinna! but I think we should keep the parsing of /etc/fstab as lean as possible; I don't understand why. How many times per second does /etc/fstab get parsed? cheers, DaveK
Re: Mounting /tmp at TMP or TEMP as a last resort
On 09/09/2010 21:53, Earl Chew wrote: On 09/09/2010 1:03 PM, Dave Korn wrote: but I think we should keep the parsing of /etc/fstab as lean as possible; I don't understand why. How many times per second does /etc/fstab get parsed? I interpreted cgf's comment as not wishing to add to the amount of coupling with /etc/fstab. /etc/fstab is already parsed for /usr/bin and /usr/lib, so in my mind the additional query for /tmp doesn't seem to add significantly. Right, in case I wasn't clear, my question was really shorthand for it can't just be a matter of cycle count, so what is the exact problem? cheers, DaveK
Re: Mounting /tmp at TMP or TEMP as a last resort
On 09/09/2010 2:16 PM, Pierre A. Humblet wrote: So, for example, if the user logs in interactively while a cron job (or another service) is running, /tmp may be mapped differently than if no cron job is running, because TMP may be defined differently in the service environment. That is not desirable. I believe that information is kept in Cygwin shared memory regions on a per-user basis. I imagine there would other other unwanted side-effects if this were not the case. Assuming this to be the case, services running as SYSTEM or another user cannot influence the mount decision of /tmp for the current user. So the only consideration is if there is a service running alongside the currently logged in user. 1. /tmp specified in /etc/fstab 2. /tmp present on filesystem. No difference in behaviour with proposed patch in these cases. 3. /tmp not present in either /etc/fstab or filesystem, and no TMP or TEMP No /tmp is available. Programs will have manage without it. 4. /tmp not present in either /etc/fstab or filesystem, but either TMP or TEMP present Without the patch, this is the same as case (3). Settings for TMP or TEMP are injected into the Win32 process via the User Environment Variables: http://msdn.microsoft.com/en-us/library/bb776899%28VS.85%29.aspx Thus the service-running-as-user and the logged in user would inherit the same values. I can see one way to subvert (4). It is possible for a service to run as a plain Win32 process, modify TMP (or TEMP), then launch the first Cygwin process which would then mount /tmp at the modified location. A similar scenario could occur the other way around too. I think these scenarios are not likely to occur often. Usually TMP and TEMP are set as User Environment Variables and don't get changed. If it's important to lock down the location of /tmp, then either create /tmp in the filesystem or create an entry in /etc/fstab. This is what you're required to do in the current implementation anyway because without it, no /tmp is made available (and bash will complain, etc). Earl
AW: [bulk] - Re: GSMlib
Hi Larry, Von: Larry Hall (Cygwin) Gesendet: Mittwoch, 8. September 2010 17:33 Betreff: [bulk] - Re: GSMlib On 9/8/2010 10:00 AM, DEWI - N. Zacharias wrote: Hi all, has someone successfully compiled and installed gsmlib 1.10 (http://www.pxh.de/fs/gsmlib/index.html) ? Norbert, please don't commandeer another thread for your own purposes. If you have something that isn't related to an existing thread, just send a new email message to the list. Replying to an existing message and changing the subject does not create a new thread Opps, I'm very sorry !! Will do so in future! By the way the spam protection blocks also mails containing the list address. Is this intended ?? Norbert -- Dipl. Phys. Norbert Zacharias Wind Measurements Power Curve Measurements DEWI GmbH Ebertstrasse 96 26382 Wilhelmshaven Germany Tel.: +49 4421 4808 876 Fax:+49 4421 4808 843 Email: n.zachar...@dewi.de Home: http://www.dewi.de DEWI GmbH - Deutsches Windenergie-Institut, Wilhelmshaven Commercial Register No.: Amtsgericht Oldenburg, HRB 130241 Managing Director: Jens Peter Molly Chairman of the supervisory board: Ministerialrat Dr. Niels Kämpny P Please consider the environment before printing this 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
change character set in API delivery
Hello, I run a Perlscript with a Database-Interface in cygwin. The database is web-based. The character set of my values is latin1, but when I browse the Database the values are shown in UTF-8. Does cygwin generally deliver values in UTF-8? Can I change it somehow? The values should be encoded in latin1. To make it clearer: I don't want to change the character set in the console, but in the work process of cygwin. I hope, I could explain my problem and I'm curios to get tips. Best regards, Judith Metzner -- 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: cross compile windows = Linux
On Wed, Sep 8, 2010 at 13:37, Bryan bra...@gmail.com wrote: So, I've been searching for a way to build linux binaries, and then package them using the rpmbuild command. I've not been able to find a cross compiler other than the one here: http://metamod-p.sourceforge.net/cross-compiling.on.windows.for.linux.html I had kind of expected there to be one in cygwin that I could install. But since there isn't, has anyone used the one above? Does it work? I'm making a special build of OpenSSH/OpenSSL-fips, and having a linux build would be great. I found the documentation on the cygwin... you'll have to forgive me, I'm not used to an open source project actually having useful information in their FAQ. -- 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: AW: [bulk] - Re: GSMlib
On 9/9/2010 3:50 AM, DEWI - N. Zacharias wrote: snip By the way the spam protection blocks also mails containing the list address. Is this intended ?? You mean in the body of the message? Yes, that's intended. Goes to not feeding the spammers and all that. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ 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: Oddities with file deletion on CIFS drive
--On Wednesday, September 08, 2010 10:50 PM -0400 Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote: Yeah, there's been plenty of these network appliances that really foul up their implementation of permissions. MVFS and NetApp are a couple in the past that have had problems. If you have the csih package installed, run /usr/lib/csih/getVolInfo drive letter:/ and send the results here. And then wait for the groans. ;-) Ok, here is the results. ;) $ /usr/lib/csih/getVolInfo /cygdrive/z Device Type: 7 Characteristics: 10 Volume Name: 121 Serial Number : 27 Max Filenamelength : 255 Filesystemname : NTFS Flags : 4007e FILE_CASE_SENSITIVE_SEARCH : FALSE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : TRUE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : TRUE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration -- 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: RSH hangs indefinitely
On 9/9/2010 12:37 AM, 7force wrote: Here is the situation I have and the things I did to get it:- 1. Initiate an RCP connection from Server A (Windows Vista) via Cygwin to Server B (Linux). You haven't specified which computer is running the rsh server, and which computer is running the rcp client. But, it doesn't really matter...you'd get the same behavior either way. 2. Disconnect the RJ45 cable to simulate a server down event (@ Server B). This is not a server down event. This is a network disconnection event -- they are different. If the server is down, there are several possibilities: (a) the computer is reachable via the network, but no process (rshd) is listening on port 514/tcp (or the firewall is blocking connection attempts with reject) (b) the computer isn't on the network at all (or the firewall is blocking connections with drop). At best, you're simulating (b), but not (a). This is where I notice two possibilities. Scenario #1 RJ45 unplug while the RCP/RSH is synchronising (used netstat). In this case, the session at Server A will close nicely. Yep. This is standard protection from a SYN FLOOD attack, built in to most modern TCP (kernel) stacks. Without this, a bad guy could send thousands of SYN packets to the server. The server responds to each with a SYN/ACK, and the (half-open) connection waits in the SYN_RCVD state...for an ACK that never arrives. Without some sort of timeout, this could exhaust the server's resources, at zero cost to the attacker. Bad news. Scenario #2 RJ45 unplug after the RCP/RSH hits ESTABLISHED (used netstat). This is when the session at Server A will remain opened indefinitely. I have waited more than two hours for it to close but it's not happening yet (or ever). So, let me make sure I understand: rcp/rsh works for you. However, if you physically disrupt the connection after it is ESTABLISHED (e.g. after the SYN, SYN/ACK, ACK sequence is complete), the server continues to listen on the socket rather than closing it. That's...pretty much the design behavior of a TCP connection, on any platform (unless your higher level protocol implements its own timeout semantics and keep-alive behavior; rcp/rsh does not). Once a connection is established, neither side will shut it down until a FIN or RST packet (or a FIN/ACK packet) is sent from one side to the other. If you physically disrupt the connection, then that packet can't be sent...and the connection will not be closed. For very simple protocols like rcp/rsh, this is what you want: if you've rsh'ed to another computer, the terminal might just sit there with no input for days -- and no data being transmitted between the two computers over the connection. You wouldn't want the server to hang up on you. Smarter protocols, like telnet, implement their own timeout semantics, and the clients continually send background keep alive packets. If the server doesn't get those packets regularly, it assumes the connection has been disrupted, and closes the socket. But that has nothing to do with the low-level TCP protocol (e.g. ESTABLISHED, etc). Question:- 1. Is this a Windows issue or a Cygwin issue? It's a TCP/IP issue. I *think* you'll see the same behavior between two linux boxes. 2. How do I remedy this issue? You don't. Stop unplugging network cables. :-) Oh, and use a smarter -- and more secure -- protocol. I don't think you will encounter this behavior with scp/ssh. -- 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: Windows-style pathname does not work as command - why?
on Thu, 02 Sep 2010 12:13:12 -0600, Eric Blake 4c7fe938.6060...@redhat.com
attacked their terminal with
[stuff relating to Win32 paths]
Here's a sed script I use to get around that... Put this in your script (or
~/.bashrc) and enjoy
function wintocyg {
if [ x${$1} == x ]; then
return 1
fi
echo $1 | sed 's/\([a-zA-Z]\)\:/\/cygdrive\/\1/g;s:\\:/:g'
}
This:
- checks that there is an argument.
- Converts that argument using a sed script that looks for a drive letter, :\
and converts that into a Cygdrive path. This works for root level stuff
(d:\) and for deeply nested things (like d:\ping\me_with\a hundred boxes
of\liquor).
Pretty Simple Stuff, but its a pain. I've used this for a while now.
I know its a hack but its /works/. You could easily make it escape ' '* but I'm
assuming you're calling it using `wintocyg mypath` ( /always/ escape your
paths )
* that would be done by taking and actually wrapping the entire function around
an echo statement like « echo \`echo $1 ...`\ »
--
Morgan Gangwere
Key ID A8B6F243, available from MIT.
BOFH excuse #441:
Hash table has woodworm
signature.asc
Description: PGP signature
Re: change character set in API delivery
judithmetz...@arcor.de schrieb: I run a Perlscript with a Database-Interface in cygwin. The database is web-based. The character set of my values is latin1, but when I browse the Database the values are shown in UTF-8. Does cygwin generally deliver values in UTF-8? Can I change it somehow? The values should be encoded in latin1. To make it clearer: I don't want to change the character set in the console, but in the work process of cygwin. I hope, I could explain my problem and I'm curios to get tips. perl or cygwin per se do no encoding with your database data. This is a matter of the perl module and database client and server you are using. So you are better asking at perlmonks -- Reini Urban -- 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-style pathname does not work as command - why?
On 9/9/2010 11:20 AM, Morgan Gangwere wrote:
on Thu, 02 Sep 2010 12:13:12 -0600, Eric Blake 4c7fe938.6060...@redhat.com
attacked their terminal with
[stuff relating to Win32 paths]
Here's a sed script I use to get around that... Put this in your script (or
~/.bashrc) and enjoy
function wintocyg {
if [ x${$1} == x ]; then
return 1
fi
echo $1 | sed 's/\([a-zA-Z]\)\:/\/cygdrive\/\1/g;s:\\:/:g'
}
This:
- checks that there is an argument.
- Converts that argument using a sed script that looks for a drive letter, :\
and converts that into a Cygdrive path. This works for root level stuff
(d:\) and for deeply nested things (like d:\ping\me_with\a hundred boxes
of\liquor).
Pretty Simple Stuff, but its a pain. I've used this for a while now.
I know its a hack but its /works/. You could easily make it escape ' '* but
I'm
assuming you're calling it using `wintocyg mypath` ( /always/ escape your
paths )
Actually, this function only works if the user has the default cygdrive
prefix. This can and often *is* changed, however. Fortunately, the
Cygwin developers have had your back on this for a very long time. Use
the cygpath program to convert all your paths. It safely handles
conversions both to and from POSIX for both absolute and relative paths,
can convert to short form DOS paths (e.g C:\Progra~1\...), supports
paths with arbitrary whitespace, can provide many well known paths such
as the user's Desktop directory, can be run by Windows-native programs,
and more.
-Jeremy
--
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
Installing unix modules package on cygwin
I have installed the unix module package version 3.2.7 for Cygwin 1.7.1. However when I type module list I get the following error message. $ module list init.c(640):WARN:165: Cannot set TCL variable '!::' No Modulefiles Currently Loaded. My issue is the variable '!::' What is it and where is it set? This variable can not be processed TCL. When I type env, I that special variable listed . . . hlainc=D:\hla\include SVN_EDITOR=vim USER=8nt VBOX_INSTALL_PATH=C:\Program Files\Oracle\VirtualBox\ !::=::\ TEMP=/cygdrive/c/Users/8nt/AppData/Local/Temp DEFLOGDIR=C:\ProgramData\McAfee\DesktopProtection . . . -- 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: Installing unix modules package on cygwin
My issue is the variable '!::' What is it and where is it set? This variable can not be processed TCL. When I type env, I that special variable listed At least I can confirm, to have the same variable in my environment. So far nothing wrong. Al -- 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: cross compile windows = Linux
On Thu, Sep 09, 2010 at 07:11:38AM -0500, Bryan wrote: On Wed, Sep 8, 2010 at 13:37, Bryan bra...@gmail.com wrote: So, I've been searching for a way to build linux binaries, and then package them using the rpmbuild command. I've not been able to find a cross compiler other than the one here: http://metamod-p.sourceforge.net/cross-compiling.on.windows.for.linux.html I had kind of expected there to be one in cygwin that I could install. ??But since there isn't, has anyone used the one above? ??Does it work? I'm making a special build of OpenSSH/OpenSSL-fips, and having a linux build would be great. I found the documentation on the cygwin... you'll have to forgive me, I'm not used to an open source project actually having useful information in their FAQ. You must not be frequenting the right open source projects. Many of them have very useful FAQs. 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: Windows-style pathname does not work as command - why?
on Thu, 09 Sep 2010 13:50:08 -0500, Jeremy Bopp 4c892c60.6040...@bopp.net attacked their terminal with +Actually, this function only works if the user has the default cygdrive +prefix. This can and often *is* changed, however. Fortunately, the +Cygwin developers have had your back on this for a very long time. Use +the cygpath program to convert all your paths. It safely handles +conversions both to and from POSIX for both absolute and relative paths, +can convert to short form DOS paths (e.g C:\Progra~1\...), supports +paths with arbitrary whitespace, can provide many well known paths such +as the user's Desktop directory, can be run by Windows-native programs, +and more. how do you change the default cygdrive path? I figured it was a set-in-stone kindof thing. -- Morgan Gangwere Key ID A8B6F243, available from MIT. BOFH excuse #81: Please excuse me, I have to circuit an AC line through my head to get this database working. signature.asc Description: PGP signature
Re: Windows-style pathname does not work as command - why?
On 9/9/2010 2:27 PM, Morgan Gangwere wrote: on Thu, 09 Sep 2010 13:50:08 -0500, Jeremy Bopp 4c892c60.6040...@bopp.net attacked their terminal with +Actually, this function only works if the user has the default cygdrive +prefix. This can and often *is* changed, however. Fortunately, the +Cygwin developers have had your back on this for a very long time. Use +the cygpath program to convert all your paths. It safely handles +conversions both to and from POSIX for both absolute and relative paths, +can convert to short form DOS paths (e.g C:\Progra~1\...), supports +paths with arbitrary whitespace, can provide many well known paths such +as the user's Desktop directory, can be run by Windows-native programs, +and more. how do you change the default cygdrive path? I figured it was a set-in-stone kindof thing. Add something like the following line to your /etc/fstab file and restart all your Cygwin processes: none / cygdrive binary,posix=0,noacl,user 0 0 This example will set your cygdrive prefix to simply be /, so you can access the C: drive via /c/whatever. More details are available in the user guide: http://cygwin.com/cygwin-ug-net/using.html#mount-table -Jeremy -- 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: ocaml-3.12.0-2
Version 3.12.0-2 of ocaml has been uploaded. OCaml is a functional programming language with imperative features, objects, and modules. This update (from 3.08.1) represents 6 years of OCaml development, so I'm not going to list all the changes. From now on, I will keep this package up to date with upstream releases. Dynamic linking support is not included yet, but will soon be. -- Damien Doligez, the new ocaml maintainer for cygwin *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Windows-style pathname does not work as command - why?
Larry Hall (Cygwin) wrote: On 9/8/2010 1:24 PM, Andy Koppe wrote: On 8 September 2010 17:35, Larry Hall (Cygwin) wrote: Isn't the whole reason for Cygwin actually to enable doing Unixy things in Windows (that is, providing Windows/Unix interoperablity? No, that's not a key goal. From the Cygwin main web page: Cygwin is a Linux-like environment for Windows Well, I (and my employer) would not be using Cygwin if it wasn't for the Windows integration, in particular the ability to plug POSIX and Windows programs together. If I just wanted to run Linux software on Windows, I'd use a virtual machine or coLinux. While Cygwin's lower resource usage is nice to have, that's easily outweighed by the inevitable compatibility and performance drawbacks that come with building on top of Win32. There are allot of different reasons people choose to use Cygwin. However, as a product (and I'm not suggesting anything commercially motivated here when using that term), it has some key design goals. They are the ones I quoted from the main page on the Cygwin web site. There are others that are secondary goals. Interoperability is certainly one. But Windows/DOS-style path support is not the whole reason for Cygwin as the OP suggested. I did NOT say that Windows/DOS-style path support was the whole reason for Cygwin. Pay attention to your quoting/paraphrasing. It is, rather, a case where the primary goals of Linux compatibility require a choice to be made and in this case the choice is POSIX-style paths trump Windows/DOS-style paths anywhere the support cost is too high for the latter. The general argument of Windows interoperability in Cygwin has been discussed on the list in the past. I'm not trying to re-open those threads or start a new flame war on the subject. I'm only trying to correct a misconception of the OP with regards to accepted path syntax. I hope that's clear now. Not yet. Cygpath certainly supports Windows-style paths. Are you claiming that places like that are the only place that it is accepted to use Windows-styles paths (that is, if something like ls 'C:\x\y' quit working, it likely wouldn't be fixed)? Daniel -- 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-style pathname does not work as command - why?
Date: Thu, 9 Sep 2010 16:56:37 -0400 From: daniel To: cygwin Subject: Re: Windows-style pathname does not work as command - why? Not yet. Cygpath certainly supports Windows-style paths. Are you claiming that places like that are the only place that it is accepted to use Windows-styles paths (that is, if something like ls 'C:\x\y' quit working, it likely wouldn't be fixed)? I'm answering more generally than just ls. Everything is ultimately on a case by case basis. If it stops working because of a conflict with an important posixy thing, then it is likely gone. If it just stops working because of an update to some package, then if someone (the package maintainer or some motivated user) wants it fixed, it can be fixed. But clearly SHTDI. I think that it is time for this thread to move to the cygwin talk list. Thanks, ...Karl -- 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: Installing unix modules package on cygwin�
Greetings, Arnold Tharrington! I have installed the unix module package version 3.2.7 for Cygwin 1.7.1. However when I type module list I get the following error message. $ module list init.c(640):WARN:165: Cannot set TCL variable '!::' No Modulefiles Currently Loaded. My issue is the variable '!::' What is it and where is it set? This variable can not be processed TCL. When I type env, I that special variable listed The bug is in TCL or whatever wrapper around it, that trying to deal with variable names. POSIX clearly states that program must be prepared to deal with variables having names not really safe for printing. This has been discussed already, in this very list. mid:2bf01eb27b56cc478ad6e5a0a28931f201302...@a1dal1swpes19mb.ams.acs-inc.net And especially mid:20100804192416.ga4...@calimero.vinschen.de -- WBR, Andrey Repin (anrdae...@freemail.ru) 10.09.2010, 4:42 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: ocaml-3.12.0-2
Version 3.12.0-2 of ocaml has been uploaded. OCaml is a functional programming language with imperative features, objects, and modules. This update (from 3.08.1) represents 6 years of OCaml development, so I'm not going to list all the changes. From now on, I will keep this package up to date with upstream releases. Dynamic linking support is not included yet, but will soon be. -- Damien Doligez, the new ocaml maintainer for cygwin *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
