cygwin (as in the base cygwin package) is missing /lib/libdl.a. The
install for the cygwin package should create a symlink with this name
that links to libcygwin.a in the same directory. Otherwise, builds for
a lot of different software packages are broken. Example is bash-3.1.
It will die
Hello all,
I'm trying to troubleshoot an issue with an old version of rsync on
Cygwin. Is there a git repo somewhere with historical patches? The
version in question is 3.0.4. This is on a remote machine that I can't
change, so I'm trying to decipher what I can from the logs.
Thanks,
Daniel
-
Hello Marco,
On 11/30/19 4:23 AM, Marco Atzeri wrote:
> Am 30.11.2019 um 06:44 schrieb Daniel Santos:
>> Hello all,
>>
>> I'm trying to troubleshoot an issue with an old version of rsync on
>> Cygwin. Is there a git repo somewhere with historical patches? The
Hello,
I see that when you copy Cygwin executables (and dlls) to a random
windows machine and run (for example) bash.exe that Cygwin treats the
parent directory as the root, assigns it an 8-byte serial number and
records it in the user registry. Can somebody point me to where the
code is that doe
ecture and then other docs to "drill down" to the
details on certain areas. I've always been amazed by what Cygwin does.
Daniel
On 12/9/19 4:22 AM, Corinna Vinschen wrote:
> On Dec 9 01:12, Daniel Santos wrote:
>> Hello,
>>
>> I see that when you copy Cygwin ex
Hello. I'm trying to validate a gcc patchset that affects msabi
functions, so I need good test results on Cygwin, but my unpatched tests
are getting hundreds of failures for which I cannot determine the cause.
I'm running Cygwin 64 bit on Windows 7 in a qemu vm (with kvm). My
sources are on a
HAH! Well I hadn't actually subscribed to the mailing list and decided
to check the archive to see if anybody replied only to the list. (I'm
subscribed now)
> In order to test gfortran 7.1 without installing, you will need to copy
> cyggfortran-4.dll into a folder which is on LD_LIBRARY_PATH. m
On 03/04/2017 09:46 PM, JonY wrote:
Cygwin does NOT use LD_LIBRARY_PATH, Cygwin uses PATH like all Windows
programs. It is one aspect that does not conform to *nix expectations.
Wonderful, this simplifies it greatly! I was wondering why the dlls
were under /usr/bin. :) Anyway, I'm waiting f
Seeing how this means that gcc testsuite results are useless for
exposing regressions in gcc libraries, I've opened a gcc bug report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79867
Daniel
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/fa
Is this a documentation error then? (from
https://cygwin.com/cygwin-ug-net/setup-env.html)
The LD_LIBRARY_PATH environment variable is used by the Cygwin function
dlopen () as a list of directories to search for .dll files to
load. This
environment variable is converted from Windows
On 03/05/2017 05:08 AM, David Billinghurst wrote:
No.
LD_LIBRARY_PATH is used by dlopen ().
PATH is one of the locations searched by Windows when starting
applications, see https://msdn.microsoft.com/en-us/library/7d83bc18.aspx
Thank you for this clarification. So load-time dlls are resolve
On 03/07/2017 07:58 AM, cyg Simple wrote:
On 3/6/2017 9:03 PM, Daniel Santos wrote:
On 03/05/2017 05:08 AM, David Billinghurst wrote:
No.
LD_LIBRARY_PATH is used by dlopen ().
PATH is one of the locations searched by Windows when starting
applications, see https://msdn.microsoft.com/en-us
On 03/07/2017 06:36 PM, David Billinghurst wrote:
On 8/03/2017 10:25, Daniel Santos wrote:
My concern is with the dynamic portion of this behavior -- what is
affected by environment variables.
Many years ago I ran a nightly build/test of gcc under cygwin and
reported the results to gcc
First of all, thank you for your response!
On 03/08/2017 02:21 AM, Brian Inglis wrote:
After any Windows Update, or a lot of package installs, you may want
look at running
rebase-trigger full[rebase]
before rebooting to remove all Cygwin and Windows processes, then
(with no Cygwin servic
This is just a minor annoyance. When I start a mintty session and even
if I type bash -l or basy -li, I don't get my /etc/profile sourced and I
have to manually do it each time I log in. Any idea what's causing that?
Possibly related, sshd doesn't seem to be reading my
~/.ssh/authorized_keys
First off, thanks for your response and I apologize for my late reply.
On 03/09/2017 06:21 PM, Brian Inglis wrote:
On 2017-03-09 15:58, Daniel Santos wrote:
This is just a minor annoyance. When I start a mintty session and
even if I type bash -l or basy -li, I don't get my /etc/profile
so
Thanks for the help Brian.
On 03/09/2017 05:51 PM, Brian Inglis wrote:
Windows DLLs updated or added could increase in size and overlap
Cygwin's assumed address space allocated by rebase.
Mingw has no problem as native Windows programs, but Cygwin emulates
how Unix uses shared libraries [handwav
On 03/10/2017 12:56 PM, Achim Gratz wrote:
Brian Inglis writes:
Ensure that all Cygwin dlls including anything you build are included
in every rebase, and do an incremental rebase after every build.
Don't do this, it's not what incremental rebase is for. I've
specifically implemented the "ephe
On 03/13/2017 12:25 PM, Marco Atzeri wrote:
The risk of collision is very low on 64 bit.
It is higher on 32 bit but as gcc don't depend on other libraries,
I don't expect that to happen.
If happens you can rebase in tree before running the tests,
providing the list of new dll to rebase.
I used i
On 03/15/2017 02:36 PM, Brian Inglis wrote:
Do the local rebase on your build targets as detailed in my question
to Achim and his response. Rerun after any system change or build.
Alright, I think I've got it now, thank you. I'll experiment with it
first and then I'm guessing that this might
On 03/17/2017 12:17 AM, Brian Inglis wrote:
On 2017-03-16 14:59, Daniel Santos wrote:
Alright, I think I've got it now, thank you. I'll experiment with it
first and then I'm guessing that this might eventually belong in
libtool or some such, although I'm guessing that that
This is a silly one because I ran gdb --args strace ls and it doesn't
crash. Then I ran 'gdb --args strace strace ls' and it crashed in gdb
ONCE! However, I don't usually work on Cygwin/Windows so I think gdb
loaded up the wrong debug info and/or source files. I built
cygwin-newlib from git
I got the crash again (when trying to do something else of course). So
here is the complete backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x771fc3bc in KERNEL32!GetVolumePathNamesForVolumeNameW () from
/c/Windows/system32/kernel32.dll
(gdb) bt
#0 0x771fc3bc i
I should probably import this onto my github account. There doesn't
appear to be an actual repository for expect at the moment. There are
many terrible coding practices employed, potential use of uninitialized
locals, etc. I'm going to do some basic cleanup before I dig back into
trying to f
I'm hacking expect to try to solve its "broken pipe" problem, but I
haven't done any serious windows programming/debugging in over 10
years. I want to be able to set some type of "trap" after a fork (on
the child) and then disable it before it calls execvp to catch any
crashes or normal progra
Is anybody else getting this problem? I'm using Windows 7 pro that's
fully updated. At least I'm getting the crash consistently now, even
when debugging. I didn't have cygwin1.dll built with -O3, so I had to
experiment to find the thread local storage. If I've done in correctly,
then it look
I didn't have cygwin1.dll built with -O3,
oops, I meant -g3 :)
--
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
On 04/14/2017 10:49 PM, Dan Kegel wrote:
On Fri, Apr 14, 2017 at 8:41 PM, Daniel Santos wrote:
oops, I meant -g3 :)
That was suboptimal of you
/me ducks
lol!
/me swings
/me ducks
/me misses, damn!
strace ls doesn't die for me with plain old cygwin installed a while ago.
Is this
Well here's the problem, gcc got too smart and optimized out the stack
buffer.
int
main (int argc, char **argv)
{
4074c0: 56 push %rsi
4074c1: 53 push %rbx
4074c2: 48 83 ec 28 sub$0x28,%rsp
4074c6: 89 c
Well I've solved one problem, but now I have another one. To try to
understand why except is getting broken pipes (child processes are
"going away"), I modified DejaGNU's /usr/bin/runtest so that it would
strace each except process:
-exec "$expectbin" $debug -- "$runpath"/runtest.exp $target $
On 04/20/2017 08:43 AM, Gluszczak, Glenn wrote:
I haven't run Cygwin Expect for about 6 moths on Windows but it was behaving
fine last time I did.
One thing I am aware of is you can't interrupt sleep in TCL. The sleep must
complete until the Control C is processed (regardless of whether you red
On 04/20/2017 09:38 PM, Daniel Santos wrote:
I usually disable most services, I can probably disable a few more
Actually, I was wrong as I had re-enabled a lot of services to try some
ms debugging tools, but I've pared it down to these and the problem
still happens:
C:\Users\danie
I've tracked it down to this little Sleep() loop in pinfo::init.
bool created = shloc != SH_JUSTOPEN;
/* Detect situation where a transitional memory block is being
retrieved.
If the block has been allocated with PINFO_REDIR_SIZE but not yet
updated with a PID_EXECED stat
On 04/21/2017 04:38 AM, Mark Geisert wrote:
I can reproduce your issue on a real Win7.64 machine so that removes
any possible virtual machine root cause. I was running 'top -s1' in
one window while running your testcase in another window. Yes, top
froze for many seconds at a time, then caug
On 04/21/2017 05:12 PM, Mark Geisert wrote:
Re debugging strace itself, you may not realize that strace is not a
Cygwin-native program. It's a Windows-native program. So debugging
it with Cygwin gdb is problematic.
I can tell you roughly how strace operates. It launches the target
progr
Unfortunately, I don't have much time to spend on this issue as the gcc8
stage1 has started and I have a few more issues to clear up with my
patchset.
On 04/23/2017 02:42 AM, Mark Geisert wrote:
Anyway, I can see that the strace process's shared _pinfo object is
never fully
populated:
_pinfo
Well, waiting for GNU/Linux tests to run, so I had a little more time to
play with this.
On 04/23/2017 02:42 AM, Mark Geisert wrote:
Daniel Santos wrote:
Well thank you, I wish I had read this earlier. I've been trying to
debug (with
gdb) strace (following children) and now I know wh
On 04/24/2017 02:00 AM, Mark Geisert wrote:
Excellent debugging work! I'm inclined to agree with your last
point. I'm poring over pinfo.cc as well as dcrt0.cc, which is the
Cygwin DLL init code. The latter talks about special cases if the DLL
is runtime loaded (like strace does) vs link-tim
I finally found a solution and submitted a patch, but I don't know if
it's the correct fix or not.
Daniel
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygw
39 matches
Mail list logo
