Re: Updated [experimental]: {emacs,emacs-X11,emacs-el}-23.2-2
Ken Brown writes: >> Now that that's fixed, it still says: >> >>This is GNU Emacs 23.2.1 >>of 2010-08-16 >> >> I assume that's the new version, why does it still say 23.2.1? > > The '.1' at the end is added by Emacs. I don't know why. This has > nothing to do with the fact that from Cygwin's point of view, it's > release -2 of the emacs-23.2 package. Every time you compile a new Emacs binary, the minor release version is increased by 1, it is a compilation counter. Existing binaries are not overwritten, you could have emacs-23.2.1, emacs-23.2.2 etc in parallel. During extensive development phases, I have had more than 100 compiled binaries in parallel :-) Once you apply `make bootstrap', all binaries are removed, and counting restarts with 1. > Ken Best regards, Michael. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Emacs and DBUS
Ken Brown writes: >> This is also a D-Bus client, which connects to the *same* session bus as >> Emacs did due to $DBUS_SESSION_BUS_ADDRESS. Now you should see the >> signal sent by dbus-monitor in Emacs. > > OK, I started the session bus the right way this time, but I still > didn't see any signal from dbus-monitor in Emacs. I assume I should > have seen something in the echo area? Yes. You could test whether both Emacs and dbus-monitor use the same bus by reordering the calls: - apply dbus-launch as described - echo $DBUS_SESSION_BUS_ADDRESS - in *another* shell, set $DBUS_SESSION_BUS_ADDRESS to this value, and start dbus-monitor - start Emacs in the first shell, and load dbus.el. You shall see in the other shell output from dbus-monitor, telling that an application has started. It will also tell you the name of that application, like ":1.2". - apply (dbus-get-unique-name :session) in Emacs. The result shall be the same name. - start dbus-monitor in the same shell as Emacs. In the other dbus-monitor, you should be notified, that an application has been started. >> Maybe you can compile dbusbind.c with the compiler flag DBUS_DEBUG, >> something like this in the Emacs source tree: >> >> # MYCPPFLAGS='-DDBUS_DEBUG' make >> >> This enables test traces sent to Emacs' stdout (the shell where you have >> started it). I've introduced this flag while testing dbusbind.c, when it >> has blocked Emacs, and I didn't want to start gdb ... >> >> Maybe I can see something suspicious in the traces. > > There's very little there. It prints the two lines > > xd_add_watch: fd 8 > xd_add_watch: fd 9 > > and no more. Does this tell you anything? It's the initialization phase. Two watch functions are installed on file descriptors 8 and 9 (connected to the system and session buses), polling for incoming messages in Emacs' mainloop. When you call dbus-get-unique-name, there shall be more output. But this works, as you have confirmed, so this is not the interesting case. I've hoped to see more :-( Did you play with the running/non-running system bus? Anyway, I need to debug when I'm back. > Ken Best regards, Michael. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SEGV in gcc 4.3.4 on cygwin 1.7.6-1
2010/8/27 Eirik Nordbrøden : > Hello > > I have been trying to build Net-SNMP on cygwin/Windows XP. When I start > compiling gcc (4.3.4) crashes with a segmentation fault. It is the following > command that crashes: > > gcc -I../include -I. -I../snmplib -I/usr/include -g -Wall -Ucygwin > -Dcygwin=cygwin -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing > -pipe -fstack-protector -I/usr/local/include > -I/usr/lib/perl5/5.10/i686-cygwin/CORE -Wall -Wstrict-prototypes > -Wwrite-strings -Wcast-qual -c test_segv.c -o test_segv.o > It crashes even if the file does not actually exist. You could try losing -pipe. Perhaps tweaking the configuration of cpan would help. How odd. It seems to crash only with that exact number of parameters. Try convincing the makefile generator to add another option (e.g. -pedantic or -W) -- Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How/Where do I get an older version of Cygwin?
Am 26.08.2010 21:41, schrieb Blaine Miller: > Again, I agree. I'm between a rock and a hard place here. I have to > prove it's not the current version of Cygwin (also read *free*) and new > hardware (read *costs them some money*). > > I have related to you and others at Cygwin user list both of my issues > of cron possibly causing a system fault and can't kill the ssmtp > dead.letter running over. Does it have to be ssmtp? How about Exim? Works for me without exploding dead.letter files. You can have cron logging to syslog-ng, and suppress cron's sending mail from the crontab, if that helps. -- Matthias Andree -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: problem with dblatex
Oh, I'm stupid, yes, texlive2007 is in my path... The problem is: I can't modify this path, only the administrator has access to it. Is there a solution to tell cygwin to not use texlive version of pdflatex? david 2010/8/26 David Hajage : > Hello, > I have a fresh install of cygwin and I am trying to use dblatex (I > should also say that I am a new user of cygwin). > I have installed dblatex and tetex, but: > - first, with dblatex: > > BEGIN > dhajage $ dblatex essai.xml > /usr/lib/python2.6/site-packages/dbtexmf/dblatex/grubber/util.py:8: > > DeprecationW > arning: the md5 module is deprecated; use hashlib instead > import md5 > Build the book set list... > Build the listings... > XSLT stylesheets DocBook - LaTeX 2e (0.3) > === > Build essai.pdf > cygwin warning: > MS-DOS style path detected: \TeXLive2007\texmf-var\web2c > Preferred POSIX equivalent is: /cygdrive/c/TeXLive2007/texmf-var/ > web2c > CYGWIN environment variable option "nodosfilewarning" turns off this > warning. > Consult the user's guide for more details about POSIX paths: > http://cygwin.com/cygwin-ug-net/using.html#using-pathnames > This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) > kpathsea: Running mktexfmt pdflatex.fmt > /bin/mktexfmt: line 333: /texconfig/tcfmgr: No such file or directory > fmtutil: config file `fmtutil.cnf' not found. > I can't find the format file `pdflatex.fmt'! > pdflatex failed > Could not run pdflatex. > Unexpected error occured > END > > - with pdflatex > > BEGIN > dhajage $ pdflatex essai.tex > This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) > kpathsea: Running mktexfmt pdflatex.fmt > /bin/mktexfmt: line 333: /texconfig/tcfmgr: No such file or directory > fmtutil: config file `fmtutil.cnf' not found. > I can't find the format file `pdflatex.fmt'! > END > > What could be the problem of my installation? Is there any special > configuration for pdflatex? > > Thank you very much for any help. > > david > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: problem with dblatex
On Fri, Aug 27, 2010 at 10:46 AM, David Hajage wrote: > Is there a solution to tell cygwin to not use texlive > version of pdflatex? Put this in your .bashrc: PATH=`echo $PATH | tr ":" "\n" | grep -v texlive2007 | tr "\n" ":" Note1: substitute "texlive2007" above with the proper directory name (not path) -- Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
setup hangs at perl-min
I find during a brand new install of "All" that setup hangs at perl-ming; the reason for this is that both bzips (curr and prev) release\ming\perl-ming\perl-ming-0.4.3-[12].tar.bz2 contain tars perl-ming-0.4.3-[12].tar that contain files at usr\share\man\man3\ whose names include the string "::", not liked by Windows. Can this difficulty be addressed by renaming the files? (I don't actually need or use these files, but the glitch in setup is a headache. Possibly relevant that I still use XP on FAT32 not e.g. W7 on NTFS; but this finding is for the current Cygwin 1.7 (not 1.5 where there is no such problem).) Thank you, Fergus -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
setup.exe crashes when downgrading gcc4
Hello, I've installed version 4.5.0 of gcc4-core, gcc4-g++ and libgcc1. Now I would like to uninstall these packages or go back to version 4.3.4. There is no possibility to uninstall these packages, when cycling in setup.exe, there are these possibilities: - 4.3.4-3 - source - 4.3.4-1 - keep So I select "4.3.4-3", and then "next". Then setup.exe crashes with this error: An unhandled win32 exception occurred in setup.exe [1672]. The system is Windows-XP SP3. TIA for any help! Peter -- Contact information: http://pmrb.free.fr/contact/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup hangs at perl-min
On Aug 27 10:59, Fergus wrote: > I find during a brand new install of "All" that setup hangs at > perl-ming; the reason for this is that both bzips (curr and prev) > release\ming\perl-ming\perl-ming-0.4.3-[12].tar.bz2 > contain tars > perl-ming-0.4.3-[12].tar > that contain files at > usr\share\man\man3\ > whose names include the string "::", not liked by Windows. Not liked by the Win32 API, but no problem at all for the native NT API. However, these are not really colons: http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars > Can this difficulty be addressed by renaming the files? > > (I don't actually need or use these files, but the glitch in setup > is a headache. Possibly relevant that I still use XP on FAT32 not > e.g. W7 on NTFS; FAT32 has no such problem with colons in filenames, but in this case it doesn't really matter, see above. FAT32 also stores filenames as Unicode, so the characters you see are not really colons, but Unicode characters in the 0xf0XX area. Additionally I tested to install perl-ming via the current setup.exe on W7/FAT32 and XP/FAT32, and it works fine. http://cygwin.com/acronyms/#BLODA ? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: problem with PATH set by libtool for uninstalled pixman library
On 29/07/2010 09:20, Charles Wilson wrote:
On 7/28/2010 2:24 PM, Jon TURNEY wrote:
I have a tinderbox which does daily builds of the X.Org stack for
cygwin, and I've come across a something I don't understand with the way
libtool is working when building the pixman library, and I hope someone
can shed a bit of light.
(lt_update_lib_path) modifying 'PATH' by prepending
'/opt/jhbuild/build/pixman/pixman/.libs:'
(lt_setenv) setting 'PATH' to
'/opt/jhbuild/build/pixman/pixman/.libs:/home/jon/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0/:/bin'
(lt_update_exe_path) modifying 'PATH' by prepending
'/opt/jhbuild/install/lib:/opt/jhbuild/install/bin:/opt/jhbuild/build/pixman/pixman/.libs:'
(lt_setenv) setting 'PATH' to
'/opt/jhbuild/install/lib:/opt/jhbuild/install/bin:/opt/jhbuild/build/pixman/pixman/.libs:/opt/jhbuild/build/pixman/pixman/.libs:/home/jon/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0/:/bin'
This is because the wrapper prepends the rpath onto $$LIB_PATH_VARNAME,
and prepends the dllsearchpath onto $$EXE_PATH_VARNAME.
But, since LIB_PATH_VARNAME==EXE_PATH_VARNAME on cygwin (both are
"PATH") that's basically saying:
PATH=$rpath:${PATH}
PATH=$dllsearchpath:${PATH}
I think it was a deliberate choice (e.g. on linux) for the wrapper to
add the $rpath to $LD_RUN_PATH, but...it's not such a great idea for win32.
This is a case where the wrapper exe was trying to do exactly what the
wrapper script used to do -- without considering whether the wrapper
script was doing the right thing, for this platform.
I think a patch to simply swap the order of these two assignments would
be fine (e.g. do $dllsearchpath first, then make sure it gets pre-empted
by $rpath). On *nix it wouldn't matter, since the two variables are
DISTINCT vars.
Okay, thanks very much for the explanation. This clarifies for me that this
is a bug or platform quirk with libtool, and not something that pixman is
doing wrong, so I can stick with the workaround I have for the moment.
I don't think I'm feeling brave enough at the moment to look at the libtool
source:-)
As you can see, the install path appears before .libs in the PATH the
libtool wrapper constructs, so the installed version from a previous
build is used, rather than the uninstalled version we want to test.
I'm not quite clear why the install path is being added at all, I don't
think libpixman has any dependencies which it needs to find there (at
least in the cygwin build)
But libtool doesn't know that, at that particular point in the code.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: grep-2.6.3-1
cgf wrote: > Note that [now] grep opens files in binary mode for both reading and writing > so the output of grep will always have \n endings unless you specify the > --binary option which will (perhaps paradoxically) force the output to > reflect exactly what was in the file being grepped. For those of us who only RTFM [1] when forced to, I learned the hard way that the mapping of \r\n to \n implied above actually happens on _input_, so many patterns involving \r will fail w/o --binary. You have been warned. ht [1] The online documentation reads: By default, under ms-dos and ms-Windows, grep guesses the file type by looking at the contents of the first 32kB read from the file. If grep decides the file is a text file, it strips the CR characters from the original file contents (to make regular expressions with ^ and $ work correctly). Specifying [--binary] overrules this guesswork, causing all files to be read and passed to the matching mechanism verbatim; if the file is a text file with CR/LF pairs at the end of each line, this will cause some regular expressions to fail. This option has no effect on platforms other than ms-dos and ms-Windows. -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Emacs and DBUS
On 8/27/2010 3:41 AM, Michael Albinus wrote: Ken Brown writes: This is also a D-Bus client, which connects to the *same* session bus as Emacs did due to $DBUS_SESSION_BUS_ADDRESS. Now you should see the signal sent by dbus-monitor in Emacs. OK, I started the session bus the right way this time, but I still didn't see any signal from dbus-monitor in Emacs. I assume I should have seen something in the echo area? Yes. You could test whether both Emacs and dbus-monitor use the same bus by reordering the calls: - apply dbus-launch as described - echo $DBUS_SESSION_BUS_ADDRESS - in *another* shell, set $DBUS_SESSION_BUS_ADDRESS to this value, and start dbus-monitor - start Emacs in the first shell, and load dbus.el. You shall see in the other shell output from dbus-monitor, telling that an application has started. It will also tell you the name of that application, like ":1.2". This doesn't happen. Is it possible that dbus.el doesn't complete its initialization because the system bus isn't running? (Keep in mind that I can't do *anything* with dbus in Emacs unless I load dbus.el before starting the system bus.) I note that when I use the version of Emacs built with MYCPPFLAGS='-DDBUS_DEBUG', loading dbus.el results in the following error message in the echo area: D-Bus error: "Failed to connect to socket /var/run/dbus/system_bus_socket: Interrupted system call" - apply (dbus-get-unique-name :session) in Emacs. The result shall be the same name. - start dbus-monitor in the same shell as Emacs. In the other dbus-monitor, you should be notified, that an application has been started. Maybe you can compile dbusbind.c with the compiler flag DBUS_DEBUG, something like this in the Emacs source tree: # MYCPPFLAGS='-DDBUS_DEBUG' make This enables test traces sent to Emacs' stdout (the shell where you have started it). I've introduced this flag while testing dbusbind.c, when it has blocked Emacs, and I didn't want to start gdb ... Maybe I can see something suspicious in the traces. There's very little there. It prints the two lines xd_add_watch: fd 8 xd_add_watch: fd 9 and no more. Does this tell you anything? It's the initialization phase. Two watch functions are installed on file descriptors 8 and 9 (connected to the system and session buses), polling for incoming messages in Emacs' mainloop. When you call dbus-get-unique-name, there shall be more output. But this works, as you have confirmed, so this is not the interesting case. I've hoped to see more :-( Did you play with the running/non-running system bus? Yes, the traces above were produced when starting Emacs with the system bus running. I'm stuck at that point and can't do anything to produce more traces. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How/Where do I get an older version of Cygwin?
Matthias, Thanks very much for your time and assistance. I'll give your ideas a try! Thanks again... Blaine Matthias Andree wrote: Am 26.08.2010 21:41, schrieb Blaine Miller: Again, I agree. I'm between a rock and a hard place here. I have to prove it's not the current version of Cygwin (also read *free*) and new hardware (read *costs them some money*). I have related to you and others at Cygwin user list both of my issues of cron possibly causing a system fault and can't kill the ssmtp dead.letter running over. Does it have to be ssmtp? How about Exim? Works for me without exploding dead.letter files. You can have cron logging to syslog-ng, and suppress cron's sending mail from the crontab, if that helps. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How/Where do I get an older version of Cygwin?
Andy, Thanks very much for your thoughtful consideration. I do indeed see a *Prev* button... I understand about the risks of reverting back to a previous version, however, I may have no choice for political rather than technical reasons. Thanks again! Blaine Andy Koppe wrote: On 26 August 2010 20:24, Larry Hall (Cygwin) wrote: On 8/26/2010 3:03 PM, Blaine Miller wrote: PS... I read in the archives the following quote... Rerun 'setup.exe' and pick "Prev". There is no such option that I can find... Look at the page where you select packages, just above the list of packages and to the right, next to the "Category" button. "Cur" is the default selected radio button. "Prev" is one of the other options. I'd recommend against using the "Prev" button. It gives you a rather random collection of old packages, where some are years older than the current one and others just a couple of weeks. There's no guarantee that those disparate versions will actually work together properly, in fact, it's very likely that things will break. It sure doesn't get tested. Going back to the previous version of a particular package is useful when there's a regression in the latest version, but doing the same across the whole distro, not so much. Cygwin 1.5 and setup-legacy.exe is the way to go if you want something old and unsupported that actually works. Question: would anyone miss the "Prev" button if it were to disappear? Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Emacs and DBUS
On 8/27/2010 10:24 AM, Ken Brown wrote: On 8/27/2010 3:41 AM, Michael Albinus wrote: Ken Brown writes: This is also a D-Bus client, which connects to the *same* session bus as Emacs did due to $DBUS_SESSION_BUS_ADDRESS. Now you should see the signal sent by dbus-monitor in Emacs. OK, I started the session bus the right way this time, but I still didn't see any signal from dbus-monitor in Emacs. I assume I should have seen something in the echo area? Yes. You could test whether both Emacs and dbus-monitor use the same bus by reordering the calls: - apply dbus-launch as described - echo $DBUS_SESSION_BUS_ADDRESS - in *another* shell, set $DBUS_SESSION_BUS_ADDRESS to this value, and start dbus-monitor - start Emacs in the first shell, and load dbus.el. You shall see in the other shell output from dbus-monitor, telling that an application has started. It will also tell you the name of that application, like ":1.2". This doesn't happen. Is it possible that dbus.el doesn't complete its initialization because the system bus isn't running? To partially answer my own question, I tried removing the line (dbus-init-bus :system) from dbus.el. The good news is that when I then load dbus.el, I do get the expected output from dbus-monitor. The bad news is that Emacs then behaves exactly as in the scenario where I start Emacs with the system bus running. Namely, it prints the trace 'xd_add_watch: fd 9' and then becomes unresponsive. All I can do is press C-g if I want to hear bells or C-x C-c to exit. I suspect we can't go any further with this until you return from your trip and start debugging. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: linux->cygwin cross build environment
On 8/25/2010 10:53 PM, Charles Wilson wrote:
> Anybody have a suggestion? What am I doing wrong?
Based on Corinna's posted procedure
http://cygwin.com/ml/cygwin-developers/2010-08/msg00099.html
with a few changes, I was able to create a working linux->cygwin toolchain.
The changes I had to make were:
1) I had to do the "unpack a couple of cygwin distro packages" step and
the "postinstall" step BEFORE trying to compile gcc. Otherwise,
compiling libgcc fails because of "missing stdio.h".
2) I *did* have to patch gcc's libstdc++-v3/crossconfig.m4 file.
Otherwise, I got a complaint about unsupported "host/target" combination.
3) And, since Dave's patches do modify m4, Makefile.am, and configure.ac
files, I did run automake and autoconf manually in the affected
subdirectories, before attempting to build.
Testing:
Hello World in C, worked fine
Hello World in C++, worked fine
Rebuilt cygwin-1.7.6 from source, and installed into win32 -- worked fine.
Now, how this build -- unlike my previous attempt -- doesn't have a
sysroot. The $target libs are installed directly under
$host_prefix/$target_triple. Also, unlike the native cygwin 4.5.0
compiler, this one doesn't --enable-libgomp nor --enable-graphite nor
--enable-lto. And builds only C, C++, and Fortran.
But...this one works. I'll try again, with some of the other options
and maybe sysroot support, but not until next week.
I've attached my *working* recipe, based on Corinna's instructions. It
also includes the recipe for then building cygwin itself, and packaging
the results for installation on win32.
--
Chuck
HOST_TRIPLE=i686-pc-linux-gnu
HOST_PREFIX=/opt/devel/cygwin
TARGET_TRIPLE=i686-pc-cygwin
TARGET_PREFIX=/usr
SRCTOP=/mnt/junk/gcc45b/src
BUILDTOP=/mnt/junk/gcc45b/build
GCCVER=4.5.0
PKGREL=2
DOWNLOADS=/opt/devel/cygwin/src/DOWNLOADS
MIRROR=http://mirrors.kernel.org/sourceware/cygwin/release
export PATH=${HOST_PREFIX}/bin:/mnt/junk/private/bin:${PATH}
mkdir -p ${BUILDTOP}
mkdir -p ${SRCTOP}
do_get () {
pushd ${DOWNLOADS} >/dev/null
wget ${MIRROR}/$1
popd >/dev/null
}
mkdir -p ${DOWNLOADS}
do_get binutils/binutils-2.20.51-2-src.tar.bz2
do_get gcc4/gcc4-4.5.0-1-src.tar.bz2
do_get cygwin/cygwin-1.7.6-1-src.tar.bz2
## Prepare $target libs and headers
do_get binutils/binutils-2.20.51-2.tar.bz2
do_get w32api/w32api-3.14-1.tar.bz2
do_get cygwin/cygwin-1.7.6-1.tar.bz2
do_get zlib/zlib-devel/zlib-devel-1.2.3-10.tar.bz2
do_get mingw/mingw-zlib/mingw-zlib-devel/mingw-zlib-devel-1.2.3-10.tar.bz2
do_get mingw-runtime/mingw-runtime-3.18-1.tar.bz2
do_get libiconv/libiconv-1.13.1-1.tar.bz2
do_get gettext/gettext-0.17-11.tar.bz2
cd ${HOST_PREFIX}
tar xjf ${DOWNLOADS}/binutils-2.20.51-2.tar.bz2usr/include usr/lib
tar xjf ${DOWNLOADS}/gettext-0.17-11.tar.bz2 usr/include usr/lib
tar xjf ${DOWNLOADS}/libiconv-1.13.1-1.tar.bz2 usr/include usr/lib
tar xjf ${DOWNLOADS}/mingw-runtime-3.18-1.tar.bz2 usr/include usr/lib
tar xjf ${DOWNLOADS}/mingw-zlib-devel-1.2.3-10.tar.bz2 usr/include usr/lib
tar xjf ${DOWNLOADS}/zlib-devel-1.2.3-10.tar.bz2 usr/include usr/lib
tar xjf ${DOWNLOADS}/w32api-3.14-1.tar.bz2 usr/include usr/lib
tar xjf ${DOWNLOADS}/cygwin-1.7.6-1.tar.bz2usr/include usr/lib
find i686-pc-cygwin/lib -name '*.dll.a' -o -name '*.la' | xargs rm
mkdir i686-pc-mingw32
cd i686-pc-mingw32
ln -s ../i686-pc-cygwin/bin bin
ln -s ../i686-pc-cygwin/include/mingw include
ln -s ../i686-pc-cygwin/lib/mingw lib
cd ..
# ensure linux package installed: libgmp-devel, libgmp10
# ensure linux package installed: mpfr-devel, libmpfr1
# ensure linux package installed: libmpc-devel, libmpc2
# ensure linux package installed: libcloog-devel, libcloog0
# ensure linux package installed: libppl-devel, libppl7
## custom autoconf, automake
## gcc-4.5.0 requires ac-2.64, am-1.11.1
cd ${DOWNLOADS}
wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.64.tar.bz2
wget http://ftp.gnu.org/gnu/automake/automake-1.11.1.tar.bz2
cd ${SRCTOP}
tar xvjf ${DOWNLOADS}/autoconf-2.64.tar.bz2
tar xvjf ${DOWNLOADS}/automake-1.11.1.tar.bz2
cd ${BUILDTOP}
mkdir autoconf
cd autoconf
${SRCTOP}/autoconf-2.64/configure --prefix=/mnt/junk/private
make
make install
cd ${BUILDTOP}
mkdir automake
cd automake
${SRCTOP}/automake-1.11.1/configure --prefix=/mnt/junk/private
make
make install
mkdir -p /mnt/junk/private/share/aclocal
echo '/usr/share/aclocal' > /mnt/junk/private/share/aclocal/dirlist
## unpack gcc, binutils source
cd $SRCTOP
tar xvjf ${DOWNLOADS}/binutils-2.20.51-2-src.tar.bz2
tar xvjf ${DOWNLOADS}/gcc4-4.5.0-1-src.tar.bz2
tar xvjf gcc-4.5.0.tar.bz2
## apply patches
cd gcc-4.5.0
pa
WLMP cannot map to parent and Rebaseall fails for unknown reason.
Hi all, I am trying to get my version of Cygwin to play nicely with WLMP[1] which installs it's own version of some key cygwin dlls locally. When I launch the WLMP version of lightty, I get the classic 'Unable to Remap' error [2]. This is usually solved by a quick trip to rebaseall, so I tried: $ ./rebaseall -v -T `./find /cygdrive/c/WLMP/LightTPD/ -iname '*dll' rebaseall: '/cygdrive/c/WLMP/LightTPD/CygBZ2-1.dll' is not readable $ ./cat /cygdrive/c/WLMP/LightTPD/CygBZ2-1.dll << BINARY JUNK >> The file is, in fact, readable. I can 'cat' it from the ash command line right there. Heck, I can even write to it. NTFS file permissions are set to 'Full Control' for the user running ./rebaseall. No other files have it open (per process explorer). So why in blazes does rebaseall think that it's not readable?! Oren PS. I know that WLMP is not Cygwin's problem. I was merely hoping that some kind soul would point me in the right direction to rebasing all my DLLs for a happy cygwin + WLMP family. [1] http://en.wlmp-project.net/ -- unfortunately the build of lightty that comes with Cygwin doesn't have SSL baked in, nor is there a PHP/MySQL stack. [2] 35 [main] LightTPD 4604 C:\WLMP\LightTPD\LightTPD.exe: *** fatal error - unable to remap C:\WLMP\LightTPD\cygminires.dll to same address as parent (0x33) != 0x6EFC -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Emacs and DBUS
Ken Brown writes: > I suspect we can't go any further with this until you return from your > trip and start debugging. Yes, I'm sorry. Let's continue in September. > Ken Best regards, Michael. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
BLODA diagnostics
Hi, what tool is best to track down what BLODA is causing fork failures on my Cygwin installation? Baldur -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
SSH - Can't Login
I've set up SSH with no problems in the past, yet when I try to log into itself I get the following: # ssh -v ca53...@localhost OpenSSH_5.6p1, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh_config debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/544 debug1: identity file /home/ca53918/.ssh/id_rsa type 1 debug1: identity file /home/ca53918/.ssh/id_rsa-cert type -1 debug1: identity file /home/ca53918/.ssh/id_dsa type 2 debug1: identity file /home/ca53918/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.6 debug1: match: OpenSSH_5.6 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY The authenticity of host 'localhost (127.0.0.1)' can't be established. RSA key fingerprint is Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (RSA) to the list of known hosts. debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/ca53918/.ssh/id_rsa Connection closed by 127.0.0.1 There's an immediate connection. The sshd service is running, and I've used both the ssh_user_config and ssh_host_config script to set up the environment. All the appropriate files look clean underneath my .ssh directory. Any help will be greatly appreciated. Thanks, and regards, Auteria W. Winzer Jr. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup.exe crashes when downgrading gcc4
On 27 August 2010 11:56, Peter Münster wrote: > I've installed version 4.5.0 of gcc4-core, gcc4-g++ and libgcc1. Now I would > like to uninstall these packages or go back to version 4.3.4. > > There is no possibility to uninstall these packages, when cycling in > setup.exe, there are these possibilities: > - 4.3.4-3 > - source > - 4.3.4-1 > - keep Unticking the checkbox in the 'Bin?' column next to 'New' should uninstall it. (No, I don't understand the logic either.) > So I select "4.3.4-3", and then "next". Then setup.exe crashes with this > error: > An unhandled win32 exception occurred in setup.exe [1672]. I wasn't able to reproduce this. Were you using the then-latest version 2.712 of setup.exe? You could also try 2.721, which has just been uploaded. I take it you didn't click on the Exp or Keep radio buttons? Did you downgrade all three packages you mentioned? Did it crash straight away, after some delay, or only when it got to the 'Progress' page? Another thing to try is to simply click Next without changing anything, because setup automatically downgrades you from any experimental packages anyway, unless you tell it otherwise using Exp or Keep. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
When I invoke gitk like this:
#
$ cygcheck -c cygwin git gitk tcltk
Cygwin Package Information
Package VersionStatus
cygwin 1.7.6-1OK
git 1.7.1-1OK
gitk 1.7.1-1OK
tcltk20080420-1 OK
$ ls -a
. .. .git
$ git rev-parse --git-dir
.git
$ gitk
#
I got the following error:
#
"Cannot find a git repository here."
#
This error message is shown when a valid .git directory is not found.
#
$ sed -n "11441,11446p" /usr/bin/gitk
# check that we can find a .git directory somewhere...
if {[catch {set gitdir [gitdir]}]} {
show_error {} . [mc "Cannot find a git repository here."]
exit 1
}
#
But as the "ls -a" output above shows, I do have a .git directory. So this
means the procedure "gitdir" somehow failed to detect the .git directory.
The cause of this error comes down to this:
#
$ echo "puts [pwd]"|wish
//?/PIPE
#
/usr/bin/gitk is a tcl (wish) script, but tcltk-20080420-1 is a native
Win32 app. So in cygwin-1.7.6-1, the working directory of wish is set to
//?/PIPE. That is why the git command invoked from inside gitk failed
saying "Cannot find a git repository here."
A temporary workaround is to use cygwin-1.7.5-1, but,
1. I see a long discussion about cygwin vs. win32 CWD is taking place in
cygwin-developer. What is win32 CWD going to be in cygwin in the future?
2. I understand that the reason to have tcltk-20080420-1 as a win32 app is
to have a graphical insight that does not depend on X Window. (Thread
"Does anyone use insight on cygwin?" in cygwin 2008-08.) But in the thread
"gdb, insight, and tcltk" in cygwin 2009-10, Charles Wilson discussed War
and Peace of an X-based package. Is anything moving recently in this vein?
--
neomjp
--
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Upgrading to cygwin 1.7.6 vs gcc 4.5
On 18 August 2010 21:19, Andy Koppe wrote: > On 18 August 2010 06:25, Andy Koppe wrote: >> On 18 August 2010 00:09, Eric Blake wrote: >>> On 08/17/2010 04:54 PM, Ross Smith wrote: I've installed the experimental gcc 4.5 packages (because that's the version I'm using in all my other development environments, and it's nice not to have to target multiple compiler versions any more), but now that cygwin dll 1.7.6 is out, I can't seem to find a way to upgrade cygwin without also downgrading gcc. In the installer, if I select Current I get the new cygwin but the old gcc, while if I select Experimental, it keeps the new gcc but doesn't offer me the new cygwin. At the moment I'm sticking with the old cygwin, because the gcc upgrade is more important to me than the cygwin upgrade. Is there some way I'm missing to select both, or do I just have to accept that I can't upgrade anything else until the official gcc 4.5 is ready? >>> >>> Stay on the 'Curr' (not 'Exp'), click 'View' until you are on the >>> Pending page, then cycle on the string next to each gcc package until it >>> says Keep instead of the downgraded version number. >> >> I'd recommend selecting the 'Exp' button actually. That ensures that >> all dependencies of gcc, e.g. libgcc and libffi, are upgraded to 4.5 >> too. (It's yet another flaw of setup.exe that it doesn't automatically >> upgrade dependencies of experimental versions accordingly.) > > Scratch that. I hadn't realised that if you select 'Exp', > non-experimental packages no longer get updated, which of course is > exactly what the OP was saying. This should be fixed in the newly uploaded setup.exe 2.721. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
MANPATH not being cygpathed like PATH is?
Hello Everyone, I recently switched from setting up environment variables within my bash_profile/bashrc file and instead started setting them on the box I'm on. This works great for PATH. In Windows I set the values to c:/whateverwhatever and then when my terminal fires up they get cygpathed (I'm assuming) into the right /usr/etcetcetc. Unfortunately, I'm observing no such behavior with the MANPATH. I can't see any difference between it and the PATH value so I was wondering if this was something that cygwin does intentionally. Thanks in advance! -- In Christ, Timmy V. http://blog.twonegatives.com/ http://five.sentenc.es/ - Spend less time on e-mail -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Is it possible to run cygwin version of rsync in daemon mode?
Re: (Note that this doesn't solve a hang that some folks see in the middle of a transfer -- using daemon mode instead of ssh can work around that one.) I'm not sure of how to do this... Thanks for your time and consideration... Blaine -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
On 27 August 2010 19:22, neomjp wrote: > 1. I see a long discussion about cygwin vs. win32 CWD is taking place in > cygwin-developer. What is win32 CWD going to be in cygwin in the future? It will be synced with the POSIX working directory again, except when the path is too long or it's a "virtual" directory such as /proc. > 2. I understand that the reason to have tcltk-20080420-1 as a win32 app is > to have a graphical insight that does not depend on X Window. Cygwin programs can have Win32 interfaces actually, as proven by the likes of rxvt, mintty, and the Xwin server itself. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Windows batch program to open shell at directory specified as argument
On Thu, Aug 26, 2010 at 11:45 PM, Reckoner wrote: > I use chere to right-click and open a shell at a given directory, and > I was wondering if it is possible to setup a windows batch script that > would accomplish the same thing from the Windows command line. In > other words something like, > > c:> cygwin_start_dir.bat c:\mystuff\directory > > which would then open my favourite shell at the c:\mystuff\directory. Yes, this is possible. You simply want to grab the command that chere puts a registry and paste it into a batch file. You probably need to fix up quoting, and change any %L to %1. Run 'chere -r' and look for the text associated with the command key. Cheers, Dave. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Windows batch program to open shell at directory specified as argument
On Fri, Aug 27, 2010 at 11:42 AM, Dave Kilroy wrote: > On Thu, Aug 26, 2010 at 11:45 PM, Reckoner wrote: >> I use chere to right-click and open a shell at a given directory, and >> I was wondering if it is possible to setup a windows batch script that >> would accomplish the same thing from the Windows command line. In >> other words something like, >> >> c:> cygwin_start_dir.bat c:\mystuff\directory >> >> which would then open my favourite shell at the c:\mystuff\directory. > > Yes, this is possible. You simply want to grab the command that chere > puts a registry and paste it into a batch file. You probably need to > fix up quoting, and change any %L to %1. > > Run 'chere -r' and look for the text associated with the command key. > > > Cheers, > > Dave. > You could also use something from this site: http://www.mindview.net/Etc/Cygwin/BashHere slide -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: MANPATH not being cygpathed like PATH is?
On 8/27/2010 1:28 PM, Tim Visher wrote: > Hello Everyone, > > I recently switched from setting up environment variables within my > bash_profile/bashrc file and instead started setting them on the box > I'm on. This works great for PATH. In Windows I set the values to > c:/whateverwhatever and then when my terminal fires up they get > cygpathed (I'm assuming) into the right /usr/etcetcetc. > Unfortunately, I'm observing no such behavior with the MANPATH. I > can't see any difference between it and the PATH value so I was > wondering if this was something that cygwin does intentionally. Cygwin only processes a handful of environment variables automatically in the way you expect. They include PATH, HOME, TMP, and TEMP if my memory serves correctly. Anything else you need to do for yourself. The problem is that there is no general way to know what environment variables should be processed, so an explicit list must be created and maintained. Apparently, a minimal set was chosen which is usually sufficient to get you into a Cygwin environment at which point you can selectively handle further processing as necessary. For defining MANPATH within Windows, you could just specify it as Cygwin wants it unless you have some non-Cygwin programs which also need to use MANPATH. -Jeremy signature.asc Description: OpenPGP digital signature
Re: Is it possible to run cygwin version of rsync in daemon mode?
On 8/27/2010 1:32 PM, Blaine Miller wrote: > Re: > > (Note that this doesn't solve a hang that some folks see in the middle > of a transfer -- using daemon mode instead of ssh can work around that > one.) > > I'm not sure of how to do this... > > Thanks for your time and consideration... Read the manpages for rsync and especially rsyncd.conf. -Jeremy signature.asc Description: OpenPGP digital signature
Re: Is it possible to run cygwin version of rsync in daemon mode?
Thank you Jeremy, I'll look now... Thanks again for your time and consideration... Blaine Jeremy Bopp wrote: On 8/27/2010 1:32 PM, Blaine Miller wrote: Re: (Note that this doesn't solve a hang that some folks see in the middle of a transfer -- using daemon mode instead of ssh can work around that one.) I'm not sure of how to do this... Thanks for your time and consideration... Read the manpages for rsync and especially rsyncd.conf. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
On 8/27/2010 2:33 PM, Andy Koppe wrote: > On 27 August 2010 19:22, neomjp wrote: >> 2. I understand that the reason to have tcltk-20080420-1 as a win32 app is >> to have a graphical insight that does not depend on X Window. > > Cygwin programs can have Win32 interfaces actually, as proven by the > likes of rxvt, mintty, and the Xwin server itself. The real issue is that tcltk-20080420-1 presents the GDI (e.g. native windows) backend implementation for tcl/tk. I was proposing that we eventually modify our offerings so that the new (probably split up) replacement package(s) present the X11 backend implementation instead. It has nothing to do with whether "tcltk" is a "win32" *application* as opposed to a cygwin one. It's all about which interface the application/library uses to put graphics on the screen: GDI or X11. So far, nothing has occurred on that line AFAIK. If it is to happen, the current maintainer has to just pull the trigger and say "we are going to do this". Existing maintainers of tcl/tk clients will then adapt; until (if) that happens, nothing will change. I think the big hangups were (a) insight (b) git (c) python-idle. insight might actually be dead or dying, not sure. Obviously git and python-idle both work with X (on linux) so it's doable to convert -- just a nuisance. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: How/Where do I get an older version of Cygwin?
> Date: Fri, 27 Aug 2010 07:08:58 +0100 > Subject: Re: How/Where do I get an older version of Cygwin? > From: andy > To: cygwin > > I'd recommend against using the "Prev" button. It gives you a rather > random collection of old packages, where some are years older than the > current one and others just a couple of weeks. There's no guarantee > that those disparate versions will actually work together properly, in > fact, it's very likely that things will break. It sure doesn't get > tested. > > Going back to the previous version of a particular package is useful > when there's a regression in the latest version, but doing the same > across the whole distro, not so much. Cygwin 1.5 and setup-legacy.exe > is the way to go if you want something old and unsupported that > actually works. > > Question: would anyone miss the "Prev" button if it were to disappear? > I agree with eliminating it. ...Karl -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: BLODA diagnostics
Since no one replied, perhaps you could supply more details. What exactly are you trying to do and what happens? There may be a sysinternals tool, I use those to track down open handles that have been a problem on earlier systems. On 8/27/10, Baldur Gislason wrote: > Hi, what tool is best to track down what BLODA is causing fork failures on > my > Cygwin installation? > > Baldur > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > -- marchy...@gmail.com note new address 2009-12-16: Mike Marchywka 1975 Village Round Marietta GA 30064 415-264-8477 (w)<- use this 404-788-1216 (C)<- leave message 989-348-4796 (P)<- emergency only marchy...@hotmail.com Note: If I am asking for free stuff, I normally use for hobby/non-profit information but may use in investment forums, public and private. Please indicate any concerns if applicable. Note: hotmail is censoring incoming mail using random criteria beyond my control and often hangs my browser but all my subscriptions are here..., try also marchy...@yahoo.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: BLODA diagnostics
I am attempting to diagnose why fork() fails during the cygwin installation. It looks like some kind of BLODA may be causing this, per documentation, but obviously, the list of known troublemakers in the documentation does not cover all troublemakers and I'd like to trace what is going on. Baldur On Fri, Aug 27, 2010 at 04:44:22PM -0400, mike marchywka wrote: > Since no one replied, perhaps you could supply more details. > What exactly are you trying to do and what happens? > > There may be a sysinternals tool, I use those to track down open handles > that have been a problem on earlier systems. > > > On 8/27/10, Baldur Gislason wrote: > > Hi, what tool is best to track down what BLODA is causing fork failures on > > my > > Cygwin installation? > > > > Baldur > > > > -- > > Problem reports: http://cygwin.com/problems.html > > FAQ: http://cygwin.com/faq/ > > Documentation: http://cygwin.com/docs.html > > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > > > > > > -- > marchy...@gmail.com > note new address 2009-12-16: > Mike Marchywka > 1975 Village Round > Marietta GA 30064 > 415-264-8477 (w)<- use this > 404-788-1216 (C)<- leave message > 989-348-4796 (P)<- emergency only > marchy...@hotmail.com > Note: If I am asking for free stuff, I normally use for hobby/non-profit > information but may use in investment forums, public and private. > Please indicate any concerns if applicable. > Note: hotmail is censoring incoming mail using random criteria beyond > my control and often hangs my browser > but all my subscriptions are here..., try also marchy...@yahoo.com > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: BLODA diagnostics
On 2010-08-27 21:22Z, Baldur Gislason wrote: > I am attempting to diagnose why fork() fails during the cygwin installation. > It looks like some kind of BLODA may be causing this, per documentation, but > obviously, the list of known troublemakers in the documentation does not > cover all troublemakers and I'd like to trace what is going on. Does it succeed in "safe mode with networking"? If so, then by a process of elimination you may be able to find what's causing the problem. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Support for the TIOCINQ ioctl
By any chance, has support for the TIOCINQ ioctl on file descriptors (used to check how many bytes of data are in the input buffer) been added to Cygwin? It hadn't as of 2004: http://sourceware.org/ml/cygwin/2004-07/msg00910.html ...but I haven't found any newer references to it. I'm inferring that it's not supported, as ioctl(fd, TIOCINQ, &available) (where fd is a valid file descriptor, and available is a long) fails, with errno set to 'invalid argument'. I'm running Cygwin 1.7.6 on Vista. I'm hoping I'm missing something... Is there an alternative way to check the number of bytes on an fd's input buffer in Cygwin? Thanks, -Brennan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How/Where do I get an older version of Cygwin?
On Fri, Aug 27, 2010 at 3:36 PM, Karl M <> wrote: > >> Date: Fri, 27 Aug 2010 07:08:58 +0100 >> Subject: Re: How/Where do I get an older version of Cygwin? >> From: andy >> To: cygwin >> >> I'd recommend against using the "Prev" button. It gives you a rather >> random collection of old packages, where some are years older than the >> current one and others just a couple of weeks. There's no guarantee >> that those disparate versions will actually work together properly, in >> fact, it's very likely that things will break. It sure doesn't get >> tested. >> >> Going back to the previous version of a particular package is useful >> when there's a regression in the latest version, but doing the same >> across the whole distro, not so much. Cygwin 1.5 and setup-legacy.exe >> is the way to go if you want something old and unsupported that >> actually works. >> >> Question: would anyone miss the "Prev" button if it were to disappear? >> > I agree with eliminating it. > > ...Karl > > -- Hello! I agree! - Gregg C Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and again." -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How/Where do I get an older version of Cygwin?
On Fri, 27 Aug 2010, Andy Koppe wrote: Greetings, Andy, On 26 August 2010 20:24, Larry Hall (Cygwin) wrote: On 8/26/2010 3:03 PM, Blaine Miller wrote: PS... I read in the archives the following quote... Rerun 'setup.exe' and pick "Prev". There is no such option that I can find... Look at the page where you select packages, just above the list of packages and to the right, next to the "Category" button. "Cur" is the default selected radio button. "Prev" is one of the other options. I'd recommend against using the "Prev" button. It gives you a rather random collection of old packages, where some are years older than the current one and others just a couple of weeks. There's no guarantee that those disparate versions will actually work together properly, in fact, it's very likely that things will break. It sure doesn't get tested. Going back to the previous version of a particular package is useful when there's a regression in the latest version, but doing the same across the whole distro, not so much. Cygwin 1.5 and setup-legacy.exe is the way to go if you want something old and unsupported that actually works. Question: would anyone miss the "Prev" button if it were to disappear? Yes, I, for one, would miss it. While it may give a "random collection of old packages", for packages that are actively maintained it does give you the ability to revert to the previous version that is/was working when the "current" version either does not do what you want or, in some cases, breaks what you already had working. For that reason alone, the "Prev" has value. While I can hear the whispers of "report it as a bug" in cases of breakage, for those of us who use these tools on a daily bases (whether test or "production" (used loosely)), waiting for community support to "fix it" would likely take too long and thus not be viable. This is probably why people get a specific set of packages that work well for them and just stick with them for a while rather than upgrading. This is one of the main reasons I create the Cygwin Time Machine, btw. I have, on several occasions upgraded older cygwin installations to latest only to have them "change" in ways unanticipated/unwanted and then had to wipe and install the older, working, versions. But the older packages get purged from the mirrors pretty quickly and that is a problem when you need to install older versions. This is why the CTW exists. For people who are proactive and keep their installations up to date, the "Prev" button can be a life-saver in cases of breakage. So, please do keep the "Prev" button. Thanks! Andy -- Peter A. Castro or "Cats are just autistic Dogs" -- Dr. Tony Attwood -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How/Where do I get an older version of Cygwin?
On 8/27/2010 7:05 PM, Peter A. Castro wrote: > On Fri, 27 Aug 2010, Andy Koppe wrote: >> Question: would anyone miss the "Prev" button if it were to disappear? > > Yes, I, for one, would miss it. While it may give a "random collection > of old packages", for packages that are actively maintained it does give > you the ability to revert to the previous version that is/was working > when the "current" version either does not do what you want or, in some > cases, breaks what you already had working. For that reason alone, the > "Prev" has value. Peter, I think you're misinterpreting Andy's proposal. He's not talking about the ability to click on the 'spinner' icon, to cycle thru various versions of a specific package. He's talking about the 'Prev' radio button, which can have VERY unexpected results. It reverts EVERY package that you have installed to the prev version of that package -- not just a single package whose current version may be giving you temporary difficulties. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How/Where do I get an older version of Cygwin?
On Fri, 27 Aug 2010, Charles Wilson wrote: On 8/27/2010 7:05 PM, Peter A. Castro wrote: On Fri, 27 Aug 2010, Andy Koppe wrote: Question: would anyone miss the "Prev" button if it were to disappear? Yes, I, for one, would miss it. While it may give a "random collection of old packages", for packages that are actively maintained it does give you the ability to revert to the previous version that is/was working when the "current" version either does not do what you want or, in some cases, breaks what you already had working. For that reason alone, the "Prev" has value. Peter, I think you're misinterpreting Andy's proposal. He's not talking about the ability to click on the 'spinner' icon, to cycle thru various versions of a specific package. He's talking about the 'Prev' radio button, which can have VERY unexpected results. HmmI had taken it to mean complete removal of all "prev" functionality, spinner and all. So, if that's not what was proposed, then I'd say: "never mind" (*sigh* that's what I get for not taking time to fully read every single email) It reverts EVERY package that you have installed to the prev version of that package -- not just a single package whose current version may be giving you temporary difficulties. Yes, I'm aware of that (and I have used exactly that functionality on occasion to interesting results, I'll admit), but was taking the wrong meaning of the proposal. My mistake. I suppose there's not a lot of sense in keeping "Prev", then. I retract my objection. (I'll go back to mumbling in the corner now :) Thanks, Chuck! -- Chuck -- Peter A. Castro or "Cats are just autistic Dogs" -- Dr. Tony Attwood -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
command-line package installation
I'm in the process of deploying cygwin with an OpenSSH that has an OpenSSL-fips built into it. Our cygwin build environment averages around 200MB with gcc-core, perl, mingw-runtime, etc... with all of these uninstalled, the base environment is around 70MB. I need the ability to uninstall packages inside a script to shrink our environment, but the setup.exe is crippled and does not allow for uninstalling packages. I did find "apt-cyg", and while it does do the uninstall successfully, I find that when I try to use it to install things, that it doesn't always work... And I have seen posts from folks in the past talking about how that it is "unsupported". Is there any chance that the roadmap for cygwin has a commandline package manager, or to expand the capabilities of setup.exe in the future? I think I can "find and delete" what I need to until then, but a package manager type thing would be great... other than "find and delete", are there any other ways to do what I'm needing? Bryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Support for the TIOCINQ ioctl
On 27 August 2010 23:31, Brennan Peter Sellner wrote: > By any chance, has support for the TIOCINQ ioctl on file descriptors (used > to check how many bytes of data are in the input buffer) been added to > Cygwin? It hadn't as of 2004: > > http://sourceware.org/ml/cygwin/2004-07/msg00910.html It's still implemented only for serial devices. > ...but I haven't found any newer references to it. I'm inferring that it's > not supported, as ioctl(fd, TIOCINQ, &available) (where fd is a valid file > descriptor, and available is a long) fails, with errno set to 'invalid > argument'. I'm running Cygwin 1.7.6 on Vista. > > I'm hoping I'm missing something... Is there an alternative way to check > the number of bytes on an fd's input buffer in Cygwin? What's your use case? And on what sort of fd? select() of course can tell you whether there are any bytes available to be read from an fd, and usually that's all one needs to know. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
