Re: How do I get an old version of cygwin?
On Thu, 2005-01-20 at 11:07 +0100, Corinna Vinschen wrote: On Jan 20 09:47, Adrian Cox wrote: It would be useful if there was a forum for people who distribute cygwin1.dll along with an application. I'm not very interested in the whole Cygwin distribution, and I'm going to end up maintaining an in-house fork of the code to solve my problems. I doubt I'm the only one doing this, and I'll happily take it to a more appropriate list. But you're aware that you have to release the DLL and depending applications under the GPL, with all sources, aren't you? No problem at all. My application is a GCC cross-compiler used as a code generator behind a Windows front-end. -- Adrian Cox [EMAIL PROTECTED] -- 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: How do I get an old version of cygwin?
On Wed, 2005-01-19 at 10:06 -0800, Yitzchak Scott-Thoennes wrote: Gets kind of old to hear this debated over and over again when it's clear that the developers are not interested in the work involved. Time for a cygwin-multi-versions (moderated?) list? cygwin-licensing was very successful at reducing the licensing traffic (both here and there). It would be useful if there was a forum for people who distribute cygwin1.dll along with an application. I'm not very interested in the whole Cygwin distribution, and I'm going to end up maintaining an in-house fork of the code to solve my problems. I doubt I'm the only one doing this, and I'll happily take it to a more appropriate list. I'm even prepared to host the list myself if there's demand. If anybody else does need to do this sort of thing, mail me off list. -- Adrian Cox [EMAIL PROTECTED] -- 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: How do I get an old version of cygwin?
On Tue, 2005-01-18 at 09:51 -0500, Christopher Faylor wrote: On Tue, Jan 18, 2005 at 08:41:51AM +, Adrian Cox wrote: Have you considered building a custom version of the latest Cygwin, and putting it on their box in a different directory? Trying to solve this sort of problem is unpopular on this list, but my initial research suggests that changing the values of CYGWIN_VERSION_DLL_IDENTIFIER and CYGWIN_INFO_CYGNUS_REGISTRY_NAME should do the job. You really shouldn't be giving out advice to people without understanding what the problems are. You don't even know why this person needs to hve an older version of cygwin. Immediately jumping to the conclusion that they just need to mess with things in the source and recompile is not good advice. Because it is extremely common to distribute an application along with the correct version of the support packages. If I distribute a Windows application which uses perl, I want to distribute a tested working perl interpreter in the same package. If I distribute a Windows application using Cygwin, I want to distribute a tested working Cygwin DLL in the same package. Disk space and bandwidth are so cheap they're almost free. Testing takes time. These people already have one tested and working application on an old version of Cygwin. Now they want to run a second application validated against a newer version of Cygwin. As far as I can see Cygwin has been deliberately designed to make this difficult. -- Adrian Cox [EMAIL PROTECTED] -- 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: How do I get an old version of cygwin?
On Mon, 2005-01-17 at 15:11 -0800, James M. Rogers wrote: My company has a small program that we use to pull data from files on multiple OSes. We use the latest version of cygwin on our own internal computers to run under windows systems and this works fine. However, one of our clients has an old version of cygwin that uses the 1.5.4 DLL. This is a DLL on a production box over which we have no control. The client themselves just installs the product from another vendor and it just works. This is not a full version of the cygwin install. There are no build tools on this box. Have you considered building a custom version of the latest Cygwin, and putting it on their box in a different directory? Trying to solve this sort of problem is unpopular on this list, but my initial research suggests that changing the values of CYGWIN_VERSION_DLL_IDENTIFIER and CYGWIN_INFO_CYGNUS_REGISTRY_NAME should do the job. -- Adrian Cox [EMAIL PROTECTED] -- 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: Multiple installations and 3PPs
On Sat, 2005-01-15 at 19:42 -0500, Arturus Magi wrote: Adrian Cox wrote: So what are the other problems? Programs picking up the wrong version of the DLL and failing with little or no explanation available to the user (whom will, likely as not, fail to provide a useful report to the developer, if they bother to report it at all), for one. I know that with current Cygwin both instances will open the same shared memory region but expect a different format of the contents. That's why I proposed making each cygwin1.dll derive the name of the shared memory region from its native WIN32 path. I'm interested in failures that would still occur if the two cygwin DLLs used different shared memory regions and registry keys. -- Adrian Cox [EMAIL PROTECTED] -- 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: update on hyperthreading system for cgf
On Thu, 2005-01-13 at 19:58 -0500, Christopher Faylor wrote: This is still pretty far off from the goal but I would still appreciate it if anyone could recommend a cheap system which demonstrates the problem. So far, I don't recall anyone giving specific details about a name brand computer or a specific motherboard. If I start getting names I can start doing research on the best place to purchase a system. I just put together a machine with an Intel D865PERL motherboard and 3.0GHz P4 (1MB cache, 800MHz bus), PC3200 RAM on two banks. It shows the bug within minutes when running XP Pro. The same machine runs the test case for a very long time without incident under Windows 2000. -- Adrian Cox [EMAIL PROTECTED] -- 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/
Multiple installations and 3PPs
Multiple installations of Cygwin clash, both over the registry name used for the mount table and the name of the shared memory region. This makes it difficult to have several versions for testing purposes, and causes problems with software from 3PPs. Has anybody considered using PSAPI to find the full path to cygwin1.dll, and using a hash of this path as the name of the shared memory region and of the registry key? (I couldn't find anything with Google, but cygwin-developers isn't indexed). Win98 would have to fall back to the old name, but this could allow multiple installations to remain independent of each other on NT based windows. -- Adrian Cox [EMAIL PROTECTED] -- 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: Multiple installations and 3PPs
On Fri, 2005-01-14 at 12:15 -0500, Christopher Faylor wrote: On Fri, Jan 14, 2005 at 04:50:03PM +, Adrian Cox wrote: Multiple installations of Cygwin clash, both over the registry name used for the mount table and the name of the shared memory region. This makes it difficult to have several versions for testing purposes, and causes problems with software from 3PPs. I don't know what 3PPs (third party providers?) might be but there is only supposed to be one version of cygwin1.dll in use on your computer at a time. The DLL even issues a rather verbose error when it detects two versions running. Sorry, just trying to speak the local language: http://cygwin.com/acronyms/#3PP I don't understand why it is a goal to have only one version of cygwin1.dll in use at a single time. I'd like to create separate Cygwin universes, with no communication between them except via IP networking. Has anybody considered using PSAPI to find the full path to cygwin1.dll, and using a hash of this path as the name of the shared memory region and of the registry key? This is rather like asking Has anyone found a way to put sound deadening foam over the little thing that chimes when you're not wearing your seatbelt? The warnings are there for a reason, not because we couldn't figure out how to name the shared memory region to avoid clashes. The problem isn't as simple as trying to avoid shared memory clashes. So what are the other problems? Is there any other way the processes could become aware of each other's existence, except for making native Win32 calls? [...] (I couldn't find anything with Google, but cygwin-developers isn't indexed). That's because cygwin-developers is a private mailing list. Which is why people like me have to ask so many questions. -- Adrian Cox [EMAIL PROTECTED] -- 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: Hyperthreading Problem - suggestion
On Mon, 2005-01-10 at 12:20 -0500, Christopher Faylor wrote: The last time I tried to duplicate the problem, I ran a test for three days, tying up a machine that I use for other purposes. I'd previously tried other variations as well. The system is an SMP system so there should have been a good chance of duplicating the bug. I'm not going to try every variation of this problem when it shows up on the list. Just a quick observation and a question. Hyperthreading exposed a race condition in an NT driver of mine that had run for a long time on an SMP system. The timing is different. Is there anybody out there who has Windows XP and hyperthreading and _can't_ reproduce the problem? This is making me nervous about a project I'm planning, as most of the target machines will be P4s with hyperthreading running XP. -- Adrian Cox [EMAIL PROTECTED] -- 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: Rebuilding GDB
On Mon, 2004-09-20 at 18:14, Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of Adrian Cox Sent: 20 September 2004 14:44 I'm trying to build a Cygwin hosted GDB for debugging ARM and PowerPC boards. After running into a lot of problems, I tried to rebuild the native GDB that Cygwin installed for me, and that didn't work either. BTW, when discussing compile problems with gnu packages, you should always quote the options you gave to configure (if any). 1) Use setup.exe to download the gdb source. 2) mkdir /tmp/build 3) cd /tmp/build 4) /usr/src/gdb-20030919-1/configure --prefix=/usr/local/test 5) make make[3]: Entering directory `/tmp/inbuild/libgui/src' gcc -DHAVE_CONFIG_H -I. -I/usr/src/gdb-20030919-1/libgui/src -I.. -DWIN32 -mwin3 2 -fwritable-strings -I/usr/include -I/usr/include -I/netrel/src/libtcltk/tk/xl ib -DHAVE_NO_SEH=1 -DEXCEPTION_DISPOSITION=int -I/usr/include/../unix -I/usr/ include/../win -DTBL_VERSION=\2.7\ -DTBL_COMMAND=\table\ -DTBL_RUNTIME=\tkT able.tcl\ -DTBL_RUNTIME_DIR=\/usr/local/insight/share/redhat/gui\ -DSTATIC_BU ILD-g -O2 -c /usr/src/gdb-20030919-1/libgui/src/tclwinprint.c /usr/src/gdb-20030919-1/libgui/src/tclwinprint.c:26:22: tkWinInt.h: No such file or directory Hmm. It should be in the source distribution itself, at /usr/src/gdb-20030919-1/tk/win. ls /usr/src/gdb-20030919-1/tk ls: /usr/src/gdb-20030919-1/tk: No such file or directory [...] Ok, so your one has this strange include path to /netrel/src/libtcltk/tk/xlib which my one doesn't. Looks like maybe you have an older version of the tcl/tk headers in your installation and somehow it got chosen at configure time over the ones included with the gdb source distro? Also, there really shouldn't be all those -I /usr/includes in there. And what on earth are /usr/include/../win and /usr/include/../unix? Maybe configure has somehow failed to find something and is using /usr/include as a default, no-hope-last-chance fallback; and then bogusly concatenating relative paths onto it that would have been relevant if it had found the real headers but make no sense when just hoping they're in the standard system includes dir. Yech. I've just had a second go at downloading with setup.exe, and the tk directory is still missing. This makes me think that the bug is really in setup.exe or in the Cygwin repository. I haven't really worked out how Cygwin packages work yet - should each source package contain a build script, like Redhat or Debian packages do? - Adrian Cox -- 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/
Rebuilding GDB
I'm trying to build a Cygwin hosted GDB for debugging ARM and PowerPC boards. After running into a lot of problems, I tried to rebuild the native GDB that Cygwin installed for me, and that didn't work either. I'm up to date with Cygwin setup, and running on Win2k SP4. Below is the end of the build where everything goes wrong: make[3]: Entering directory `/tmp/inbuild/libgui/src' gcc -DHAVE_CONFIG_H -I. -I/usr/src/gdb-20030919-1/libgui/src -I.. -DWIN32 -mwin3 2 -fwritable-strings -I/usr/include -I/usr/include -I/netrel/src/libtcltk/tk/xl ib -DHAVE_NO_SEH=1 -DEXCEPTION_DISPOSITION=int -I/usr/include/../unix -I/usr/ include/../win -DTBL_VERSION=\2.7\ -DTBL_COMMAND=\table\ -DTBL_RUNTIME=\tkT able.tcl\ -DTBL_RUNTIME_DIR=\/usr/local/insight/share/redhat/gui\ -DSTATIC_BU ILD-g -O2 -c /usr/src/gdb-20030919-1/libgui/src/tclwinprint.c /usr/src/gdb-20030919-1/libgui/src/tclwinprint.c:26:22: tkWinInt.h: No such file or directory /usr/src/gdb-20030919-1/libgui/src/tclwinprint.c: In function `winprint_page_set up_command': /usr/src/gdb-20030919-1/libgui/src/tclwinprint.c:187: warning: assignment makes pointer from integer without a cast /usr/src/gdb-20030919-1/libgui/src/tclwinprint.c: In function `winprint_print_te xt_dialog': /usr/src/gdb-20030919-1/libgui/src/tclwinprint.c:360: warning: assignment makes pointer from integer without a cast /usr/src/gdb-20030919-1/libgui/src/tclwinprint.c: At top level: /usr/src/gdb-20030919-1/libgui/src/tclwinprint.c:905: warning: initialization fr om incompatible pointer type /usr/src/gdb-20030919-1/libgui/src/tclwinprint.c:906: warning: initialization fr om incompatible pointer type /usr/src/gdb-20030919-1/libgui/src/tclwinprint.c:907: warning: initialization fr om incompatible pointer type /usr/src/gdb-20030919-1/libgui/src/tclwinprint.c:908: warning: initialization fr om incompatible pointer type make[3]: *** [tclwinprint.o] Error 1 Where should tkWinInt.h come from? I've got other Tcl/Tk header files in /usr/include, but I'm missing this one. - Adrian Cox Humboldt Solutions Ltd. Cygwin Configuration Diagnostics Current System Time: Mon Sep 20 14:45:16 2004 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\WINNT\system32 c:\WINNT c:\WINNT\System32\Wbem Output from C:\cygwin\bin\id.exe (nontsec) UID: 500(Administrator) GID: 513(None) 513(None) Output from C:\cygwin\bin\id.exe (ntsec) UID: 500(Administrator) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINNT\system32 WinDir: C:\WINNT HOME = `C:\cygwin\home\Administrator' MAKE_MODE = `unix' PWD = `/home/Administrator' USER = `Administrator' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\Administrator\Application Data' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `FROG' COMSPEC = `C:\WINNT\system32\cmd.exe' CVS_RSH = `/bin/ssh' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\Administrator' HOSTNAME = `frog' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' LOGONSERVER = `\\FROG' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man' NUMBER_OF_PROCESSORS = `2' OLDPWD = `/usr/bin' OS2LIBPATH = `C:\WINNT\system32\os2\dll;' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig' PRINTER = `\\http://newt.humboldt.co.uk:631\Kyocera FS-600' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 3, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0803' PROGRAMFILES = `C:\Program Files' PROMPT = `$P$G' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINNT' TEMP = `C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp' TERM = `cygwin' TMP = `C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp' USERDOMAIN = `FROG' USERNAME = `Administrator' USERPROFILE = `C:\Documents and Settings\Administrator' WINDIR = `C:\WINNT' _ = `/usr/bin/cygcheck' POSIXLY_CORRECT = `1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/home/adrian (default) = `h:' flags = 0x010a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a
