Re: RFD: cygwin + *native* MinGW compiler
Greg Chicares wrote: > On 2009-01-28 05:28Z, Charles Wilson wrote: First, thanks for your detailed response. It was very helpful. >> Do you use gnu-style configured projects (autoconf, automake, libtool, >> all that?) -- or some other build framework? > > Yes. I use autotools to build "native" versions of libraries I need, > in particular libxml2, libxslt, and wxwidgets. As an example, for > libxml2, here's the crucial part: ...(reordered, below)... > I can live with '--disable-dependency-tracking' because I rarely > modify the sources; if I ever do, I can 'make clean' and rebuild > them from scratch. ... > I use only Cygwin's make-3.81: ... [ stuff concerning -M*, including notations that you use "identity" mounts ] Interesting. So you have to be quite careful about how your system is configured: without identity mounts, it *will* break. If you (or any package you build) uses -M* (except for -MMD) then it *will* break, and -MMD only works if all paths in your build process are relative -- or (again) if you have identity mounts. (And identity mounts are not possible if you routinely use more than one drive). This is already quite fragile. >> What about creating static libraries?... > > I don't build third-party libraries as static. When I build my own > static libraries, I use MinGW's 'ar', but the command line is just > /MinGW_/bin/ar -rus liblmi.a convenience.o exception.o [...] > where all the '.o' files are in the directory where I invoke 'ar'. Once again -- a carefully managed situation where all paths are explicitly relative. > An incidental oddity is that the technique above produces > cygxml2-2.dll > cygxslt-1.dll > cygwxmsw28_gcc_344-0.dll > with 'cyg-' instead of 'lib-'. AFAICT, this doesn't matter > because the MinGW linker looks for both prefixes. I happen to > have Cygwin's version of some dlls as well as my own, e.g.: > $where cygxml2-2.dll > /opt/lmi/local/bin/cygxml2-2.dll > /usr/bin/cygxml2-2.dll > /bin/cygxml2-2.dll > but I specify my own '-L' path to the linker. Well, actually, I > guess that doesn't matter: the MinGW linker wouldn't look here: > C:\cygwin\bin\cygxml2-2.dll > by default anyway. Oh, geez. That's really bad. The whole POINT of cygwin using a special prefix for its DLLs is so that they won't be found by "accident" when the Windows Runtime Loader is loading a mingw app. That is, mingw-foo.exe <-- (mingw) libz-1.dll cygwin-foo.exe <-- (cygwin) cygz-1.dll So in the first case, the WRL sees that mingw-foo.exe needs a DLL named "libz-1.dll" and searches (according to certain rules) for it. Because all (ok, almost all) cygwin DLLs begin with 'cyg', none of them will be named "libz-1.dll" -- so mingw-foo will work properly even if cygwin's bin directory comes before (wherever libz-1.dll is) in the $PATH. However, if instead you have: mingw-foo.exe <-- (mingw) cygz-1.dll cygwin-foo.exe <-- (cygwin) cygz-1.dll Then either mingw-foo.exe or cygwin-foo.exe may break, depending on which cygz-1.dll is found first in $PATH. (You might assume that if mingw-foo.exe is in the same directory as the "mingw" cygz-1.dll, and cygwin-foo.exe is in the same directory as the "cygwin" cygz-1.dll, that the WRL would never be confused and things would always work, because $PATH is never searched. You'd be wrong: what if mingw-foo.exe is a very long-running process. So, it's in memory, along with a mapped copy of the (mingw) cygz-1.dll. Now, you launch cygwin-foo.exe. The WRL is smart: it sees that it needs a "cygz-1.dll" -- but wait! it already has one loaded in memory. All it needs to do is map the readonly parts of the (mingw) cygz-1.dll into cygwin-foo.exe's address space, and call the dll initialization routines. But that's the wrong cygz-1.dll. Bang. Dead. Note that my concerns have little to do with what happens at link-time; these are *run-time* problems. [Aside: the mingw linker does NOT search for cyg*dll. It searches for: libxxx.dll.a xxx.dll.a libxxx.a xxx.lib libxxx.dll xxx.dll because the mingw gcc spec file does NOT include --dll-search-prefix. However, if the libxxx.dll.a that it DOES find specifies "I'm an import library for cygxxx.dll" well, then, that's what the exe will tell the Windows Runtime Loader that it needs. cygwin's gcc spec file specifies --dll-search-prefix=cyg, so its ld searches for: libxxx.dll.a xxx.dll.a libxxx.a xxx.lib cygxxx.dll libxxx.dll xxx.dll But this usually doesn't matter, because you tell gcc -L/some/libdir/, where it only finds *.dll.a and *.a, not -L/some/bindir where the *.dll's live.] What confuses me, tho, is this: if your package KNOWS (because you told it) that $build and $host are mingw, then WHY is your libtool using cygwin rules to generate the DLL name? But that's something for another thread. >> This led to a suggestion that "--build=cygwin --host=mingw32" should >>
Re: find assert
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Gregory Sharp on 1/28/2009 4:46 PM: > Hi, > >> That makes sense. I changed ENOSHARE to ENOENT throughout. > > I upgraded my cygwin 1.7 today, but cygwin+find+UDFS still > reboots my windows 2000 computer. Was the above change > supposed to have solved the problem? No, it only solved the problem of dereferencing a broken symbolic link to //somewhere. The current version of find still asserts if it encounters a looping broken symbolic link. And rebooting your computer is not caused directly by find, but by a bad driver which goofs up when find is trying to list contents of a directory via some Windows call that uses that bad driver. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmBCfwACgkQ84KuGfSFAYAN8ACfaiuJ71CGVc2HuLB+G8asBGRT 9w8AoI9WZfruPc5doh6AidvQ/BYE9+98 =YbYy -END PGP SIGNATURE- -- 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: find assert
Hi, > That makes sense. I changed ENOSHARE to ENOENT throughout. I upgraded my cygwin 1.7 today, but cygwin+find+UDFS still reboots my windows 2000 computer. Was the above change supposed to have solved the problem? Thank you, Greg Greg Sharp gregsh...@geocities.com -- 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: opengl-1.1.0-10 glut32 linking problems
2009/1/28 Reini Urban:
> The importlib /usr/lib/w32api/libglut32.a has some problems. Linking
> to the dll directly works fine.
>
> $ cat test.c
> #include
> #include
> #include
> int main(int argc, char *argv[])
> {
>if(glutInit == NULL) {
>printf("glutInit is NULL\n");
>return EXIT_FAILURE;
>}
>printf("GLUT %d\n",GLUT_API_VERSION);
>return EXIT_SUCCESS;
> }
> $ gcc test.c -lglut32 -lglu -lopengl32
> undefined reference to `___glutInitWithExit'
> undefined reference to `___glutCreateWindowWithExit'
> undefined reference to `___glutCreateMenuWithExit'
> $ gcc test.c /bin/glut32.dll -lglu -lopengl32
>
> $ ./a
> GLUT 3
> I see nothing problematic, but I'm no expert
And to answer the libsearch patch question, about being shadowed from
another libglut:
$ gcc --verbose test_1676.c -lglut32 -lglu32 -lopengl32 2>&1 |grep collect2
$ /usr/lib/gcc/i686-pc-cygwin/3.4.4/collect2.exe --verbose -Bdynamic
--dll-search-prefix=cyg
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o
-L/usr/lib/gcc/i686-pc-cygwin/3.4.4
-L/usr/lib/gcc/i686-pc-cygwin/3.4.4
-L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. test.o -lglut32 -lglu32
-lopengl32 -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32
-lgcc 2>&1 |grep succeed
attempt to open /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o succeeded
attempt to open test.o succeeded
attempt to open /usr/lib/w32api/libglut32.a succeeded
attempt to open /usr/lib/w32api/libglu32.a succeeded
attempt to open /usr/lib/w32api/libopengl32.a succeeded
attempt to open /usr/lib/gcc/i686-pc-cygwin/3.4.4/libgcc.a succeeded
attempt to open /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a succeeded
attempt to open /usr/lib/w32api/libuser32.a succeeded
attempt to open /usr/lib/w32api/libkernel32.a succeeded
attempt to open /usr/lib/w32api/libadvapi32.a succeeded
attempt to open /usr/lib/w32api/libshell32.a succeeded
attempt to open /usr/lib/gcc/i686-pc-cygwin/3.4.4/libgcc.a succeeded
Everything looks okay to me here also
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
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/
opengl-1.1.0-10 glut32 linking problems
The importlib /usr/lib/w32api/libglut32.a has some problems. Linking
to the dll directly works fine.
$ cat test.c
#include
#include
#include
int main(int argc, char *argv[])
{
if(glutInit == NULL) {
printf("glutInit is NULL\n");
return EXIT_FAILURE;
}
printf("GLUT %d\n",GLUT_API_VERSION);
return EXIT_SUCCESS;
}
$ gcc test.c -lglut32 -lglu -lopengl32
undefined reference to `___glutInitWithExit'
undefined reference to `___glutCreateWindowWithExit'
undefined reference to `___glutCreateMenuWithExit'
$ gcc test.c /bin/glut32.dll -lglu -lopengl32
$ ./a
GLUT 3
Note that there are two more ___glut* functions, not only these three.
$ nm /lib/w32api/libglut32.a | grep " ___glut"
T ___glutset...@8
T ___glutinitwithe...@12
T ___glutget...@4
T ___glutcreatewindowwithe...@8
T ___glutcreatemenuwithe...@8
$ objdump -t /lib/w32api/libglut32.a | grep " ___glut"
[ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x ___glutset...@8
[ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x ___glutinitwithe...@12
[ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x ___glutget...@4
[ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x
___glutcreatewindowwithe...@8
[ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x
___glutcreatemenuwithe...@8
I see nothing problematic, but I'm no expert
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
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: RFD: cygwin + *native* MinGW compiler
Charles Wilson wrote: > Pursuant to a discussion on the libtool list, I'm trying to get a feel > for how many cygwin users rely on the cygwin environment to drive the > *native* MinGW gcc compiler. That is, incantations like this: [snip] > I hope this is considered on-topic here, because I'm interested in the > uses of the cygwin environment itself. I don't want reports of why it > doesn't work, or how hard it is to get one of the incantations above to > work. I just want to get an idea of how many people are currently, > actually, successfully, doing something like 1a) or 1b) above. None of then above... MOST of the time I use a true self-compiled cross compiler that resides in /mingw and use the cygwin environment [1]. I only use a native MinGW and cygwin when dealing with more exotic build systems like bjam for boost or things that were desined for the mingw32-make. Kai [1] ...well aside from uname. When using my cross compiler I start a script that resets some enviroment variables and switches to a self-written uname that claims a MSYS/MinGW Enviroment. That way I can run something like that --build=i686-pc-mingw32 --host=i686-pc-mingw32 under cygwin without the hiccups of true cross-compiling (running executables when a configure does tests). That way I can use a patched cygport that resides in /mingw/bin, the cygwin setup.exe and get a nice sum of packages.. enough to compile gtk, xchat, gimp, mplayer and some others. Its a rather strange enviroment I admit... and thew new libtool 2.0 won't work too. It did start a windows-command shell when linking that did nothing but idling in my process list. I did use MSYS for quite some time, but the cygwin enviroment is better maintained for my needs. -- Warum hat eigentlich noch niemand Electrocution-via-IP implementiert? ECP -> electric-chair-protocol Stab-over-IP hört sich immer noch am besten an -- 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: RFD: cygwin + *native* MinGW compiler
On 2009-01-28 05:28Z, Charles Wilson wrote: > Greg Chicares wrote: >> On 2009-01-28 02:21Z, Charles Wilson wrote: >>> Pursuant to a discussion on the libtool list, I'm trying to get a feel >>> for how many cygwin users rely on the cygwin environment to drive the >>> *native* MinGW gcc compiler. >> >> I use the native MinGW compiler in a Cygwin environment, >> successfully, many hours every day. > > A few additional questions, then: > > Do you use gnu-style configured projects (autoconf, automake, libtool, > all that?) -- or some other build framework? Yes. I use autotools to build "native" versions of libraries I need, in particular libxml2, libxslt, and wxwidgets. As an example, for libxml2, here's the crucial part: [snippet begins] # For 'host' and 'build' configure options, see: # http://cygwin.com/ml/cygwin/2002-01/msg00837.html # '--disable-dependency-tracking' is required with the MinGW toolchain # in a Cygwin shell, to prevent a catastrophic dependency-tracking # failure. Apparently the problem is colons in header paths, e.g.: # c:/MinGW-20050827/bin/../lib/gcc/mingw32/3.4.4/include/stddef.h: # which elicit fatal errors such as this: # .deps/DOCBparser.Plo:1: *** multiple target patterns. Stop. common_options := \ --build=i686-pc-mingw32 \ --host=i686-pc-mingw32 \ --disable-dependency-tracking \ [...] CC='$(mingw_bin_dir)/gcc' \ LD='$(mingw_bin_dir)/ld' \ LDFLAGS='-lws2_32' \ [snippet ends] [It may seem weird that I use a *makefile* to invoke autotools; maybe that's just a personal quirk because I'm comfortable with make's intricacies, whereas someone else might write a shell script for that.] As for --build and --host, the rationale for --build=i686-pc-mingw32 \ --host=i686-pc-mingw32 \ is just that I copied them from the old message cited above http://cygwin.com/ml/cygwin/2002-01/msg00837.html and they do seem to work; I don't have enough understanding of autotools to explain them any better than that. I can live with '--disable-dependency-tracking' because I rarely modify the sources; if I ever do, I can 'make clean' and rebuild them from scratch. An incidental oddity is that the technique above produces cygxml2-2.dll cygxslt-1.dll cygwxmsw28_gcc_344-0.dll with 'cyg-' instead of 'lib-'. AFAICT, this doesn't matter because the MinGW linker looks for both prefixes. I happen to have Cygwin's version of some dlls as well as my own, e.g.: $where cygxml2-2.dll /opt/lmi/local/bin/cygxml2-2.dll /usr/bin/cygxml2-2.dll /bin/cygxml2-2.dll but I specify my own '-L' path to the linker. Well, actually, I guess that doesn't matter: the MinGW linker wouldn't look here: C:\cygwin\bin\cygxml2-2.dll by default anyway. For my own code that uses libraries built as above, I personally use handwritten makefiles. But my project is autotoolized, and I have coworkers who use auto* files to build it, instead of my handwritten makefiles. > Do you use cygwin's make (which version?), mingw32-make, or perhaps a > cygwin build of msys's csmake/cpmake? I use only Cygwin's make-3.81: $which make /usr/bin/make $make --version GNU Make 3.81 [...] This program built for i686-pc-cygwin > Do you use gcc's -M* options for generating dependencies -- with > mingw-gcc, these rules will be in dos format and cygwin-make-3.81 > doesn't grok them? Yes. With '-MD', I'd have the problem you mention, but I'd fix that with 'sed'. (It might be smarter to use 'cygpath', but I've been using 'sed' for this since before the '-M*' options became stable.) With '-MMD', however, I can skip the 'sed' step and everything just works. For instance, I get fenv_lmi.o fenv_lmi.o: /lmi/src/lmi/fenv_lmi.cpp \ /lmi/src/lmi/fenv_lmi.hpp /lmi/src/lmi/config.hpp ... Perhaps that's just a happy consequence of using mount -f -s -b "C:/lmi" "/lmi" mount -f -s -b "C:/opt/lmi" "/opt/lmi" (which IIRC is the sort of "identity mount" Danny uses to build gcc) and keeping all my stuff in those two directories. > What about creating static libraries? If you use mingw's ar.exe, do you > use explicit `cygpath` rules to convert unix paths to the DOS paths that > version of ar can understand, or some other technique? I don't build third-party libraries as static. When I build my own static libraries, I use MinGW's 'ar', but the command line is just /MinGW_/bin/ar -rus liblmi.a convenience.o exception.o [...] where all the '.o' files are in the directory where I invoke 'ar'. I don't use 'cygpath' at all, anywhere. Using the "identity mount" technique, and always specifying paths with forward slashes (which virtually all msw programs accept), covers almost everything I need. For 'CPP -MD', I'd use 'sed' as mentioned above. I occasionally use a couple of compilers other than gcc, and where they don't grok forward slashes, I use a C++ program as a wrapper that does the translation. > For a hint about why I started this thread, and why I am asking these > questions, see > http://lists.gnu.org/archive/html/libto
Re: chmod, ownership, etc
Thank you. -- View this message in context: http://www.nabble.com/chmod%2C-ownership%2C-etc-tp21649645p21712842.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: [Fwd: Possible sscanf %f conversion glitch]
Jeff Johnston wrote: Patch has been made. The vfscanf code to look for "inf" and "nan" was not stopped if we had only collected zeroes to that point so it thought it was processing an invalid infinity. Thanks. Corinna Vinschen wrote: I'm forwarding this problem to the newlib list. I checked against the latest Cygwin from CVS and the problem still exists, afaics. - Forwarded message from KHMan - Date: Wed, 28 Jan 2009 23:19:07 +0800 From: KHMan Subject: Possible sscanf %f conversion glitch To: cygwin@cygwin.com [snip snip] -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia -- 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: [Fwd: Possible sscanf %f conversion glitch]
Patch has been made. The vfscanf code to look for "inf" and "nan" was
not stopped if we
had only collected zeroes to that point so it thought it was processing
an invalid infinity.
-- Jeff J.
Corinna Vinschen wrote:
I'm forwarding this problem to the newlib list. I checked against
the latest Cygwin from CVS and the problem still exists, afaics.
- Forwarded message from KHMan -
Date: Wed, 28 Jan 2009 23:19:07 +0800
From: KHMan
Subject: Possible sscanf %f conversion glitch
To: cygwin@cygwin.com
Hi all,
Someone ran into a problem with sscanf %f conversion on the Lout list. It
appeared that one specific case fails. I am running cygwin-1.5.25-15. Test
cases:
#include
int main()
{
char *foo1 = "10i";
char *foo2 = "0i";
char *foo3 = "0.0i";
char *foo4 = "1.0i";
char *foo5 = "0.1i";
float f;
printf("%d ", sscanf(foo1, "%f", &f)); printf("%f\n", f);
printf("%d ", sscanf(foo2, "%f", &f)); printf("%f\n", f);
printf("%d ", sscanf(foo3, "%f", &f)); printf("%f\n", f);
printf("%d ", sscanf(foo4, "%f", &f)); printf("%f\n", f);
printf("%d ", sscanf(foo5, "%f", &f)); printf("%f\n", f);
}
As the scanf man page specifies, 'i' is not supposed to be converted, only
the number part is supposed to be recognized.
On Cygwin:
$ ./test
1 10.00
0 10.00
1 0.00
1 1.00
1 0.10
On Linux (Ubuntu 8.04) and MinGW, the second case succeeds, the result
being the same as the third case. I've done some googling, and haven't
found anything related to this behaviour.
--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia
- End forwarded message -
Corinna
--
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: New Cygwin install and "configure: command not found" installing other packages
> From: cygwin-ow...@cygwin.com > [mailto:cygwin-ow...@cygwin.com] On Behalf Of Sjors Gielen > Sent: Wednesday, January 28, 2009 11:21 AM > To: cygwin@cygwin.com > Subject: Re: New Cygwin install and "configure: command not > found" installing other packages > That's because when you type 'configure', it searches for a file with > that name in your $PATH, i.e. in /bin, /usr/bin, but not in the local > directory (.). `sh` is in /bin/sh, and it searches in the current > directory, so `sh configure` works. However, it's better to run: > > ./configure > > as then you explicitly say "I want to run configure in this > directory". > > > > > The file "configure" is NOT something that I created but > was supplied with > > the packages. Two packages that have had this same problem > are "from > > reliable" sites. For example: > > http://gmplib.org/ > > http://www.gnu.org/software/libtool/libtool.html > > > > We know. Configure is a standard program that prepares compilation. > > Sjors I would swear that I had used "./" and not ".\" but, apparently, I hadn't because (of course) now it works with the correct command. Thanks for the explanation (that made be retry it). -- 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/
[Fwd: Possible sscanf %f conversion glitch]
I'm forwarding this problem to the newlib list. I checked against
the latest Cygwin from CVS and the problem still exists, afaics.
- Forwarded message from KHMan -
> Date: Wed, 28 Jan 2009 23:19:07 +0800
> From: KHMan
> Subject: Possible sscanf %f conversion glitch
> To: cygwin@cygwin.com
>
> Hi all,
>
> Someone ran into a problem with sscanf %f conversion on the Lout list. It
> appeared that one specific case fails. I am running cygwin-1.5.25-15. Test
> cases:
>
> #include
> int main()
> {
> char *foo1 = "10i";
> char *foo2 = "0i";
> char *foo3 = "0.0i";
> char *foo4 = "1.0i";
> char *foo5 = "0.1i";
> float f;
> printf("%d ", sscanf(foo1, "%f", &f)); printf("%f\n", f);
> printf("%d ", sscanf(foo2, "%f", &f)); printf("%f\n", f);
> printf("%d ", sscanf(foo3, "%f", &f)); printf("%f\n", f);
> printf("%d ", sscanf(foo4, "%f", &f)); printf("%f\n", f);
> printf("%d ", sscanf(foo5, "%f", &f)); printf("%f\n", f);
> }
>
> As the scanf man page specifies, 'i' is not supposed to be converted, only
> the number part is supposed to be recognized.
>
> On Cygwin:
> $ ./test
> 1 10.00
> 0 10.00
> 1 0.00
> 1 1.00
> 1 0.10
>
> On Linux (Ubuntu 8.04) and MinGW, the second case succeeds, the result
> being the same as the third case. I've done some googling, and haven't
> found anything related to this behaviour.
>
> --
> Cheers,
> Kein-Hong Man (esq.)
> Kuala Lumpur, Malaysia
- End forwarded message -
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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: New Cygwin install and "configure: command not found" installing other packages
Bill Klein wrote: A) my hope is to use as little "shell" as possible. I am installing Cygwin in order to be able to use a specific "product" that does not (normally) require shell programming. B) I am using the commands as they appear in the INSTALL file for the packages that I am using. (I simply made a typo in my original note) C) After trying the original command, I ran this from the directory where the "configure" file was (which I verified with "dir"). when I typed configure it got the "configure: command not found" message when I typed sh configure it worked. That's because when you type 'configure', it searches for a file with that name in your $PATH, i.e. in /bin, /usr/bin, but not in the local directory (.). `sh` is in /bin/sh, and it searches in the current directory, so `sh configure` works. However, it's better to run: ./configure as then you explicitly say "I want to run configure in this directory". The file "configure" is NOT something that I created but was supplied with the packages. Two packages that have had this same problem are "from reliable" sites. For example: http://gmplib.org/ http://www.gnu.org/software/libtool/libtool.html We know. Configure is a standard program that prepares compilation. Sjors -- 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: New Cygwin install and "configure: command not found" installing other packages
> From: cygwin-ow...@cygwin.com > [mailto:cygwin-ow...@cygwin.com] On Behalf Of Thorsten Kampe > Sent: Wednesday, January 28, 2009 10:59 AM > To: cygwin@cygwin.com > Subject: Re: New Cygwin install and "configure: command not > found" installing other packages > > * Bill Klein (Wed, 28 Jan 2009 10:40:48 -0600) > > I am new and know that I have done something wrong, but haven't been > > able to find the solution in the FAQ or archives. > > > > when I type > >.\configure > > I am getting the > > configure: command not found > > message. > > The path separator on Unix is "/". So it should be > "./configure". Please > consider getting some basic shell knowledge before using a shell. > > Thorsten > A) my hope is to use as little "shell" as possible. I am installing Cygwin in order to be able to use a specific "product" that does not (normally) require shell programming. B) I am using the commands as they appear in the INSTALL file for the packages that I am using. (I simply made a typo in my original note) C) After trying the original command, I ran this from the directory where the "configure" file was (which I verified with "dir"). when I typed configure it got the "configure: command not found" message when I typed sh configure it worked. The file "configure" is NOT something that I created but was supplied with the packages. Two packages that have had this same problem are "from reliable" sites. For example: http://gmplib.org/ http://www.gnu.org/software/libtool/libtool.html http://www.oracle.com/technology/software/products/berkeley-db/db/index.html I can't believe that ALL 3 have made a mistake in their INSTALL instructions or in their "configure" file. I am certain, as I said, that I have done something wrong. (Possibly not installed something in Cygwin that I should have). However, I need help in finding out what it is. -- 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: New Cygwin install and "configure: command not found" installing other packages
* Bill Klein (Wed, 28 Jan 2009 10:40:48 -0600) > I am new and know that I have done something wrong, but haven't been > able to find the solution in the FAQ or archives. > > when I type >.\configure > I am getting the > configure: command not found > message. The path separator on Unix is "/". So it should be "./configure". Please consider getting some basic shell knowledge before using a shell. Thorsten -- 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: RFD: cygwin + *native* MinGW compiler
Charles Wilson schrieb: I just want to get an idea of how many people are currently, actually, successfully, doing something like 1a) or 1b) above. I never do serious cross-compiling from or to mingw in a cygwin shell. When testing mingw I do it from cmd.exe and the mingw toolkit and no cygwin in the path. -- Reini -- 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: Having problems with bash
On Wed, Jan 28, 2009 at 08:08:24AM -0800, syllk wrote: >I am hoping that there is a simple fix to this. I am new to cygwin and >tinyos and when running cygwin it immediately runs with this first line >'bash: [: /home/Chris: binary operator expected'. With this problem I >seem to get errors whenever I try to 'make' anything. > >If anyone knows how to fix this I would much appreciate it. If this really is a distribution that you've downloaded from the Cygwin site then please provide the details asked for here: http://cygwin.com/problems.html If you got this from the tinyos.net site (which may be third-party repackagers of Cygwin) then ask them for help. We don't support Cygwin packages provided by other sites here. cgf -- 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/
New Cygwin install and "configure: command not found" installing other packages
I am new and know that I have done something wrong, but haven't been able to find the solution in the FAQ or archives. when I type .\configure I am getting the configure: command not found message. However, if I type sh .\configure it works fine. This happens when trying to install several different packages. I have read about CR/LF problems and I have used tar to "unzip" the packages. I even ran dos2unix on them and this does not help. Right after I first installed Cygwin, this worked for the first package. However, then it stopped. I thought I had messed something up, so I totally uninstalled everything (including Cygwin) and re-installed and still am having this problem (and using "sh" first still works. I am running on XP. I have attached a cygchekc.out file and hope that someone can tell me what obvious thing I have done wrong and how to fix it. Thanks in advance. cygcheck.out Description: Binary data -- 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/
Having problems with bash
I am hoping that there is a simple fix to this. I am new to cygwin and tinyos and when running cygwin it immediately runs with this first line 'bash: [: /home/Chris: binary operator expected'. With this problem I seem to get errors whenever I try to 'make' anything. If anyone knows how to fix this I would much appreciate it. -- View this message in context: http://www.nabble.com/Having-problems-with-bash-tp21708788p21708788.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: CSIH csih_get_cygenv function (was Re: permission problems with ssh-host-config)
On Jan 28 10:17, Charles Wilson wrote: > Corinna Vinschen wrote: > > What I'm planning to do is this: > > > > - In cygwin-service-installation-helper.sh I would like to drop the > > check for the content of CYGWIN entirely. > > OK. Fine. I'll apply a patch at one point today. > > - In ssh-host-config I'd like to set the default for the CYGWIN settings > > to an empty string. > > OK. > > > What do you think? > > We still have the on-going confusion concerning "Do you want to use > another name?" with -y. Yeah, I still have the patch I sent once here in my local CVS copy. How should we fix that? The problem was about what to do if the --yes option has been given on the command line, right? My patch reverts the meaning of the request and you said this breaks postinstall scripts. I just read your reply from 2008-12-09 again(*). What strucks me as weird is the fact that any postinstall script would ask for a user account at all. No postinstall script should ever try to install a Windows service automatically, IMHO. Assuming that's true, is the aforementioned account problem a postinstall problem at all? > I'm hung up on libtool issues right now, but > that's on the list to be addressed. However, I won't hold up a release > of csih-0.19 waiting for that. It's not that pressing, IMHO. > BTW, do you think we should fork csih for cygwin-1.7? I don't think so. CSIH already knows about cygwin 1.7 and can act differently. At one point you can simply stop supporting 1.5 in new versions of csih and that's that. Corinna (*) http://www.cygwin.com/ml/cygwin/2008-12/msg00189.html -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: RFD: cygwin + *native* MinGW compiler
Charles Wilson wrote: > > Pursuant to a discussion on the libtool list, I'm trying to get a feel > for how many cygwin users rely on the cygwin environment to drive the > *native* MinGW gcc compiler. > - I currently use Cygwin for cross-platform development of software and firmware. - I use Msys/MinGW for development of Windows software. - I plan to move from Msys/MinGW to Cygwin/MinGW to develop Windows software, soon. Claude. -- 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: RFD: cygwin + *native* MinGW compiler
Charles Wilson wrote: Pursuant to a discussion on the libtool list, I'm trying to get a feel for how many cygwin users rely on the cygwin environment to drive the *native* MinGW gcc compiler. That is, incantations like this: 1a) cygwin$ some-src-pkg/configure \ --build=i686-pc-cygwin --host=mingw32 \ CC=/c/MinGW/bin/gcc.exe \ CXX=/c/MinGW/bin/g++.exe \ NM=/c/MinGW/bin/nm.exe \ DLLTOOL=/c/MinGW/bin/dlltool.exe \ OBJDUMP=/c/MinGW/bin/objdump.exe \ LD=/c/MinGW/bin/ld.exe or possibly 1b) cygwin$ export PATH=/c/MinGW/bin:$PATH cygwin$ some-src-pkg/configure \ --build=i686-pc-cygwin --host=mingw32 Note that this is *DIFFERENT* than installing a true cygwin-hosted mingw-target cross-compiler, and just doing 2) cygwin$ some-src-pkg/configure \ --build=i686-pc-cygwin --host=i686-pc-mingw32 It is ALSO different than the (deprecated, unsupported, go-away-don't-bother-us) incantation: 3) cygwin$ some-src-pkg/configure \ --build=i686-pc-cygwin --host=i686-pc-mingw32 \ CFLAGS='-mno-cygwin' I hope this is considered on-topic here, because I'm interested in the uses of the cygwin environment itself. I don't want reports of why it doesn't work, or how hard it is to get one of the incantations above to work. I just want to get an idea of how many people are currently, actually, successfully, doing something like 1a) or 1b) above. Our development group uses "native" MinGW every day with the Cygwin bash shell as the center of operations. I believe that we are over ten years into this at this point Our build environment uses Serena Configuration Builder and PVCS, but I can feel a more standard unixish (autoconf, automake, etc) environment coming in as well. I also use Cygwin to develop using Embedded C++, Visual C++ by starting bash via a windows batch file that sets the "BASHENV" environment variable to another script, eg .mingwrc, that sets the build environment specifically ensuring in this case that MinGW's gcc, etc is ahead of Cygwin's in the PATH. -- Chuck -- 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/ -- Roger Wells, P.E. SAIC 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) roger.k.we...@saic.com -- 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/
Possible sscanf %f conversion glitch
Hi all,
Someone ran into a problem with sscanf %f conversion on the Lout
list. It appeared that one specific case fails. I am running
cygwin-1.5.25-15. Test cases:
#include
int main()
{
char *foo1 = "10i";
char *foo2 = "0i";
char *foo3 = "0.0i";
char *foo4 = "1.0i";
char *foo5 = "0.1i";
float f;
printf("%d ", sscanf(foo1, "%f", &f)); printf("%f\n", f);
printf("%d ", sscanf(foo2, "%f", &f)); printf("%f\n", f);
printf("%d ", sscanf(foo3, "%f", &f)); printf("%f\n", f);
printf("%d ", sscanf(foo4, "%f", &f)); printf("%f\n", f);
printf("%d ", sscanf(foo5, "%f", &f)); printf("%f\n", f);
}
As the scanf man page specifies, 'i' is not supposed to be
converted, only the number part is supposed to be recognized.
On Cygwin:
$ ./test
1 10.00
0 10.00
1 0.00
1 1.00
1 0.10
On Linux (Ubuntu 8.04) and MinGW, the second case succeeds, the
result being the same as the third case. I've done some googling,
and haven't found anything related to this behaviour.
--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia
--
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: CSIH csih_get_cygenv function (was Re: permission problems with ssh-host-config)
Corinna Vinschen wrote: > What was the exact reason to restrict the input for the CYGWIN settings > in csih? I don't quite understand why a lot of options are disallowed > at all, for instance "winsymlinks", "ntea", etc. Inherited from pre-existing code (either old ssh-*-config or exim-config). > IMHO this doesn't make much sense, especially given that Cygwin 1.7 > has a quite different set of CYGWIN settings. I don't mind removing that. > What I'm planning to do is this: > > - In cygwin-service-installation-helper.sh I would like to drop the > check for the content of CYGWIN entirely. OK. > - In ssh-host-config I'd like to set the default for the CYGWIN settings > to an empty string. OK. > What do you think? We still have the on-going confusion concerning "Do you want to use another name?" with -y. I'm hung up on libtool issues right now, but that's on the list to be addressed. However, I won't hold up a release of csih-0.19 waiting for that. BTW, do you think we should fork csih for cygwin-1.7? -- Chuck -- 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: RFD: cygwin + *native* MinGW compiler
On Wed, Jan 28, 2009 at 04:05:55PM +0100, Vincent R. wrote: >Actually I am using cygwin because there are many packages, adn a good >installer but I will >switch completely to mingw if I could get the same. >Couldn't be possible to share more things between the two projects ? >I mean for instance share the cywgin installer that could allow people to >install cygwin and mingw >on two different places to avoid lib/path issues. >For instance : > >C:\gnu\cygwin >C:\gnu\mingw >C:\gnu\home > >They could share for instance the same home directory ... >Last time I tried to compile something with cygwin targeting mingw it just >failed... The Cygwin installer is open source. There is nothing stopping people from using it. There is no benefit to the Cygwin project in trying to adapt to some other project's need but, in your above example, you could arrange your own system to use those paths easily. cgf -- 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: RFD: cygwin + *native* MinGW compiler
On Wed, Jan 28, 2009 at 12:14:40AM -0600, Yaakov (Cygwin/X) wrote: >Charles Wilson wrote: >>This led to a suggestion that "--build=cygwin --host=mingw32" should >>always be interpreted as: mingw32-gcc is a cygwin-hosted cross >>compiler, NOT the native MinGW-project supported gcc (and if it IS the >>native MinGW one, expect breakage). I'm not sure such a sweeping >>statement is accurate, or wise -- will that assumption break people's >>exising (working) setups? > >If you're talking about configure gcc with those flags, then wouldn't >that usually mean that you're cross-compiling a regular, native MinGW >compiler? If you want a cygwin-hosted MinGW cross-compiler, you should >be using "--build=cygwin --host=cygwin --target=mingw32". I would be >hesitant to change the usual meaning of build/host just for >Cygwin/MinGW; I don't think we need to add to the confusion that most >people have about Cygwin. Ditto. cgf -- 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: RFD: cygwin + *native* MinGW compiler
On Wed, 28 Jan 2009 09:38:47 -0500, Ralph Hempel wrote: > Charles Wilson wrote: >> Pursuant to a discussion on the libtool list, I'm trying to get a feel >> for how many cygwin users rely on the cygwin environment to drive the >> *native* MinGW gcc compiler. That is, incantations like this: > > > > I find myself bouncing around between cygwin and mingw because > each one helps me accomplish different tasks. > > I use the Cygwin environment (including vim) for the actual > software development of embedded systems, and to host the > different gcc flavours needed for each target processor. There's > lots of great tools ready to go, and it's now possible > to drive the install from the command line, which makes it > easy to reproduce a specific workstation configuration. > > Occasionally, I want to compile special tools that I can > redistribute without source, so I use mingw for that. > > I have a build framework for embedded systems that I use for > all my projects - even PC based ones. If I'm compiling third > party software that comes with a makefile or autoconf script > then I'll use that. > > Once you start designing makefiles that have to work with > multiple compiler versions and flags and include and library > paths, it gets complicated very quickly :-) > > One reason I have not tried to drive the native MinGW compiler > is because of the path issues for includes and libraries. I > was worried that Cygwin includes and libraries would accidentally > get referenced. > > Ralph > > -- > 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/ Actually I am using cygwin because there are many packages, adn a good installer but I will switch completely to mingw if I could get the same. Couldn't be possible to share more things between the two projects ? I mean for instance share the cywgin installer that could allow people to install cygwin and mingw on two different places to avoid lib/path issues. For instance : C:\gnu\cygwin C:\gnu\mingw C:\gnu\home They could share for instance the same home directory ... Last time I tried to compile something with cygwin targeting mingw it just failed... -- 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: RFD: cygwin + *native* MinGW compiler
Charles Wilson wrote: Pursuant to a discussion on the libtool list, I'm trying to get a feel for how many cygwin users rely on the cygwin environment to drive the *native* MinGW gcc compiler. That is, incantations like this: I find myself bouncing around between cygwin and mingw because each one helps me accomplish different tasks. I use the Cygwin environment (including vim) for the actual software development of embedded systems, and to host the different gcc flavours needed for each target processor. There's lots of great tools ready to go, and it's now possible to drive the install from the command line, which makes it easy to reproduce a specific workstation configuration. Occasionally, I want to compile special tools that I can redistribute without source, so I use mingw for that. I have a build framework for embedded systems that I use for all my projects - even PC based ones. If I'm compiling third party software that comes with a makefile or autoconf script then I'll use that. Once you start designing makefiles that have to work with multiple compiler versions and flags and include and library paths, it gets complicated very quickly :-) One reason I have not tried to drive the native MinGW compiler is because of the path issues for includes and libraries. I was worried that Cygwin includes and libraries would accidentally get referenced. Ralph -- 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: CSIH csih_get_cygenv function (was Re: permission problems with ssh-host-config)
On Jan 28 12:21, Corinna Vinschen wrote: > What I'm planning to do is this: > > - In cygwin-service-installation-helper.sh I would like to drop the > check for the content of CYGWIN entirely. > > - In ssh-host-config I'd like to set the default for the CYGWIN settings > to an empty string. ... and to remove the text which mentiones that ntsec is required. That's really old cruft which I was just too lazy to change all the time. At least it didn't hurt... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
CSIH csih_get_cygenv function (was Re: permission problems with ssh-host-config)
Hi Chuck, On Jan 28 11:19, Corinna Vinschen wrote: > On Jan 27 19:35, Siegmar Gross wrote: > > *** Info: Note that the CYGWIN variable must contain at least "ntsec" > > *** Info: for sshd to be able to change user context without password. > > *** Query: Enter the value of CYGWIN for the daemon: [ntsec] ntsec tty > > server > > *** ERROR: Only [no] "check_case:strict" "ntsec" "smbntsec" "traverse" > > allowed. > > [...] > > Why doesn't the script allow the values "ntsec tty server" for CYGWIN > > any longer although "cygserver" needs "server" in CYGWIN? > > Chris is right about "tty", you don't need it. However, disallowing > "tty" and "server" is a bug in the script. The text about ntsec should > be changed as well, it's not correct anymore for a long time. I'll fix > that. What was the exact reason to restrict the input for the CYGWIN settings in csih? I don't quite understand why a lot of options are disallowed at all, for instance "winsymlinks", "ntea", etc. IMHO this doesn't make much sense, especially given that Cygwin 1.7 has a quite different set of CYGWIN settings. What I'm planning to do is this: - In cygwin-service-installation-helper.sh I would like to drop the check for the content of CYGWIN entirely. - In ssh-host-config I'd like to set the default for the CYGWIN settings to an empty string. What do you think? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
[ANNOUNCEMENT] [1.7] Updated: cygwin-1.7.0-39
Hi folks,
I just uploaded a new Cygwin 1.7 test release, 1.7.0-39.
Just download http://cygwin.com/setup-1.7.exe and use that setup tool
to install Cygwin 1.7. As usual, please report bugs and problems to
the mailing list cygwin AT cygwin DOT com.
I'm not quite sure I already mentioned that we also have a new
User's Guide for 1.7, which is currently located at
http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html (Multiple HTML files)
or
http://cygwin.com/1.7/cygwin-ug-net.html (One single big HTML file)
I would appreciate bug fixes and extensions to the documentation in
the form of patches to the source SGML files. The SGML sources are
located in the CVS repository under the winsup/doc directory, for
example here:
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/doc/?cvsroot=src
We don't have a new 1.7 FAQ yet since we don't know what *will* be a FAQ
in future, but I'm planning to drop at least old stuff from the FAQ in
the next couple of days.
Maybe that goes without saying, but we would really appreciate help with
the new FAQ as well as with the User's Guide and Cygwin in general.
THIS IS STILL A TEST RELEASE. DON'T USE IN PRODUCTION ENVIRONMENTS.
What's new in contrast to 1.7.0-38:
===
- The CYGWIN environment variable option "server" has been removed.
Cygwin automatically uses cygserver if it's available.
- A hack has been added to allow proper serial I/O operation with
com0com driver.
Bugfixes:
=
- The bug which resulted in broken pipes when using scp has been fixed.
- The /etc/fstab, /etc/passwd and /etc/group files are now opened with
backup intent. This means, they can be read by every administrative
account, even if the permissions have been screwed up. Note that
correctly all these files should be readable by everyone!
FAQ:
- Q: How do I know that I'm running Cygwin 1.7.0-39?
A: The `uname -v' command prints "2009-01-27 16:49"
Have fun,
Corinna
Just for completeness, here's once more the list of Changes in 1.7.0
related to 1.5.25:
OS releated changes:
- Windows 95, 98 and Me are not supported anymore. The new DLL will
not run on any of these systems.
File Access related changes:
- Mount points are no longer stored in the registry. Use /etc/fstab
and /etc/fstab.d/$USER instead. Mount points created with mount(1)
are only local to the current session and disappear when the last
Cygwin process in the session exits.
- PATH_MAX is now 4096. Internally, path names can be as long as the
underlying OS can handle (32K).
- UTF-8 filenames are supported now. So far, this requires to set
the environment variable CYGWIN to contain "codepage:utf8". but this
will likely disappear at one point. The setting of $LANG or $LC_CTYPE
will be used instead.
- struct dirent now supports d_type, filled out with DT_REG or DT_DIR.
All other file types return as DT_UNKNOWN for performance reasons.
- The CYGWIN environment variable options "ntsec" and "smbntsec" have
been replaced by the per-mount option "acl"/"noacl".
- The CYGWIN environment variable option "ntea" has been removed without
substitute.
- The CYGWIN environment variable option "check_case" has been removed
in favor of real case-sensitivity on file systems supporting it.
- Creating filenames with special DOS characters '"', '*', ':', '<',
'>', '|' is supported.
- Creating files with special DOS device filename components ("aux",
"nul", "prn") is supported.
- File name are case sensitive if the OS and the underlying file system
supports it. Works on NTFS and NFS. Does not work on FAT and Samba
shares. Requires to change a registry key (see the user's guide).
Can be switched off on a per-mount base.
- Due to the above changes, managed mounts have been removed.
- Incoming DOS paths are always handled case-insensitive and get no POSIX
permission, as if they are mounted with noacl,posix=0 mount flags.
- unlink(2) and rmdir(2) try very hard to remove files/directories even
if they are currently accessed or locked. This is done by utilizing
the hidden recycle bin directories and marking the files for deletion.
- rename(2) rewritten to be more POSIX conformant.
- Add st_birthtim member to struct stat.
- File locking is now advisory, not mandatory anymore. The fcntl(2) and
the new lockf(2) APIs create and maintain locks with POSIX semantics,
the flock(2) API creates and maintains locks with BSD semantics.
POSIX and BSD locks are independent of each other.
- Implement atomic O_APPEND mode.
- Handle NTFS native symlinks available since Vista/2008 as symlinks
(but don't create Vista/2008 symlinks due to unfortunate OS restrictions).
- Recognize NFS share
Re: permission problems with ssh-host-config
On Jan 27 19:35, Siegmar Gross wrote: > *** Info: Note that the CYGWIN variable must contain at least "ntsec" > *** Info: for sshd to be able to change user context without password. > *** Query: Enter the value of CYGWIN for the daemon: [ntsec] ntsec tty server > *** ERROR: Only [no] "check_case:strict" "ntsec" "smbntsec" "traverse" > allowed. > [...] > Why doesn't the script allow the values "ntsec tty server" for CYGWIN > any longer although "cygserver" needs "server" in CYGWIN? Chris is right about "tty", you don't need it. However, disallowing "tty" and "server" is a bug in the script. The text about ntsec should be changed as well, it's not correct anymore for a long time. I'll fix that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: RFD: cygwin + *native* MinGW compiler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: > Right, if I'm building a compiler. I'm not -- although that wasn't very > clear, since the only examply I gave was Danny's incantation for > building gcc, a compiler. Oops. > > I'm talking about building, say, ncurses so that it will run "natively" > (that is, in the mingw environment without cygwin). The question is, > what assumptions should be made about the compiler that is used to > compile ncurses, when you configure ncurses using --build= --target=? > Does that compiler understand /cygdrive/c/foo, or C:\foo? That's a totally different story. I think that would be obvious; - --build=cygwin --target=mingw32 should mean you're using a Cygwin-based MinGW cross-compiler. AFAIK that's consistent with other platform combinations. > Only compilers and linkers have --targets. Everything else, you > (cross)compile using build/host (or just host; build is implicit). So, > the implication of the suggestion above is that: > > ../ncurses/configure --build=cygwin --host=mingw32 > > would mean that the gcc involved runs on the cygwin build platform, and > understands /cygdrive/c/foo, but the ncurses library and tools will be > native mingw32 and will only understand C:\foo. That is, it is a > cygwin->mingw cross compiler. (Bringing this down to earth: > specifically, when libtool is creating a wrapper executable -- say, for > tic.exe -- using the cross-compiler, the wrapper exe will be a native > win32 prog, and will need the DOS path to the exe it needs to "wrap". > Not the cygwin path -- and libtool should use cygpath to obtain that DOS > path). Right. > OTOH, > > ../ncurses/configure --build=mingw32 --host=mingw32 > > would mean that the compiler TOO only understands C:\foo. That is, it is > a native MinGW compiler as distributed by the MinGW team. (Back to > earth: specifically, when libtool is creating a wrapper executable using > this "native" compiler, the wrapper exe will be a native win32 prog, and > will need the DOS path to the exe it needs to "wrap". However, because > of the oddities of "MinGW" $build -- it's actually msys, and has its own > idea of a unix-like path -- libtool will need to convert that unix-like > path to DOS format using the msys mechanism to do so. NOT cygpath). So far so good. > These are both logical scenarios, and represent the "normal" way of > interpreting build/host for an cross-compile or native setup [other than > the utter weirdness that is msys]. However...and here's the rub...until > now the various win32 "hosted" platforms have been rather lax about > these distinctions. So, for instance, Danny can currently get away with > the following: > > cygwin-machine$ ../gcc/configure --build=mingw32 --host=ming32 > --target=mingw32 > > even though $build is NOT, actually, mingw32 (or even msys). It's > cygwin. Enforcing the "normal" interpretation will break that usage > (Back to earth: because the "wrong" mechanism (msys->mingw, instead of > the true cygwin->mingw) to convert unix-like paths to the DOS path > needed by the wrapper exe will be used. Don't lie to your tools about > their $build environment...) > > Maybe this usage *should* be broken (or strongly discouraged, with an > esoteric workaround for those who insist on mistreating their tools). I > dunno. Of course it's broken, period. And just like all the other misconceptions around Cygwin, I don't see why it we shouldn't be allowed to fix it. > Seems kinda harsh, to break something that currently works (even if it > is evil) -- and the point of this thread, really, is to see how many > people use cygwin + mingw in situations where they may be tempted to -- > or already do -- lie to their configure scripts about $build. WJM. :-) But as we're (finally!) abandoning the long-broken - -mno-cygwin, I don't see why we can't dump this breakage as well. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkmAH8sACgkQpiWmPGlmQSPTwQCghn3w7Sr2ojNXQTdiizeIr9Qu f8cAoPKk8R710du8gOFvFYDJuMAkGEUY =7g0F -END PGP SIGNATURE- -- 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/
