Dear Jay,
> On the advice of Jon Turney, I ran a "bt f" command after gdb caught the
> exception, and it appears that a Trend Micro dll (TmUmEvt64.dll) is where the
> error occurs:
Since the message with a similar problem I posted is from April 2016, it would
also make sense to report this to T
Dear Jon,
It has been reported in the past that antivirus software from Trend Micro
result in STATUS_GUARD_PAGE_VIOLATION in ntdll!RtlAllocateHeap ().
See:
http://cygwin.1069669.n5.nabble.com/XWin-startup-crash-x86-64-Windows-10-td126544.html#a126561
Best regards,
Michael
Intel Deutschland Gm
Dear Kaz,
> You might be interested in the Cygnal project:
> http://www.kylheku.com/cygnal/
from your description I would think this doesn't work for Emacs. Emacs has its
own functions for path management, e.g. to decide what an absolute path is.
These need to be adjusted inside of Emacs. OS su
Dear Cygwin Team and Users,
In May I modified Emacs for Cygwin so that it can truly handle Windows paths. I
do a lot of MinGW cross compilation on Windows and want to seamlessly use tools
like debuggers compiled for MinGW in Cygwin Emacs, so I need this. I also tried
the Windows Emacs distrubut
Dear Hans-Bernhard,
> There is indeed a general bug in the original source that requires fixing.
> The
> following line is sorely missing from the top-level
> Makefile.am:
>
> ACLOCAL_AMFLAGS = -I m4
thanks a lot for taking the time to investigate this! I will suggest this
change to the gtkso
Dear Hans-Bernhard,
thanks for sharing your thoughts on this!
One more note: in the latest version of the configure file for gnome 3.24 from
May 6th 2019:
https://github.com/GNOME/gtksourceview/blob/gnome-3-24/configure.ac
the problematic AX_REQUIRE_DEFINED([GTK_CHECK_BACKEND]) is still in. So
Dear Hans-Bernhard,
> Are we building this from a tarball, or directly off the bleeding edge?
From a tarball. As far as I can tell I am exactly reproducing the original
package that is available as binary on Cygwin repos with exactly the same
sources, patches and cygport file.
> If that had t
Dear Cygwin Team,
recompiling the package "mingw64-x86_64-gtksourceview3.0-3.24.6" from sources
with cygport (In order to generate the debug info) I found that the compile
step fails. Aclocal fails in a few macro availability checks. The reason is
that aclocal is missing a "-I m4" option to inc
Dear Cygwin Team,
a few more observations on this:
1.)I just finished building mingw64-x86_64-gtk3-debuginfo-3.22.28-1.tar.xz
from sources (using cygport) - this file does contain .dbg files (as expected).
So it seems to be a bug in the specific package that
mingw64-x86_64-runtime-debugin
Dear Cygwin Team,
this is a follow up on the discussion "cygport: how to install package sources
for debugging without recompiling".
I am still struggling to understand the concept behind the -debuginfo packages,
e.g. mingw64-x86_64-runtime-debuginfo-6.0.0-1.tar. Is it intentional that this
pa
Dear Brian,
> For Cygwin dlls, look at your installed lib... packages and install the
> related lib...-
> debuginfo packages where available:
> $ apt-cyg listall lib*-debuginfo | wc
> 3501050 12704
As far as I can tell these files only contain sources, but nothing which wou
Dear Jon,
> Is there some reason why you can't just install that?
thanks for the hint - I was not aware that the -debuginfo package contains
sources - I thought these just contain dwarf files or similar for stripped
binaries and sources are in the -src packages.
Unfortunately for MinGW debugin
Dear Cygwin Team,
Cygwin setup allows downloading sources of libraries, but the resulting sources
are not immediately useful for debugging. One gets a compressed tar archive,
some patches and the cygport file. I know that I can expand sources and apply
patches with
cyport prep
which gives me
Dear Agner,
> But the compiler generates a Windows executable following most of the
> Windows ABI (object file format, calling convention, etc.)
Still cygwin is intentionally very different from Windows, e.g. on Cygwin you
use / as path separator, on Windows you use \ as path separator. Cygwin c
Dear Adam,
thanks for the explanation! I found the temporary install folder. For my case
it should work to simply copy the temp-install folder contents to my root. The
post install scripts did already run since I have the package installed and
don't need to be rerun.
It would be useful to have
Dear Cygwin Team,
I compiled a package using cygport all. According to the
documentation this should also install the package, but I don't see the files
in my local installation updated. Is this a misunderstanding of what "install"
means in this context or do I miss some command line options?
Dear Laszlo,
I think you also need to give the --site option and likely also --no-admin if
you want an unattended install.
You can find a (lengthy) batchfile which installs cygwin (unattended is an
option) and excutes a shell script using it here:
https://github.com/coq/coq/blob/master/dev/bui
Dear Timo,
you are mixing a DOS echo which will produce a \r\n line ending with a Cygwin
sed which expects \n line endings. The second . matches the \r.
Either work in bash and use Cygwin echo or use a MinGW compile of sed or strip
the \r e.g. with tr or maybe match it more explicitly with a \r
Dear Cygwin team,
there have been recently some substantial changes to pkg-config, notably the
package mingw64-i686-pkg-config seems to have been replaced by
pkg-config-1.6.0-1 (the mingw variant is now just a shell script).
I wonder where this has been announced and where I can find the releas
Dear Ondrej,
> # Use —text —> finds the text OK
Afaik -a / --text only suppresses this behavior (from man grep):
... when grep discovers that a file is binary it suppresses any
further
output, and instead outputs either a one-line message saying
that a binary fi
Dear Ondrej,
this has been discussed to quite some length and detail more than once on this
list. The initial message of a lengthy discussion (> 30 replies) on the topic
is here:
https://www.cygwin.com/ml/cygwin/2017-06/msg00040.html
Best regards,
Michael
Intel Deutschland GmbH
Registered Add
Dear Michel,
> 1. Where in the release notes is this mentioned so that I can try to ensure
> that I
> find out about future changes?
As far as I can tell such things are announced here on this mailing list with
subject "[ANNOUNCEMENT]". This specific change was announced here:
https://source
Dear Marco,
> this is due to the preference given by Windows to load dll's from the same
> directory where the program is resident instead of using the ones in the PATH
yes, this is expected behavior. What is not expected is that the location of
the system root in the Windows file system does no
Dear Andrey,
> The mapping is consistent throughout the execution tree.
I would like to understand the underlying mechanism. The documentation (FAQ
section 4.20) states (as far as I understand) that the Windows path of the
Cygwin system root an executable sees is the parent directory of the fol
Dear Tuyanyi,
what has been changed in sed and awk is handling of carriage returns. The sed
and awk of older Cygwin version strip \r from the input. Newer versions behave
like the same tools on Linux and don't strip CR. This is documented in the
release notes, intended behavior and has been dis
Dear Cygwin Users,
I got it, I just have to clear the HOME variable before.
But I have a few more observations on this:
the FAQ (section 4.20) state that the root path for the mount table depends on
the path of the cygwin1.dll, to which an executable is linked. This doesn't
seem to be the case
Dear Cygwin users,
I have several Cygwin installation for different purposes (think of it as light
weight VMs). I observe an unexpected behavior of ~ when I call a bash from one
Cygwin from a bash of another Cygwin. The procedure is as follows:
*I have a Cygwin in C:\bin\cygwinA
*
Dear Ulli,
> There is no way to run a 32 bit cygwin binary ob a 64 bit Windows system?
You can easily install 32 bit Cygwin on 64 bit Windows (as I mentioned before).
Best regards,
Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-
Dear Ulli,
are you sure you want a cygwin build? I thought you are doing a MinGW build
(since Cygwin1.ddl was missing from ldd).
There are 3 possible ways:
1.) Do a MinGW cross compile in case you don't need any Cygwin infrastructure
(bash, ...) or fully posix compliant C environment
2.) Do a
Dear Uli,
in case you are not comfortable using gdb, Sysinternals ProcMon (can be
downloaded for free from Microsoft) will give you information about what
happens during process startup.
Best regards,
Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Dear Ulli,
sorry, I just saw that you did compile on a 32 bit Windows, so you had a 32 bit
Cygwin - strange. What I can tell is that compiling a 32 bit app on a 32 bit
Cygwin on a 64 bit Windows works and that such an app runs fine on 32 bit and
64 bit Windows. I test this regularly. I can't co
Dear Ulli,
for MinGW (your ldd dump didn't include Cygwin dlls, so I assume you are doing
MinGW builds) I would recommend to compile 32 bit binaries using a 32 bit
Cygwin (which can be installed on 64 bit machines).
The reason is that the Windows file system has some hacks. Some DLLs are
avail
Dear Andy,
here you can find a batch file, which sets up a Cygwin from scratch with a
defined set of packages:
https://github.com/coq/coq/blob/master/dev/build/windows/MakeCoq_MinGW.bat
The setup of Cygwin takes about 2 minutes and is without any user interaction.
I would say, this is a more r
Dear Corinna,
> ...which is what I described in the rest of my mail :)
ah, yes, sorry. I stumbled on the "0x96c75d80 which appears to be perfectly
valid for a 32 bit int", fell on my nose and looks like I forgot to walk on
then.
Best regards,
Michael
Intel Deutschland GmbH
Registered Address:
Dear Corinna,
> L is of type Long == int32_t, aadj is of type double. The value of aadj at
> this time is 2529648000.0 == 0x96c75d80 which appears to be perfectly valid
> for a 32 bit int.
2529648000 is a valid unsigned long, but not a valid signed long. The largest
32 bit long is 2^31-1 = 21
> Probably doesn't fit precisely into a double. Does strtold behave
> better?
actually both numbers can be represented exactly as IEEE double. In Maxima:
(%i1) factor(121645100408832000);
(%o1) 2^16*3^8*5^3*7^2*11*13*17*19
(%i2) float(log(3^8*5^3*7^2*11*13*17*19)/log(2));
(%o2) 40.755455
Dear Tim,
do you compile c or c++ code (.cpp extension)?
As far as I can tell, you need "gcc-core" and "gcc-g++" if you want to compile
c++ code - or at least this is what I install and it works (regularly tested
with automated regression tests, which always install a fresh Cygwin)
Best regar
See "Subscribing and unsubscribing" at the bottom of
https://www.cygwin.com/lists.html.
Best regards,
Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Dear Wouter,
great that you found the root cause - I was about to try it on some of my
cygwin installation.
I would report it as a bug towards the virus scanner manufacturer, that they
kill processes without notifying the user. I think users generally want to be
informed if the virus scanner t
Dear Wouter,
> One day on, and it's all reverted. Everything failing again in exactly the
> same way
> as before. It was too good to be true...
You might want to disassemble the good and bad binaries and compare the
disassemblies. This should reveal what is going on. You can send me the
binari
Dear Wouter,
when things get bizarre on Windows, I tend to use Sysinternals/Microsoft
ProcMon. It is free and can be downloaded here:
https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx
ProcMon shows you all Windows system calls with parameters and error results.
You should se
Dear Hans-Bernhard,
> You're doing this via Cygwin, i.e. on a Windows machine, where MinGW is a
> _native_ toolchain. That begs the question: why are you doing a cross build
> in
> the first place?
I simply couldn't find another way to build 50 configure / make style libraries
and tools on Win
Dear Eric,
> Building mingw apps may be one use of cygwin, but it is not the "intended use
> case".
I said "an" intended use case, not "the". I also use cygwin for a lot of other
things.
> If you are writing a Linux app that processes data produced on a windows
> machine, then YOU must strip C
Dear Dan,
> One could try making a wrapper shell script where sed usually lives that adds
> those options and calls the real sed...
I tried to do exactly this, but I tried to pipe a dos2unix command in between.
It got a bit complicated because I had to parse the sed command line arguments.
The
Dear Brian,
> alias sed='sed -b -e '\''s/\r$//'\'''
thanks, an interesting idea! Putting this into something like .bashrc might
have a similar effect as having a special sed build with CR stripping built in.
Best regards,
Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 855
Dear cyg Simple,
> but it would be most beneficial if you caused the stdio of your
> Windows applications to be in binary format instead of text format. Then the
> CR wouldn't be an issue during the pipe process. Why does your applications
> stdio need to be in text format instead of binary form
Dear Blake,
> External products were being lazy by relying on cygwin to strip CR when they
> should have stripped it themselves. But 'sed -b' does NOT strip CR (it is the
> exact opposite, of keeping CR unstripped).
I think that there are more people who use sed for text processing in a MinGW
c
Dear Vince,
> Use binary mounts. The root of the problem is using text mounts in the first
> place.
How would this help to convince sed to do CR-LF to LF conversion, especially on
piped input?
Also I think all my mounts are binary:
$ mount
D:/bin/cygwin /bin on /usr/bin type ntfs (binary,auto
Dear Eric,
> No, the documented behavior is that CR-LF is converted to LF only for text-
> mounted files; but pipelines are default binary-mounted. If you want to strip
> CR from a pipeline, then make it explicit.
>
> > var=$( prog | sed .)
>
> Rewrite that to var=$( prog | tr -d '\r' | sed .)
Dear Cygwin Team,
in the latest version of cygwin with sed-4.4-1.tar.bz2 the behavior of sed
regarding handling CR-LF sequences changed. The last version I tried where this
was still working is sed-4.2.2-3.tar.bz2.
I would say that the documented behavior in both versions is that they replace
50 matches
Mail list logo