Re: warnings starting "emacs"
Hi Ken, thank you very much for your answer. Unfortunately, I still get the same messages. I've updated my system to the latest package versions and I use Cygwin x86_64 on top of Windows 10. Unfortunately, I get some warnings when a start "emacs". PC26 cygwin64 26 emacs Cygwin.bat PC26 cygwin64 27 libGL error: Screen is not Windows-DRI capable Do you know why I now get a libGL error message that I didn't get before? ** (emacs:9112): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. I often see this when I'm logged in as an Administrator. I think it's harmless and can be ignored. (emacs:9112): Gtk-WARNING **: gtk_window_parse_geometry() called on a window with no visible children; the window should be set up before gtk_window_parse_geometry() is called. This can also be ignored. I think it's been fixed upstream. (emacs:9112): GdkPixbuf-WARNING **: Error loading XPM image loader: Image type 'xpm' is not supported This one I haven't seen. Do you have libXpm4 installed? I've installed all libXpm4 packages, but they didn't change anything. Can I do anything else to avoid the confusing error and warning messages? Best regards Siegmar -- 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: Re: RPC clnt_create() adress already in use
Hello Mark Geisert,
i have an other testprogram making the connections not using RPC. Instead it
uses socket-connections directly (without setsockopt()). The operations in the
program are the same as in my RPC-testprogram.
But now the program works perfectly (in Cygwin 1.5.18 and Cygwin 2.5.1). There
are no errors.
Therefore I think the cause for the error in my RPC-testprogram is not the
socket-handling but the RPC-handling in libtirpc. But I have no idea to control
the RPC-handling to avoid the error.
Raimund Paulus
Source of socket-testprogram:
/*=*/
/* Include-Files */
/*=*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/*===*/
/* global definitions */
/*===*/
// max. nr. of connection attempts
#define CONNECT_MAX (int)3
// waittime for connection
#define CONNECT_WAITTIME (unsigned int)5
char host_ip[] = "128.2.9.1"; // IP host
int svc_port= 49154; // port-nr. for service
char local_errmsg[512];
/*===*/
/* prototyping */
/*===*/
// function for open a connection
int SVC_Open(void);
// function for close a connection
int SVC_Close(int fd_svc);
/**/
/* main-program */
/**/
int main(int argc, char *argv[])
{
int retval = 0;
int sleeptime = 0;
int fd_sock = 0;// socket descriptor
// read sleep-Time
if(argc < 2)
{
printf("no input for sleep-Time --> default\n");
sleeptime = 10;
}
else
{
char *endptr;
errno = 0;
sleeptime = (int)strtol(argv[1], &endptr, 10);
if ( (errno == ERANGE && (sleeptime == LONG_MAX || sleeptime == LONG_MIN))
|| (errno != 0 && sleeptime == 0))
{
fprintf(stderr, "input for sleeptime (%s) invalid: %s\n",
argv[1], strerror(errno));
exit(1);
}
}
printf("sleep-Time = %d \n", sleeptime);
// loop for 20 connection
int i;
for(i=0; i<20; i++)
{
fd_sock = SVC_Open();
if(retval < 0)
break;
printf("connection nr. %d established \n", i+1);
sleep(1);
retval = SVC_Close(fd_sock);
if(retval < 0)
break;
printf("connection closed\n");
printf("wait for %d sec.\n", sleeptime);
sleep(sleeptime);
}
if(retval < 0)
fprintf(stderr, "%s\n", local_errmsg);
return(0);
}
int SVC_Open(void)
{
int nr_connects = 0;// nr of connection attempts
int retval = 0;
struct sockaddr_in server_address;
int fd_svc = -1;// socket descriptor
// get socket descriptor
errno = 0;
fd_svc = socket (AF_INET, SOCK_STREAM, 0);
if (fd_svc < 0)
{
sprintf(local_errmsg, "socket(): %s", strerror(errno));
return(-1);
}
// initializing struct
bzero ((char *) &server_address, sizeof (server_address));
server_address.sin_family = AF_INET;
server_address.sin_addr.s_addr = inet_addr(host_ip);
server_address.sin_port = htons(svc_port);
errno = 0;
// establish connection; if error --> retry max. CONNECT_MAX times
for(nr_connects = 0; nr_connects < CONNECT_MAX; nr_connects++)
{
printf("connection attempt nr. %d\n",nr_connects+1);
retval = connect (fd_svc,
(struct sockaddr *) &server_address,
sizeof (server_address));
if (retval < 0)
{
sprintf(local_errmsg, "connect(): %s", strerror(errno));
if(nr_connects < CONNECT_MAX)
{
fprintf(stderr, "%s\n", local_errmsg);
sleep(CONNECT_WAITTIME);
}
continue;
}
else
break;
} // end for()
// error handling (no success)
if (retval < 0)
{
close(fd_svc);
return(retval);
}
else
return(fd_svc);
}
int SVC_Close(int fd_svc)
{
int retval = 0;
if(fd_svc > 0)
{
errno = 0;
retval = close(fd_svc);
if(retval < 0)
sprintf(local_errmsg, "close(): %s", strerror(errno));
}
return(retval);
}
-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von
Mark Geisert
Gesendet: Sonntag, 24. September 2017 11:49
An: cygwin@cygwin.com
Betreff: Re: RPC clnt_create() adress already in use
PAULUS, Raimund, TI-ABN wrote:
> In our environment we have a Linux-Server and several Windows-PCs (Windows XP
> SP3, in the past Windows NT too). On the Linux-Server RPC-Services (Remote
> Procedure Call) are running, one service for one Windows-PC each. To build
> the RPC-clients on the Windows-boxes, I used Cygwin 1.5.18 and actually
> Cygwin 2.5.1 (because we now have Windows 7 too).
>
> The RPC-Client (*.exe) on the Windows-box is started at any time by hand,
> establishes a connection to the server (clnt_create), executes a few calls to
> the server (clnt_call), closes the connection (clnt_destroy) and exits. The
>
Re: RPC clnt_create() adress already in use
Hello Raimund,
Let's keep this on the mailing list please.
PAULUS, Raimund, TI-ABN wrote:
Hallo Mark Geisert,
many thanks for your answer. I supposed this too.
I included in my source code the following function calls after clnt_create():
int fd = 0;
bool bool_ret = clnt_control(cl, CLGET_FD, &fd); if(bool_ret == true) {
printf("fd: %d\n", fd);
int enable = 1;
retval = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &enable, sizeof(int));
if(retval < 0)
fprintf(stderr, "Fehler setsockopt(): %s\n", strerror(errno)); }
The function clnt_control() delivers the socket of the RPC-Client-Handle.
The result is the same as before. Moreover i think, the effect of setsockopt()
would be valid only during the process is running (my test scenarios 1 and 2).
But it wouldn't change anything regarding my test scenario 3 (several restarts).
Raimund
I looked through the libtirpc source code and nowhere is SO_REUSEADDR being set.
You are on the right track with how to do it, but by the time clnt_create()
returns to you it is already too late. As far as I can tell there is no way to
get access to the socket between the time it's created within libtirpc and the
time it's made available to you by clnt_create().
I did try running your testcase (thanks for supplying that) but I don't have a
local machine running RPC services and don't wish to poke at random machines on
the Internet ;-). I had to compile it as so:
gcc -g -o test_rpc -I/usr/include/tirpc test_rpc.c -ltirpc
You are taking care to compile against the correct RPC-package includes and link
against the correct RPC-package libraries, yes?
Speculation: There might be a way to decompose what clnt_create() does into
other libtirpc functions that accomplish the same thing, but in smaller pieces
such that you could set the socket option before bind() is called. That would
be a fair amount of work though and given my cursory look at the source I don't
know if it's even possible.
..mark
--
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: Re: Does Cygwin setup modify dlls?
Thanks for all answers.
We will patch /usr/bin/rebaselst and extend the sed-expression in function
rebase_pkg()
by adding another exception to the existing ones:
sed -e '/\(cygwin1\|cyglsa.*\)\.dll$/d' \
-e '/\/\(d\?ash|rebase\|peflags\)\.exe$/d' \
-e '/\/octave\//!{/\(mex\|oct\)$/d}' \
-e '/gnuplot\/demo\/plugin\/.*\.so/d' \
-e '/^\/usr\/lib\/ocaml\/.*\.so/d' \
-e '/sys-root\/mingw/d' \
+ -e '/our-subdir/d' \
-e 's/^/\//' \
>>"${g}"
> > Is there a possibility to avoid the rebasing, e.g. for certain folders?
> > In my case the intention was to use the Cygwin installer only, but the
> > files in the package are not dependent on cygwin libraries. So forking is
> > not an issue.
> He did mean fork(2) call, not a "source code fork".
> DLL rebase is necessary for Cygwin to run in first place.
I understood this. The tools we install aren't run in a cygwin-context.
Best regards,
Joachim
--
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: FAO Jari Aalto: Update guilt package request [Was: Quilt: Unsupported version of git (2.13.2)]
On 2017-08-07 12:10, Adam Dinwoodie wrote: | > bash# guilt list | > Unsupported version of git (2.13.2) | > | > bash# cygcheck.exe -c -d | grep git'\|'guilt | > 37:git 2.13.2-2 | > 42:guilt 0.35-2 | | This has been fixed in guilt v0.36, which was released in August 2015, | specifically with commit v0.35-7-gf1c2f45. Latest now uploaded, Jari -- 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: RPC clnt_create() adress already in use
Hello Mark,
i compiled and linked just as you.
As i mentioned in an other email, if I use socket-connections in the same
manner with a socket-service, in don't need to setsockopt(.., SO_REUSEADDR,
...) and it works.
Raimund
-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von
Mark Geisert
Gesendet: Mittwoch, 27. September 2017 11:50
An: cygwin@cygwin.com
Betreff: Re: RPC clnt_create() adress already in use
Hello Raimund,
Let's keep this on the mailing list please.
PAULUS, Raimund, TI-ABN wrote:
> Hallo Mark Geisert,
>
> many thanks for your answer. I supposed this too.
>
> I included in my source code the following function calls after clnt_create():
>
> int fd = 0;
> bool bool_ret = clnt_control(cl, CLGET_FD, &fd); if(bool_ret == true) {
> printf("fd: %d\n", fd);
>
> int enable = 1;
> retval = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &enable, sizeof(int));
> if(retval < 0)
> fprintf(stderr, "Fehler setsockopt(): %s\n", strerror(errno)); }
>
> The function clnt_control() delivers the socket of the RPC-Client-Handle.
> The result is the same as before. Moreover i think, the effect of
> setsockopt() would be valid only during the process is running (my test
> scenarios 1 and 2).
> But it wouldn't change anything regarding my test scenario 3 (several
> restarts).
>
> Raimund
I looked through the libtirpc source code and nowhere is SO_REUSEADDR being
set.
You are on the right track with how to do it, but by the time clnt_create()
returns to you it is already too late. As far as I can tell there is no way to
get access to the socket between the time it's created within libtirpc and the
time it's made available to you by clnt_create().
I did try running your testcase (thanks for supplying that) but I don't have a
local machine running RPC services and don't wish to poke at random machines on
the Internet ;-). I had to compile it as so:
gcc -g -o test_rpc -I/usr/include/tirpc test_rpc.c -ltirpc You are taking
care to compile against the correct RPC-package includes and link against the
correct RPC-package libraries, yes?
Speculation: There might be a way to decompose what clnt_create() does into
other libtirpc functions that accomplish the same thing, but in smaller pieces
such that you could set the socket option before bind() is called. That would
be a fair amount of work though and given my cursory look at the source I don't
know if it's even possible.
..mark
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Error Linking LTO programs using GCC6.4
The same program was linking fine using previous gcc 5.X , please advise how to debug further. [Linking driver.exe] collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped compilation terminated. /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../x86_64-pc-cygwin/bin/ld: libdriver.a(regexp.o) (15065197): Section flag STYP_GROUP (0x4) ignored /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../x86_64-pc-cygwin/bin/ld: libdriver.a(regexp.o) (15065197): Section flag STYP_COPY (0x10) ignored make: *** [Makefile:194: driver.exe] Error 1 aunyx@DESKTOP-R60LL3E ~/fluffos/src $ cat ld.exe.stackdump Exception: STATUS_ACCESS_VIOLATION at rip=0010045A417 rax= rbx=000600525E40 rcx=000600525E40 rdx=000100571C00 rsi=0001 rdi=0006002E2420 r8 =000600528C70 r9 =0058 r10=0001 r11= r12=03EE r13=000100571C00 r14=0006000D5B50 r15=0006000CDC00 rbp=0006000D9A30 rsp=C4D0 program=D:\cygwin\usr\x86_64-pc-cygwin\bin\ld.exe, pid 8564, thread main cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: FrameFunctionArgs 006000D9A30 0010045A417 (00100571C00, 006000E3374, 000C6A0, 00100571C00) 006000D9A30 0010045382E (006002E2420, 006000D9A30, 3EE, 00100571C00) 006000D9A30 0010045433E (001004EAE20, 000, 0010042843B, 000C70C) 006000D9A30 0010043C095 (00100571C00, 001004542E0, 001800BAE1C, 000) 000 0010040EDB8 (00600075530, 00600076970, 0010050295C, 000) 000 0010040F8D0 (001802FDC50, 00600068A50, 001800BB092, 00600069690) 000CA40 00100411976 (003FED791C0, 00603F0, 001800BB092, 0390038) 000CA40 001004E8C7A (000CA40, 000CAF0, 000, 001801C31A0) 000CCB0 00180047BC2 (000, 000, 000, 000) 000 00180045863 (000, 000, 000, 000) 000FFF0 00180045914 (000, 000, 000, 000) End of stack trace -- 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 Linking LTO programs using GCC6.4
Okay, so I managed to extract more details using binutils-debuginfo
package , but still has no clue how to solve this. OTOH, binutils
2.25 seems to be doing better
Starting program: /usr/x86_64-pc-cygwin/bin/ld -plugin
/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/cyglto_plugin.dll
-plugin-opt=/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/lto-wrapper.exe
-plugin-opt=-fresolution=/tmp/ccNFf1JQ.res
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lcygwin
-plugin-opt=-pass-through=-ladvapi32
-plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32
-plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc --build-id -m i386pep --wrap _Znwm
--wrap _Znam --wrap _ZdlPv --wrap _ZdaPv --wrap _ZnwmRKSt9nothrow_t
--wrap _ZnamRKSt9nothrow_t --wrap _ZdlPvRKSt9nothrow_t --wrap
_ZdaPvRKSt9nothrow_t -Bdynamic --dll-search-prefix=cyg --tsaware -o
driver.exe -L/usr/lib/w32api
/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../lib/crt0.o
/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/crtbegin.o -L/usr/lib
-L/usr/lib/gcc/x86_64-pc-cygwin/6.4.0
-L/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../x86_64-pc-cygwin/lib/../lib
-L/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../lib -L/lib/../lib
-L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../x86_64-pc-cygwin/lib
-L/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../.. -v main.o libdriver.a
-lpcre -lz -lcrypt -lpcre -levent -lstdc++ -lgcc_s -lgcc -lcygwin
-ladvapi32 -lshell32 -luser32 -lkernel32 -lgcc_s -lgcc
/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../lib/default-manifest.o
/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/crtend.o
[New Thread 6752.0x2d9c]
[New Thread 6752.0x206c]
[New Thread 6752.0x284c]
[New Thread 6752.0x2278]
[New Thread 6752.0x1154]
GNU ld (GNU Binutils) 2.29.51.20170708
/usr/x86_64-pc-cygwin/bin/ld: libdriver.a(regexp.o) (15065208):
Section flag STYP_COPY (0x10) ignored
Program received signal SIGSEGV, Segmentation fault.
_bfd_coff_get_external_symbols (abfd=abfd@entry=0x6005374e0) at
/usr/src/debug/binutils-2.28-3/bfd/coffgen.c:1635
1635 if (obj_coff_external_syms (abfd) != NULL)
(gdb) bt
#0 _bfd_coff_get_external_symbols (abfd=abfd@entry=0x6005374e0) at
/usr/src/debug/binutils-2.28-3/bfd/coffgen.c:1635
#1 0x00010045382e in coff_link_add_object_symbols
(abfd=0x6005374e0, info=0x100571c00 ) at
/usr/src/debug/binutils-2.28-3/bfd/cofflink.c:183
#2 0x00010045433e in coff_link_check_archive_element
(abfd=0x6005374e0, info=0x100571c00 , h=,
name=, pneeded=0xc11c) at
/usr/src/debug/binutils-2.28-3/bfd/cofflink.c:220
#3 0x00010043c095 in _bfd_generic_link_add_archive_symbols
(abfd=0x6000ba0e0, info=0x100571c00 , checkfn=0x1004542e0
) at
/usr/src/debug/binutils-2.28-3/bfd/linker.c:977
#4 0x00010040edb8 in load_symbols (entry=0x60003a200,
place=) at
/usr/src/debug/binutils-2.28-3/ld/ldlang.c:2863
#5 0x00010040f8d0 in open_input_bfds (s=0x60003a200,
mode=mode@entry=OPEN_BFD_NORMAL) at
/usr/src/debug/binutils-2.28-3/ld/ldlang.c:3312
#6 0x000100411976 in lang_process () at
/usr/src/debug/binutils-2.28-3/ld/ldlang.c:7010
#7 0x0001004e8c7a in main (argc=69, argv=0xc450) at
/usr/src/debug/binutils-2.28-3/ld/ldmain.c:437
(gdb) print *abfd
$1 = {filename = 0x600537640 "regexp.o (symbol from plugin)", xvec =
0x10053f140 , iostream = 0x600537670, iovec =
0x100523360 <_bfd_memory_iovec>, lru_prev = 0x0, lru_next = 0x0, where
= 9, mtime = 0, id = 4294967261, format = bfd_unknown,
direction = read_direction, flags = 71680, cacheable = 0,
target_defaulted = 1, opened_once = 0, mtime_set = 0, no_export = 0,
output_has_begun = 0, has_armap = 0, is_thin_archive = 0,
selective_search = 0, is_linker_output = 0, is_linker_input = 0,
plugin_format = bfd_plugin_unknown, lto_output = 0, plugin_dummy_bfd
= 0x0, origin = 0, proxy_origin = 0, section_htab = {table =
0x6005381d0, newfunc = 0x100441630 , memory
= 0x600537620, size = 13, count = 0, entsize = 304,
frozen = 0}, sections = 0x0, section_last = 0x0, section_count =
0, archive_pass = 0, start_address = 0, outsymbols = 0x0, symcount =
0, dynsymcount = 0, arch_info = 0x100522c00 ,
arelt_data = 0x0, my_archive = 0x0,
archive_next = 0x0, archive_head = 0x0, nested_archives = 0x0, link
= {next = 0x0, hash = 0x0}, tdata = {aout_data = 0x0, aout_ar_data =
0x0, oasys_obj_data = 0x0, oasys_ar_data = 0x0, coff_obj_data = 0x0,
pe_obj_data = 0x0, xcoff_obj_data = 0x0,
ecoff_obj_data = 0x0, ieee_data = 0x0, ieee_ar_data = 0x0,
srec_data = 0x0, verilog_data = 0x0, ihex_data = 0x0, tekhex_data =
0x0, elf_obj_data = 0x0, nlm_obj_data = 0x0, bout_data = 0x0, mmo_data
= 0x0, sun_core_data = 0x0, sco5_core_data = 0x0,
trad_core_data = 0x0, som_data = 0x0, hpux_core_data = 0x0,
hppabsd_core_data = 0x0, sgi_core_data = 0x0, lynx_core_data = 0x0,
osf_core_data = 0x0, cisco_core_data = 0x0, versados_data = 0x0,
netbsd_core_data = 0x0, mach_o_data = 0x0,
mach_o_fat_data = 0x0, plugin_data = 0x0, pef_data = 0x0,
pef_xlib_
Re: lftp / zlib problems
> From: Harri T. > > Hi all, > > > > After updating Cygwin 32-bit we have had problems with all the > > combinations of lftp 4.7.7.-1 / 4.8.0-1 and zlib 1.2.8-3 / 1.2.11-1. > > ... > > assertion "ptr(x.heap_index)==&x" faSKiled: file > > "/home/ASchulma/dev/cygwin/lftp/lftp-4.8.0-1.i686/src/lftp- > > 4.8.0/src/xheap.h", line 127, function: void > > xheap::remove(xheap::node&) [with T = Timer] > > > > generating a stackdump file. > > > > Is there something we can do to avoid these issues? > > To add some weight to Harri T.'s message, I've reported the same problem > twice: > > https://sourceware.org/ml/cygwin/2017-08/msg00051.html > https://sourceware.org/ml/cygwin/2017-09/msg00014.html > > -Ken Nellis OK. I'm sorry for the delay in dealing with this problem. Clearly 4.8.0 is broken in Cygwin, and the build of 4.8.1 fails so far so that's no help. Meanwhile 4.7.8 is out so I'll try that and see if it fixes the problems with 4.7.7 and 4.8.0. Andrew -- 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: lftp / zlib problems
> > From: Harri T. > > > Hi all, > > > > > > After updating Cygwin 32-bit we have had problems with all the > > > combinations of lftp 4.7.7.-1 / 4.8.0-1 and zlib 1.2.8-3 / 1.2.11-1. > > > ... > > > assertion "ptr(x.heap_index)==&x" faSKiled: file > > > "/home/ASchulma/dev/cygwin/lftp/lftp-4.8.0-1.i686/src/lftp- > > > 4.8.0/src/xheap.h", line 127, function: void > > > xheap::remove(xheap::node&) [with T = Timer] > > > > > > generating a stackdump file. > > > > > > Is there something we can do to avoid these issues? > > > > To add some weight to Harri T.'s message, I've reported the same problem > > twice: > > > > https://sourceware.org/ml/cygwin/2017-08/msg00051.html > > https://sourceware.org/ml/cygwin/2017-09/msg00014.html > > > > -Ken Nellis > > OK. I'm sorry for the delay in dealing with this problem. Clearly 4.8.0 is > broken in Cygwin, and the build of 4.8.1 fails so far so that's no help. > > Meanwhile 4.7.8 is out so I'll try that and see if it fixes the problems > with 4.7.7 and 4.8.0. I just uploaded 4.7.8-1 as a test release. Once it appears in Setup in the "Test" release, please try it and let me know if it fixes this problem. In my brief testing it seemed to fix the problem for me. Andrew -- 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 Linking LTO programs using GCC6.4
On Wed, 27 Sep 2017 06:51:05, =?UTF-8?B?5Y+26Zuo6aOe?= wrote: The same program was linking fine using previous gcc 5.X , please advise how to debug further. Known issue: - http://cygwin.com/ml/cygwin/2017-09/msg00236.html - http://github.com/Martchus/tageditor/issues/23 doesnt looks like this will be resolved soon -- 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: GNU screen trouble
Greetings, Andrey Repin! > # uname -a; screen --version; screen -admS mc-server-session > CYGWIN_NT-6.1 daemon2 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin > Screen version 4.05.01 (GNU) 25-Feb-17 > # screen -S mc-server-session -Q windows > > If I SEGV the hung child, there's a stacktrace, though I don't know how useful > it is. > Anything I can do to help trace it down? Still an issue to an extent. $ uname -a; screen --version; screen -admS mc-server-session CYGWIN_NT-6.1 daemon2 2.9.0(0.318/5/3) 2017-09-12 10:18 x86_64 Cygwin Screen version 4.06.01 (GNU) 10-Jul-17 $ screen -S mc-server-session -Q windows This is running from mintty, results from cosole differs slightly, but I'm not ready to explain it, I still can'[t get the pattern. But they aren't much more useful compared to TTY runs. I cn attach to a running session, often - list sessions, but unable to query session information or send commands. -- With best regards, Andrey Repin Wednesday, September 27, 2017 21:51:41 Sorry for my terrible english... -- 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: lftp / zlib problems
From: Andrew Schulman > > > From: Harri T. > > > > Hi all, > > > > > > > > After updating Cygwin 32-bit we have had problems with all the > > > > combinations of lftp 4.7.7.-1 / 4.8.0-1 and zlib 1.2.8-3 / 1.2.11-1. > > > > ... > > > > assertion "ptr(x.heap_index)==&x" faSKiled: file > > > > "/home/ASchulma/dev/cygwin/lftp/lftp-4.8.0-1.i686/src/lftp- > > > > 4.8.0/src/xheap.h", line 127, function: void > > > > xheap::remove(xheap::node&) [with T = Timer] > > > > > > > > generating a stackdump file. > > > > > > > > Is there something we can do to avoid these issues? > > > > > > To add some weight to Harri T.'s message, I've reported the same > problem twice: > > > > > > https://sourceware.org/ml/cygwin/2017-08/msg00051.html > > > https://sourceware.org/ml/cygwin/2017-09/msg00014.html > > > > > > -Ken Nellis > > > > OK. I'm sorry for the delay in dealing with this problem. Clearly > > 4.8.0 is broken in Cygwin, and the build of 4.8.1 fails so far so that's > no help. > > > > Meanwhile 4.7.8 is out so I'll try that and see if it fixes the > > problems with 4.7.7 and 4.8.0. > > I just uploaded 4.7.8-1 as a test release. Once it appears in Setup in the > "Test" release, please try it and let me know if it fixes this problem. In > my brief testing it seemed to fix the problem for me. > > Andrew Thank you for giving this matter some attention. Since I last used lftp I was issued a new laptop running Windows 10. Previously I was running Win7. Win10 has been giving me a number of access problems, which seem to be resolved by running Cygwin in admin- istrator mode. This particular problem with 4.8.0 goes away in admin mode, which is now my standard operating mode, so 4.8.0 is no longer a problem for me. -- Ken Nellis -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
ssh + remote tmux
Hi all, I have a slightly annoying problem with tmux on a remote machine when using Cygwin ssh client from Windows 10 console. I have two linux machines: a VM running on Hyper-V and a Raspberry Pi3. When I connect to the VM machine and run tmux, the status line is offset by one line up and basically "fights" with the last line of output about which one gets painted. If I leave it for a while, the status line gets duplicated every few seconds and moves upwards. This happens with both my tmux config and the default one (my config only remaps some keys) This doesn't happen if I connect from mintty or if I use putty. This does not happen when I ssh into my RPi3. When I ssh into either of them, TERM is set to "cygwin". When I start tmux, TERM is "screen". uname -a for the VM: Linux seed 4.12.0-1-amd64 #1 SMP Debian 4.12.6-1 (2017-08-12) x86_64 GNU/Linux uname -a for RPi3: Linux rpi3 4.9.41-v7+ #1023 SMP Tue Aug 8 16:00:15 BST 2017 armv7l GNU/Linux The VM uses debian's testing repo, and tmux version is 2.6-rc3. Rpi3 is on stretch., tmux version is 2.3. I've tried sshing into a few of our office proxmox nodes, running tmux 2.3 and they work fine. Would this be some strange tmux 2.6/Cygwin/Windows console interaction, since both tmux 2.6 and 2.3 work fine from mintty and putty? I've attached cygcheck output. Thank you! -- Marko Cygwin Configuration Diagnostics Current System Time: Wed Sep 27 21:04:03 2017 Windows 10 Professional Ver 10.0 Build 15063 Path: C:\ProgramData\Oracle\Java\javapath C:\Python27\ C:\Python27\Scripts C:\Cygwin\bin f:\Apps\Utils F:\Apps\Utils\sysinternals C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0\ C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common C:\Program Files\Microsoft DNX\Dnvm\ C:\Program Files\Microsoft SQL Server\130\Tools\Binn\ C:\Program Files\Microsoft SQL Server\120\DTS\Binn\ C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\ C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ C:\Program Files\Microsoft SQL Server\120\Tools\Binn\ C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\ C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\ C:\Program Files (x86)\GnuPG\bin C:\Program Files\jEdit C:\Program Files\OpenVPN\bin C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\ C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\ C:\Program Files (x86)\Calibre2\ C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\WINDOWS\System32\WindowsPowerShell\v1.0\ C:\Program Files (x86)\QuickTime\QTSystem\ C:\Program Files\TortoiseHg\ C:\Program Files (x86)\Skype\Phone\ C:\ProgramData\chocolatey\bin C:\Program Files (x86)\vim\vim80 C:\Program Files\dotnet\ C:\Program Files\Git\cmd C:\Program Files\TortoiseGit\bin F:\Users\bozho\apps F:\Users\bozho\scripts C:\Program Files (x86)\OpenVPN\bin F:\Users\bozho\AppData\Roaming\npm F:\Users\bozho\AppData\Local\Microsoft\WindowsApps C:\Program Files\Mercurial F:\Users\bozho\.powershell\modules\Pscx\3.2.2\Apps Output from C:\Cygwin\bin\id.exe UID: 197610(bozho) GID: 197121(None) 197121(None) 114(Local account and member of Administrators group) 197611(HelpLibraryUpdaters) 544(Administrators) 578(Hyper-V Administrators) 559(Performance Log Users) 545(Users) 4(INTERACTIVE) 66049(CONSOLE LOGON) 11(Authenticated Users) 15(This Organization) 113(Local account) 66048(LOCAL) 262154(NTLM Authentication) 4294967295(Unknown+Group) 405504(High Mandatory Level) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS CYGWIN = 'binmode glob title nodosfilewarning' HOME = 'F:\Users\bozho' Path = 'C:\ProgramData\Oracle\Java\javapath;C:\Python27\;C:\Python27\Scripts;C:\Cygwin\bin;f:\Apps\Utils;F:\Apps\Utils\sysinternals;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Microsoft DNX\Dnvm\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\;C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files (x86)\GnuPG\bin;C:\Program Files\jEdit;C:\Program Files\OpenVPN\bin;C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\;C:\Program Files (x86)\Calibre2\;C:\WINDOWS\system32;C:\W
Re: warnings starting "emacs"
On 9/27/2017 5:00 AM, Siegmar Gross wrote: Hi Ken, thank you very much for your answer. Unfortunately, I still get the same messages. I've updated my system to the latest package versions and I use Cygwin x86_64 on top of Windows 10. Unfortunately, I get some warnings when a start "emacs". PC26 cygwin64 26 emacs Cygwin.bat PC26 cygwin64 27 libGL error: Screen is not Windows-DRI capable Do you know why I now get a libGL error message that I didn't get before? No, I don't. I sometimes get it too. ** (emacs:9112): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. I often see this when I'm logged in as an Administrator. I think it's harmless and can be ignored. (emacs:9112): Gtk-WARNING **: gtk_window_parse_geometry() called on a window with no visible children; the window should be set up before gtk_window_parse_geometry() is called. This can also be ignored. I think it's been fixed upstream. (emacs:9112): GdkPixbuf-WARNING **: Error loading XPM image loader: Image type 'xpm' is not supported This one I haven't seen. Do you have libXpm4 installed? I've installed all libXpm4 packages, but they didn't change anything. Can I do anything else to avoid the confusing error and warning messages? Not that I know of. Sorry. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Error Linking LTO programs using GCC6.4
This is actually not the same issue at https://cygwin.com/ml/cygwin/2017-09/msg00236.html In my case, it is caused by latest binutils 2.28 , when using 2.25 everything is fine (even with gcc-6.4) Maybe we should hold back upgrading binutils , or maybe it need a more recent version? There seems to be binutils 2.29.1 now -- 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
Kindle Fire Utility 0.9.6
Hello, I am trying to "Install Permanent Root with Superuser" with Kindle Fire Utility 0.9.6 . I keep getting twrp.img is missing and fff.bin is missing . Can you tell me how I can install these ? I tried the option "Install latest FireFireFire" but that also did not work. The ADB Status shows : Online and the Boot Status : Unknown . Any help would be appreciated. Thank you, Kevin -- 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 Linking LTO programs using GCC6.4
On Wed, 27 Sep 2017 14:42:43, =?UTF-8?B?5Y+26Zuo6aOe?= wrote:
This is actually not the same issue at
https://cygwin.com/ml/cygwin/2017-09/msg00236.html
In my case, it is caused by latest binutils 2.28 , when using 2.25
everything is fine (even with gcc-6.4)
Maybe we should hold back upgrading binutils , or maybe it need a more
recent version? There seems to be binutils 2.29.1 now
Actually, it is the same issue:
$ cygcheck -s | grep -e binutils -e gcc
mingw64-x86_64-binutils 2.25.0.1.23f238d-1 OK
mingw64-x86_64-gcc-core 6.3.0-1OK
mingw64-x86_64-gcc-g++ 6.3.0-1OK
$ cat z.cpp
#include
main() {
std::cout << "cout test\n";
}
$ x86_64-w64-mingw32-g++ -static -o z z.cpp
$ ./z
cout test
So, with both your post and my post, the issue is fixed by not using:
- binutils 2.28.1
- mingw64-x86_64-binutils 2.28.1
- mingw64-i686-binutils 2.28.1
which leaves the last working version:
- binutils 2.25.0
- mingw64-x86_64-binutils 2.25.0
- mingw64-i686-binutils 2.25.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: [ANNOUNCEMENT] [Updated] mingw64-{i686,x86_64} binutils, gcc (Test)
On 09/25/2017 06:33 PM, Steven Penny wrote: > On Mon, 25 Sep 2017 14:17:28, JonY wrote: >> You can actually use Cygwin gdb to debug and see what went wrong, >> assuming the debug symbols are around. >> >> Sorry if I'm not much help, kind of busy these days. > > New command: > > x86_64-w64-mingw32-g++ -g -static -o z z.cpp > > Output: > > (gdb) run > Starting program: /tmp/z [New Thread 5956.0xfe4] > Program received signal SIGSEGV, Segmentation fault. > std::ostream::sentry::sentry (this=this@entry=0x22fd90, __os=...) > at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/ > mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/ > ostream.tcc:51 > 51 /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/ > mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/ > ostream.tcc: No such file or directory. > (gdb) backtrace > #0 std::ostream::sentry::sentry (this=this@entry=0x22fd90, __os=...) > at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/ > > mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/ > ostream.tcc:51 > #1 0x0049ece9 in std::__ostream_insert std::char_traits > > (__out=..., __s=__s@entry=0x4ab031 "cout > test\n", __n=10) > at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/ > mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/ > ostream_insert.h:82 > #2 0x004a3547 in std::operator<< > ( > __out=..., __s=0x4ab031 "cout test\n") > at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/ > mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/std/ > ostream:561 > #3 0x004015e0 in main () at z.cpp:3 > Looks like the ostream is not properly initialized, all the C++ constructors involved makes it even more messy to debug. signature.asc Description: OpenPGP digital signature
Re: Kindle Fire Utility 0.9.6
On 27.09.2017 15:18, Kevin McCaffrey wrote: Hello, I am trying to "Install Permanent Root with Superuser" with Kindle Fire Utility 0.9.6 . Why are you posting this question as a follow-up in the middle of a thread titled "Challenge: a VERY strange problem with command substitution in bash" in the Cygwin mailing list? and the Boot Status : Unknown . Any help would be appreciated. Try some Kindle Fire or Android mailing list maybe? "Kindle Fire Utility" doesn't appear to be a Cygwin component. From some cursory Google searches, it appears some people with Cygwin installations have had problems with the KF utility due to the wrong find.exe (Cygwin's, rather than Windows') and possibly other utilities being found in PATH. -- 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: lftp 4.8.0-1
> Still getting this, but have since paid a bit more attention to the output, > and I'm seeing: > > assertion "ptr(x.heap_index)==&x" failed: file "/home/ASchulma/dev/cygwin/ > lftp/lftp-4.8.0-1.x86_64/src/lftp-4.8.0/src/xheap.h", line 127, function: > void xheap::remove(xheap::node&) [with T = Timer] I've just got the same error when running cygport upload in x86. Interestingly, there was no error when I did the same in x86_64. Downgrading lftp to the previous version (4.7.7-1) "fixed" the cygport upload. Best, Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: lftp 4.8.0-1
On Thu, Sep 28, 2017 at 10:41 AM, Andy Li wrote: > > >> Still getting this, but have since paid a bit more attention to the >> output, >> and I'm seeing: >> >> assertion "ptr(x.heap_index)==&x" failed: file >> "/home/ASchulma/dev/cygwin/lftp/lftp-4.8.0-1.x86_64/src/lftp-4.8.0/src/xheap.h", >> line 127, function: void xheap::remove(xheap::node&) [with T = >> Timer] > > > I've just got the same error when running cygport upload in x86. > Interestingly, there was no error when I did the same in x86_64. > Downgrading lftp to the previous version (4.7.7-1) "fixed" the cygport > upload. > Just noticed that it has been reported upstream and fixed in lftp 4.8.2. https://github.com/lavv17/lftp/issues/390 Andrew: Would you package that soon? Best regards, Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] [Updated] mingw64-{i686,x86_64} binutils, gcc (Test)
On Wed, 27 Sep 2017 23:15:45, JonY wrote: Looks like the ostream is not properly initialized, all the C++ constructors involved makes it even more messy to debug. http://cygwin.com/ml/cygwin/2017-09/msg00289.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: Error Linking LTO programs using GCC6.4
Aha, do you get the same stacktrace that I have? Also, it seems you don't use -flto , so it has nothing to do with LTO. -- 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
