Unable to subscribe to the cygwin-announce list
Hi Admins, On Thu, Sep 21, 2023 at 03:46:31PM +0100, cygwin wrote: > > The auto-forwarding of announcements from the cygwin-announce mailing list > to the cygwin mailing list has been removed. > > This seems to be hard to make work reliably (sometimes it doubles the > messages, sometimes they don't get forwarded), apparently prevents us from > adding a meaningful standard footer (e.g. with unsubscribe instructions, so > we have to rely on maintainers remembering to add it manually), and no-one > seems to know why we're doing it. > > If you want to continue to receive these announcements in the future, please > consider subscribing to the cygwin-announce mailing list (or reading it via > news://news.gmane.io/gmane.os.cygwin.announce, or via the various protocols > that inbox.sourceware.org provides). > I've tried a number of times to subscribe via https://cygwin.com/mailman/listinfo/cygwin-announce/ : I get the message "Your subscription request has been received, ... you will soon get a confirmation email ...", but I never get an email. Could an Admin subscribe me to the list please? Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Announcements now only go to the cygwin-announce list
Hi cygwin, On Thu, Sep 21, 2023 at 03:46:31PM +0100, cygwin wrote: > > The auto-forwarding of announcements from the cygwin-announce mailing list > to the cygwin mailing list has been removed. > > This seems to be hard to make work reliably (sometimes it doubles the > messages, sometimes they don't get forwarded), apparently prevents us from > adding a meaningful standard footer (e.g. with unsubscribe instructions, so > we have to rely on maintainers remembering to add it manually), and no-one > seems to know why we're doing it. > > If you want to continue to receive these announcements in the future, please > consider subscribing to the cygwin-announce mailing list (or reading it via > news://news.gmane.io/gmane.os.cygwin.announce, or via the various protocols > that inbox.sourceware.org provides). > Can someone with appropriate access update https://cygwin.com/lists.html then please? It still says " Announcements sent to cygwin-announce are automatically sent to the Cygwin mailing list so there is no reason to subscribe to both ...". I tried subscribing, but no confirmation email after half an hour. Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Memory Barriers at pthread using CYGWIN
On Thu, Jun 08, 2023 at 05:29:59PM +0300, cygwin wrote:
> Hi,
>
> I wrote a simple test for pthread_barrier_wait. it won't work as expected.
>
> result should be
>
> r1 = 1, r2 = 1
>
> Thanks,
> Mümin
> cmake_minimum_required(VERSION 3.26)
>
> project(test)
>
> set(CMAKE_CXX_STANDARD 14)
> set(CMAKE_CXX_STANDARD_REQUIRED ON)
> set(CMAKE_CXX_EXTENSIONS OFF)
>
>
> add_definitions(-D__POSIX_VISIBLE=200112 -D_POSIX_C_SOURCE=200112)
>
> add_executable(test main.cpp)
>
> target_link_libraries(test pthread)
> #include
> #include
>
> int x = 0;
> int y = 0;
> int r1 = 0;
> int r2 = 0;
>
> pthread_barrier_t barrier;
>
> void* thread1(void* arg) {
> y = 1;
> pthread_barrier_wait(&barrier); // Memory barrier
> r1 = x;
> return NULL;
> }
>
> void* thread2(void* arg) {
> x = 1;
> pthread_barrier_wait(&barrier); // Memory barrier
> r2 = y;
> return NULL;
> }
>
> int main() {
> pthread_t t1, t2;
>
> pthread_barrier_init(&barrier, NULL, 2);
>
> pthread_create(&t1, NULL, thread1, NULL);
> pthread_create(&t2, NULL, thread2, NULL);
>
> pthread_join(t1, NULL);
> pthread_join(t2, NULL);
>
> printf("r1 = %d, r2 = %d\n", r1, r2);
>
> pthread_barrier_destroy(&barrier);
>
> return 0;
> }
WFFM (compiled as a C program)
Cheers ... Duncan.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mintty mouse behavior with vim
On Thu, May 11, 2023 at 03:24:18PM +, cygwin wrote: > > Greetings. > > In mintty, while using vim, I would like to highlight a few lines, and > have vim tell me how many lines have been highlighted. Is this a > possibility? For example: > > 0 > 1 > ->2 > ->3 > ->4 > ->5 > 6 > 7 > 8 > 9 > > If I highlight lines 2 through 5, I would like vim to tell me that 4 > lines have been highlighted. It works fine with the windows vim, but it > does not want to do it through mintty. Thoughts? Thanks. > > José > > PS: The real problem is that I am ssh'ing to an ubuntu box which I am > using vim, but the mouse is not being acknowledged. Although, I can > highlight and copy/paste, but clicking to a word to move the cursor > there, it's not acknowledged. > You expect too much of ssh. ssh is a text utility, not an X one. The remote vim never sees your mouse actions: it's mintty that performs select / paste. Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin X11 on second (Nvidia) graphics card
Hi Franz, On Sun, Jan 29, 2023 at 06:18:43PM +0100, cygwin wrote: > Am 27.01.2023 um 20:58 schrieb Brian Inglis via Cygwin: > > On 2023-01-27 08:22, Franz Fehringer via Cygwin wrote: > > > I have a question which seems quite natural but i cannot find > > > anything useful using google & co. > > > My (business) notebook has two graphics cards, one builtin > > > identifying as Intel Iris Xe and an additional one, a Nvidia MX550. > > > I start X11 (xwin) with defaults (-listen tcp is the only extra option). > > > Using nvidia-smi and the Nvidia activity dialog i see that the > > > Nvidia graphics card is not used. > > > Using glxinfo i see that the builtin Intel Iris Xe is used instead. > > > I already prefer Nvidia over Intel via the Nvidia control panel. > > > How do i make X11 and OpenGL use the Nvidia graphics card instead of > > > the Intel one? > > > > $ man Xwin # See OPTIONS FOR SPECIFYING X SCREENS > > > > In your XWin Server shortcut etc., add server options -multimonitors or > > -screen ... after startxwin ... -- ["--" required to allow server > > options]. > > > > Using these options does not change anything. > The XWin server simply doesn not detect the second (Nvidia) graphics card. > I think i will repost with a more concise subject. > AIUI, your notebook screen will be "plugged in" to your embedded card and you will need to plug another monitor into your Nvidia card in order to use it. Once you have plugged in the second monitor, you may need a reboot for it to be fully functional (I have to do that on my *linux* laptop). After that, with X running, `xrandr` should show you available resolutions on both screens. By default, the second screen appears to the right of the first: xrandr options --left-of, --right-of, --above, --below, --same-as can change this. Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: variables, mostly private, not included into debug symbols list on -g3 -ggdb settings
Hi Ariel, On Thu, Jun 30, 2022 at 12:38:49AM +0200, Ariel Burbaickij wrote: > Hello list, > any idea why private variables from C++ source files are not included into > symbols list with -g3 and -ggdb compilation settings in gcc version 11.3.0 > under Cygwin. Like that, roughly: > > grep isInProgress * > > :bool isInProgress; > > $nm -Cal |grep isInProgress > $ > > So, watchpoints obviously do not work. Why is it like this ? > > Kind Regards > Ariel Burbaickij > I had a similar problem with -g3 -ggdb: macros were not recognised. Using -g3 -gdwarf4 fixed that for me. IIUC -ggdb is supposed to select the optimum debug format for gdb. It may be a bug that it no longer does. HTH, Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: raise(-1) has stopped returning an error recently
On Wed, Nov 24, 2021 at 11:01:46AM -0700, cygwin wrote: [...] > Trying to rerun cygport build most tests are now "skipped test: failed to > find an adequate shell SKIP ... (exit status: 77)"! Something more may have > changed (in gnulib?) to invalidate Cygwin shell(s) in something updated > since that grep release in August, as I am getting the same skipped tests > under GitHub CI, although it could just be that something expects say bash > > 4.4 or even >= 5! > They all pass for me in a directory tree created by 'make dist' under Linux. Maybe something changed in your test environment? N.B. grep maintainer replaced my patch with a fancier one that creates new surrogate-search test that Cygwin skips. Cheers ... Duncan. PASS: backref PASS: backref-alt PASS: backref-multibyte-slow PASS: backref-word PASS: backslash-dot PASS: backslash-s-and-repetition-operators PASS: backslash-s-vs-invalid-multibyte big-hole: skipped test: expensive: disabled by default SKIP: big-hole big-match: skipped test: expensive: disabled by default SKIP: big-match PASS: binary-file-matches PASS: bogus-wctob PASS: bre PASS: c-locale PASS: case-fold-backref PASS: case-fold-backslash-w PASS: case-fold-char-class PASS: case-fold-char-range PASS: case-fold-char-type PASS: case-fold-titlecase PASS: char-class-multibyte PASS: char-class-multibyte2 PASS: context-0 PASS: count-newline PASS: dfa-coverage PASS: dfa-heap-overrun PASS: dfa-infloop PASS: dfa-invalid-utf8 PASS: dfaexec-multibyte PASS: empty PASS: empty-line PASS: empty-line-mb PASS: encoding-error PASS: epipe XFAIL: equiv-classes PASS: ere PASS: euc-mb false-match-mb-non-utf8: skipped test: no support for the zh_CN.gb18030 locale SKIP: false-match-mb-non-utf8 PASS: fedora PASS: fgrep-infloop PASS: fgrep-longest PASS: file PASS: filename-lineno.pl PASS: fmbtest PASS: foad1 PASS: grep-dev-null PASS: grep-dev-null-out PASS: grep-dir ratio=0 PASS: hash-collision-perf PASS: help-version PASS: high-bit-range PASS: in-eq-out-infloop PASS: include-exclude PASS: inconsistent-range PASS: initial-tab PASS: invalid-multibyte-infloop PASS: khadafy PASS: kwset-abuse long-line-vs-2GiB-read: skipped test: expensive: disabled by default SKIP: long-line-vs-2GiB-read long-pattern-perf: skipped test: expensive: disabled by default SKIP: long-pattern-perf many-regex-performance: skipped test: expensive: disabled by default SKIP: many-regex-performance PASS: match-lines PASS: max-count-overread PASS: max-count-vs-context PASS: mb-dot-newline PASS: mb-non-UTF8-overrun PASS: mb-non-UTF8-perf-Fw mb-non-UTF8-performance: skipped test: expensive: disabled by default SKIP: mb-non-UTF8-performance PASS: mb-non-UTF8-word-boundary warning: \s failed to match \x0a in the en_US.UTF-8 locale warning: \s failed to match \x85 in the en_US.UTF-8 locale warning: \s failed to match \xe2\x80\x8b in the en_US.UTF-8 locale warning: \S mistakenly matched \xe2\x80\x8b in the en_US.UTF-8 locale PASS: multibyte-white-space PASS: multiple-begin-or-end-line PASS: null-byte PASS: options pcre: skipped test: no PCRE support SKIP: pcre pcre-abort: skipped test: no PCRE support SKIP: pcre-abort pcre-context: skipped test: no PCRE support SKIP: pcre-context pcre-count: skipped test: no PCRE support SKIP: pcre-count pcre-infloop: skipped test: no PCRE support SKIP: pcre-infloop pcre-invalid-utf8-infloop: skipped test: no PCRE support SKIP: pcre-invalid-utf8-infloop pcre-invalid-utf8-input: skipped test: no PCRE support SKIP: pcre-invalid-utf8-input pcre-jitstack: skipped test: no PCRE support SKIP: pcre-jitstack pcre-o: skipped test: no PCRE support SKIP: pcre-o pcre-utf8: skipped test: no PCRE support SKIP: pcre-utf8 pcre-w: skipped test: no PCRE support SKIP: pcre-w pcre-wx-backref: skipped test: no PCRE support SKIP: pcre-wx-backref pcre-z: skipped test: no PCRE support SKIP: pcre-z PASS: posix-bracket PASS: prefix-of-multibyte PASS: proc PASS: r-dot PASS: repetition-overflow PASS: reversed-range-endpoints PASS: sjis-mb PASS: skip-device PASS: skip-read PASS: spencer1 PASS: spencer1-locale PASS: stack-overflow PASS: status PASS: surrogate-pair surrogate-search: skipped test: surrogate-pair search string on Cygwin, where it cannot work SKIP: surrogate-search PASS: symlink triple-backref: expect malfunction on glibc systems due to https://sourceware.org/bugzilla/show_bug.cgi?id=11053 XFAIL: triple-backref PASS: turkish-I PASS: turkish-I-without-dot turkish-eyes: skipped test: your tr_TR.UTF-8 locale appears to be broken SKIP: turkish-eyes PASS: two-chars PASS: two-files PASS: unibyte-binary PASS: unibyte-bracket-expr PASS: unibyte-negated-circumflex PASS: utf8-bracket PASS: warn-char-classes PASS: word-delim-multibyte PASS: word-multi-file PASS: word-multibyte PASS: write-error-msg PASS: yesno PASS: z-anchor-newline Testsuite summary for GNU grep 3.7.42-9c15 # TOTAL: 118 #
Re: raise(-1) has stopped returning an error recently
On Wed, Nov 24, 2021 at 10:25:46AM +0100, cygwin wrote: [...] > > What is that "permanent restriction" in Cygwin? Is that something we > could fix or something unfixable? Did you try to debug Cygwin in terms > of that problem? If not, could you extract a reduced, very simple > stand-alone testcase for further debugging? > The restriction is in grep/gnulib source. From https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27555#5 >> I've determined the cause, at least. The sole caller of mbstoupper >> (which contained the relevant __CYGWIN__-specific >> surrogate-pair-handling code) was removed by the improvements of >> v2.21-63-g8a33cde, and not long after, I noticed that mbstoupper was >> no longer used, so removed it altogether. I submitted a patch to save anyone else wasting time over this. So please don't you, Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: raise(-1) has stopped returning an error recently
On Tue, Nov 23, 2021 at 11:18:25AM -0700, Brian Inglis wrote:
> On 2021-11-23 02:50, Corinna Vinschen via Cygwin wrote:
> > On Nov 23 19:27, Duncan Roe wrote:
> > > On Mon, Nov 22, 2021 at 02:06:19PM +0100, cygwin wrote:
> > > > On Nov 22 11:25, Corinna Vinschen via Cygwin wrote:
> > > > > On Nov 22 16:20, Duncan Roe wrote:
> > > > > > #include
> > > > > > #include
> > > > > >
> > > > > > int
> > > > > > main (void)
> > > > > > {
> > > > > >int retcod;
> > > > > >
> > > > > >retcod = raise (-1);
> > > > > >printf("raise(-1) returned %d\n", retcod);
> > > > > > }
> > > > >
> > > > > Thanks for the STC. There are actually two long-standing problems,
> > > > > one in raise, calling pthread_kill even for non-threaded processes,
> > > > > one in pthread_kill, not checking the signal number.
> > > > >
> > > > > I'll patch them right away.
> > > >
> > > > I created a patchset:
> > > > https://sourceware.org/git?p=newlib-cygwin.git;a=commitdiff;h=d54d8f173d66
> > > > https://sourceware.org/git?p=newlib-cygwin.git;a=commitdiff;h=24b63eb7
> > > > https://sourceware.org/git?p=newlib-cygwin.git;a=commitdiff;h=afb7c557d2af
> > > >
> > > > Please test the latest developer snapshot from
> > > > http://cygwin.com/snapshots/
> > >
> > > Thanks, that fixed it.
> >
> > Thanks for testing.
> >
> > > Btw to whoever maintains grep for cygwin: 'make check' should pass on
> > > next release (I patched out the surrogate-pair failre).
>
> I had no problems with test-raise last release.
I don't remember having a problem with it even a few weeks ago.
> I did with surrogate pairs but after spending too much time on all the test
> infrastructure around that, decided it was a low probability event, and wait
> until anyone complains to refer it upstream.
I wasted time on that too. That's why I patched surrogate-pair to not do its 3rd
test if 'uname -s' indicates Cygwin.
For the full story, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27555#5
> Do Cygwin and/or Windows support surrogate pairs in UTF-8?
There are 3 tests in surrogate-pair and only the 3rd one failed. So I guess
surrogate pairs in UTF-8 "mostly work".
Cheers ... Duncan.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: raise(-1) has stopped returning an error recently
On Mon, Nov 22, 2021 at 02:06:19PM +0100, cygwin wrote:
> On Nov 22 11:25, Corinna Vinschen via Cygwin wrote:
> > On Nov 22 16:20, Duncan Roe wrote:
> > > Hi,
> > >
> > > I stumbled across this when running 'make check' in the grep source
> > > directory.
> > >
> > > test-raise failed when it didn't a few weeks ago.
> >
> > Pretty unlikely. This code didn;'t change for ages. I just checked
> > against Cygwin 3.2.0 and it also returns success.
> >
> > > #include
> > > #include
> > >
> > > int
> > > main (void)
> > > {
> > > int retcod;
> > >
> > > retcod = raise (-1);
> > > printf("raise(-1) returned %d\n", retcod);
> > > }
> >
> > Thanks for the STC. There are actually two long-standing problems,
> > one in raise, calling pthread_kill even for non-threaded processes,
> > one in pthread_kill, not checking the signal number.
> >
> > I'll patch them right away.
>
> I created a patchset:
> https://sourceware.org/git?p=newlib-cygwin.git;a=commitdiff;h=d54d8f173d66
> https://sourceware.org/git?p=newlib-cygwin.git;a=commitdiff;h=24b63eb7
> https://sourceware.org/git?p=newlib-cygwin.git;a=commitdiff;h=afb7c557d2af
>
> Please test the latest developer snapshot from http://cygwin.com/snapshots/
>
>
> Thanks,
> Corinna
Thanks, that fixed it.
Btw to whoever maintains grep for cygwin: 'make check' should pass on
next release (I patched out the surrogate-pair failre).
Cheers ... Duncan.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
raise(-1) has stopped returning an error recently
Hi,
I stumbled across this when running 'make check' in the grep source directory.
test-raise failed when it didn't a few weeks ago. I cut it down to the STC at
the end of this email
Under Linux:
> 16:15:57$ ./test-raise
> raise(-1) returned -1
Under Cygwin:
> 16:16:51$ ./test-raise.exe
> raise(-1) returned 0
Hope this is nothing too complicated,
Cheers ... Duncan.
#include
#include
int
main (void)
{
int retcod;
retcod = raise (-1);
printf("raise(-1) returned %d\n", retcod);
}
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygport build injecting /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/ paths
On Fri, Nov 12, 2021 at 01:25:48PM -0700, Brian Inglis wrote: > On 2021-11-12 12:18, Ken Brown via Cygwin wrote: [...] > Now should I patch /usr/bin/libtool, libtoolize the sources, cygautoreconf, > or upgrade libtool? > Anyone have any ideas for the best approach? > Or just go for it and try each in turn in case something works? > autoreconf -fi rm -Rf autom4te.cache (taken from autogen.sh in various netfilter prokects) Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygport build injecting /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/ paths
On Fri, Nov 12, 2021 at 10:50:41AM -0700, Brian Inglis wrote: > Got these errors trying to build latest ncurses on my system, so retried on > scallywag and got same result, with no clue where that is coming from! > There are no files in the tarball, repo, or build dirs containing 7.4.0 but > it looks suspiciously like the package version 6.3.0 incremented! > Anyone ever seen these kinds of artifacts, or aware of any code doing this > kind of incrementing? > > $ fgrep 7.4.0 scallywag/*86*/6_Build\ packages.log > scallywag/i686/6_Build packages.log:2021-11-12T09:54:57.1027256Z libtool: > link: g++ -shared -nostdlib /usr/lib/gcc/i686-pc-cygwin/7.4.0/crtbeginS.o > ../obj_lo/.libs/cursesf.o ../obj_lo/.libs/cursesm.o > ../obj_lo/.libs/cursesw.o ../obj_lo/.libs/cursespad.o > ../obj_lo/.libs/cursesp.o ../obj_lo/.libs/cursslk.o > ../obj_lo/.libs/cursesapp.o ../obj_lo/.libs/cursesmain.o > -L/cygdrive/d/a/scallywag/ncurses/ncurses-6.3-1.20211106.i686/build/lib/.libs > -L../lib > /cygdrive/d/a/scallywag/ncurses/ncurses-6.3-1.20211106.i686/build/lib/.libs/libformw.dll.a > > /cygdrive/d/a/scallywag/ncurses/ncurses-6.3-1.20211106.i686/build/lib/.libs/libmenuw.dll.a > > /cygdrive/d/a/scallywag/ncurses/ncurses-6.3-1.20211106.i686/build/lib/.libs/libpanelw.dll.a > ../lib/.libs/libformw.dll.a ../lib/.libs/libmenuw.dll.a > ../lib/.libs/libpanelw.dll.a > /cygdrive/d/a/scallywag/ncurses/ncurses-6.3-1.20211106.i686/build/lib/.libs/libncursesw.dll.a > ../lib/.libs/libncursesw.dll.a -lutil -L/usr/lib/gcc/i686-pc-cygwin/7.4.0 > -L/usr/lib/gcc/i686-pc-cygwin/7.4.0/../../../../i686-pc-cygwin/lib > -L/usr/lib/gcc/i686-pc-cygwin/7.4.0/../../.. -lstdc++ -lgcc_s -lgcc -lcygwin > -ladvapi32 -lshell32 -luser32 -lkernel32 -lgcc_s -lgcc > /usr/lib/gcc/i686-pc-cygwin/7.4.0/crtend.o -ggdb -O2 > -fstack-protector-strong -o .libs/cygncurses++w-10.dll > -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker > .libs/libncurses++w.dll.a > scallywag/i686/6_Build packages.log:2021-11-12T09:54:57.1848593Z > /usr/lib/gcc/i686-pc-cygwin/11/../../../../i686-pc-cygwin/bin/ld: cannot > find /usr/lib/gcc/i686-pc-cygwin/7.4.0/crtbeginS.o: No such file or > directory > scallywag/i686/6_Build packages.log:2021-11-12T09:54:57.3516554Z > /usr/lib/gcc/i686-pc-cygwin/11/../../../../i686-pc-cygwin/bin/ld: cannot > find /usr/lib/gcc/i686-pc-cygwin/7.4.0/crtend.o: No such file or directory > scallywag/x86_64/6_Build packages.log:2021-11-12T09:52:54.1343744Z libtool: > link: g++ -shared -nostdlib /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/crtbeginS.o > ../obj_lo/.libs/cursesf.o ../obj_lo/.libs/cursesm.o > ../obj_lo/.libs/cursesw.o ../obj_lo/.libs/cursespad.o > ../obj_lo/.libs/cursesp.o ../obj_lo/.libs/cursslk.o > ../obj_lo/.libs/cursesapp.o ../obj_lo/.libs/cursesmain.o > -L/cygdrive/d/a/scallywag/ncurses/ncurses-6.3-1.20211106.x86_64/build/lib/.libs > -L../lib > /cygdrive/d/a/scallywag/ncurses/ncurses-6.3-1.20211106.x86_64/build/lib/.libs/libformw.dll.a > > /cygdrive/d/a/scallywag/ncurses/ncurses-6.3-1.20211106.x86_64/build/lib/.libs/libmenuw.dll.a > > /cygdrive/d/a/scallywag/ncurses/ncurses-6.3-1.20211106.x86_64/build/lib/.libs/libpanelw.dll.a > ../lib/.libs/libformw.dll.a ../lib/.libs/libmenuw.dll.a > ../lib/.libs/libpanelw.dll.a > /cygdrive/d/a/scallywag/ncurses/ncurses-6.3-1.20211106.x86_64/build/lib/.libs/libncursesw.dll.a > ../lib/.libs/libncursesw.dll.a -lutil -L/usr/lib/gcc/x86_64-pc-cygwin/7.4.0 > -L/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/lib/../lib > -L/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../lib -L/lib/../lib > -L/usr/lib/../lib > -L/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/lib > -L/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../.. -lstdc++ -lgcc_s -lgcc > -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lgcc_s -lgcc > /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/crtend.o -ggdb -O2 > -fstack-protector-strong -o .libs/cygncurses++w-10.dll > -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker > .libs/libncurses++w.dll.a > scallywag/x86_64/6_Build packages.log:2021-11-12T09:52:54.2146113Z > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: cannot > find /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/crtbeginS.o: No such file or > directory > scallywag/x86_64/6_Build packages.log:2021-11-12T09:52:54.4873238Z > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: cannot > find /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/crtend.o: No such file or directory > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in binary units and prefixes, physical quantities in SI.] > Try env | grep -E 7\.4\.0 I had a kind-of similar problem from having LIBS in the environment. Otherwise on a freshly restored tarball before even running ./configure: find . -type f|xargs grep -E 7\.4\.0 find . -name '*7.4.0*' btw fgrep and egrep are retired at GNU grep 3.7
Re: Problem or question on Cygwin XWin
On Mon, Jun 14, 2021 at 04:41:42PM -0700, L A Walsh wrote: > There is a listen parameter on XWin, but the man page doesn't > say what format to use for the listen parameter. > > I want to have it listen for tcp from a local net: 192.168.3.0. > > I started having problems with my cygwin X receiving > network connections via TCP, locally (like 192.168.3.1 => 192.168.3.12). > > And was trying to figure out what the syntax was for specifying what > net to have it listen on. > > Thanks! > At least under Linux, 'man Xserver' gives the format "-listen trans-type" with example "-listen tcp". You can '-[no]listen' to tcp, inet (i.e.IP4), inet6, unix or local. Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: odd prob for cygwin 'dd' from a character device on network disk
On Thu, Jun 10, 2021 at 08:20:30PM -0700, L A Walsh wrote: > On 2021/06/09 19:23, Duncan Roe wrote: > > > > > nfs / nodev? > > > I'm not sure what you mean or are asking. > I'm not using nfs...but cygwin. > > The file 'zero' is in the same dir as the file 'null'. > I usually read 'zero' and write to 'null, though > for 1-way testing, I read from file 'zero' on the remote > file system and write, locally to /dev/null. > > For other direction write to 'null' and read from > /dev/zero locally. > > When you said you were accessing zero over the network, you didn't say how so I suggested if you were using nfs then nodev might be the culprit. How are you accessing files aver the network? I suspect that whatever mechanism you are using has the equivalent of the nfs nodev feature (part of nfsmount, may be specified in fstab) and the nodev equivalent is turned on in your case. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: odd prob for cygwin 'dd' from a character device on network disk
On Wed, Jun 09, 2021 at 06:19:43PM -0700, L A Walsh wrote: > I've been using a character device on linux in my > home directory named 'zero' that is a copy of the > 'zero' device in /dev: > crwxrwxrw- 1 1, 5 Jun 15 2015 zero > > to do read benchmarks using 'dd' (and write benchmarks > using a file named 'null' thats a copy of /dev/null). > > I run it "occasionally", but not on a regular basis, since > it stays a bit boring. Nevertheless, ballpark numbers > consistent with historical norms verify correct network > function (separate from read/write files). Read/write speeds > at last check a few weeks ago were typical with > reads at 700MB/s and writes at about 300MB/s. > > A few hours ago I tried it again due to some strange network > probs where I seemed to be getting file xfer speeds as low > as 200K/s. > > I tried the bench script, and its half broken now -- because > I can no longer get anything back from the zero device > on my server via the network. Locally, I can do 'dd' from > /dev/zero (or the zero file) and it takes a few seconds and > gave about 800MB/s. So seemed to have been working fine, > but remotely -- still nada... reads 0 bytes from /dev/zero > and about 300MB/s write speed. > > Can anyone think of anything that might have changed in > cygwin such that it would know the remote device is a > "/dev/zero". Wondered if the 'dd' prog might have changed, > but just realize it did same with 'cat' as well. > > Anyway -- I'm a bit stumped as to possible causes... > The writing to a remote /dev/null part is still working, > so not sure why one would change and not the other. > > If anyone can think of anything, please let me know -- I'm > also gonna ping the samba list and maybe my distro list > > Thanks! > -linda > nfs / nodev? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Test message - please ignore
On Sun, May 02, 2021 at 12:43:41PM +1000, Duncan Roe wrote: > Hi Chris, > > On Sat, May 01, 2021 at 09:41:26PM -0400, Christopher Faylor wrote: > > On Sat, May 01, 2021 at 11:47:46AM +1000, Duncan Roe wrote: > > >Test ezmlm replacement > > > > Please don't send test messages. If you have something to say, > > send the message. That will show you if your mail made it through or > > not. If you don't have anything to post about then there's no need for > > hundreds of people to see your test. > > > Thank you for replying. I assumed no-one saw the message since I didn't see > it. > > So - what is going on? Does the new list manager assume no copy to sender? I > always used to see my emails to the list. > > Cheers ... Duncan. I saw that one so ... sorry for the noise. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Test message - please ignore
Hi Chris, On Sat, May 01, 2021 at 09:41:26PM -0400, Christopher Faylor wrote: > On Sat, May 01, 2021 at 11:47:46AM +1000, Duncan Roe wrote: > >Test ezmlm replacement > > Please don't send test messages. If you have something to say, > send the message. That will show you if your mail made it through or > not. If you don't have anything to post about then there's no need for > hundreds of people to see your test. > Thank you for replying. I assumed no-one saw the message since I didn't see it. So - what is going on? Does the new list manager assume no copy to sender? I always used to see my emails to the list. Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Test message - please ignore
Test ezmlm replacement -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Tee and file redirections are very slow to write anything.
On Wed, Feb 24, 2021 at 04:58:24PM -0500, Eliot Moss wrote: > On 2/24/2021 3:48 PM, ASSI wrote: > > Hamish McIntyre-Bhatty via Cygwin writes: > > > I found recently when trying to save output from a script for later > > > inspection that "tee" and file redirections seem to have massive > > > delays when run in Cygwin - usually nothing is written to file or > > > stdout until after the command has finished - not very helpful. > > > > You will want to switch from fully buffered to line-buffered or even > > unbuffered output. > > And this does not have to do with Cygwin. The same happens on Linux. > The default is that terminal I/O is unbuffered while other stream are > buffered. Pipes come under "other streams". One can make programmatic > changes to get around this, but most programs won't override the > default behavior on their own ... > > Best -- Eliot Moss The (Linux) default is that terminal I/O is *line* buffered The man page for tee doesn't show an option to change buffering, while that for grep does. Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: blockdev.exe is missing in util-linux. How to determine block device size in bash?
On Sat, Dec 05, 2020 at 12:43:25PM +0300, cygwin wrote: > Strange. On Win7 this doesn't work: > > il@mar2 /cygdrive/c/Windows/System32 > $ cat /proc/partitions > major minor #blocks name win-mounts > > 8 0 0 sda > 816 0 sdb > > il@mar2 /cygdrive/c/Windows/System32 > $ dd of=/dev/null if=/dev/sda bs=1M count=100 > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB, 100 MiB) copied, 0.215181 s, 487 MB/s > > > On 28.11.2020 20:04, Brian Inglis wrote: > > $ cat /proc/partitions > > major minor #blocks name win-mounts > > > > 8 0 976762584 sda > > 8 1 16384 sda1 > > 8 2 97678 sda2 C:\ > > 816 976762584 sdb > > 817131072 sdb1 > > 818102400 sdb2 > > 819 975482161 sdb3 D:\ > > 820577536 sdb4 > > 821465920 sdb5 > > 832 0 sdc WFFM with Win7 Home 12:34:05$ cat /proc/partitions major minor #blocks name win-mounts 8 0 488386584 sda 8 1203776 sda1 8 2 467246080 sda2 C:\ 8 3 20829184 sda3 D:\ 8 4105472 sda4 F:\ Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: BUG: command invocation misinterpreted as variable setting, SOMETIMES.
Hi Jason,
On Fri, Nov 20, 2020 at 02:52:09PM +, cygwin wrote:
>
> Good day -
>
> I am using a fairly up-to-date Cygwin:
>release: cygwin
>arch: x86_64
>setup-timestamp: 1603379981
>include-setup: setup <2.878 not supported
>setup-minimum-version: 2.895
>setup-version: 2.905
> , bash version : 4.4.12(3)-release
> on Windows 10 :
>EditionWindows 10 Pro
>Version20H2
>OS build 19042.630
>Experience Windows Feature Experience Pack 120.2212.31.0
> , which I am forced to use for a work related Visual Studio project,
> , running in a Qemu/KVM VM under Fedora-32 on a modern X86_64 Dell XPS
> laptop, and am experiencing some strange and disconcerting behaviour:
>
> I am a complete novice Windows user, I have used only BSD / Solaris
> / AIX / HP-UX / MacOSX / z/OS or Linux since 1990, so I am an advanced UNIX
> shell script user & C/C++ + LISP + PERL programmer (I prefer LISP nowadays).
>
> I have to run a script with an alternate setting of $HOME, so I do:
>
>$ HOME="C:\\USERS\\JVD\\" sbcl --script "C:\\${path-to-my-script}.lisp"
>
> This works, but now:
>
>$ cd ~
>-bash: cd: "C:\\USERS\\JVD\\" sbcl --script
> "C:\\${path-to-my-script}.lisp": No such file or directory
>$ echo $HOME
>/home/JVD
>
> This is very weird! "$HOME" is still set to its /etc/bash.bashrc set
> default, but evaluation of 'echo ~', which I thought should be
> equivalent to 'echo $HOME', yields the last command to be prefixed
> by a command-specific HOME=... setting .
>
> I think this is a bug. Since setting HOME=... has no effect now,
> (it still has its correct value),
> use of '~' is now effectively disabled for this shell session .
>
> What is 'echo ~' doing other than 'echo $HOME' ?
If you had tried 'set -x' you would have seen what it does: tilde expansion is
done by bash before the echo command is invoked. So you would see something like
'echo /home/jvd'.
Could it be that 'sbcl' has popped a new bash command level?
I can't reproduce your issue with a simple command instead of 'sbcl' e.g.
> 09:33:42$ HOME="C:\\USERS\\DUNCAN\\" pwd
> /home/dunc
> 09:34:02$ echo ~
> /home/dunc
>
[...]
>
Cheers ... Duncan.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Failed assertion dialog box ATTN: Takashi Yano
On Fri, Nov 20, 2020 at 09:19:29AM +0900, cygwin wrote: > Hi all, > > On Fri, 20 Nov 2020 11:06:58 +1100 > Duncan Roe wrote: > > On Thu, Nov 19, 2020 at 07:30:20PM +0100, Thomas Wolff wrote: > > > > > > It does not seem to happen in xterm which is weird. > > > > It happens in an xterm for me. > > xterm is /dev/pty1 and mintty is /dev/pty0. They both do it. > > So I think it has to be pseudo-console. > > (xterm has DISPLAY set to a Linux system but that shouldn't matter should > > it?) > > Could you please try latest cygwin snapshot? > > -- > Takashi Yano Tried 20200909 - no popup Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Failed assertion dialog box ATTN: Takashi Yano
On Fri, Nov 20, 2020 at 09:19:29AM +0900, cygwin wrote: > Hi all, > > On Fri, 20 Nov 2020 11:06:58 +1100 > Duncan Roe wrote: > > On Thu, Nov 19, 2020 at 07:30:20PM +0100, Thomas Wolff wrote: > > > > > > It does not seem to happen in xterm which is weird. > > > > It happens in an xterm for me. > > xterm is /dev/pty1 and mintty is /dev/pty0. They both do it. > > So I think it has to be pseudo-console. > > (xterm has DISPLAY set to a Linux system but that shouldn't matter should > > it?) > > Could you please try latest cygwin snapshot? > > -- > Takashi Yano Never done that before. How do I get it? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Failed assertion dialog box ATTN: Takashi Yano
On Thu, Nov 19, 2020 at 07:30:20PM +0100, Thomas Wolff wrote: > > It does not seem to happen in xterm which is weird. It happens in an xterm for me. xterm is /dev/pty1 and mintty is /dev/pty0. They both do it. So I think it has to be pseudo-console. (xterm has DISPLAY set to a Linux system but that shouldn't matter should it?) > It does however also happen in rxvt-unicode, xfce4-terminal, and vte. > The message text of the popup can be easily found in cygwin code. > Thomas Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Failed assertion dialog box
On Fri, Nov 13, 2020 at 11:21:12PM -0500, cygwin wrote:
> On Fri, Nov 13, 2020 at 10:45 PM Duncan Roe
> wrote:
>
> > Hi William,
> >
> > On Fri, Nov 13, 2020 at 12:27:57PM -0500, cygwin wrote:
> > > I've run into a problem running a collection of tests under Cygwin and I
> > > wonder if anyone can suggest a way around it.
> > >
> > > The problem occurs when a program being run fails a C/C++ runtime
> > > assertion. Ordinarily, this just writes an error message on stderr and
> > > aborts. Under Cygwin, however, if both stdin and stderr are redirected to
> > > files, the program instead pops up a dialog box that must be
> > interactively
> > > dismissed before the failed program will exit - holding up all the tests
> > > that follow it.
> > >
> > > Specifically, if I have the following as assert.cpp:
> > >
> > > #include
> > > int main() {
> > > assert(false);
> > > }
> > >
> > > and say
> > >
> > > gcc assert.cpp
> > > ./a.exe < /dev/null > output 2>&1
> > >
> > > I get an error dialog box saying
> > >
> > > Failed assertion
> > > false
> > > at line 3 of file assert.cpp
> > > in function int main()
> > >
> > > If I omit either the stdin or the stderr redirection, the program behaves
> > > as desired with no dialog box.
> > >
> > > Is there an environment setting or compiler command-line option I can
> > give
> > > to suppress the dialog box and always just write a message to stderr and
> > > abort? Thanks for any insights.
> >
> > Your example WFFM, (Cygwin64, gcc 10.2.0, everything else also up to date).
> >
> > Do you still see this behaviour if you run the installer?
> >
>
> Thanks for your reply; unfortunately, yes, it does. I had refreshed
> the installation fairly recently, and running the installer only updated a
> few things, not cygwin.dll and not gcc; my installation is the same as
> yours. I've tried it with three different shells (tcsh, bash, mksh) and
> with both gcc and clang, and all have the same behavior. (Interestingly, if
> I compile the example with MSVC and run it in a Cygwin shell, it does _not_
> pop up an error dialog box, so presumably it's in the Cygwin runtime,
> specifically the definition of __assert_func.)
>
> --
> William M. (Mike) Miller | Edison Design Group
> william.m.mil...@gmail.com
Sorry, should have mentioned running on Win7 Home.
When I try it on my wife's Win10 system, I get the dialog box same as you.
Cheers ... Duncan.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Failed assertion dialog box
Hi William,
On Fri, Nov 13, 2020 at 12:27:57PM -0500, cygwin wrote:
> I've run into a problem running a collection of tests under Cygwin and I
> wonder if anyone can suggest a way around it.
>
> The problem occurs when a program being run fails a C/C++ runtime
> assertion. Ordinarily, this just writes an error message on stderr and
> aborts. Under Cygwin, however, if both stdin and stderr are redirected to
> files, the program instead pops up a dialog box that must be interactively
> dismissed before the failed program will exit - holding up all the tests
> that follow it.
>
> Specifically, if I have the following as assert.cpp:
>
> #include
> int main() {
> assert(false);
> }
>
> and say
>
> gcc assert.cpp
> ./a.exe < /dev/null > output 2>&1
>
> I get an error dialog box saying
>
> Failed assertion
> false
> at line 3 of file assert.cpp
> in function int main()
>
> If I omit either the stdin or the stderr redirection, the program behaves
> as desired with no dialog box.
>
> Is there an environment setting or compiler command-line option I can give
> to suppress the dialog box and always just write a message to stderr and
> abort? Thanks for any insights.
>
> --
> William M. (Mike) Miller | Edison Design Group
> william.m.mil...@gmail.com
> --
Your example WFFM, (Cygwin64, gcc 10.2.0, everything else also up to date).
Do you still see this behaviour if you run the installer?
Cheers ... Duncan.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin-64 on W10-64 : the only game in town?
On Sun, Nov 01, 2020 at 08:49:23AM +, cygwin wrote: > With W7 no longer supported, W10-32 supported but no longer provided on > new machines (Microsoft states that, "Beginning with Windows 10, version > 2004, all new Windows 10 systems will be required to use 64-bit builds > and Microsoft will no longer release 32-bit builds for OEM distribution > .. the weaker version of Windows 10 has several limitations, like > capping out at 3.2GB of RAM and less stringent security measures") and > the functionality of Cygwin-32 significantly downplayed on Cygwin's own > Home page, that really does leave Cygwin-64 on W10-64 on 64-bit hardware > as the sole recommended platform. Yes? > > -- No, I run Cygwin64 on Win 7. There is an outstanding W7 update, it appeared a few weeks ago, but I'm not taking it. Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: GDB missing libraries after upgrade
On Sat, Oct 31, 2020 at 02:09:28PM +0900, cygwin wrote: > On Sat, 31 Oct 2020 14:56:14 +1100, Duncan Roe > > On Sat, Oct 31, 2020 at 02:30:07PM +1100, Duncan Roe wrote: > > > Hi, > > > > > > Updated cygwin64 this morning and now gdb won't start. > > > > > > cygcheck shows 2 missing libraries: > > > > > > 14:10:32$ cygcheck gdb > > > Found: C:\cygwin64\bin\gdb.exe > > > C:\cygwin64\bin\gdb.exe > > > C:\cygwin64\bin\cygwin1.dll > > > C:\Windows\system32\KERNEL32.dll > > > C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll > > > C:\Windows\system32\ntdll.dll > > > C:\Windows\system32\KERNELBASE.dll > > > C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll > > > C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll > > > C:\cygwin64\bin\cygexpat-1.dll > > > C:\cygwin64\bin\cygiconv-2.dll > > > C:\cygwin64\bin\cygintl-8.dll > > > C:\cygwin64\bin\cyglzma-5.dll > > > C:\cygwin64\bin\cygmpfr-6.dll > > > C:\cygwin64\bin\cyggmp-10.dll > > > C:\cygwin64\bin\cyggcc_s-seh-1.dll > > > C:\cygwin64\bin\cygncursesw-10.dll > > > C:\cygwin64\bin\libpython3.6m.dll > > > C:\cygwin64\bin\cygreadline7.dll > > > C:\cygwin64\bin\cygsource-highlight-4.dll > > > C:\cygwin64\bin\cygstdc++-6.dll > > > C:\cygwin64\bin\cygboost_regex-1_66.dll > > > C:\cygwin64\bin\cygz.dll > > > cygcheck: track_down: could not find cygicui18n61.dll > > > > > > cygcheck: track_down: could not find cygicuuc61.dll > > > > > > > > > Where do I get them from? > > > > > > Cheers ... Duncan. > > > > Reverting to gdb 8.2.1-1 works. So looks like gdb 8.3.1-1 needs the extra > > libraries. > > > > Cheers ... Duncan. > > > libicu61 provides them. > > https://www.cygwin.com/packages/summary/libicu61.html > https://www.cygwin.com/packages/x86_64/libicu61/libicu61-61.1-1 > libicu61: IBM Internationalization Components for Unicode > 2018-03-27 01:1526896896 usr/bin/cygicudata61.dll > 2018-03-27 01:15 2395155 usr/bin/cygicui18n61.dll > 2018-03-27 01:15 48147 usr/bin/cygicuio61.dll > 2018-03-27 01:15 1542163 usr/bin/cygicuuc61.dll > > -- > > $ cygcheck -p cygicui18n61.dll cygicuuc61.dll > Found 1 matches for cygicui18n61.dll > libicu61-61.1-1 - libicu61: IBM Internationalization Components for Unicode > > $ cygcheck -p cygicuuc61.dll > Found 1 matches for cygicuuc61.dll > libicu61-61.1-1 - libicu61: IBM Internationalization Components for Unicode > > -- > > > Lem > -- Thanks. Installer said libicu61 was installed already, but after a reinstall gdb 8.3.1-1 was fine. Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: GDB missing libraries after upgrade
On Sat, Oct 31, 2020 at 02:30:07PM +1100, Duncan Roe wrote: > Hi, > > Updated cygwin64 this morning and now gdb won't start. > > cygcheck shows 2 missing libraries: > > 14:10:32$ cygcheck gdb > Found: C:\cygwin64\bin\gdb.exe > C:\cygwin64\bin\gdb.exe > C:\cygwin64\bin\cygwin1.dll > C:\Windows\system32\KERNEL32.dll > C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll > C:\Windows\system32\ntdll.dll > C:\Windows\system32\KERNELBASE.dll > C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll > C:\cygwin64\bin\cygexpat-1.dll > C:\cygwin64\bin\cygiconv-2.dll > C:\cygwin64\bin\cygintl-8.dll > C:\cygwin64\bin\cyglzma-5.dll > C:\cygwin64\bin\cygmpfr-6.dll > C:\cygwin64\bin\cyggmp-10.dll > C:\cygwin64\bin\cyggcc_s-seh-1.dll > C:\cygwin64\bin\cygncursesw-10.dll > C:\cygwin64\bin\libpython3.6m.dll > C:\cygwin64\bin\cygreadline7.dll > C:\cygwin64\bin\cygsource-highlight-4.dll > C:\cygwin64\bin\cygstdc++-6.dll > C:\cygwin64\bin\cygboost_regex-1_66.dll > C:\cygwin64\bin\cygz.dll > cygcheck: track_down: could not find cygicui18n61.dll > > cygcheck: track_down: could not find cygicuuc61.dll > > > Where do I get them from? > > Cheers ... Duncan. Reverting to gdb 8.2.1-1 works. So looks like gdb 8.3.1-1 needs the extra libraries. Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
GDB missing libraries after upgrade
Hi, Updated cygwin64 this morning and now gdb won't start. cygcheck shows 2 missing libraries: 14:10:32$ cygcheck gdb Found: C:\cygwin64\bin\gdb.exe C:\cygwin64\bin\gdb.exe C:\cygwin64\bin\cygwin1.dll C:\Windows\system32\KERNEL32.dll C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll C:\Windows\system32\ntdll.dll C:\Windows\system32\KERNELBASE.dll C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll C:\cygwin64\bin\cygexpat-1.dll C:\cygwin64\bin\cygiconv-2.dll C:\cygwin64\bin\cygintl-8.dll C:\cygwin64\bin\cyglzma-5.dll C:\cygwin64\bin\cygmpfr-6.dll C:\cygwin64\bin\cyggmp-10.dll C:\cygwin64\bin\cyggcc_s-seh-1.dll C:\cygwin64\bin\cygncursesw-10.dll C:\cygwin64\bin\libpython3.6m.dll C:\cygwin64\bin\cygreadline7.dll C:\cygwin64\bin\cygsource-highlight-4.dll C:\cygwin64\bin\cygstdc++-6.dll C:\cygwin64\bin\cygboost_regex-1_66.dll C:\cygwin64\bin\cygz.dll cygcheck: track_down: could not find cygicui18n61.dll cygcheck: track_down: could not find cygicuuc61.dll Where do I get them from? Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Problems with native Unix domain sockets on Win 10/2019
On Fri, Sep 25, 2020 at 04:30:45PM -0400, cygwin wrote: > On 9/25/2020 2:50 PM, Ken Brown via Cygwin wrote: > > On 9/25/2020 10:29 AM, Michael McMahon wrote: > > > > > > > > > On 25/09/2020 14:19, Ken Brown wrote: > > > > On 9/24/2020 8:01 AM, Michael McMahon wrote: > > > > > > > > > > > > > > > On 24/09/2020 12:26, Ken Brown wrote: > > > > > > On 9/23/2020 7:25 AM, Michael McMahon via Cygwin wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I searched for related issues but haven't found anything. > > > > > > > > > > > > > > I am having some trouble with Windows native Unix domain sockets > > > > > > > (a recent feature in Windows 10 and 2019 server) and Cygwin. > > > > > > > I think I possibly know the cause since I had to investigate a > > > > > > > similar looking issue on another platform built on Windows. [SNIP} Perhaps the question here is: "Is it a bug that Cygwin rm can't remove a file system entry that no Cygwin program can create?" HTH Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Command line processing in dcrt0.cc does not match Microsoft parsing rules
Hi Eric, On Mon, Sep 09, 2019 at 11:57:21AM -0500, Eric Blake wrote: > On 9/9/19 11:47 AM, Stephen Provine via cygwin wrote: > > Argh, my mistake about top posting again. My email client does not help me > > with this by default and I have to manually construct quoting of previous > > responses and delete what shouldn't be there (and missed it again). If > > there's > > any way for someone to delete my previous message from the archive, please > > do. > > > > Why doesn't Cygwin utilize Github or something else more modern to manage > > issues? > > Just because it is "modern" does not necessarily make it better. > > https://www.gnu.org/software/repo-criteria-evaluation.en.html > > ranks github as worse than gitlab, in part because there is no way to > use the full power of github without surrendering to the use of non-free > software. No problems with that. I think though, that the OP's point was to use *git* (wherever the repo may be). Cheers ... Duncan. -- 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: bug with grep 3.0.2 in cygwin 3.0.7
On Thu, Aug 29, 2019 at 09:42:46PM -0400, Eliot Moss wrote: > On 8/29/2019 3:08 PM, Andrey Repin wrote: > > Greetings, ak...@free.fr! > > > > > Hi, > > > I encounter some problem with grep option -E on cygwin 3.0.7 > > > > > > > echo "a^b" | grep "a^b" #answer a^b ie it's OK > > > but > > > echo "a^b" | grep -E "a^b" #answer nothing " for me it's KO > > > > That's an expected result of an impossible constraint. > > > > > I have to backslash ^ to be OK like : grep -E 'a\^b' > > > > Yes. > > > > > Is-it a bug ? > > > > No. > > > > > I don't know if all versions of cygwin and grep are concerned. > > > > RTFM, this is regexp basics. > > There was a really great answer to this earlier. I tried an > answer, but was wrong. One has to read the "fine print" really > carefully. At first I thought it was a bug, at least in the > documentation, but the meaning of a^b, when ^ is the metacharacter, > is kind of subtle (IMO at least). It's easy to miss that > subtlety and think that if ^ is not at the beginning of an > expression it will be treated as an ordinary character ... > > But my main point is that RTM would be enough; RTFM seemed > to me perhaps a little more rude than necessary. > > Regards - EM > I don't see anything to object to in "Read The Fine Manual" ;) Cheers ... Duncan. -- 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: Error "fatal: write failure on 'stdout': No error" in native console
Hi Audrey, On Fri, Aug 16, 2019 at 01:36:58PM +0300, Andrey Repin wrote: > Greetings, All! > > I'm trying to resolve the problem at my new workplace, which seems to be > affecting the ability to use git with VS Code. > It just does not see the repo, no matter if I point its nose directly to the > directory. > > When toying around the terminal, I noticed that calling simple > > > git log | head -1 > commit 8f4c6f50a4c6becee2c6007fdb2e67be70fc06b6 > fatal: write failure on 'stdout': No error > > Bummer. I can't replicate it on my home system, which have more or less > identical setup. > Any pointers? > > P.S. > This all happens on Win7 PRO. > > > -- > With best regards, > Andrey Repin > Friday, August 16, 2019 13:32:30 > > Sorry for my terrible english... Cheap & cheerful solution: > git log | head -1 2>/dev/null You got your 1 line of output. The head program closes stdin after reading "n" lines. That sends SIGPIPE to the previous process, or EPIPE to write(), if SIGPIPE is caught. I suspect you are seeing the latter, but with errno not getting set properly for some reason. If you would care to experiment with a simple C program that outputs a few lines and try catching SIGPIPE you may well come up with an STC. Cheers ... Duncan. -- 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: `std::stod ("nan")` returns negative NaN
On Mon, Aug 13, 2018 at 12:52:48PM -0400, Stephen John Smoogen wrote:
> On Mon, 13 Aug 2018 at 11:16, Masamichi Hosoda wrote:
[...]
> On Fedora 27 with 7.3.1 it gives
> ```
> stod ("nan") = nan
> stod ("-nan") = nan
> quiet_NaN () = nan
> ```
[...]
Same with Slackware 14.2 / gcc (GCC) 5.3.0
--
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: My delayed complaint about spam on this list
On Mon, Jun 04, 2018 at 04:26:57PM -0400, Jeffrey Altman wrote: > > My mail servers regularly categorize cygwin at cygwin.com mail as spam. > > And then there is all of the mail that simply gets rejected because of > DMARC policies applied by the sender's domain. > > > There are other alternatives. > > I'm a member of a few mailing lists that accept e-mails from non-list > members but only after the non-list member successfully accesses a URL > that is mailed to the sender's address. > > Would something like that be possible for the cygwin lists? > > Jeffrey Altman > I'm a member of a list in which posts from non-members are moderated. Would that be a possibility here? I realise it's an extra task for someone, but as it is we are all wasting our time discarding spam. And there's no need for moderation to be *prompt* Cheers ... Duncan. -- 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: Floating point exception in strtod()
On Sat, Apr 07, 2018 at 04:56:13PM -0400, Eliot Moss wrote:
> On 4/7/2018 1:40 PM, Ken Brown wrote:
> > $ cat strtod_test.c
> > #include
> > #include
> > #include
> >
> > int
> > main ()
> > {
> > /* The following number comes from /usr/share/asymptote/ode.asy. */
> > const char *str = "121645100408832000.0";
> > char *ptr;
> >
> > feenableexcept (FE_INVALID);
> > strtod (str, &ptr);
> >
> > /* If there was an exception, the following will not get executed. */
> > printf ("No exception.\n");
> > }
>
> If I do the same thing WITHOUT the feenableexcept, it works fine.
> Perhaps strtod catches an exception and then applies a different
> method in some cases, or perhaps it wants exceptions off and
> deals with things its own way.
>
> If I include the feenableexcept, I get the same behavior you
> reported (in 32-bit; I did not test 64-bit).
>
> Regards - Eliot Moss
>
I tried in 64-bit with the same result as Eliot: works fine w/out
feenableexcept, no o/p with feenableexcept.
Cheers ... Duncan.
--
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: convenient trimming of quoted text to make points
On Sat, Aug 26, 2017 at 11:26:10AM -0400, cyg Simple wrote: > On 8/26/2017 2:04 AM, L A Walsh wrote: > > cyg Simple wrote: > >> On 8/24/2017 8:36 PM, L A Walsh wrote: > >> > >>> If you can't trim your quoted text, then please stop burying the > >>> new stuff on the bottom. > >>> > >> > >> Did you wake up on the wrong side of the bed. I see from a google > >> search that you've had problems with style in the past even on this list. > >> > > Maybe I'm one of the few who has RSI and gets irritated by having > > to go through extra steps to skip large walls of text. > > I don't know what RSI is. I might guess it to be Residual Self Image or > Remotely Sensed Imagery. ;p RSI == Repetitive Strain Injury. It's a real medical condition. > > >> List etiquette frowns on both bottom and top posting and warrants to > >> interleaving the replies. > >> > > --- > > I know of no list where that is commonly practiced. > > Every list including this one since before you began using email lists. > Interleaving began back in the days before the RFC for email standards > was created. The fact that people misuse quoting doesn't change the > etiquette for using interleaving which most open source lists state to use. > > >> Well all and good but you hijacked a thread to bring home a point which > >> is in itself just wrong. > >> > > To selectively quote things in your reply to make your point is the > > problem here, since I replied to the original subject, extensively. > > It was you who deleted the "on-topic" part of the message to make > > your point. > > > > No, you changed it, the client I use elided the (was: ...) portion since > it was no longer the subject to which I was responding. And my context > to you did not include any of the original message. > > -- > cyg 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 > -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- 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: alias appears to not work inside a called bash scripty
On Mon, Aug 21, 2017 at 06:30:15PM -0400, Michel LaBarre wrote:
> Hello all,
>
> I have a 4 line bash script:
> #!/bin/bash
> alias nawk=gawk
> alias nawk
> nawk 'BEGIN {FS="^"} ; (length($0) > maxline) { maxline = length($0) ;
> line=$0} ; END{print maxline, line}' $*
>
>
> When I run the script I see:
> alias nawk='gawk'
> /cygdrive/c/mybin/maxline/: line 4: nawk: command not found
>
> It looks like the alias is properly defined but it does not appear to take
> effect.
>
> Same thing happens if I alias to awk instead of qawk.
>
> Same thing happens if I define the alias in .bashrc (I include an echo in
> bashrc to confirm that it is being invoked).
>
> My .bashrc is not likely a factor - I empty it and the result is the same.
> No carriage returns in the script or .bashrc.
>
> I have updated everything August 5th using setup and letting all "Pending"
> pkgs update so I believe I am up to date.
>
> The funny thing is that it works ok from an interactive session, whether the
> alias is explicitly defined in the session or in .bashrc.
>
> Thank you in advance for any insights.
>
> BTW - I just re-subscribed to cygwin 4-5 hours ago and have not seen any
> mail which seems unusual based on past experience.
>
> Michel LaBarre
> 613-692-0507
>
>
This is expected behaviour. "man bash" gibes
" Aliases are not expanded when the shell is not interactive, unless the
expand_aliases shell option is set using shopt (see the description of shopt
under SHELL BUILTIN COMMANDS below).
Cheers ... Duncan.
--
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: Bug? wcsxfrm causing memory corruption
On Wed, May 10, 2017 at 11:30:46AM +0200, Erik Bray wrote:
> Greetings--
>
> In the process of fixing the Python test suite on Cygwin I ran across
> one test that was consistently causing segfaults later on, not
> directly local to that test. The test involves wcsxfrm so that's
> where I focused my attention.
>
> The attached test demonstrates the bug. Given an output buffer of N
> wide characters, wcsxfrm will cause bytes beyond the destination size
> to be reversed. I believe it might actually be a bug in the underlying
> LCMapStringW workhorse (this is on Windows 10; have not tested other
> versions).
>
> According to its docs [1], the cchDest argument (size of the
> destination buffer) is treated as a *byte* count when using
> LCMAP_SORTKEY. However, for the purposes of applying the
> LCMAP_BYTEREV transformation it seems to be treating the output size
> (in bytes) as character count. So in the example I give, where the
> output sort key is 7 bytes (including the null terminator), it swaps
> *14* bytes--the bytes including the sort key as well as the next 7
> adjacent bytes. This is obviously a problem if the destination buffer
> is allocated out of some larger memory pool.
>
> This definitely has to be a bug, right? Or at least very poorly
> documented on MS's part. A workaround would either be to not use
> LCMAP_BYTEREV and just swap the bytes manually, or in a second call to
> LCMapStringW with LCMAP_BYTEREV and the correct character count...
>
> Thanks,
> Erik
>
>
> [1]
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd318700(v=vs.85).aspx
> #include
> #include
> #include
> #include
> #include
> #include
>
> #define SIZE 32
>
>
> void fill_bytes(uint8_t *a, int n) {
> int idx;
> for (idx=0; idx a[idx] = idx;
> }
> }
>
>
> void print_bytes(uint8_t *a, int n) {
> int idx;
> for (idx=0; idx printf("0x%02x ", ((uint8_t*)a)[idx]);
> if ((idx + 1) % 8 == 0) printf("\n");
> }
> }
>
> int main(void) {
> wchar_t *a, *b;
> uint8_t *aa;
> size_t ret;
> LCID collate_lcid;
> int idx;
> collate_lcid = 1033;
> b = L"b";
> a = (wchar_t*) malloc(SIZE);
> aa = (uint8_t*) a;
>
> setlocale(LC_ALL, "en_US.UTF-8");
>
> printf("using wcsxfrm:\n");
> fill_bytes(aa, SIZE);
> printf("before:\n");
> print_bytes(aa, SIZE);
> ret = wcsxfrm(a, b, 4);
> printf("after (%d):\n", ret);
> print_bytes(aa, SIZE);
>
> printf("\nusing LCMapStringW directly:\n");
> fill_bytes(aa, SIZE);
> printf("before:\n");
> print_bytes(aa, SIZE);
>
> ret = LCMapStringW(collate_lcid, LCMAP_SORTKEY | LCMAP_BYTEREV, b, -1, a,
> 8);
> printf("after (%d):\n", ret);
> print_bytes(aa, SIZE);
>
> printf("\nwithout LCMAP_BYTEREV:\n");
> fill_bytes(aa, SIZE);
> printf("before:\n");
> print_bytes(aa, SIZE);
>
> ret = LCMapStringW(collate_lcid, LCMAP_SORTKEY, b, -1, a, 8);
> printf("after (%d):\n", ret);
> print_bytes(aa, SIZE);
> free(a);
>
> return 0;
> }
Hi Erik,
I get
using wcsxfrm:
before:
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07
0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17
0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f
after (3):
0x09 0x0e 0x01 0x01 0x01 0x01 0x00 0x00
0x09 0x08 0x0b 0x0a 0x0d 0x0c 0x0e 0x0f
0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17
0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f
using LCMapStringW directly:
before:
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07
0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17
0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f
after (7):
0x09 0x0e 0x01 0x01 0x01 0x01 0x07 0x00
0x09 0x08 0x0b 0x0a 0x0d 0x0c 0x0e 0x0f
0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17
0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f
without LCMAP_BYTEREV:
before:
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07
0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17
0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f
after (7):
0x0e 0x09 0x01 0x01 0x01 0x01 0x00 0x07
0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17
0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f
Is that the same as you see?
Cheers ... Duncan.
--
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: Segfault using `watch -c` with ANSI escapes in output
On Wed, Apr 19, 2017 at 11:14:02AM +0200, Csaba Raduly wrote: > On Wed, Apr 19, 2017 at 8:35 AM, Duncan Roe wrote: > > > > Where does "watch" come from? It's not on my cygwin installation: > > > >> 16:12:50$ type watch > >> -bash: type: watch: not found > > > > https://cygwin.com/cgi-bin2/package-grep.cgi?grep=watch%5C.exe&arch=x86_64 > > gives us > > https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fprocps%2Fprocps-3.2.8-5&grep=watch%5C.exe > > Csaba Thanks Csaba - got it. Is now version 3.3.11 (according to spinner), or 3.3.10 (according to watch). Either way, it now works fine, Cheers ... Duncan. -- 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: Segfault using `watch -c` with ANSI escapes in output
On Tue, Apr 18, 2017 at 01:36:34PM +0100, Adam Dinwoodie wrote: > I'm seeing a segfault from using `watch -c` with commands that output > ANSI colour sequences, which is a bit sad given the whole point of the > `-c` is to get the ANSI colour sequences to be displayed. > > Simple test case: > > $ echo -e '\e[0;32mGreen\e[0;0m' >escapes > > $ cat escapes # Text is green in my terminal > Green > > $ xxd escapes > : 1b5b 303b 3332 6d47 7265 656e 1b5b 303b .[0;32mGreen.[0; > 0010: 306d 0a 0m. > > $ watch -c cat escapes > Segmentation fault (core dumped) > > $ cat watch.exe.stackdump > Exception: STATUS_ACCESS_VIOLATION at rip=001004029B0 > rax=58F5FF8D rbx=00061200 rcx=00060060 > rdx= rsi= rdi=0004 > r8 =CA2C r9 =00018013C800 r10=0001 > r11=00010040299A r12=0004 r13=CAF0 > r14=00060E50 r15=0001801F82C0 > rbp= rsp=CA60 > program=C:\cygwin64\bin\watch.exe, pid 12100, thread main > cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B > Stack trace: > FrameFunctionArgs > 000 001004029B0 (000, 000, 030, > 3000101FF00) > 000CCC0 00180047812 (000, 000, 000, > 000) > 000 001800455E3 (000, 000, 000, > 000) > 000FFF0 00180045694 (000, 000, 000, > 000) > End of stack trace > > This works as expected when using `watch` without the `-c` option, and > when using `watch -c` with output that doesn't include any ANSI colour > sequences. > > Output from `cygcheck -srv` is attached, and `cygcheck -f > /usr/bin/watch.exe` returns `procps-ng-3.3.11-1`. Where does "watch" come from? It's not on my cygwin installation: > 16:12:50$ type watch > -bash: type: watch: not found and when I enter "watch" in the installer Search window, all it shows me is > xfce-mailwatch-plugin: Xfce mail watcher panel plugin and > xfce-mailwatch-plugin-debuginfo: Debug info for xfce4-mailwatch-plugin Cheers ... Duncan. -- 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: Cygwin - Install Liquidsoap for Shoutcast or Icecast
On Mon, Mar 27, 2017 at 11:58:23AM -0500, Vince Rice wrote: > >>> On Mon, Mar 27, 2017 at 10:31 AM, Andrew Schulman > >>> You should start at https://cygwin.com/cgi-bin2/package-grep.cgi to see if > >>> someone has already packaged it for Cygwin. > >>> > >>> If no one has, then you can either build and install it yourself, or try > >>> to > >>> convince someone else to do it. Since you're the one who wants it, you're > >>> most likely to get it done by doing it yourself. If you succeed, > >>> considering offering it as a new package (https://cygwin.com/setup.html). > >>> > >>> Andrew > >> > >> On Mon, Mar 27, 2017 at 12:35 PM, Wayne Barron wrote: > >> Hey, Andrew. > >> I did a search on the site, and nothing came up with it. > >> So, it looks like I will be on my own. > >> > >> I love new challenges, so I will probably look in on it a little more > >> throughout the week. > >> > > On Mar 27, 2017, at 11:44 AM, Wayne Barron wrote: > > > > OK, I found out that I needed to get cygport > > http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/media/liquidsoap/ > > I downloaded the file and looked it over. > > I will try to install it later on, today, and see if I can get it to, > > at least. Install. > > Excellent. But please don't https://cygwin.com/acronyms/#TOFU here. (And > please watch the https://cygwin.com/acronyms/#PCYMNTNQREAIY as well, even > when it's your own.) > Should be: https://cygwin.com/acronyms/#PCYMTNQREAIYR Hey - is anyone still maintaining / updating that list? Here's a suggestion: PTUIYEBHS Please Test URLs In Your Emails Before Hitting Send Cheers ... Duncan. -- 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: inetutils-server, OpenSP and units install glitches and fixes
On Mon, Mar 27, 2017 at 12:48:07PM +, Nellis, Kenneth (Conduent) wrote: > From: Ian Lambert via cygwin > > ... > > On a related note, using not ancient Red Hat 5.6 where the mirror is > > stored, tar won't expand the Cygwin packages? > > > > $ tar -xvf units-2.13-1.tar.xz > > > > tar: This does not look like a tar archive > > tar: Skipping to next header > > tar: Archive contains obsolescent base-64 headers > > tar: Read 9640 bytes from units-2.13-1.tar.xz > > tar: Error exit delayed from previous errors > > > > $ tar --version > > tar (GNU tar) 1.15.1 > > > > > > but tar Packaged by Cygwin (1.29-1) will. > > > > I believe you need to tell tar if the file is in a compressed > format. Not sure if your version takes the same options as > Cygwin's tar 1.29, but there you would want to say (I suspect): > > $ tar -xvjf units-2.13-1.tar.xz > > --Ken Nellis No, -j is for bz2. -J (capital j) is for xz, but the tar being tried may be too old to have that option. Cheers ... Duncan. -- 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: dash-0.5.9.1-1
On Sat, Feb 25, 2017 at 09:08:55AM -0800, Steven Penny wrote: > On Sat, 25 Feb 2017 11:46:08, cyg Simple wrote: > > If *your* script has a dependency to run using *dash* instead of *sh* > > then you _must_ use #!/bin/dash anyway. > > I think you have a fundamental misunderstanding of what Dash is. Dash is a > minimal shell, similar to the "sh" defined by POSIX: > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html > > So saying "a dependency to run using *dash*" makes about as much sense as > saying > "Cygwin has a dependency to run using Cygwin". > > > And what I _*I*_ don't want dash as /bin/sh? You see not everyone in the > > community will agree. > > With respect to the community, yes of course you get a say. If the community > doesn???t agree on this we will continue to use Bash. However you do not get > a say > with respect to the standard. The POSIX standard specified that /bin/sh is the > shell I have linked above. Bash is a superset of that, so by definition those > extra features are not defined or guaranteed to exist. When writing /bin/sh > scripts, you should be assuming the users /bin/sh only has those features > defined by POSIX. Example: > > #!/bin/bash -> script that follows might have Bashisms > #!/bin/dash -> script that follows might have Dashisms (echo -n, local) > #!/bin/sh -> script that follows should be a POSIX script > > > You can make the suggestion to those using your script to do so otherwise > > but > > forcing dash as /bin/sh worldwide isn't something you can actually do. > > Yes we certainly can. Debian and Ubuntu have already done this. > "we" being you and who else? /bin/sh has been bash for a long time and I would prefer it stays that way. OTOH, I have started prefacing scripts with /bin/bash -p to be on the safe side. "-p" stops bash from importing functions from the environment BTW Cheers ... Duncan. -- 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: Installer names not meaningful enough
On Tue, Dec 06, 2016 at 10:11:42AM +0100, Gerrit Haase wrote: > 2016-12-01 11:51 GMT+01:00 Roberto Ríos Gallardo says: > > Please give the installers more meaningful names. In particular, make > > sure "cygwin" is part of it. "setup-x86_64.exe" is not very obvious. A > > version number would be nice too. > > The version is part of setup.ini in the header: > > # This file was automatically generated at 2016-12-05 09:43:16 UTC. > # > # If you edit it, your edits will be discarded next time the file is > # generated. See http://cygwin.com/setup.html for details. > release: cygwin > arch: x86_64 > setup-timestamp: 1480930996 > setup-version: 2.876 > ... > > > Regards, > Gerrit Where is setup.ini? Cheers ... Duncan. -- 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: Cygwin 64 problem
On Sun, Nov 27, 2016 at 11:02:29AM -0500, Ken Brown wrote: > On 11/27/2016 9:03 AM, Girish Joglekar wrote: > > Hi Ken, > > Thank you for your reply on the Cygwin mailing list. I have created a > > slightly smaller test example smaller than what I had created in Feb. > > Attached is a tar file. After make insall if you run TEST.x and click > > the Open button, it gives segmentation fault. > > Hope you will be able to help. > > Thank you. > > Girish > > Please keep the discussion on the mailing list so that people who might be > able to help will see it. I personally am not familiar with X11 > programming, so I'm not one of those people. > > I do have a few comments, however: > > 1. This may be slightly smaller than your previous program, but it is still > *very* far from a small test case. You really can't expect people to debug > a program of this size for you. > > 2. I suggest that you build with -Wall (as Marco already suggested in the > earlier discussion) and fix all the compiler warnings. I saw several that > need attention (aside from the many "unused variable" warnings). It > wouldn't hurt to also use -Wextra. > > 3. I also suggest that you use gdb to find out where the program is crashing > and why. You made a start on that in the discussion last March, but you > didn't follow through. (By the way, I recommend building without > optimization; otherwise you may not be able to get accurate information > about the crash from gdb.) > > 4. If, after the steps above, you still think the crash is due to a Cygwin > bug rather than a programming error, then try to extract from your program a > test case as small as possible that reproduces the crash. > > Ken I thought I would have a crack at this but immediately got the error: testc.h:8:19: fatal error: Xm/Xm.h: No such file or directory #include I thought /usr/include/Xm/ should come with motif, which I have installed. What have I missed? Cheers ... Duncan. -- 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 Subsystem for Linux starts to compete with Cygwin?
On Thu, Oct 27, 2016 at 12:21:07AM +0300, Evgeny Grin wrote: > With latest Window Insider preview it's possible to run Linux command > from cmd, Windows commands from bash and even use input-output redirects! > https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows-and-ubuntu-interoperability/ > Seems that WSL also automatically translate \r\n<->\n. > > There still no (official) way to run GUI with WSL. > > Is Cygwin still better for something? > > I understand that WSL and Cygwin are completely different approaches, > but from user perspective both are kind of sets of GNU/Linux commands > and both are using some intermediate layer (cygwin1.dll or LXSS). > CMD.EXE has supported input and output redirection since forever (XP at least). I suggest claiming it as a "new feature" is just marketing hype. Cheers ... Duncan. -- 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: bc version has issue with \r when run from cmd
On Sun, Oct 23, 2016 at 06:19:31PM -0400, Andrew Schulman wrote: > > >From: "L. A. Walsh" > > >Date: Sat, 22 Oct 2016 15:52:42 -0700 > > > > To L.A. Walsh. > > > > I understand all that but what i'm saying is that version 1.06 (not > > 1.06.95, which cygwin is using, but 1.06, which Gow uses), So, version > > 1.06 Doesn't have a problem with the fact that cmd sends a \r So, > > if one doesn't want to call it a bug, then one can call it a lost > > feature, useful feature of 1.06 (allowing bc to conveniently also be > > used from cmd), and that beneficial flexible feature was lost in > > 1.06.95 > > Hi. I adopted the bc package about a year ago, since fish uses it and I > maintain > fish for Cygwin. > > I think L.A. is right that because this is an issue of integration between > Cygwin and cmd, it's in the category of a nice-to-have feature. But I get that > it would be useful for you, and maybe for others too. > > I haven't looked at the bc source code. It could take some time to find where > the issue is. A place to start would be to compare the code archives: > > http://ftp.gnu.org/gnu/bc/bc-1.06.tar.gz > http://alpha.gnu.org/gnu/bc/bc-1.06.95.tar.bz2 > > If you were to localize the problem in the source code and even propose a > patch, > that would make it a lot more likely to get the problem fixed. Heck, you might > even get a gold star. I maintain the gold star page too :) > > Andrew > Hi Andrew, I don't think it's a change to bc. I built and tried bc 1.06 under Linux and it behaves the same (1.06.95 was released about 10 years ago BTW): 21:44:51$ ./bc --version bc 1.06 21:53:24$ echo -e "scale=10; 4*a(1)\r"|./bc -l (standard_in) 1: illegal character: ^M 21:59:04$ echo -e "scale=10; 4*a(1)"|./bc -l 3.1415926532 21:59:29$ On debugging ./bc, I found this: Breakpoint 2, yyparse () at /usr/gnu/share/bison.simple:254 254 /usr/gnu/share/bison.simple: No such file or directory. (gdb) fin Run till exit from #0 yyparse () at /usr/gnu/share/bison.simple:254 (standard_in) 1: illegal character: ^M main (argc=1, argv=0xbfffeb34) at main.c:262 262 if (compile_only) Value returned is $1 = 0 So it would seem that the new error is a consequence of some update to flex or bison in the last 10 years. Does Gow have a patched flex or bison? Or maybe their bc build is just very old? Cheers ... Duncan. -- 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: Autotools support group, forum, mailing list, ???
On Thu, Sep 22, 2016 at 06:13:07PM -0400, HiTech HiTouch wrote: > Please forgive the somewhat off topic, but people who use Autotools and > Mingw hang here and may be able to point me. > > I'm looking for a central place where people ask questions about Autotools > (autoconf automake, etc.). My google-ing finds (in addition to the manuals) > only mailing list and blogs, all of which haven't had significant activity > for years, like 2013, 2007, 2004. I find no BBS systems (forums) in use. > > The most questioners seem to be on the various stackexchange communities, > pick one, pick many. > > Where should one go to ask questions, pray tell? > > > PS: I'm trying to build the tool chain for Arduino IDE by cross compiling. > I am using MinGW 4.9.2 on WIndows XP SP3 32 bit to produce tools that run on > native win32 (32 bit windows) and produce code for ARM. I've been given the > avr tool chain package produced using Autotools for my starting point. > > PPS: The Autotools anchor, > https://www.gnu.org/software/autoconf/autoconf.html, has a bad pointer to > its mailing list archive. Letting google do the work, there is nothing in > that last several years for XP, Windows, or win32 save for spam. > Hi HiTech, Have you tried "info Automake" and "info Autoconf" on your installation? They give you much more information than the man pages - automake even has a "Hello World" example. Cheers ... Duncan. -- 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: pick or semilar
On Fri, Aug 26, 2016 at 04:28:07PM -0600, Doug Henderson wrote:
> On 26 August 2016 at 15:46, Adam Dinwoodie wrote:
> > On 17/08/2016 15:25, Morten Kjærulff wrote:
> >>
> >> Hi,
> >>
> >> Is there a tool like "pick"
> >> https://github.com/thoughtbot/pick
> >>
> >> in cygwin?
> >
> > I've just taken a brief look at that GitHub page, and it looks to be at
> > least vaguely similar to fzf, which is included with Cygwin. You might want
> > to take a look at that and see if it meets your needs.
> ...
>
> Have you considered the bash select command? The following command
> takes you to the documentation
>
> info bash select
>
> for example:
>
> select fname in *.txt ;
> do
> echo you picked No. ${REPLY}: ${fname} ;
> break ;
> done
>
>
> HTH
>
> Doug
>
For quick documentation of bash select, you can simply enter
help select
at the bash / mintty prompt. Bash has help for most builtins actually,
Cheers ... Duncan.
--
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: /dev/ptmx fails with Azure accounts
On Mon, Aug 08, 2016 at 09:05:27AM +0200, Corinna Vinschen wrote:
> On Aug 7 13:27, Duncan Roe wrote:
> > On Fri, Aug 05, 2016 at 12:27:51PM +0200, Corinna Vinschen wrote:
> > > On Aug 4 09:00, Corinna Vinschen wrote:
> > > > On Aug 3 15:05, rm...@aboutgolf.com wrote:
> > > > > [...]
> > > > > Unknown+User@Lenovo-PC /cygdrive/c/cygwin64
> > > > > $ ./azure-check2
> > > > > Sid: S-1-12-1-2043906341-1249388050-2635137163-399631282
> > > > > Dom\Name: AzureAD\RussellMora
> > > > > Primary Group:
> > > > > Sid: S-1-12-1-2043906341-1249388050-2635137163-399631282
> > > > > Dom\Name: AzureAD\RussellMora
> > > > > NetUserGetInfo: 53
> > > > >
> > > > > Unknown+User@Lenovo-PC /cygdrive/c/cygwin64
> > > > > $
> > > > >
> > > > > (As an aside, I assume that the fact that the permissions on the
> > > > > compiled executable are totally messed up, and thus the executable
> > > > > won't run until I fix them via Windows, is incidental to the fact that
> > > > > I am running under "Unknown+User" and thus you don't want any
> > > > > information on that as well.)
> > > >
> > > > Good thinking :)
> > > >
> > > > Can you please try the attached testcase? Probably my last straw. If
> > > > that doesn't work as desired, support for AzureAD accounts will be very
> > > > limited.
> > >
> > > I guess you're already on vacation, but never mind.
> > >
> > > I improved my testcase a bit and attached it to this mail. Can you please
> > > try this one when you're back?
> > >[...]
> > Hi Corrina,
>
> s/rr/in/rinn/ :)
>
> > I've been trying your tests out of interest (no Axure accounts here), and
> > they all worked except this last one which segfaults:
>
> That you, I think I see where I made the mistake. Can you try the
> attached?
>
>
> Thanks,
> Corinna
>
> --
> Corinna Vinschen Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat
> #include
> #include
> #define _WIN32_WINNT 0x0a00
> #define WINVER 0x0a00
> #include
> #include
> #include
> #include
>
> int
> main ()
> {
> HANDLE tok;
> PTOKEN_USER tp = (PTOKEN_USER) malloc (65536);
> DWORD ret;
> LPSTR str;
> WCHAR name[256];
> WCHAR dom[256];
> DWORD nlen, dlen;
> SID_NAME_USE type;
> PDOMAIN_CONTROLLER_INFOW pci;
> NET_API_STATUS status;
> PUSER_INFO_3 ui3;
> PUSER_INFO_24 ui24;
>
> if (!OpenProcessToken (GetCurrentProcess (), TOKEN_QUERY, &tok))
> {
> printf ("OpenProcessToken: %u\n", GetLastError ());
> return 1;
> }
> if (!GetTokenInformation (tok, TokenUser, tp, 65536, &ret))
> {
> printf ("GetTokenInformation(user): %u\n", GetLastError ());
> return 1;
> }
> ConvertSidToStringSidA (tp->User.Sid, &str);
> printf (" Sid: %s\n", str);
> LocalFree (str);
> nlen = dlen = 256;
> if (LookupAccountSidW (NULL, tp->User.Sid, name, &nlen,
>dom, &dlen, &type))
> printf ("Dom\\Name: %ls\\%ls\n", dom, name);
> else
> printf ("LookupAccountSidW: %u\n", GetLastError ());
>
> ret = DsGetDcNameW (NULL, dom, NULL, NULL,
> DS_IS_FLAT_NAME | DS_RETURN_DNS_NAME, &pci);
> if (ret != ERROR_SUCCESS)
> {
> printf ("DsGetDcNameW: %u\n", status);
> pci = NULL;
> }
>
> status = NetUserGetInfo (NULL, name, 3, (PBYTE *) &ui3);
> if (status != NERR_Success)
> printf ("NetUserGetInfo(NULL, 3): %u\n", status);
> else
> {
> printf ("UserInfo NULL, 3:\n");
> printf (" Name: %ls\n", ui3->usri3_name);
> NetApiBufferFree (ui3);
> }
> status = NetUserGetInfo (NULL, name, 24, (PBYTE *) &ui24);
> if (status != NERR_Success)
> printf ("NetUserGetInfo(NULL, 24): %u\n", status);
> else
> {
> printf ("UserInfo NULL, 24:\n");
> printf (" InternetIdentity: %d\n", ui24->usri24_internet_identity);
> printf (" Flags: 0x%08x\n", ui24->usri24_flags);
> printf (" ProviderName: %ls\n", ui24->usri24_internet_provider_name);
> printf (" PrincipalName: %ls\n", ui2
Re: /dev/ptmx fails with Azure accounts
On Fri, Aug 05, 2016 at 12:27:51PM +0200, Corinna Vinschen wrote:
> On Aug 4 09:00, Corinna Vinschen wrote:
> > On Aug 3 15:05, rm...@aboutgolf.com wrote:
> > > [...]
> > > Unknown+User@Lenovo-PC /cygdrive/c/cygwin64
> > > $ ./azure-check2
> > > Sid: S-1-12-1-2043906341-1249388050-2635137163-399631282
> > > Dom\Name: AzureAD\RussellMora
> > > Primary Group:
> > > Sid: S-1-12-1-2043906341-1249388050-2635137163-399631282
> > > Dom\Name: AzureAD\RussellMora
> > > NetUserGetInfo: 53
> > >
> > > Unknown+User@Lenovo-PC /cygdrive/c/cygwin64
> > > $
> > >
> > > (As an aside, I assume that the fact that the permissions on the
> > > compiled executable are totally messed up, and thus the executable
> > > won't run until I fix them via Windows, is incidental to the fact that
> > > I am running under "Unknown+User" and thus you don't want any
> > > information on that as well.)
> >
> > Good thinking :)
> >
> > Can you please try the attached testcase? Probably my last straw. If
> > that doesn't work as desired, support for AzureAD accounts will be very
> > limited.
>
> I guess you're already on vacation, but never mind.
>
> I improved my testcase a bit and attached it to this mail. Can you please
> try this one when you're back?
>
>
> Thanks a lot,
> Corinna
>
> --
> Corinna Vinschen Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat
> #include
> #include
> #define _WIN32_WINNT 0x0a00
> #define WINVER 0x0a00
> #include
> #include
> #include
> #include
>
> int
> main ()
> {
> HANDLE tok;
> PTOKEN_USER tp = (PTOKEN_USER) malloc (65536);
> DWORD ret;
> LPSTR str;
> WCHAR name[256];
> WCHAR dom[256];
> DWORD nlen, dlen;
> SID_NAME_USE type;
> PDOMAIN_CONTROLLER_INFOW pci;
> NET_API_STATUS status;
> PUSER_INFO_3 ui3;
> PUSER_INFO_24 ui24;
>
> if (!OpenProcessToken (GetCurrentProcess (), TOKEN_QUERY, &tok))
> {
> printf ("OpenProcessToken: %u\n", GetLastError ());
> return 1;
> }
> if (!GetTokenInformation (tok, TokenUser, tp, 65536, &ret))
> {
> printf ("GetTokenInformation(user): %u\n", GetLastError ());
> return 1;
> }
> ConvertSidToStringSidA (tp->User.Sid, &str);
> printf (" Sid: %s\n", str);
> LocalFree (str);
> nlen = dlen = 256;
> if (LookupAccountSidW (NULL, tp->User.Sid, name, &nlen,
>dom, &dlen, &type))
> printf ("Dom\\Name: %ls\\%ls\n", dom, name);
> else
> printf ("LookupAccountSidW: %u\n", GetLastError ());
>
> ret = DsGetDcNameW (NULL, dom, NULL, NULL,
> DS_IS_FLAT_NAME | DS_RETURN_DNS_NAME, &pci);
> if (ret != ERROR_SUCCESS)
> {
> printf ("DsGetDcNameW: %u\n", status);
> pci->DomainControllerName = NULL;
> }
>
> status = NetUserGetInfo (NULL, name, 3, (PBYTE *) &ui3);
> if (status != NERR_Success)
> printf ("NetUserGetInfo(NULL, 3): %u\n", status);
> else
> {
> printf ("UserInfo NULL, 3:\n");
> printf (" Name: %ls\n", ui3->usri3_name);
> NetApiBufferFree (ui3);
> }
> status = NetUserGetInfo (NULL, name, 24, (PBYTE *) &ui24);
> if (status != NERR_Success)
> printf ("NetUserGetInfo(NULL, 24): %u\n", status);
> else
> {
> printf ("UserInfo NULL, 24:\n");
> printf (" InternetIdentity: %d\n", ui24->usri24_internet_identity);
> printf (" Flags: 0x%08x\n", ui24->usri24_flags);
> printf (" ProviderName: %ls\n", ui24->usri24_internet_provider_name);
> printf (" PrincipalName: %ls\n", ui24->usri24_internet_principal_name);
> ConvertSidToStringSidA (ui24->usri24_user_sid, &str);
> printf (" Sid: %s\n", str);
> LocalFree (str);
> NetApiBufferFree (ui24);
> }
>
> if (pci->DomainControllerName)
> {
> status = NetUserGetInfo (pci->DomainControllerName, name,
> 3, (PBYTE *) &ui3);
> if (status != NERR_Success)
> printf ("NetUserGetInfo(%ls, 3): %u\n", pci->DomainControllerName,
> status);
> else
> {
> printf ("UserInfo %ls, 3:\n", pci->DomainControllerName);
> printf (" Name: %ls\n", ui3->usri3_name);
> NetApiBufferFree (ui3);
> }
>
> status = NetUserGetInfo (pci->DomainControllerName, name,
> 24, (PBYTE *) &ui24);
> if (status != NERR_Success)
> printf ("NetUserGetInfo(%ls, 24): %u\n",
> pci->DomainControllerName, status);
> else
> {
> printf ("UserInfo %ls, 24:\n", pci->DomainControllerName);
> printf (" InternetIdentity: %d\n", ui24->usri24_internet_identity);
> printf (" Flags: 0x%08x\n", ui24->usri24_flags);
> printf (" ProviderName: %ls\n", ui24->usri24_internet_provider_name);
> printf (" PrincipalName: %ls\n",
> ui24->usri24_internet_principal_name);
> ConvertSidToStringSidA (ui24->usri24_user_sid, &str);
> printf (" Sid: %s\n
Font error message during Cygwin update (mostly harmless)
Hi When upgrading to current 5.2.1 Cygwin, this message appears in the window: > Package: z/Perpetual > zp_fontconfig_cache_1.sh exit code 1 The relevant lines in /var/log/setup.log.full appear to be: > 2016/07/11 22:24:30 running: C:\cygwin64\bin\bash.exe --norc --noprofile > "/etc/postinstall/zp_fontconfig_cache_1.sh" > /usr/share/fonts: failed to write cache > 2016/07/11 22:25:30 abnormal exit: exit code=1 I got this in 32-bit and 64-bit upgrades. I added xfontsel to 64-bit; 32-bit was a plain upgrade. I'm using an X server on a Linux system, so can't say whether Cygwin fonts are working or not. Cheers ... Duncan. -- 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: mintty issue with version 2.3.7
On Wed, Jun 29, 2016 at 11:56:14AM +0200, Christoph Zimmermann wrote:
> After the recent update to version 2.3.7 mintty prints the error message
>
> Error: could not open log file: File exists.
> : File exists
>
> every time I open a mintty window. I've tracked this down to the following
> snippet (around line # 228) in child.c:
>
>char * logf = newn(char, MAX_PATH + 1);
> strftime (logf, MAX_PATH, log, localtime (& now.tv_sec));
> free(log);
> log = logf;
> }
>
> log_fd = open(log, O_WRONLY | O_CREAT | O_EXCL, 0600);
> if (log_fd < 0) {
> // report message and filename:
> childerror("could not open log file", false);
> childerror(log, false);
> }
>
> The culprit seems to be the open invocation with the combination of flags;
> possibly pointing to
> a problem in the corresponding cygwin.dll implementation.
>
> Please let me know if you need more details.
>
> Thanks, Chris
>
No problem with cydwin.dll. O_CREAT | O_EXCL makes it an error if the file
exists: see "man open"
Cheers ... Duncan.
--
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: Help debugging a dll issue
On Sat, May 21, 2016 at 07:30:37PM -0400, Eliot Moss wrote:
> On 5/19/2016 10:54 PM, Eliot Moss wrote:
> >Dear Cygwin friends --
> >
> >I am trying to get pypy to build under cygwin. (It used to do so, but
> >has not been maintained.) I am very close, but there is something quite
> >odd happening when trying to access the large dll that the system builds:
> >the first call into that dll goes wild and causes a segfault. The issue
> >seems to lie with run-time linking, for I can use dlopen to open the dll
> >and then dlsym to look up the function, and I get the same bad address.
> >I see nothing wrong from nm and objdump. The dll is about 70 million
> >bytes long, so I can't really post it, but if you want to have a crack
> >at this, we can find some mutually agreeable place and I can tell you
> >the entry point I am trying to access.
> >
> >I have found that if I patch the indirection in the associated .exe file
> >to refer to the actual address of the function, then the program runs,
> >so it's just this one linkage that is not working (apparently). Very
> >mysterious to me.
>
> I used binary search, eliminating .o files from the .dll on the thought
> that it was either a particular .o file that was leading to a problem,
> or possibly the overall size (this is a huge link!). I found that a .dll
> with 58725 section 1 symbols (as reported by objdump -t) works, and one
> with 66675 section one symbols fails. So it appears to be a size issue.
>
> Is anyone out there skilled enough with gnu ld to guide me as to how to
> keep that section from getting too big? I tried --split-by-reloc, but
> that gave no improvement (I don't think it's relocations that are the
> problem, just the overall size of a section). I'll try --split-by-file,
> but I am doubting that is the right thing either.
>
> In fact, it is looking that the solution may be to get pypy to build
> its .dll with fewer symbols in the symbol table, perhaps by suitable
> use of __declspec(dllexport) and __declspec(dllimport), etc. (These
> are apparently deprecated in favor of __attribute__((visibility("hidden"))),
> etc., but a number of those generate warnings that the visbility
> attributes are not supported in this configuration!)
>
> Any thoughts from the populace?
>
> Regards -- EM
>
You surely tried this already: strip --strip-unneeded or --strip-debug?
Cheers ... Duncan.
--
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: Help debugging a dll issue
On Fri, May 20, 2016 at 08:02:20AM -0400, Eliot Moss wrote: > On 5/20/2016 7:26 AM, Duncan Roe wrote: > > >Hi Eliot, > > > >Do you know what is the name of the totally different symbol? (maybe from nm > >-D) > > Yes -- I have been using nm and objdump to examine the relevant files. The > dll > is called libpypy-c.dll. The symbol I want to bind to is pypy_main_startup, > and > its proper value (as returned by nm and objdump) is 0x6410ac60. The result I > get is the value of symbol pypy_g_PyNumber_Negative (an automatically > generated > C function), which is 0x63443f00. > > I wonder if these collide in some internal hash table and the hash lookup (or > the table building) is broken in some subtle way. > > Regards -- Eliot > Does findit give the same answer for both symbols? If you could build your library and libdl.a with debug (-g) then you might be able to see how the lookup goes wrong. HTH ... Duncan. -- 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: Help debugging a dll issue
On Fri, May 20, 2016 at 06:37:57AM -0400, Eliot Moss wrote: > On 5/19/2016 11:28 PM, Sam Habiel wrote: > >I had trouble with dlopen in Cygwin, where it did not behave intuitively. In > >my case, I was > >dlopening libicu and friends. If you search using my name on the Cygwin > >mailing list, you should be > >able to find out how I resolved the issue. I don't recall exactly what I > >did, but I think it was > >that Cygwin put everything in a global namespace, and you need to dlsym NULL > >to grab the function > >addresses. > > I just tried using NULL for the handle in dlsym, and I get the same result as > before, and it > does not change between using RTLD_LOCAL or RTLD_GLOBAL in dlopen. > > What I am seeing is that looking up one symbol is giving the value for a > totally different > one -- it's not returning an error indication. > > And this same wrong value is what happens if I just allow the natural linking > to take place > (which is what I really want to happen -- the dl calls simply help focus the > issue). > > I will look up your previous issue, though, to see if there is something else > there of use > in this situation. > > Regards -- EM > Hi Eliot, Do you know what is the name of the totally different symbol? (maybe from nm -D) I wrote a "findit" utility a while back - it would be interesting if it gave the same answer for both symbols. If you would git clone https://github.com/duncan-roe/command_line_tools, cd to the findit subdirectory and enter "make" then you will have it. Example use: > 21:23:15$ ./findit cygwin1.dll printf > Found printf in cygwin1.dll at 0x18012ecbe > 21:24:37$ HTH ... Duncan. -- 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: bcftools error running Make after installing update 2.4.1.1 to Cygwin64
On Mon, Jan 25, 2016 at 09:30:29PM +, David Stacey wrote: > On 25/01/16 21:00, Robert May wrote: > >many warnings are given in the following text - see end for error message > > > >echo '#define BCFTOOLS_VERSION "1.3"'> version.h > >gcc -g -Wall -Wc++-compat -O2 -std=c99 -I. -Ihtslib-1.3 > >-DPLUGINPATH=\"/usr/local/libexec/bcftools\" -c -o main.o main.c > >gcc -g -Wall -Wc++-compat -O2 -std=c99 -I. -Ihtslib-1.3 > >-DPLUGINPATH=\"/usr/local/libexec/bcftools\" -c -o vcfindex.o vcfindex.c > >vcfindex.c: In function ?main_vcfindex?: > >vcfindex.c:209:9: warning: implicit declaration of function ?alloca? > >[-Wimplicit-function-declaration] > > char*idx_fname = (char*)alloca(strlen(fname) + 5); > > ^ > >vcfindex.c:209:27: warning: cast to pointer from integer of different size > >[-Wint-to-pointer-cast] > > char*idx_fname = (char*)alloca(strlen(fname) + 5); > > These warnings can be generated for a number of reasons. One is that the > source code you are attempting to compile pre-dates this version of gcc. > Another reason is that you are somehow using a combination of compiler > switches that were never expected. A third reason is that the source code > simply isn't well written, but the majority of Open Source contributors take > great pride in their work. > > In your case, it could be the compiler switches - see below. > > >gcc -g -Wall -Wc++-compat -O2 -std=c99 -I. -Ihtslib-1.3 > >-DPLUGINPATH=\"/usr/local/libexec/bcftools\" -c -o vcfcnv.o vcfcnv.c > >vcfcnv.c: In function ?norm_prob?: > >vcfcnv.c:602:93: error: ?M_PI? undeclared (first use in this function) > > return exp(-(baf-param->mean)*(baf-param->mean)*0.5/param->dev2) / > > param->norm / sqrt(2*M_PI*param->dev2); > > > > ^ > >vcfcnv.c:602:93: note: each undeclared identifier is reported only once for > >each function it appears in > >vcfcnv.c: In function ?main_vcfcnv?: > >vcfcnv.c:1349:9: warning: implicit declaration of function ?fileno? > >[-Wimplicit-function-declaration] > > if ( !isatty(fileno((FILE *)stdin)) ) fname = "-"; > > ^ > >vcfcnv.c: In function ?norm_prob?: > >vcfcnv.c:603:1: warning: control reaches end of non-void function > >[-Wreturn-type] > > } > > ^ > > This looks like expected behaviour to me. Specifying '-std=c99' defines a > __STRICT_ANSI__ macro, which in turn means that mathematical constants like > M_PI are not defined. Using '-std=gnu99' instead should work. You may also > find that this more relaxed compiler setting doesn't generate so many > warnings. > > Dave. > Definitely you need a gnu standard for /usr/include/alloca.h to make alloca visible. It is not a POSIX function. Cheers ... Duncan. -- 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: Error installing/updating Cygwin on Windows 10
On Sun, Jan 24, 2016 at 05:09:54PM -0500, Maarten Jacobs wrote: > > > Date: Mon, 25 Jan 2016 09:02:07 +1100 > > From: duncan_...@acslink.net.au > > To: cygwin@cygwin.com > > Subject: Re: FW: Error installing/updating Cygwin on Windows 10 > > > > On Sun, Jan 24, 2016 at 02:30:34PM -0500, Maarten Jacobs wrote: > >> Hello, > >> > >> I have been getting the following error when I update/install packages in > >> Cygwin (32-bit) on Windows 10: > >> > >> Package: _/Unknown package > >> base-files-mketc.sh exit code 1 > >> > >> When I look at /var/log/setup.log.full, it gives me the following cryptic > >> error message: > >> > >> 2016/01/24 14:21:35 running: C:\cygwin\bin\bash.exe --norc --noprofile > >> "/etc/postinstall/base-files-mketc.sh" > >> Directory /cygdrive/c/Windows/SysWOW64/drivers/etc does not exist; exiting > >> If directory name is garbage you need to update your cygwin package > >> 2016/01/24 14:21:35 abnormal exit: exit code=1 > >> > > Hi Martin, > > > > I got that message yesterday. It went away when I created the etc directory > > (from an Admin CMD window), suggest you do likewise. > > > > Cheers ... Duncan. > > > Hi Duncan, > > Thanks for the suggestion, but this is not a solution for me as /etc > (/cygwin/etc) already exists and has been populated with the packages that I > have installed so far. > > I omitted to mention in my original email that even though the error is > presented every time I make a change to my Cygwin installation, it does not > appear to affect the operation of Cygwin in any way - at least I have not run > into any unexpected behavior yet. > > Thanks, > > Maarten > Hi Maarten. I meant you need to create C:\Windows\SysWOW64\drivers\etc i.e. (in DOS / CMD window with Admin privilege): > cd C:\Windows\SysWOW64\drivers > mkdir etc I agree there seem to be no ill effects from the error except the nuisance of having an error popup. Cheers ... Duncan. -- 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: FW: Error installing/updating Cygwin on Windows 10
On Sun, Jan 24, 2016 at 02:30:34PM -0500, Maarten Jacobs wrote: > Hello, > > I have been getting the following error when I update/install packages in > Cygwin (32-bit) on Windows 10: > > Package: _/Unknown package > base-files-mketc.sh exit code 1 > > When I look at /var/log/setup.log.full, it gives me the following cryptic > error message: > > 2016/01/24 14:21:35 running: C:\cygwin\bin\bash.exe --norc --noprofile > "/etc/postinstall/base-files-mketc.sh" > Directory /cygdrive/c/Windows/SysWOW64/drivers/etc does not exist; exiting > If directory name is garbage you need to update your cygwin package > 2016/01/24 14:21:35 abnormal exit: exit code=1 > Hi Martin, I got that message yesterday. It went away when I created the etc directory (from an Admin CMD window), suggest you do likewise. Cheers ... Duncan. -- 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: Rounding off real (floating point) values - bash to awk
On Thu, Nov 26, 2015 at 09:18:52AM -0500, Eliot Moss wrote:
> On 11/26/2015 8:24 AM, Lester Anderson wrote:
> >Hello,
> >
> >I can use a script like:
> >
> >#!/bin/bash
> >x=3.7
> ># pass variable x to awk via -v (var=value)
> >awk -v x=$x 'BEGIN { printf "%3.0f\n", x }'
> >#
> >
> >which returns the value 4 as expected, but are there any other methods
> >that can be used?
>
> In bash this must be a string (bash uses only fixed width integers for
> numbers),
> so you can put as many decimal places as you like. awk will treat it as a
> string
> or floating point number, depending on context. The f output format forces
> conversion.
> Another way is to do arithmetic; even x+0 will do it. IIRC, all numbers in
> awk are
> doubles (IEEE 64-bit floats). The documentation on awk can tell you more
> about
> conversions, rounding, etc.
>
> Regards -- Eliot Moss
>
You can skip using awk: under bash 'printf "%3.0f\n" 3.7' gives " 4".
Or 'printf "%.0f\n" 3.7' gives 4,
Cheers ... Duncan.
--
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: Calling cygpath from find exec?
On Mon, Nov 23, 2015 at 02:23:33PM -0700, Eric Blake wrote:
> On 11/23/2015 01:45 PM, Matt D. wrote:
> > Is there a reason why these produce different results?
> >
> > find . -exec cygpath -wa {} \;
> > find . -exec echo $(cygpath -wa {}) \;
>
> Incorrect quoting. You are invoking:
>
> find . -exec echo c:\cygwin\home\you\{} \;
>
> (or whatever ./{} resolves to), instead of one cygpath per name found by
> find.
>
> >
> > I have to do this which is much slower:
> > find . -exec bash -c 'echo $(cygpath -wa {})' \;
> >
>
> This indeed quotes things so that cygpath is now invoked once per file,
> but at the expense of an additional bash per file as well.
>
> Why not just:
>
> find . -exec cygpath -wa {} +
>
> since cygpath handles more than one file in an invocation (that is,
> using '-exec {} +' rather than '-exec {} \;' is generally faster).
>
I would be using xargs. Especially under /cygdrive, the "-print0 / xargs -0"
combination takes care of spaces and other nasties in file names.
find . -print0 | xargs -0 cygpath -wa
For utilities that only accept one argument, you can use xargs -n1 -0; you
still get the benefit of -print0.
Cheers ... Duncan.
--
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: cygwin 64bit on Win7 gcc internal compiler error: Segmentation fault on floating point literal 10.0
On Sat, Nov 21, 2015 at 07:02:50PM -0500, Ken Brown wrote:
> On 11/21/2015 3:10 PM, David Standish wrote:
> >gcc is broken on fresh install of 64 bit cygwin on 64 bit Win7
> >Enterprise on new laptop.
> >version 4.9.3-1 , but other versions broken as well (4.9.2-3, 5.2.0-1)
> >
> >I suspect there is a straightforward fix to my problem but I have no
> >idea where to begin.
> >
> >
> >Cygwin DLL version info:
> > DLL version: 2.3.1
> >
> >gcc-core 4.9.3-1
> >
> >Fresh cygwin64 install default base files + gcc_core
> >
> >bug5.c
> >
> >
> >
> >void demo(void)
> >{
> > 1.0;
> > 10.01;
> > 11.0;
> > 10.0;
> >}
> >
> >$ gcc -c bug5.c
> >bug5.c: In function 'demo':
> >bug5.c:9:3: internal compiler error: Segmentation fault
> >10.0;
> >^
> >Please submit a full bug report,
> >with preprocessed source if appropriate.
> >See for instructions.
>
> It works fine for me. Maybe you should send cygcheck output as requested at
> http://cygwin.com/problems.html:
>
> "Run cygcheck -s -v -r > cygcheck.out and include that file as an
> *attachment* in your report. Please do not compress or otherwise encode the
> output. Just attach it as a straight text file so that it can be easily
> viewed."
>
> Ken
>
FWIW, WFFM too. Win7 Home 64-bit, gcc 4.9.3-1, cygwin 2.3.1-1,
Cheers ... Duncan.
--
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: initial cygwin installation
On Thu, Oct 29, 2015 at 08:43:20AM +0100, Achim Gratz wrote: > Am 28.10.2015 um 21:38 schrieb Duncan Roe: > >As it happens, I also saw that message last night. I only wanted to > >*reinstall* > >everything I had installed previously, owing to AVG antivirus having deleted > >I > >don't know what. > > One way to do that (if you really want to re-install instead of running > cygcheck and just re-install those packages listed as incomplete) is to edit > /etc/setup/installed.db so that each package version listed there is > "outdated". The next time you run setup it will upgrade everything, which > is thre re-install you want. > > sed -re 's/( [a-zA-Z].*-.*-)[0-9]+\./\10./' \ > -i.bak /etc/setup/installed.db > > -- > Achim. > > (on the road :-) > Thanks Audrey & Achim, I already did the re-install and it just worked(!). Didn't take especially long either - guess I don't have a huge amount of stuff installed, compared with some folks. Cheers ... Duncan. -- 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: initial cygwin installation
On Wed, Oct 28, 2015 at 12:05:06AM -0600, Warren Young wrote: > On Oct 27, 2015, at 7:21 AM, Nellis, Kenneth wrote: > > > > From: Warren Young > >> > >> On Oct 25, 2015, at 3:11 PM, t s wrote: > >>> > >>> Q: How do I install everything? > >>> A: You do not want to do this! > >> > >> I explain this in more detail here: > >> > >> http://stackoverflow.com/a/21233990 > > > > For the hell of it I decided to check out this hidden feature. > > What I got was two dialog boxes popping up talking about > > Cygwin limitations, something about "this port of Avahi", > > references to Apple's "Bounjour mDNSResponder" service, > > and a link to http://support.apple.com/kb/DL999. > > > > What's up with that? > > That???s actually a great illustration of the point I tried to make. > > You just asked setup.exe to install a whole bunch of software you do not > actually need, so when it starts asking you questions about what you want done > with this software, you are lost, because you don???t even know what the > software *is*, much less how to use it. > > So don???t do that. :) > As it happens, I also saw that message last night. I only wanted to *reinstall* everything I had installed previously, owing to AVG antivirus having deleted I don't know what. I configured AVG to never look at C:\cygwin64 in future but was that the best I could have done? Cheers ... Duncan. -- 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] Early Deprecation Notice: Windows XP and Server 2003 support
On Thu, Aug 27, 2015 at 05:57:06AM -0400, Bryan Berns wrote: > On Wed, Aug 26, 2015 at 8:23 AM, Andrey Repin wrote: > > Greetings, Corinna Vinschen! > > > >> On Aug 26 12:56, Helmut Karlowski wrote: > >>> > > Guess that's better than to stick with the kludges, migration to 10 is > >>> > > on the way. > >>> > From what I've seen and heard W10, while mostly stable, still coerces > >>> > users > >>> > towards the software as (an expensive) service model and follows the > >>> > dictum > >>> > that Microsoft knows more about what you want than you do (default > >>> > saves to > >>> > microsoft cloud storage, grabs your pictures for background slide show > >>> > without asking, etc.). > >>> > >>> I hope I can customize it to behave like XP (only the goodies of > >>> course). > > > >> http://classicshell.net > > > > That doesn't solve the hotkeys bound at driver levels, unfortunately. > > Half of my keyboard dead now thanks to the move to Win7. > > > > Anyway, on the topic: All I could ask is to give us a notice when the final > > build for XP is available, so that we could prepare own mirrors. > > If you're passionate about it and you have any programming experience, > keyboard filter drivers are quite easy to write. Only annoying thing > is you need a signing certificate that is authorized for kernel code > signing -- which is only available to companies and some slightly more > expensive issuing authorities for individuals. Test signing? (works for com0com) Cheers ... Duncan. -- 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: tclsh does not export changes to env to child process
> > On Mon, Jun 29, 2015 at 2:45 PM, Stas Maximov
> > wrote:
> > > Hi,
> > >
> > > Tcl shell does not export changes to array variable env:
> > > http://wiki.tcl.tk/env
> > >
> > > Test script: test_env_export1:
> > > - begin --
> > > set env(FILENAME) filename_val
> > > puts $env(PATH)
> > > puts [exec /bin/bash -c {echo $PATH}]
> > > puts $env(FILENAME)
> > > puts [exec /bin/bash -c {echo $FILENAME}]
> > > - end --
> > >
> > > Expect two lines of output "filename_val", receive only one. The bug
> > > affects 'guitool' feature of git-gui.
> > >
> > > cygwin 2.0.4-1
> > > tclsh 8.5
> > >
> > >
> > > Thanks,
> > > Stas.
> On Tue, Jun 30, 2015 at 9:39 AM, Stas Maximov wrote:
> > Yakov,
> >
> > Thanks for the reply.
> >
> > Apologies for confusion. 8.5 was version of tcl as reported by
> > tcl_version. Please find below more information. Note that
> > "filename_val" is printed only once -- by tclsh, but the child (bash)
> > does not see environment variable FILENAME.
> >
> > Any specific information that you might want to see?
> >
> > Stas.
> >
> >
> > $ which tclsh
> > /usr/bin/tclsh
> >
> > $ cygcheck.exe -c tcl cygwin
> > Cygwin Package Information
> > Package VersionStatus
> > cygwin 2.0.4-1OK
> > tcl 8.5.18-1 OK
> >
> > $ cat test_env_export1.tcl
> > set env(FILENAME) filename_val
> > puts $env(FILENAME)
> > puts [exec /bin/bash -c {echo $FILENAME}]
> > puts $env(EDITOR)
> > puts [exec /bin/bash -c {echo $EDITOR}]
> >
> > $ tclsh test_env_export1.tcl
> > filename_val
> >
> > vim
> > vim
> >
> >
>
On Tue, Jun 30, 2015 at 09:43:27AM -0700, Stas Maximov wrote:
> Interestingly, if environment variable FILENAME was exported when
> tclsh called, the test passes. Tclsh falis to export only new env
> variable. Compare two results:
>
> $ env FILENAME=gaga tclsh test_env_export1.tcl
> filename_val
> filename_val
> vim
> vim
> $ env -u FILENAME tclsh test_env_export1.tcl
> filename_val
>
> vim
> vim
>
>
Years ago I seem to recall a problem with tclsh not exporting amended
environment variables. Looks like it's fixed now though, at least on my Linux
system (sorry it's tclsh 8.6)
> 12:37:18$ env|grep ZXC
> 12:37:31$ tclsh
> % set env(ZXC) hello
> hello
> % puts $env(ZXC)
> hello
> % puts [exec /bin/bash -c {echo $ZXC}]
> hello
> % info vars
> tcl_rcFileName tcl_version argv0 argv tcl_interactive auto_path auto_index
> env tcl_pkgPath tcl_patchLevel argc tcl_library tcl_platform
> % puts $tcl_patchLevel
> 8.6.1
> % exit
Cheers ... Duncan.
--
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 ask a question on Tkgate for Cygwin ?
On Sun, May 31, 2015 at 12:39:04PM +0200, Rémi 2005 wrote:
> Hello,
> I've worked hard and I found some responses alone. But it's not enough...
> Cygwin doesn't find the make command but I've added to Cygwin the "make" and
> the "gcc g++ compiler". And now, when I run "configure", Cygwin try to
> compile Tkgate. In contrast, it can't be make it ! And it answer "no
> makefile" (" make: *** Pas de cible spécifiée et aucun makefile n'a été
> trouvé. Arrêt." In French). Well, I'm blocked now, so it's why I've copied
> the results of the compilation of tkgate.
> Thanks in advance if you can help me,
> Cordially,
> Rémi,
> PS :Sorry for the English mistake...
> +++
> Results of tkgate compilation
> +++
> J@PC_Salon ~
> $ cd tkgate-2.0-b10
>
> J@PC_Salon ~/tkgate-2.0-b10
> $ ./configure
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking for g++... g++
> checking for C++ compiler default output file name... a.exe
> checking whether the C++ compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables... .exe
> checking for suffix of object files... o
> checking whether we are using the GNU C++ compiler... yes
> checking whether g++ accepts -g... yes
> checking for style of include used by make... GNU
> checking dependency style of g++... gcc3
> checking for gcc... gcc
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking dependency style of gcc... gcc3
> checking for bison... no
> checking for byacc... no
> checking for flex... no
> checking for lex... no
> checking whether ln -s works... yes
> checking whether make sets $(MAKE)... (cached) yes
> checking for ranlib... ranlib
> checking how to run the C preprocessor... gcc -E
> checking for a BSD-compatible install... /usr/bin/install -c
> checking for ranlib... (cached) ranlib
> checking build system type... ./config.guess: unable to guess system type
>
> This script, last modified 2003-07-02, has failed to recognize
> the operating system you are using. It is advised that you
> download the most up to date version of the config scripts from
>
> ftp://ftp.gnu.org/pub/gnu/config/
>
> If the version you run (./config.guess) is already up to date, please
> send the following data and any information you think might be
> pertinent to in order to provide the needed
> information to handle your system.
>
> config.guess timestamp = 2003-07-02
>
> uname -m = x86_64
> uname -r = 2.0.2(0.287/5/3)
> uname -s = CYGWIN_NT-6.1
> uname -v = 2015-05-08 17:00
>
> /usr/bin/uname -p = unknown
> /bin/uname -X =
>
> hostinfo =
> /bin/universe =
> /usr/bin/arch -k =
> /bin/arch = x86_64
> /usr/bin/oslevel =
> /usr/convex/getsysinfo =
>
> UNAME_MACHINE = x86_64
> UNAME_RELEASE = 2.0.2(0.287/5/3)
> UNAME_SYSTEM = CYGWIN_NT-6.1
> UNAME_VERSION = 2015-05-08 17:00
> configure: error: cannot guess build type; you must specify one
>
> J@PC_Salon ~/tkgate-2.0-b10
> $ make
> make: *** Pas de cible spécifiée et aucun makefile n'a été trouvé. Arrêt.
>
> J@PC_Salon ~/tkgate-2.0-b10
> +++
> End of results tkgate compilation
> +++
>
> -Message d'origine-
> De : David Stacey [mailto:drsta...@tiscali.co.uk]
> Envoyé : dimanche 31 mai 2015 01:01
> À : cygwin@cygwin.com
> Cc : remi2...@laposte.net
> Objet : Re: How ask a question on Tkgate for Cygwin ?
>
> On 29/05/2015 22:23, Rémi Anjou wrote:
> > What is the procedure to install Tkgate with the Cygwin version 2.871 ?
>
> tkgate isn't present as a Cygwin package, so you will have to build it from
> source yourself. tkgate compiles out of the box under Cygwin.
> However, Fedora carries four patches [1], and you may consider looking at
> these to see if they are applicable for Cygwin.
>
> Here are the commands I used to compile tkgate:
>
> wget http://www.tkgate.org/downloads/tkgate-2.0-b10.tgz
> tar -xf tkgate-2.0-b10.tgz
> cd tkgate-2.0-b10/
> ./configure
> make
>
> Then I ran the application like this:
>
> XWin -multiwindow &
> export DISPLAY=:0.0
> ./src/tkgate/tkgate &
>
> The tkgate application started, and I was presented with a window containing
> a number of electrical circuit diagrams. However, tkgate isn't an
> application I'm familiar with, so I stopped there.
>
> You could also install it into your Cygwin installation (although I didn't
> try this):
>
> make install
> make install.man
>
> Hope this helps,
>
> Dave.
Re: [TESTERS needed] New POSIX permission handling
On Fri, May 15, 2015 at 09:20:10PM -0500, Steven Penny wrote:
> On Fri, Apr 10, 2015 at 7:00 PM, Steven Penny wrote:
> > Here is the test I ran:
>
> The test I ran here
> http://cygwin.com/ml/cygwin/2015-04/msg00186.html
> is now failing again:
>
> $ cd /cygdrive/c
>
> $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh
>
> $ chmod +x ~/bravo.sh ~+/delta.sh
>
> $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh
> -rw-rwxr--+ 1 John None 0 May 15 19:12 /cygdrive/c/charlie.sh (green)
> -rwxrwxr-x+ 1 John None 0 May 15 19:12 /cygdrive/c/delta.sh(green)
> -rw-r--r-- 1 John None 0 May 15 19:12 /home/John/alpha.sh
> -rwxr-xr-x 1 John None 0 May 15 19:12 /home/John/bravo.sh (green)
>
> Please sort this out. Having ???ls --color??? is pointless if everything is
> the same
> color.
>
Your results look fine to me. In your original test, charlie.sh was -rw-rw-r--+,
but now it is -rw-rwxr--+ (i.e. it has acquired group execute access). So why
would you not expect it to show in green?
Cheers ... Duncan.
--
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: Can I move Cygwin and Cygwin64 to a drive other than C: ?
On Thu, Apr 02, 2015 at 12:55:51AM -0500, Robert Miles wrote: > On 4/1/2015 3:47 AM, Corinna Vinschen wrote: > >On Apr 1 03:26, Robert Miles wrote: > >>The C: drive on one of my 64-bit Windows 7 computers is approaching > >>90% full, but there are two other drives that are nearly empty. > >> > >>Can I move the entire Cygwin and Cygwin64 directory trees to one > >>of the nearly empty drives, without losing the extra packages I've > >>already downloaded and the files I've created? > > > >Robocopy allows to copy an entire Cygwin tree while keeping all > >permissions intact. I had good luck with something along the > >lines of > > > > robocopy C:\cygwin64 D:\cygwin64 /e /purge /z /copyall /sl > > > > > >YMMV, > >Corinna > > I tried that on C:\cygwin; it gave an error message without copying > anything. I suspect that was because this directory tree included > links to the top-level directories of all of the Windows drives, > including the one holding the Windows 7 operating system. > > I found a way to see the robocopy instructions; it looks like I'll > need to read them thoroughly in order to tell it to copy the links > but not what they point to. > Yes robocopy does have an option to copy symlinks rather than what they point to: I saw it in the robocopy instructions that you're about to read. Cheers ... Duncan. -- 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: g++4.9.2 fails to compile standard C++11 code
On Wed, Mar 11, 2015 at 06:55:16PM -0400, Vlad Gheorghiu wrote:
> The following code fails to compile under latest cygwin, Windows 7,
> g++4.9.2. Compiled with g++ -std=c++11 test.cpp. The compiler
> complains that std::log2 is not a member of std.
>
> #include
> #include
>
> int main()
> {
> auto x = std::log2(10);
> std::cout << x << std::endl;
> }
>
>
> Verbatim error:
>
> g++ -std=c++11 test.cpp
> test.cpp: In function ???int main()???:
> test.cpp:5:11: error: ???log2??? is not a member of ???std???
> auto x = std::log2(10);
>^
> test.cpp:5:11: note: suggested alternative:
> In file included from
> /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/cmath:44:0,
> from test.cpp:1:
> /usr/include/math.h:305:15: note: ???log2???
> extern double log2 _PARAMS((double));
>
FWIW, this program works fine under Linux / gcc4.8.2:
20:45:23$ uname -a
Linux dimstar 3.19.0-k8 #1 SMP Mon Mar 2 21:58:02 EST 2015 i686 AMD Athlon(tm)
64 X2 Dual Core Processor 6000+ AuthenticAMD GNU/Linux
20:45:44$ g++ --version
g++ (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
20:47:26$ g++ -std=c++11 cygwin.cpp -o cygwin
20:50:25$ ./cygwin
3.32193
20:50:36$ cat cygwin.cpp
#include
#include
int main()
{
auto x = std::log2(10);
std::cout << x << std::endl;
} /* int main() */
Cheers ... Duncan.
--
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
Odd ezmlm warning messages from this list
Hi, I get messages like the one below now and then. From the message text it would seem something has gone wrong with the mail formatting (2 reply addresses). This is just a heads-up, Cheers ... Duncan. - Forwarded message from cygwin-h...@cygwin.com - Date: 18 Jan 2015 00:03:42 - From: cygwin-h...@cygwin.com To: duncan_...@acslink.net.au Subject: ezmlm warning Hi! This is the ezmlm program. I'm managing the cygwin@cygwin.com mailing list. Messages to you from the cygwin mailing list seem to have been bouncing. I've attached a copy of the first bounce message I received. If this message bounces too, I will send you a probe. If the probe bounces, I will remove your address from the cygwin mailing list, without further notice. I've kept a list of which messages from the cygwin mailing list have bounced from your address. Copies of these messages may be in the archive. To retrieve a set of messages 123-145 (a maximum of 100 per request), send an empty message to: To receive a subject and author list for the last 100 or so messages, send an empty message to: Here are the message numbers: 194279 194280 194281 194278 194447 --- Enclosed is a copy of the bounce message I received. Return-Path: <> Received: (qmail 6504 invoked for bounce); 6 Jan 2015 00:56:24 - Date: 6 Jan 2015 00:56:24 - From: mailer-dae...@sourceware.org To: cygwin-return-1942...@cygwin.com Subject: failure notice Hi. This is the qmail-send program at sourceware.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : User and password not set, continuing without authentication. 202.124.241.196 failed after I sent the message. Remote host said: 550 Messages should have one or no Reply-To headers, not 2. - End forwarded message - -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- 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] TEST RELEASE: Cygwin 1.7.33-0.5
On Wed, Nov 05, 2014 at 06:23:54PM +, Habermann, David (D) wrote:
> > I just released a 5th TEST version of the next upcoming Cygwin release,
> > 1.7.33-0.5.
>
> Ever since using this 1.7.33-0.x series (currently running 1.7.33-0.5) I've
> been having intermittent trouble with one of my scripts, and just finally got
> around to digging further today. This is an expect script (subroutine of a
> larger system) designed to auto-login to an ssh session and then set the
> passwd -R to allow further ssh sessions to have "full network powers". (I then
> run a cron script which drops these rights off again every half-hour, so the
> "full network powers" logins are time limited.)
>
> The symptoms of the failure are that it sometimes fails to send the ssh
> password (and thus doesn't proceed to the passwd -R command at all). If I run
> the script a second time, it almost always works on the second try. After some
> time has passed I run it again and get a failure, then immediately run again
> and succeed. I would appreciate any thoughts as to why such a script would
> fail, and then succeed on successive runs. This routine basically never
> failed on the previous recent versions of cygwin (in active daily use since
> approximately July 1st).
> >
> > Dave
> >
> >
> > The script is called like this:
> >
> > $ super.exp localhost mypasswd
> >
> > and the file super.exp looks like this:
> >
> #!/usr/bin/expect
>
> set mach [lindex $argv 0]
> set pass [lindex $argv 1]
>
> spawn ssh -o PubkeyAuthentication=no $mach
> expect -exact "password: "
> send $pass\n
> expect {
> "$ " {
> send "passwd -R\n"
> expect -exact "password: "
> send $pass\n
> expect -exact "password: "
> send $pass\n
> expect -exact "$ "
> send "exit\n"
> interact
> }
> "Permission denied, please try again." {
> send_error "The password you provided was invalid.\n"
> exit 1
> }
> }
>
I would try "set exp_internal 1" and capture the output somewhere. There
shouldn't be too much for a script this size. You should see the exact failure
point quite easily.
Cheers ... Duncan.
--
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: mintty: WINCH-signal to child
On Sat, Oct 18, 2014 at 10:02:33PM +0100, Helmut Karlowski wrote: > > When I run for example an editor from a shell in a mintty-window and change > the window-size the editor is informed by a WINCH-signal. That is good. But > the shell it was started from does not know about the change, so after > exiting the editor the shell uses the old size. Could mintty send a > WINCH-signal to its direct child (-pgrp) perhaps? > > Of course for more complicated situations it could be difficult to inform > all involved processes when not all have the same pgrp, but it would be > better than nothing. > > Or do I miss something? > > -Helmut > bash at least has "shopt -s checkwinsize" to achieve what you want, Cheers ... Duncan. -- 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 cron jobs
On Thu, Aug 21, 2014 at 07:59:29AM -0400, Cary Lewis wrote: > I have created a small shell script that acts like a network > connectivity watchdog, which checks for a successful ping to the > internet, and if it doesn't work, restarts the machine. > > When I attempt to run it from a cron job, the script exits whenever > any of the commands exits with a non zero status, preventing the > script from doing its job. > > Has anyone seen this behaviour before? > Yes - this is the behaviour you get with "set -e". To negate it, put "set +e" at the top of your script, Cheers ... Duncan. -- 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: Missing strings.exe in binutils
On Sun, Jun 01, 2014 at 07:01:41PM -0400, Jeff Hubbs wrote: > Hi - > > I have a script within a very complex software package that uses the > "strings" > command. Everything I Googled/read suggests that strings.exe comes from the > binutils package. The problem is that neither of the available versions of > binutils > seem to actually contain strings.exe. It's not in /usr/bin; find can't turn > it up under /usr at all. > > There's even this: > > $ cygcheck -p strings.exe > Found 19 matches for strings.exe > x86/binutils/binutils-2.24.51-2 > x86/binutils/binutils-2.24.51-3 > > And if I go to > https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86%2Fbinutils%2Fbinutils-2.24.51$ > this appears: > > 2014-05-29 02:01 709661 usr/bin/strings.exe > > Yet there's no strings.exe. I've even tried binutils packages from a few > different mirrors. > > If there's no fixed binutils package available, can someone shoot me a > strings.exe I can just fly into place for the time being? > > Thanks, > - Jeff > On my Slackware system, binutils comes with strings-GNU. Perhaps you will find you have strings-GNU.exe - if so you could symlink it to strings.exe, Cheers ... Duncan. -- 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: POXIX regexp and i686-pc-mingw32-g++
On Wed, Apr 30, 2014 at 05:50:45PM -0600, Jim Reisert AD1C wrote: > Can anyone help me to use the POSIX regexp library (header regex.h) > with the i686-pc-mingw32-g++ compiler? I've searched through google > and I can't find any example of this. > > If this won't work, does anyone have a practical example of PCRE and > this compiler? It seems that there's a 64-bit Cygwin package, but no > 32-bit package. > > Thanks - Jim > Does "man 3 regex" not work for you? It does for me (Cygwin 64-bit), Cheers ... Duncan. -- 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: No shortcuts after default install - how to start cygwin?
On Sat, Apr 26, 2014 at 07:35:03PM +1000, ben modra wrote: > Hi, > After performing a standard (default) install using setup-x86.exe, > there are no shortcuts in the start menu or desktop. I don't really > mind but don't know how to initiate cygwin without it. > > Its a work pc, which means I have little control over the system, and > it has been meddled with quite a bit. Running XP. It quite common > for this to happen on installing software, and I usually just make a > desktop shortcut. Must be unusual for others because I can't find any > reference to it in the archives. > > Can you please tell me how to run cygwin without the shortcut? > > Thanks > I make shortcuts to /cygwin/bin/bash.exe and /cygwin64/bin/bash.exed (I have both). Perhaps there is a better way to do it, but that works for me, Cheers ... Duncan. -- 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: GIT (was: Coverity Scan)
On Sat, Apr 26, 2014 at 08:42:34AM +0800, JonY wrote: > On 4/26/2014 07:27, Andrey Repin wrote: > > This is exactly what makes me dislike it strongly. This, and idiotic model > > of > > copying whole repository to my machine, when I only want to glance at the > > source code, and find the culprit of my current issues. > > I've spent 3 hours downloading a 200Mb repo of a project, where the > > Subversion > > client pulled 4 or 5Mb HEAD of it in like 10 minutes, once I realized what > > an > > idiotic weight I pulled and went to google to see if it can be done better. > > And "fine control" doesn't mix with "project consistency" at all. > > Subversion is aimed at versioning of a whole project, in a supposedly > > consistent state at each version. What can be more "fine" than this, is > > beyond > > my understanding. > > git clone --depth 1 if you don't care about history. > > > You can still commit separate files from working copy, though, but this > > practice is discouraged for the greater good of the project you develop. > > > > Don't you need to git add individual files to mark for commit? Won't you > get into the same problems if you forgot to commit files in SVN? > > > "git commit -a" commits modified files without the need to add them first. You always have to add new files. -- 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: setting cygwin terminal (mintty) title from a very remote system
On Fri, Apr 11, 2014 at 12:13:07PM -0700, Ross Boylan wrote:
> I typically connect to systems through several hops; this note is about how
> I managed to set the title of the cygwin terminal to match the remote
> system. Usually it just shows the name on the first hop only. I would
> love to learn there is a better way to get the same results.
>
> Various internet sources advise things like
>
> echo -ne '\e]0;Title\a'
>
> to set the window title while noting that the default cygwin prompt sets
> this automatically. This did not work for me initially, but I found a way
> to get it to work.
>
> On the remote system the prompt does not contain any window titling
> commands.
>
> Concretely, my connection sequence looks like this.
>
> From System A, running Windows 7, launch a cygwin bash shell.
> In that shell, ssh to system B. B's name will appear in the title bar.
> From B ssh to C. Neither this nor later operations change the title bar.
> From C ssh to D.
> On D, run screen.
> In screen, run emacs.
> In emacs start a (bash) shell.
>
> I want the name of system D to appear in my title bar.
> Systems B-D are running various versions of Debian GNU/Linux.
> The echo command from within the bash prompt is ineffective.
>
> If I start a new shell from within screen (Ctl-a c), the echo command works
> from there.
>
> I suppose if I built the window setting command into the remote prompt
> things would just work, since I launch emacs from such a prompt. But I'm
> not sure what that would do if I were not connecting via cygwin.
>
> Ross Boylan
>
> Someone put in a request for a feature to support manually setting the
> title; this was rejected on the grounds that echoing an appropriate sequence
> would do the same thing
> (http://code.google.com/p/mintty/issues/detail?id=241). Unfortunately, that
> does not seem to be true after connecting to a remote system, or at least it
> is not true after the sequence of steps described above.
> http://superuser.com/questions/362227/how-to-change-the-title-of-the-mintty-window
> has a comment that the echo has no effect when issued from within screen.
>
It is simply inappropriate to try to set the window title from the bash prompt.
Remove any and all attempts to do that from PS1 and instead put them in
PROMPT_COMMAND which bash will obey at every prompt. This may look like
overkill, but will reset the window name should any command you run have changed
it. E.g. I have
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD/#$HOME/~}\007"'
Try it,
Cheers ... Duncan.
--
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: Still testing needed: New passwd/group AD/SAM integration
On Fri, Apr 11, 2014 at 02:39:34PM +0200, Corinna Vinschen wrote: > On Apr 11 16:20, Duncan Roe wrote: > > On Thu, Apr 10, 2014 at 09:47:26PM -0600, Warren Young wrote: > > > On 4/10/2014 20:16, Duncan Roe wrote: > > > >Yes, I'm one of those users. I need my login name to match the Linux > > > >systems so > > > >I can use rsh and not be challenged for a password when the cygwin host > > > >name is > > > >in ~/.rhosts > > > > > > If you switch to SSH, you can solve this by putting this into your > > > ~/.ssh/config file: > > > > > > Host myremotehost > > > User duncan_roe > > > > > > That is, you can override defaults (like login name) on a per-connection > > > basis. Anything you can pass as an option to ssh(1) can be changed here, > > > so > > > you don't have to keep providing the option. > > > > > > With pre-shared keys, I don't think you'll see a difference in behavior > > > relative to rsh. > > > > > I don't want to switch to ssh. rsh is in an expect script, so providing ssh > > options every time would not be a problem. But I want to use rsh. > > OTOH, if there *is* an official workaround which is, "use the /etc/passwd > file to chnage your username", wouldn't that be sufficient? Yes it's perfect. That's what I use. > > I understand your point, but the search problem in the Windows user DBs > as I outlined persists. > > What I did a couple of weeks ago ws to change the mkpasswd tool so that > it creates the exact same passwd entries as you get when fetching them > directly from Windows. For instance, the passwd entry generated for > my AD account inside of Cygwin will look like this: > > corinna:*:1049577:1049701:Corinna > Vinschen,U-VINSCHEN\corinna,S-1-5-21-2913048732-1697188782-3448811101-1001:/home/corinna:/bin/tcsh > > Using the "new" mkpasswd, calling `mkpasswd -d -u corinna', I get the > exact same entry! If I write this into /etc/passwd, I'm getting the > exact same correct uid and gid values, but I can change my username: > > $ mkpasswd -d -u corinna > /etc/passwd > $ sed -i -e 's/^corinna:/cathy:/' /etc/passwd > [logout/login] > $ id > uid=1049577(cathy) gid=1049701(vinschen) groups=1049701(vinschen), > 559(+Performance Log Users),545(+Users),[...] > > That should be sufficient, shouldn't it? > I do that already. Good to hear it as sound practice from you though, Cheers ... Duncan. -- 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: Still testing needed: New passwd/group AD/SAM integration
On Thu, Apr 10, 2014 at 09:47:26PM -0600, Warren Young wrote: > On 4/10/2014 20:16, Duncan Roe wrote: > >Yes, I'm one of those users. I need my login name to match the Linux systems > >so > >I can use rsh and not be challenged for a password when the cygwin host name > >is > >in ~/.rhosts > > If you switch to SSH, you can solve this by putting this into your > ~/.ssh/config file: > > Host myremotehost > User duncan_roe > > That is, you can override defaults (like login name) on a per-connection > basis. Anything you can pass as an option to ssh(1) can be changed here, so > you don't have to keep providing the option. > > With pre-shared keys, I don't think you'll see a difference in behavior > relative to rsh. > I don't want to switch to ssh. rsh is in an expect script, so providing ssh options every time would not be a problem. But I want to use rsh. -- 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: Still testing needed: New passwd/group AD/SAM integration
On Thu, Apr 10, 2014 at 09:11:20PM +0200, Corinna Vinschen wrote: > On Apr 10 12:42, Warren Young wrote: > > On 4/10/2014 08:53, Corinna Vinschen wrote: > > >* Support for Cygwin user names different from the Windows username. > > > > > > This is a really fat problem. > > > > Who needs this functionality? > > I don't remember, but some user on this list wrote in February about how > he uses this for... something. Something to do with logging in to other > machines or so. > > > Is it some legacy of passwd(5) compatibility, such as the wish to > > have colons in Windows login names? > > No, it's just some legacy of how we allow this for /etc/passwd and > /etc/group. See, for instance entries like > > root:S-1-5-21-544:0: > > to fake a root group backed by the administrators group. It > seemed like a good idea at the time (2000 or so) and this would > not be possible anymore. But, in fact, I was trying to make sure > all the time that our applications don't rely on this. And if we > actually have an application which relies on this, it's a bug. > > > Does the move to AD/SAM eliminate the original need, so that you > > actually have *two* reasons to stop paying the runtime expense? > > I never had this need. To me it was just a funny extension. But maybe > other users are using this, so I'm a bit unlucky now that I invented it > in the first place. > > > Corinna > Yes, I'm one of those users. I need my login name to match the Linux systems so I can use rsh and not be challenged for a password when the cygwin host name is in ~/.rhosts Cheers ... Duncan. -- 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: set Cygwin terminal title
On Tue, Apr 08, 2014 at 03:55:02PM +0100, Adam Dinwoodie wrote:
> On Tue, Apr 08, 2014 at 03:24:29PM +0100, xmoon 2000 wrote:
> > Ho can I set Cygwin termnal title?
> >
> > I have tried echoing every escape sequence I have found on web.
> >
> > None seem to work.
>
> It's reasonably likely your `$PS1` includes a line to set the terminal
> title; I think the default Cygwin Bash profile files do that. If that's
> the case, an escape sequence command to set the terminal title will
> work, but will then be immediately reset by the Bash prompt being
> displayed.
>
> To check, run `echo "$PS1"` and see if that includes a bunch of escape
> sequences. If it does, to change that behaviour you'll need to work out
> which file is setting `$PS1` and fix it. It'll probably be one of
> `~/.bashrc`, `~/.profile` or `~/.bash_profile`.
>
> If that doesn't get you anywhere, read through the below, including the
> link on how to ask smart questions. You've really not given us much to
> go on to help you.
>
I have this in my .bashrc
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD/#$HOME/~}\007"'
A bit extravegant to issue after every command I suppose, but it works,
Cheers ... Duncan.
--
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: Request for Junctions be treated consistently
On Mon, Apr 07, 2014 at 11:34:02AM -0700, Linda Walsh wrote: > Corinna Vinschen wrote: > >Look, directory reparse points are, by and large, symlinks to another, > >real directory entry. The directory has a primary path, which is its > >own path under which it has been created, and the reparse point is just > >a pointer to this directory. If that's not a symlink, what is? > --- > What is a mount 'bind' on linux? > This extract from the Linux man page explains it: The bind mounts. Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is mount --bind olddir newdir or shortoption mount -B olddir newdir or fstab entry is: /olddir /newdir none bind After this call the same contents is accessible in two places. Cheers ... Duncan. -- 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: Trouble with running cygwin dll on Vortex86MX+ CPU
On Mon, Apr 07, 2014 at 06:12:56PM -0400, Larry Hall (Cygwin) wrote: > On 4/7/2014 5:09 PM, Colin wrote: > > > > >>Indeed. And if your path under bash doesn't include /usr/bin, then I'll > >>wager your postinstall scripts didn't run or at least > >completely/correctly. > >>See /etc/postinstall for the scripts. If you aren't able to figure out > >>what didn't run properly, you can either try rerunning everything > >manually > >>and looking for faults (if any) or just rerun setup.exe and hope that it > >>has better luck with the scripts the second time around. > >> > > > >Spot on, Larry. $PATH is empty. > >I 'Reinstall'ed Cygwin, but the result is the same. I did take note of > >setup complaining that there is a more recent version available according > >to the ini file (2.774 vs 2.674) but I'm picking that isn't the problem. > > I do find it interesting that the Cygwin Time Machine wouldn't have the > setup version and the archive in sync. You'd have to check with that site > to understand why you're seeing that. > > >/etc/postinstall contains the following "done" script files: > >base-files-mketc.sh.done > >base-files-profile.sh.done > >bash.sh.done > >coreutils.sh.done > >cygwin-doc.sh.done > >man.sh.done > >passwd-grp.sh.done > >terminfo.sh.done > >terminfo0.sh.done > >update-info-dir.sh.done > > > >Is there something missing from that list? What's my next step? I haven't > >yet tried running them manually, that will have to wait until tonight (gmt > >+ 12). > > That list seems a bit limited to me, unless you specifically asked for just > those packages to install. Allowing setup to install a default installation > should get you several dozen packages I believe, in 1.5 days. So I'd say > start there and check that. If that doesn't help, check with the Cygwin > Time Machine site for help. > I have an older install at work, and thought that behaviour was normal (empty $PATH). I just set the PATH in .bashrc in the initial directory - then everything "just worked". Cheers ... Duncan. -- 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
NOT WORKED AROUND Re: No I/O redirection under GDB
Sorry for the noise everyone. I started to compose the last mail thinking "set inferior-tty" would solve my problem. Then on further testing, I found it didn't. I'm still up for fixing gdb to do the job properly - or can someone on this list tell me why I'd be wasting my time? Cheers ... Duncan. On Sat, Apr 05, 2014 at 03:15:14PM +1100, Duncan Roe wrote: > On Fri, Apr 04, 2014 at 10:51:24PM -0400, Eliot Moss wrote: > > On 4/4/2014 10:29 PM, Duncan Roe wrote: > > >I just found that gdb's "run" command doesn't action redirection (e.g. run > > >/dev/pty2 2>&1, where the shell on /dev/pty2 is doing a long > > >sleep). > > >Instead, the invoked program gets the redirections as command line > > >arguments. > > > > > >Looking through the archives, I found > > >https://sourceware.org/ml/cygwin/1999-04/msg00355.html documenting this > > >behaviour. Chris Faylor commented at the time that fixing it was more > > >trouble > > >than it appeared. > > > > > >That was 15 years ago - has anything changed since? Anyone up for this or > > >should > > >I have a go? I *could* simply make my target do the redirection itself, > > >but that > > >doesn't help anyone else. OTOH if changing gdb really *is* that hard, > > >maybe I > > >should just change my program anyway. > > > > > >Any advice welcomed, > > > > I think this is the intended design (see: > > https://sourceware.org/gdb/current/onlinedocs/gdb/Input_002fOutput.html#Input_002fOutput > > ). If you want *gdb's* input and output redirected, I would think you want > > to invoke > > gdb with I/O redirection on the command line, as in: > > > > gdb foo < infile > outfile > > > > Regards -- Eliot Moss > > > Thanks for replying. > > Sorry but your suggested command line doesn't help: I need gdb command i/o in > one screen and program i/o in another. > > The set inferior-tty command documented in the link you posted *very nearly* > gave me what I was after. Having updated my startup script to use it, I now > find > that I can't use Control-C to interrupt the session: it's ignored in the gdb > window and causes catastrophic gdb failure in the application window (as well > as > waking the shell from sleep). It's better than nothing I guess. > > So, I'm back to needing i/o redirection in the run command (as also documented > in your link). It works in Linux. > > Cheers ... Duncan. -- 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
WORKED AROUND Re: No I/O redirection under GDB
On Fri, Apr 04, 2014 at 10:51:24PM -0400, Eliot Moss wrote: > On 4/4/2014 10:29 PM, Duncan Roe wrote: > >I just found that gdb's "run" command doesn't action redirection (e.g. run > >/dev/pty2 2>&1, where the shell on /dev/pty2 is doing a long > >sleep). > >Instead, the invoked program gets the redirections as command line arguments. > > > >Looking through the archives, I found > >https://sourceware.org/ml/cygwin/1999-04/msg00355.html documenting this > >behaviour. Chris Faylor commented at the time that fixing it was more trouble > >than it appeared. > > > >That was 15 years ago - has anything changed since? Anyone up for this or > >should > >I have a go? I *could* simply make my target do the redirection itself, but > >that > >doesn't help anyone else. OTOH if changing gdb really *is* that hard, maybe I > >should just change my program anyway. > > > >Any advice welcomed, > > I think this is the intended design (see: > https://sourceware.org/gdb/current/onlinedocs/gdb/Input_002fOutput.html#Input_002fOutput > ). If you want *gdb's* input and output redirected, I would think you want > to invoke > gdb with I/O redirection on the command line, as in: > > gdb foo < infile > outfile > > Regards -- Eliot Moss > Thanks for replying. Sorry but your suggested command line doesn't help: I need gdb command i/o in one screen and program i/o in another. The set inferior-tty command documented in the link you posted *very nearly* gave me what I was after. Having updated my startup script to use it, I now find that I can't use Control-C to interrupt the session: it's ignored in the gdb window and causes catastrophic gdb failure in the application window (as well as waking the shell from sleep). It's better than nothing I guess. So, I'm back to needing i/o redirection in the run command (as also documented in your link). It works in Linux. Cheers ... Duncan. -- 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
No I/O redirection under GDB
I just found that gdb's "run" command doesn't action redirection (e.g. run /dev/pty2 2>&1, where the shell on /dev/pty2 is doing a long sleep). Instead, the invoked program gets the redirections as command line arguments. Looking through the archives, I found https://sourceware.org/ml/cygwin/1999-04/msg00355.html documenting this behaviour. Chris Faylor commented at the time that fixing it was more trouble than it appeared. That was 15 years ago - has anything changed since? Anyone up for this or should I have a go? I *could* simply make my target do the redirection itself, but that doesn't help anyone else. OTOH if changing gdb really *is* that hard, maybe I should just change my program anyway. Any advice welcomed, Cheers ... Duncan. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- 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: FIXED: GCC can't find its header directoriescy
Thanks all - it is done > Greetings, Duncan Roe! > > >> > Thanks Dave - removing the old cygwin dlls from C:\WINDOWS fixed > >> > gcc > > & >> > > alternatives. > >> > I put them there because I like to have the odd cygwin utility >> > > available to CMD.EXE. >> > > >> > > May put them back - but will take more care with them in future, >> > > > >> Adding c:\cygwn\bin to the Windows PATH might be a better solution; > > that's what I did. >> > > >> Csaba > > > OK I'm convinced. But ... how do I do it? Registry? autoexec.bat? other? > > Whatever drives your car. > Usually, it is "My computer" properties - Advanced - Environment Adjust either system or user environment settings. > > WBR, > Andrey Repin 12.04.2013, <06:27> That worked for me. Many thanks, Cheers ... Duncan. -- 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: FIXED: GCC can't find its header directoriescy
Hi Casba, > On Thu, Apr 11, 2013 at 8:08 AM, Duncan Roe wrote: > > Thanks Dave - removing the old cygwin dlls from C:\WINDOWS fixed gcc & > > alternatives. > > I put them there because I like to have the odd cygwin utility > > available to CMD.EXE. > > > > May put them back - but will take more care with them in future, > > > Adding c:\cygwn\bin to the Windows PATH might be a better solution; that's what I did. > > Csaba OK I'm convinced. But ... how do I do it? Registry? autoexec.bat? other? Cheers ... Duncan. -- 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
FIXED: GCC can't find its header directoriescy
Thanks Dave - removing the old cygwin dlls from C:\WINDOWS fixed gcc & alternatives. I put them there because I like to have the odd cygwin utility available to CMD.EXE. May put them back - but will take more care with them in future, Cheers ... Duncan. -- 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
FW: GCC can't find its header directories: test C file
Sorry - meant to include source so you can easily test, Cheers ... Duncan. -Original Message- From: Duncan Roe Sent: Thursday, 11 April 2013 3:13 PM To: cygwin. Subject: GCC can't find its header directoriescy Thanks guys for the pointers to cygmpfr-4.dll. Got it. This problem with headers started happening on an old installation so I reinstalled but it still happens: strerror.c Description: strerror.c -- 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
GCC can't find its header directoriescy
Thanks guys for the pointers to cygmpfr-4.dll. Got it. This problem with headers started happening on an old installation so I reinstalled but it still happens: 12:31:51$ gcc -v strerror.c -o strerror Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.5.3/lto-wrapper.exe Target: i686-pc-cygwin Configured with: /gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/configure --srcdir=/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5. --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc -- atarootdir=/usr/share --docdir=/usr/share/doc/gcc4 -C --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr= usr --enable-bootstrap --enable-version-specific-runtime-libs --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_a exit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite --enab e-lto --enable-java-awt=gtk --disable-symvers --enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada --enable-threads=posix - with-arch=i686 --with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND FOR_TARGET=gnatbind --with-ecj-jar=/usr/share/java/ecj.jar Thread model: posix gcc version 4.5.3 (GCC) COLLECT_GCC_OPTIONS='-v' '-o' 'strerror.exe' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe -quiet -v -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.3/../ ./../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/lib/../../i nclude/w32api strerror.c -quiet -dumpbase strerror c -mtune=generic -march=i686 -auxbase strerror -version -o /tmp/ccShhRJ9.s GNU C (GCC) version 4.5.3 (i686-pc-cygwin) compiled by GNU C version 4.5.3, GMP version 4.3.2, MPFR version 3.0.1-p4, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-cygwin/4.5.3/include" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-cygwin/4.5.3/include-fixed" ignoring nonexistent directory "/usr/i686-pc-cygwin/include" ignoring nonexistent directory "/usr/include" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/lib/../../ include/w32api" #include "..." search starts here: #include <...> search starts here: End of search list. GNU C (GCC) version 4.5.3 (i686-pc-cygwin) compiled by GNU C version 4.5.3, GMP version 4.3.2, MPFR version 3.0.1-p4, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 89d6774c1d510265da7d48b735ce61fb strerror.c:2:19: error: no include path in which to search for stdio.h strerror.c:3:20: error: no include path in which to search for string.h strerror.c:4:19: error: no include path in which to search for errno.h strerror.c:5:23: error: no include path in which to search for sys/types.h strerror.c:6:20: error: no include path in which to search for signal.h strerror.c: In function `main': strerror.c:14:7: warning: incompatible implicit declaration of built-in function `strchr' strerror.c:15:15: warning: incompatible implicit declaration of built-in function `strrchr' strerror.c:18:5: warning: incompatible implicit declaration of built-in function `fprintf' strerror.c:18:13: error: `stderr' undeclared (first use in this function) strerror.c:18:13: note: each undeclared identifier is reported only once for each function it appears in strerror.c:21:7: warning: incompatible implicit declaration of built-in function `sscanf' strerror.c:23:5: warning: incompatible implicit declaration of built-in function `fprintf' strerror.c:27:7: warning: assignment makes pointer from integer without a cast strerror.c:29:7: warning: assignment makes pointer from integer without a cast strerror.c:32:5: error: `errno' undeclared (first use in this function) strerror.c:34:5: warning: incompatible implicit declaration of built-in function `snprintf' strerror.c:39:5: warning: incompatible implicit declaration of built-in function `fprintf' strerror.c:44:3: warning: incompatible implicit declaration of built-in function `printf' 12:33:27$ ls /usr/include FlexLexer.h arpacommline.h elf.h features.h ieeefp.hmagic.h newlib.hregex.h stdlib.hticker.h wctype.h IEEE.h asm complex.h endian.h fenv.h ifaddrs.h malloc.hobjstack.h resolv.h string.htime.h wordexp.h _ansi.h assert.hcrypt.h
1.7.15 gcc post-install fails "altdir /etc/alternatives invalid"
Fresh install on this system. Installer reports errors: on checking setup.log.full I see errors like 2013/04/11 11:07:36 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/gcc4-fortran.sh" altdir /etc/alternatives invalid 2013/04/11 11:07:36 abnormal exit: exit code=2 2013/04/11 11:07:36 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/automake.sh" altdir /etc/alternatives invalid The error "altdir /etc/alternatives invalid" comes from the "alternatives" command. I get it when /etc/alternatives is empty or when it has valid symbolic links. The Fortran script: 12:14:12$ cat /etc/postinstall/gcc4-fortran.sh /usr/sbin/update-alternatives \ --install "/usr/bin/gfortran.exe" "gfortran" "/usr/bin/gfortran-4.exe" 40 \ --slave "/usr/bin/i686-pc-cygwin-gfortran.exe" "i686-pc-cygwin-gfortran" "/usr/bin/i686-pc-cygwin-gfortran-4.exe" \ --slave "/usr/share/man/man1/gfortran.1.gz" "gfortran.1.gz" "/usr/share/man/man1/gfortran-4.1.gz" \ WORK AROUND usr/sbin/update-alternatives was a symlink to usr/sbin/alternatives.exe. I found the original update-alternatives Perl script and installed that. Then I re-ran the post update scripts by hand (and renamed them .done by hand). Unfortunately the next install resets update-alternatives to be a symlink, so this always has to be a manual process. I guess you have the source for alternatives.exe on your site somewhere - I couldn't find it on the Web. Cheers ... Duncan. cygcheck.out Description: cygcheck.out update-alternatives Description: update-alternatives -- 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
1.7.15: gcc fails to load: missing cygmpfr-4.dll
I have just installed cygwin on this system. When I try to compile a small program, I get this error: /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe: error while loading shared libraries: cygmpfr-4.dll: cannot open shared object file: No such file or directory ldd agrees: 11:47:53$ ldd /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe ntdll.dll => /cygdrive/c/WINDOWS/system32/ntdll.dll (0x7c90) kernel32.dll => /cygdrive/c/WINDOWS/system32/kernel32.dll (0x7c80) cygcloog-0.dll => /usr/bin/cygcloog-0.dll (0x6ff7) cyggcc_s-1.dll => /cygdrive/c/WINDOWS/cyggcc_s-1.dll (0x67f0) cygwin1.dll => /cygdrive/c/WINDOWS/cygwin1.dll (0x6100) ADVAPI32.DLL => /cygdrive/c/WINDOWS/system32/ADVAPI32.DLL (0x77dd) RPCRT4.dll => /cygdrive/c/WINDOWS/system32/RPCRT4.dll (0x77e7) Secur32.dll => /cygdrive/c/WINDOWS/system32/Secur32.dll (0x77fe) cyggmp-3.dll => /usr/bin/cyggmp-3.dll (0x6fbb) cygppl_c-2.dll => /usr/bin/cygppl_c-2.dll (0x6f17) cygppl-7.dll => /usr/bin/cygppl-7.dll (0x6f3e) cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x6f0a) cyggmpxx-4.dll => /usr/bin/cyggmpxx-4.dll (0x6fba) cygiconv-2.dll => /cygdrive/c/WINDOWS/cygiconv-2.dll (0x674c) cygintl-8.dll => /cygdrive/c/WINDOWS/cygintl-8.dll (0x6f5c) cygmpc-1.dll => /usr/bin/cygmpc-1.dll (0x6f91) cygmpfr-1.dll => /usr/bin/cygmpfr-1.dll (0x6f8c) cygmpfr-4.dll => not found cygz.dll => /usr/bin/cygz.dll (?) Where would I find this library? (source not much help w/out working compiler :-/ Cheers ... Duncan. cygcheck.out Description: cygcheck.out -- 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
