Re: execvp error:cygwin+make+busybox
Christopher Faylor wrote: On Tue, May 03, 2005 at 10:39:13AM +1000, John Williams wrote: Attempting to cross-compile Busybox 1.00 under Cygwin (1.5.16-1) I am hitting an error similar to one previously reported on the Cygwin list (Jan 05): http://www.cygwin.com/ml/cygwin/2005-01/msg00657.html IIRC, I also had this problem on Cygwin until I deleted the .EXPORT_ALL_VARIABLES from Rules.mak. I have a specialized build environment so it is possible that there are other things required to get things working after that, but this was the culprit which caused these problems. That's done the trick - thanks for the quick response. Am still checking to see if that has any follow-on effects (perhaps I should now explicitly export the important variables from Rules.mak?). Cheers, John -- 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/
pwd vs $PWD, bash, cygwin vs Linux
Hello, I am resurrecting a topic that has been discussed before, but there doesn't seem to be a clear resolution (at least not clear to me!). It relates to the behaviour of the PWD variable in the case of multiply nested Makefiles. it was touched upon e.g. here: http://www.mail-archive.com/cygwin@sources.redhat.com/msg16375.html I'm doing a side by side comparison between Cygwin 1.5.16-1 and Linux RedHat 8.0, both using bash shell 2.05b.0(1)-release, and make version 3.79.1 Here's my test setup (sorry for dodgy ASCII art) Maketest | + topdir | + Makefile | + subdir | + Makefile topdir/Makefile looks like this: # #topdir/Makefile TOPDIR := $(shell echo $$PWD) all: @echo In topdir, TOPDIR=$(TOPDIR) @echo In topdir, PWD=$$PWD make -C subdir all .EXPORT_ALL_VARIABLES: ## and topdir/subdir/Makefile looks like this: # #topdir/subdir/Makefile all: @echo in subdir, TOPDIR=$(TOPDIR) @echo in subdir, PWD=$$PWD # Now, from the top-top level (Maketest), I run 'make -C topdir'. Under my Cygwin setup, I get this: [EMAIL PROTECTED] Maketest]$ make -C topdir make: Entering directory `/cygdrive/z/Maketest/topdir' In topdir, TOPDIR=/cygdrive/z/Maketest In topdir, PWD=/cygdrive/z/Maketest make -C subdir all make[1]: Entering directory `/cygdrive/z/Maketest/topdir/subdir' in subdir, TOPDIR=/cygdrive/z/Maketest in subdir, PWD=/cygdrive/z/Maketest make[1]: Leaving directory `/cygdrive/z/Maketest/topdir/subdir' make: Leaving directory `/cygdrive/z/Maketest/topdir' [EMAIL PROTECTED] Maketest]$ while under the identical setup on Linux, I get this: [EMAIL PROTECTED] Maketest]$ make -C topdir make: Entering directory `/mnt/home2/jwilliam/Maketest/topdir' In topdir, TOPDIR=/mnt/home2/jwilliam/Maketest/topdir In topdir, PWD=/mnt/home2/jwilliam/Maketest/topdir make -C subdir all make[1]: Entering directory `/mnt/home2/jwilliam/Maketest/topdir/subdir' in subdir, TOPDIR=/mnt/home2/jwilliam/Maketest/topdir in subdir, PWD=/mnt/home2/jwilliam/Maketest/topdir/subdir make[1]: Leaving directory `/mnt/home2/jwilliam/Maketest/topdir/subdir' make: Leaving directory `/mnt/home2/jwilliam/Maketest/topdir' [EMAIL PROTECTED] Maketest]$ Essentially under Cygwin the PWD variable seems to be frozen at its value upon first launching Make from the commandline, while under Linux it is being updated for each child process spawned by `make -C XXX` I know that Cygwin != Linux, however is it a reasonable expectation that under the same shells, the same behaviour should apply? The real context for all of this is building the net-tools package, which uses these sort of constructs to manage its recursive Makefile structure. I'm sure there are plenty of other GNU-esque packages out there doing similarly. Any insights or workarounds would be greatly appreciated. Thanks, John -- 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: pwd vs $PWD, bash, cygwin vs Linux
Christopher Faylor wrote: On Wed, May 04, 2005 at 11:08:43AM +1000, John Williams wrote: Essentially under Cygwin the PWD variable seems to be frozen at its value upon first launching Make from the commandline, while under Linux it is being updated for each child process spawned by `make -C XXX` I know that Cygwin != Linux, however is it a reasonable expectation that under the same shells, the same behaviour should apply? In this case, the operative observation is bash != ash. PWD is a bash construct. You would be much better off just using the gnu make CURDIR variable. Changing PWD to CURDIR in your examples makes things work as you'd expect. Thanks for the quick response and workaround. While what you say might be a true statement, better off means different things to different people! It's easy for me to say, but it seems cleaner for the compatability layer (e.g. Cygwin) to model the expected behaviour (even behaviour which might be considered buggy), than to push changes on fairly standard and widely distributed source/build packages. What surprised me was that the same shell, and same make, resulted in different behaviour. I guess this is just reflecting differences in the underlying process architectures of Linux vs Windows. Cheers, John -- 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: pwd vs $PWD, bash, cygwin vs Linux
Christopher Faylor wrote: In this case, the operative observation is bash != ash. PWD is a bash construct. You would be much better off just using the gnu make CURDIR variable. Changing PWD to CURDIR in your examples makes things work as you'd expect. Thanks for the quick response and workaround. While what you say might be a true statement, better off means different things to different people! What surprised me was that the same shell, and same make, resulted in different behaviour. I guess this is just reflecting differences in the underlying process architectures of Linux vs Windows. Again, it *isn't* the same shell. You have now learned that it isn't the same shell and you now know that this is the reason for the inconsistency. ash isn't normally used as /bin/sh on linux. A stripped down version of ash is used as /bin/sh for performance purposes on cygwin. ash does not set PWD. OK - I see the confusion. Make is spawning ash as the subshell, not bash. Now everything you said makes sense. Out of interest, can that behaviour be modified at the runtime/user/Makefile level? Cheers, John -- 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/
execvp error:cygwin+make+busybox
Hello, Attempting to cross-compile Busybox 1.00 under Cygwin (1.5.16-1) I am hitting an error similar to one previously reported on the Cygwin list (Jan 05): http://www.cygwin.com/ml/cygwin/2005-01/msg00657.html No resolution was posted to the list at that time. The busybox Makefile attempts to run the host CC (gcc in this case) to build some setup/config tools, as well as spawning a shell script to do a bit of preparatory work. This is before any cross-compiling begins. Make reports the following error: gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep /cygdrive/e/cygwin-uclinux/uClinux-dist/user/busybox/scripts/mkdep.c make[3]: execvp: gcc: Invalid argument make[3]: *** [scripts/mkdep] Error 127 The problem occurs with Make versions 3.79.1 and 3.80 (haven't tested any earlier versions) The Makefile fragment which fails looks like this: scripts/mkdep: $(top_srcdir)/scripts/mkdep.c $(HOSTCC) $(HOSTCFLAGS) -o $@ $ HOSTCC and HOSTCFLAGS can be deduced from above output, but there's nothing exotic in there. Another fragment which fails is this: .config.mkconfig: $(ROOTDIR)/config/.config sh ./mkconfig .config.tmp This fragment fails with: make[3]: execvp: sh: Invalid argument If executed directly from the commandline, these commands complete fine - it's only when spawning from within the Makefile. cygcheck output is attached. Any insights into the nature and possible solution of this problem would be greatly appreciated. Thanks, John Cygwin Configuration Diagnostics Current System Time: Tue May 03 10:26:33 2005 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: c:\xilinx\edk7.1\cygwin\usr\local\bin c:\xilinx\edk7.1\cygwin\bin c:\xilinx\edk7.1\cygwin\bin c:\xilinx\edk7.1\cygwin\bin c:\xilinx\edk7.1\bin\nt c:\xilinx\edk7.1\gnu\powerpc-eabi\nt\bin c:\xilinx\edk7.1\gnu\microblaze\nt\bin c:\xilinx\edk7.1\bin\nt e:\Nutc\bin e:\Nutc\bin\X11 e:\Nutc\mksnt c:\EDK\bin\nt c:\EDK\gnu\microblaze\nt\bin c:\EDK\gnu\powerpc-eabi\nt\bin c:\WINDOWS\SYSTEM32 c:\WINDOWS c:\WINDOWS\SYSTEM32\WBEM c:\PROGRAM FILES\SUPPORT TOOLS\ c:\PROGRAM FILES\J2SDK1.4.0\BIN c:\PROGRAM FILES\J2SDK1.4.0\JRE\BIN e:\Mentor\WG2002\LICENS~1 c:\matlab6p5p1\bin\win32 c:\Xilinx\ise7.1\bin\nt c:\program files\winrsync\support e:\Mentor\WG2002\vbsa\BIN c:\Program Files\SSH Communications Security\SSH Secure Shell h:\usr\bin Output from c:\xilinx\edk7.1\cygwin\bin\id.exe (nontsec) UID: 400(jwilliams) GID: 401(mkpasswd) 0(root) 544(Administrators) 545(Users) 401(mkpasswd) Output from c:\xilinx\edk7.1\cygwin\bin\id.exe (ntsec) UID: 400(jwilliams) GID: 401(mkpasswd) 0(root) 544(Administrators) 545(Users) 401(mkpasswd) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS HOME = `H:\' MAKE_MODE = `unix' PWD = `/cygdrive/e/cygwin-uclinux' USER = `jwilliams' Use `-r' to scan registry c: hd NTFS 20481Mb 91% CP CS UN PA FC e: hd FAT32 8110Mb 80% CPUN NEW VOLUME g: net NTFS 16553Mb 13% CP CS groups h: net NTFS 1048432Mb 84% CP CS jwilliams s: net NTFS 74433Mb 99% CP CS UN PA FC software z: net NTFS 29533Mb 97% CP CSPAjwilliam c:\xilinx\edk7.1\cygwin / userbinmode c:\xilinx\edk7.1\cygwin/bin /usr/bin userbinmode c:\xilinx\edk7.1\cygwin/lib /usr/lib userbinmode ./cygdrive userbinmode,cygdrive Found: c:\xilinx\edk7.1\cygwin\bin\awk.exe Found: c:\xilinx\edk7.1\cygwin\bin\bash.exe Found: c:\xilinx\edk7.1\cygwin\bin\cat.exe Found: c:\xilinx\edk7.1\cygwin\bin\cp.exe Found: c:\xilinx\edk7.1\cygwin\bin\cpp.exe Found: c:\xilinx\edk7.1\cygwin\bin\find.exe Found: c:\xilinx\edk7.1\cygwin\bin\gcc.exe Not Found: gdb Found: c:\xilinx\edk7.1\cygwin\bin\grep.exe Found: c:\xilinx\edk7.1\cygwin\bin\ld.exe Found: c:\xilinx\edk7.1\cygwin\bin\ls.exe Found: c:\xilinx\edk7.1\cygwin\bin\make.exe Found: c:\xilinx\edk7.1\cygwin\bin\mv.exe Found: c:\xilinx\edk7.1\cygwin\bin\rm.exe Found: c:\xilinx\edk7.1\cygwin\bin\sed.exe Found: c:\xilinx\edk7.1\cygwin\bin\sh.exe Found: c:\xilinx\edk7.1\cygwin\bin\tar.exe 55k 2004/09/14 c:\xilinx\edk7.1\cygwin\bin\cygbz2-1.dll 18k 2004/07/06 c:\xilinx\edk7.1\cygwin\bin\cygcharset-1.dll 7k 2003/10/19 c:\xilinx\edk7.1\cygwin\bin\cygcrypt-0.dll 895k 2004/04/28 c:\xilinx\edk7.1\cygwin\bin\cygdb-4.2.dll 1156k 2004/04/28 c:\xilinx\edk7.1\cygwin\bin\cygdb_cxx-4.2.dll 174k 2004/10/14 c:\xilinx\edk7.1\cygwin\bin\cygexpat-0.dll 40k 2004/10/10 c:\xilinx\edk7.1\cygwin\bin\cygform-8.dll 45k 2001/04/25 c:\xilinx\edk7.1\cygwin\bin\cygform5.dll 35k 2002/01/09 c:\xilinx\edk7.1\cygwin\bin\cygform6.dll 48k 2003/08/09 c:\xilinx\edk7.1\cygwin\bin\cygform7.dll 28k
Problem with home installation
I have been using cygwin at work for almost a year now and haven't had a single problem with it. Now, I want to work from home on occasion, so I am trying to duplicate my work environment at home. Both machines have Win XP. The installation at home seemed to go just fine, but when I open a cygwin shell, I get a bash-2.05b$ prompt and the only commands that work are cd and pwd. ls doesn't even work. Has anyone seen something crazy like this? Any thoughts on what I could try to debug this problem? Thanx-John -- 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: Bug in Cygwin bash?
friedman_hill ernest j wrote: I think John Williams wrote: It seems not many people build linux kernels under cygwin - I think if they did, this issue I've found would have been reported earlier, because it's the first step in the kernel configuration process. OK, I've gotta ask -- WHY do you want to do this in the first place? Porting uClinux to an embedded target, the toolchain for which runs under Cygwin. I agree it would be somewhat perverse to build an i386 linux kernel under Cygwin! Cheers, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Binary patch tool?
Hi folks, Is there a binary equivalent to the diff/patch combination? I've written a little shell script to run cmp -b over a bunch of files (I'm trying to generate binary patches), but now I'm struggling with a way to actually apply those changes. I started writing a little tcl script to do it but think there must be a better way? Thanks, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Binary patch tool?
Igor Pechtchanski wrote: On Fri, 4 Apr 2003, John Williams wrote: Hi folks, Is there a binary equivalent to the diff/patch combination? I've written a little shell script to run cmp -b over a bunch of files (I'm trying to generate binary patches), but now I'm struggling with a way to actually apply those changes. I started writing a little tcl script to do it but think there must be a better way? Thanks, John Umm, vim -b? vim *can* be used as a stream editor... Igor Ah yes excellent! Even better, now I don't need to create a patch file. In a single line I can hack Xilinx's Xygwin tools over to Cygwin. I'm doing the following for f in $( find edk -name '*.exe' -o -name '*.dll' ) do vim -b -s xyg2cyg.sed $f done where xyg2cyg.sed contains :%s/xygwin1.dll/cygwin1.dll/g :wq Is there a way I can pass these on the command line, without needing a seperate little script file like this? Thanks, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Binary patch tool?
Igor Pechtchanski wrote: Is there a way I can pass these on the command line, without needing a seperate little script file like this? Sure. The easiest for you would probably be vim -b -c :%s/xygwin1.dll/cygwin1.dll/g|:wq $f Ain't vim grand? ;-) Indeed. But not just vim, the whole thing. I guess the goal of a true hacker is to accomplish everything on a single command line. It begs the question, is there anything that *can't* be done in a single Un*x command line?! :) John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Bug in Cygwin bash?
Hi folks, I've found a bizarro error that may in fact relate to Cygwin/bash. I'm using the latest version (ran setup and refreshed just yesterday). In the linux kernel configuration process, there is a rule in /linux-2.4.x/makefile that looks like this: dep-files: scripts/mkdep -- `find .` .hdepend The find command returns a huge list of header files, from which dependencies are derived. After some digging I've found that it fails when the length of the string returned by `find...` exceeds about 32K characters. It doesn't seem to matter how many file names are returned, just the total length of the string that contains them all. This may be a bug in the mkdep utility, but I suspect more that it might be a limitation in Cygwin or bash. Is there some fundamental limitation to the length of the argv[] array when launching programs under Cygwin/bash? I created a workaround by doing dep-files: rm -f .hdepend find | xargs scripts/mkdep -- .hdepend But this means I need to patch over the standard linux build distribution before doing anything under Cygwin. Can anyone confirm or deny?! :) Cheers, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in Cygwin bash?
Randall R Schulz wrote: John, Yes, there's a limitation on the total volume of argument strings. All Unix systems have such a limit and so does Cygwin. The limits vary from system to system, though POSIX dictates a minimum value for this limit. Anybody know the standard Cygwin limit off the top of their head? I'm guessing 32K, given what I saw with mkdep For cases where the total list of files can be processed in pieces, the xargs command will do the divvying up for you, invoking the command as many times as needed to process all the arguments it reads from standard input. Check it out--it should be in your script-writing repertoire. Yup - I used xargs in my solution to this problem. It seems not many people build linux kernels under cygwin - I think if they did, this issue I've found would have been reported earlier, because it's the first step in the kernel configuration process. Thanks for your reply, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in Cygwin bash?
Randall R Schulz wrote: John, Are you a famous composer? If so, are you _the_ famous composer? No, and nor am I the famous and very talented classical guitarist. I have two guitars, but I can't play either of them :O -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in Cygwin bash?
Hi Sam, I've ported uClinux to a new reconfigurable softcore microprocessor. The gcc toolchain for this little beastie runs under Cygwin (well, actually something called Xygwin, but that's another story entirely).. For the record, I've built a couple of bootable kernels under Cygwin. Yes, I ran into the bash command line problem/ xargs solution, but never got around to submitting a patch - my apologies, John, for not saving you some small amount of pain by doing so :-/ Ah that's ok, it's all good practice. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc/Cygwin awareness
Hi Max, Max Bowsher wrote: John Williams wrote: Elfyn McBratney wrote: You could use this #if defined(__GNUC__) defined(__CYGWIN__) So __CYGWIN__ is defined in the preprocessor environment when compiling under Cygwin? That's precisely what I'm after, thanks. General answer to this kind of question: $ gcc -E -dM -xc /dev/null Excellent. Thanks for that, a useful bit of syntax to remember. John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gcc/Cygwin awareness
Hi folks, Is there a macro defined in gcc when running under Cygwin as opposed to, say, linux? I'd like to code something like #ifdef _GCC_UNDER_CYGWIN blah blah #else blah blah #endif This is to get around the fact that Cygwin doesn't provide the libgen.h header file, which I need to build uClibc for this cross-platform project I'm doing. Thanks, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc/Cygwin awareness
Elfyn McBratney wrote: You could use this #if defined(__GNUC__) defined(__CYGWIN__) So __CYGWIN__ is defined in the preprocessor environment when compiling under Cygwin? That's precisely what I'm after, thanks. John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: file name case sensitivity
Gerald S. Williams wrote: [snip] But as I said, this is OT for Cygwin. Even if it is added to Cygwin, it will almost certainly not be the default behavior. But for people like me trying to maintain Cygwin versions of Unix projects, it could be a real boon. Indeed. In my case, it would require modifications to cygwin's CVS tools, to use these special case sensitive semantics. CVS puking on a sync operation was the first sign that anything was amiss for me. Regards, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: file name case sensitivity
Shankar Unni wrote: Thorsten Kampe wrote: Yes, but in my opinion it could be of use to John Williams because he wanted to case sensitivity in filenames under Cygwin. No, it won't work, because if you remember, he said that he had files with the same name but different case *in the same directory*. That's correct. I tried the check_case hack and it only goes halfway to what I need. uClinux will have to be patched for cygwin support. John: time to start your first set of unofficial cygwin patches for uClinux. I suppose you are right. I haven't even got the port up and running yet, so the last thing I feel like doing right now is creating another parallel branch in the source tree. I'm basically going to ignore this problem for as long as I can, I've got much bigger fish to fry right now. Thanks, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
file name case sensitivity
Hi folks, I see the thread earlier today about this re: gcc - I have a similar question, but not strictly within the context of gcc. I'm building a version of uClinux under Cygwin, and for some reason there are a few places where files exist _in the same directory_ having identical names but differences in capitalisation. For example, /include/linux/netfilter/ipv4/ contains files called ipt_dscp.h and ipt_DSCP.h . There are about 10 examples of this within the uClinux source distribution. The file system in question is a Samba mount from a Solaris machine, and I'm running Cygwin 1.3.20 under WinXP. Is there a way to enable case sensitivity in filenames under Cygwin? At the moment things are not looking too good because Cygwin views these names as equivalent, meaning that which ever one is copied in last overwrites the one before. Cheers, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: file name case sensitivity
Hi Elfyn, No. You can use the check_case option in the CYGWIN environment variable, but that'll only get you half way to what you want. Take a look at (http://cygwin.com/cygwin-ug-net/using-cygwinenv.html) to see how it works and how to use it. Thanks for that. As you predict, check_case can't undo the evil that is causing my problem in the first place. My loathing goes in equal measures to Microsoft for failing after 20 years to support case-sensitive file names, and whomever it was in the linux dev group who decided it would be a good idea to duplicate some files but only change the filename capitalisation... bleughhh... the conspiracy theorist in me wonders if it was deliberate to kybosh those working under Windows... :O Cheers, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Obtaining a pervious version
Hi again, Well a postscript to yesterday's discussion - today I went through all of the Xygwin binary utilities with a hex editor, changed all references of xygwin1.dll - cygwin1.dll, and blow me down if it didn't fix the problems! I don't remember who here suggested it, but anyway, it works. So it's bye-bye Xygwin, and now I can get on with what I really want to be doing! Not clean, not elegant, but it works. Thanks again, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Obtaining a pervious version
Christopher Faylor wrote: On Wed, Feb 19, 2003 at 11:46:24AM +1000, John Williams wrote: Well a postscript to yesterday's discussion - today I went through all of the Xygwin binary utilities with a hex editor, changed all references of xygwin1.dll - cygwin1.dll, and blow me down if it didn't fix the problems! Glad to hear this. I was wondering if there was going to be some niggling detail which would make this infeasible. There may be, but it's obscure enough that I haven't found it yet. It may bite me later, but for now my linux port is back on track. I don't remember who here suggested it, *ahem* :-) Credit where credit's due! Thanks Chris! John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Obtaining a pervious version
Hey folks, Two things - first of all, as of 00:00 GMT Cygwin.com appears to be down. Hope it's nothing too serious. Secondly, can you please tell me how to obtain, via the setup installer, a prior version of the Cygwin base installation? I'm using some 3rd party software tools that were built upon Cygwin 1.3.13, and am having versioning issues when trying to run them under 1.3.20. Setup.exe defaults to downloading and installing the most recent distro, but I need to wind back the clock a couple of versions. Is there a simple way to do this? Thanks, John -- Dr John Williams, Research Fellow, Reconfigurable Computing, School of ITEE University of Queensland, Brisbane, Australia Ph : (07) 3365 8305 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Obtaining a pervious version
Christopher Faylor wrote: On Mon, Feb 17, 2003 at 09:55:26AM +1000, John Williams wrote: Hey folks, Two things - first of all, as of 00:00 GMT Cygwin.com appears to be down. Hope it's nothing too serious. Secondly, can you please tell me how to obtain, via the setup installer, a prior version of the Cygwin base installation? I'm using some 3rd party software tools that were built upon Cygwin 1.3.13, and am having versioning issues when trying to run them under 1.3.20. Um. 3rd party software tools? If you are using software distributed by someone else then *they* should be providing you with both the binary and sources that the software needs. They have a cross compiler that uses the cygwin compatability layer. They have modified and distribute a version of this layer, which is built upon cygwin1.dll version 1.3.13. However, they distribute with their tools only a minimal subset of cygwin necessary for their tools to run. However, in the project I am doing I need not only the 3rd party cross compiler, but also native gcc and binutils etc. However, simply running the 3rd party tools under the current cygwin release does not work (versioning errors), and similarly trying to run cygwin binutils under this 3rd party cut down cygwin doesn't work either (same problem). In any event, 1.3.20 is compatible with 1.3.13 so, you should be all set. Yeah that's what I would have thought, but it doesn't work. I've tried just about every combination I can think of, and it all falls in a heap. We don't have older versions of the DLL available, otherwise. Sorry. Bummer. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Obtaining a pervious version
Max Bowsher wrote:
John Williams wrote:
They have a cross compiler that uses the cygwin compatability layer.
They have modified and distribute a version of this layer, which is
built upon cygwin1.dll version 1.3.13. However, they distribute with
their tools only a minimal subset of cygwin necessary for their tools
to run. However, in the project I am doing I need not only the 3rd
party cross compiler, but also native gcc and binutils etc.
However, simply running the 3rd party tools under the current cygwin
release does not work (versioning errors),
Details?
OK, here it goes. EDK is the 3rd part tool set. They distribute
(binary and source) a modified version of cygwin they call Xygwin (with
xygwin1.dll and so on). I suspect this is part of the problem.
Starting point
?
Fresh install of Cygwin 1.3.20 into c:/cygwin
?
Fresh install of EDK SP3 into c:/EDK
At this stage, the EDK toolchain is in the path for both Xygwin and
Cygwin (i.e. c:/EDK/gnu/powerpc/bin/nt and c:/EDK/gnu/microblaze/bin/nt).
Initial testing
?
EDK/Xygwin works fine
o
Binaries executing from /usr/bin, which maps to c:/EDK/xygwin/bin
?
Cygwin works fine
o
make, gcc, etc
o
Executing from /usr/bin, which is mapped to c:/cygwin/ bin
Running Cygwin binaries from within Xygwin:
?
gcc ? not found
?
Add cygwin bin to the path
o
export PATH=${PATH}:/xygdrive/c/cygwin/bin
?
running gcc results in
o
c:\cygwin\bin\gcc.exe: *** proc version mismatch detected -
xB3836013/0x8E0899FA.
You have multiple copies of cygwin1.dll on your system.
Search for cygwin1.dll using the Windows Start-Find/Search facility and
delete all but the most recent version. The most recent version
*should* reside in x:\cygwin\bin, where 'x' is the drive on which you
have installed the cygwin distribution.
Running EDK binaries from within Cygwin:
?
Running mb-gcc results in a Windows dialog box stating
o
This application has failed to start because xygwin1.dll was not found.
Re-installing the application may fix this problem.
?
Adding xygwin/bin to the path, and re-running gives
o
c:\EDK\gnu\microblaze\nt\bin\mb-gcc.exe: *** proc version mismatch
detected - 0x8E0899FA/0xB3836013.
You have multiple copies of cygwin1.dll on your system.
Search for cygwin1.dll using the Windows Start-Find/Search facility and
delete all but the most recent version. The most recent version
*should* reside in x:\cygwin\bin, where 'x' is the drive on which you
have installed the cygwin distribution.
Clearly, there is a version mismatch between Xygwin and Cygwin 1.3.20.
Checking version info on Xygwin1.dll reveals that Xygwin is built upon
Cygwin v1.3.13. This is the source of the versioning error.
New strategy ? accept the versioning differences, and try to fool
Cygwin/Xygwin into finding the right DLLs. Approach:
?
Copy c:/cywgin/bin/cygwin1.dll ? c:/cygwin/bin/xygwin1.dll, and
?
c:/EDK/xywgin/bin/xygwin1.dll ? c:/EDK/xygwin/bin/cygwin1.dll
(Note that ?cross-copying? cygwin1.dll from cygwin to Xygwin, and
xygwin1.dll to Cygwin, won?t work because of the versioning differences
described above)
After duplicating the DLLs, running mb-gcc inside Cygwin no longer gives
an error message, but instead it fails silently. For example, ?mb-gcc
?c system.c? runs without error, but does not produce system.o.
You asked for details!! If anyone read this far they are a champion.
Thanks,
John
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Obtaining a pervious version
Christopher Faylor wrote: On Mon, Feb 17, 2003 at 10:45:20PM -, Max Bowsher wrote: Compile your own EDK toolchain against Cygwin itself, not Xygwin. Correct. I don't suppose you'd be willing to make the modified sources available, would you? I'm interested in what these people have done to cygwin. Christopher, Can I please discuss this with you privately? Email to [EMAIL PROTECTED] bounced. Regards, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Obtaining a pervious version
Max Bowsher wrote: OK, *now* its pretty obvious what the problem is. Cygwin 1.3.20 is backward compatible with Cygwin 1.3.13, but Cygwin is not and never will be sideways compatible with other slightly modified versions of Cygwin. Compile your own EDK toolchain against Cygwin itself, not Xygwin. So it seems. I've got to exhaust all other options before I commit to that effort. Thanks for your help and patience. John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Obtaining a pervious version
Christopher Faylor wrote: On Mon, Feb 17, 2003 at 10:45:20PM -, Max Bowsher wrote: Compile your own EDK toolchain against Cygwin itself, not Xygwin. Correct. I don't suppose you'd be willing to make the modified sources available, would you? I'm interested in what these people have done to cygwin. Christopher, Can I please discuss this with you privately? Thanks, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Obtaining a pervious version
Max Bowsher wrote: John Williams wrote: Max Bowsher wrote: OK, *now* its pretty obvious what the problem is. Cygwin 1.3.20 is backward compatible with Cygwin 1.3.13, but Cygwin is not and never will be sideways compatible with other slightly modified versions of Cygwin. Compile your own EDK toolchain against Cygwin itself, not Xygwin. So it seems. I've got to exhaust all other options before I commit to that effort. OK, so it's not going to be really easy, but it probably isn't going to be nightmarishly hard either. Somewhere between heaven and hell! I gather actually that this Xygwin environment doesn't do much more than fiddle with some of the path mapping stuff. Certainly no rocket science going on in there - I think the tool providor's desire was to spare their customers from a full cygwin install, and to lock in a stable distro to minimise support calls arising from factors outside their control. This is all just my conjecture. Regards, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Obtaining a pervious version
Christopher Faylor wrote: Ok. This version just changes the name of the DLL from cygwin1.dll to xygwin1.dll. What surprises me though is that if I duplicate xygwin1.dll to cygwin1.dll, it doesn't work??? Am I missing something here? Cheers, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Obtaining a pervious version
Larry Hall (RFK Partners, Inc.) wrote: What doesn't work? The Cygwin provided utilities or the Xygwin1 versions? Neither. I can't run either Cygwin utilities under Xygwin, nor the Xygwin utilities under Cygwin. Full error messages were posted earlier in the thread. I wouldn't necessarily expect the Cygwin utilities to work in this situation, since they may be using something in the newer cygwin1.dll. Hence my original question about winding back the clock. I suppose you could always use strace if this doesn't answer the it doesn't work question. Good tip. Thanks, I'll give it a try. Cheers, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Obtaining a pervious version
Hey everyone, Thanks all for your input and comments on this thread. If nothing else I've learned a little more about the mechanics of Cygwin, which can't be a bad thing. I have re-assessed my needs and decided I am, in fact, better off running with Cygwin and Xygwin side-by-side, completely independent of each other. Where I need cygwin utils, I'll run them under Cygwin, and likewise for Xygwin. It shouldn't matter for my end product. In case anybody's interested, I'm porting linux to Xilinx's soft-core embedded processor. I'll run the kernel configuration and dependency generation tools under Cygwin using native x86 gcc and bin-utils, then switch to Xygwin to do the cross compilation. I realise this is not ideal, nor is it a particularly clean or elegant solution. I will pass on some of the comments made here to the Xygwin developer, and see if they are interested in beefing up their version to make it more compliant. However, since they are just doing it to provide a basic support layer to their gcc cross-compiler, it is unlikely to be a priority for them. I can understand that, and certainly won't be badgering them about it. One point I have raised is if they really need Xygwin at all, or if they could just build their tools under standard cygwin. We'll see what comes of it. Thanks again, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Obtaining a pervious version
Christopher Faylor wrote: The sources available for download are for 1.3.2. The differences are below. Basically, it seems like they made a few changes without really thinking too hard about what they did. So, the cygwin mount table will be found in another registry entry but it will end up in the same shared memory region. Reading further in the thread, I see that there was an accommodation of sorts. I want to point out that it should be possible to build any of the tools that you're using under cygwin. IMO, that's the best solution to this. In fact, it should be possible to just binary edit the tools and change the 'xygwin1.dll' to 'cygwin1.dll'. Then you can just get rid of the xygwin1.dll crap entirely. Thanks for that - I'll pass it on to the developers. I expect they'd probably rather focus on supporting their tools anyway, instead of a non-standard compatibility layer. Cheers, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
