Re: Python - plan & execution
On 10.04.2020 14:52, Marco Atzeri wrote:
Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
I would suggest the following:
* python2-2.7.z continues to provide all '2' symlinks.
* python38 be updated to 3.8.2, and 3.8 be designated the next default
'python3' version (with the '3' symlinks continued to be kept
separate), and adjust python-wheel.cygclass accordingly.
* Similarly, a separate package (in Fedora it's called 'python-
unversioned-command') provide unversioned symlinks, pointing to 2.7 for
now (for compatibility).
I do not found a package called python-unversioned-command
on fedora
https://apps.fedoraproject.org/packages/s/python-unversioned-command
page is empty
and google seems suggest only discussion on the matter
* Anything currently dependent on 'python' or 'python2' should either
be dropped if no longer needed, switched to 3 is possible, otherwise
rebuilt.
* Drop 2.7 from the "default" version set in python-wheel.cygclass, and
only build those modules that are actually needed by other things by
specifying "all".
* Once that's done, look at what's still depending on /usr/bin/python
('python-unversioned-command'), and based on that decide when that can
be changed to point to python3.
HTH,
--
Yaakov
first steps done:
- updated 3.8 to 3.8.2
- updated 3.7 to 3.7.7
- updated also their python doc
- upload of all of them is in progress
next steps:
- I assume we can drop 3.5
- for the time being no need to update 2.7 and 3.6
(we are just one version behind)
- verify which python packages we need to build/rebuild
currently we have
119 *python27*
114 *python36*
115 *python37*
10 *python38*
and ~ 225 other *python* packages (plus 10 for python35)
- verify the fedora python-unversioned-command
Regards
Marco
what will be the drow back to use alternative to manage
/usr/bin/python and /usr/bin/python3 ?
we can put priorities for python as 2.7 3.8 3.7 3.6
and for python3 as 3.8 3.7 3.6
and rebuild python3 as empty package that pulls 3.6 (or 3.7 ?) now and
3.8 in future
Regards
Marco
Re: Python - plan & execution
On 27.04.2020 16:34, Jon Turney wrote:
On 23/04/2020 22:54, Yaakov Selkowitz wrote:
On Fri, 2020-04-10 at 14:52 +0200, Marco Atzeri via Cygwin-apps wrote:
Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
currently we have
119 *python27*
These are fine as is, but they also don't need to be rebuilt or updated
any more.
114 *python36*
115 *python37*
10 *python38*
We don't need to _obsolete or remove python3[67]-* packages, we just
need to track how many don't have python38-* equivalents yet.
Obviously that's still the vast majority, since 3.8 just got updated to
a stable version.
Jon Turney, if a python-foo source package was previously building e.g.
python27-foo, python36-foo, and python37-foo, and now starts building
only python37-foo and python38-foo, is calm going to complain?
Yes, currently it will complain about that ("install packages from
source package '...' have non-unique current versions")
calm is currently smart enough to exclude old soversions from that
check, so I guess perhaps that it needs to be taught about python27 as
well.
Hi Jon,
there will be several cases to test;
the first I am rebuilding is python-setuptools
and it seems there are half of the packages to drop in 46.4.0
python-setuptools python27-setuptools drop
python-setuptools python35-setuptools drop
python-setuptools python36-setuptools
python-setuptools python37-setuptools
python-setuptools python38-setuptools
python-setuptools python-setuptools-wheel drop
I expect to see other similar as all recent packages
are now only supporting 3.5 or more to 3.8
https://pypi.org/project/setuptools/
Yaakov,
on python-setuptools-wheel, this file is not build/installed anymore
usr/share/python-wheels/setuptools-41.2.0-py2.py3-none-any.whl
so I guess it was Py2 only
Marco
Updated: Perl distributions
The following Perl distributions have been updated to their latest version on CPAN: noarch -- perl-Mojolicious-8.43-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
[ANNOUNCEMENT] Updated: Perl distributions
The following Perl distributions have been updated to their latest version on CPAN: noarch -- perl-Mojolicious-8.43-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
[ANNOUNCEMENT] Updated: zstd-1.4.5-1 and development headers / libraries
This release updates Zstandard to the latest upstream version, which is a maintenance release with performance improvements. Zstandard, or zstd as short version, is a fast lossless compression algorithm, targeting real-time compression scenarios at zlib-level and better compression ratios. http://www.zstd.net/ Besides a standalone compression tool, development headers and a library with comprehensive API are available both for Cygwin native applications and cross-compilation toolchains in the following sub-packages: libzstd-devel-1.4.5-1 libzstd1-1.4.5-1 mingw64-i686-zstd-1.4.5-1 mingw64-x86_64-zstd-1.4.5-1 Note This version is compiled with support for GZip, LZ4 and Xz compression. Support for legacy formats from versions before 1.0 has been removed. -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
Updated: zstd-1.4.5-1 and development headers / libraries
This release updates Zstandard to the latest upstream version, which is a maintenance release with performance improvements. Zstandard, or zstd as short version, is a fast lossless compression algorithm, targeting real-time compression scenarios at zlib-level and better compression ratios. http://www.zstd.net/ Besides a standalone compression tool, development headers and a library with comprehensive API are available both for Cygwin native applications and cross-compilation toolchains in the following sub-packages: libzstd-devel-1.4.5-1 libzstd1-1.4.5-1 mingw64-i686-zstd-1.4.5-1 mingw64-x86_64-zstd-1.4.5-1 Note This version is compiled with support for GZip, LZ4 and Xz compression. Support for legacy formats from versions before 1.0 has been removed. -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK
On 2020-05-24 08:59, ASSI wrote: > Adam Dinwoodie writes: >> Outlook is singularly bad for letting you use this style of email >> reply; > > True, but you _can_ configure it away from that default, although almost > nobody does it and yes it's not very obvious and needs changes in at > least three different corners of the settings maze. Thunderbird is not much better, as you have to find the Button to click, to define domains to which you only wish to send emails in text, and line length, which is global, not per-domain, or overridable for one message. -- 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 IEC units and prefixes, physical quantities in SI.] -- 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: help compilation qemu
Am 24.05.2020 um 17:30 schrieb Juan carlos Rebate via Cygwin: [Can you _please_ cut down on the TOFU? Thanks ] Hi Caba, I know qemu-system-i386 because the official binary is that \ size.As for the command used I use this:x86_64-w64-mingw32- this way it ^^ Those two marked details form a mismatch. If it's the i386 version you're trying to build, then the tool chain (equivalent to the --target argument in configure) is i686-w64-mingw32. compiles perfectly except for the file sizes, if I add the option - s Add it where? -- 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: Help needed with gobject-introspection
On 5/24/2020 12:45 PM, Ken Brown via Cygwin-apps wrote:
On 5/24/2020 11:56 AM, Jon Turney wrote:
On 21/05/2020 18:07, Ken Brown via Cygwin-apps wrote:
On 5/21/2020 11:48 AM, Jon Turney wrote:
On 21/05/2020 16:13, Ken Brown via Cygwin-apps wrote:
On 5/21/2020 9:24 AM, Jon Turney wrote:
On 20/05/2020 15:50, Ken Brown via Cygwin-apps wrote:
On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote:
I would like to adopt gimp and related packages. At the moment I'm
having trouble with babl, which is needed for gegl0.4, which is needed
for gimp. The problem involves gobject-introspection.
If I disable introspection, the build works fine. This would be OK,
since babl has been built without introspection for several years. But
then the gegl0.4 build complains about the missing babl introspection
files, so I would have to disable introspection there too, which hasn't
been done in the past.
So my preference is to figure out what the problem is and get the babl
build working with introspection. I'm attaching my cygport file and patch.
Here's the failing command...
/usr/bin/g-ir-scanner -I/usr/include/gobject-introspection-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT
--no-libtool --namespace=Babl --nsversion=0.1 --warn-all --output
babl/Babl-0.1.gir --c-include=babl.h
'--identifier-filter-cmd=/usr/bin/python3
/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl/identfilter.py'
-DBABL_IS_BEING_COMPILED
-I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl
-I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl -I./.
-I../. -I./babl/base/. -I../babl/base/.
--filelist=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl/4170c83@@babl-0.1@sha/Babl_0.1_gir_filelist
--cflags-begin -fno-unsafe-math-optimizations
-Wdeclaration-after-statement -Winit-self -Wmissing-declarations
-Wmissing-prototypes -Wold-style-definition -Wpointer-arith -mmmx -msse
-mfpmath=sse -I./. -I../. -I./babl/base/. -I../babl/base/. --cflags-end
--library babl-0.1
-L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl --extra-library=m
--extra-library=dl --extra-library=lcms2
...and the error message:
g-ir-scanner: link: gcc -o
/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.exe
-ggdb -O2 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fstack-protector-strong --param=ssp-buffer-size=4
-fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/build=/usr/src/debug/babl-0.1.74-1
-fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74=/usr/src/debug/babl-0.1.74-1
/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.o
-L. -lbabl-0.1 -lm -ldl -llcms2
-L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl -Wl,-rpath,/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
-lgio-2.0 -lgobject-2.0 -Wl,--export-all-symbols -lgmodule-2.0
-lglib-2.0 -lintl
ERROR: can't resolve libraries to shared libraries: babl-0.1
I don't understand the error message, because the command line contains
-L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
and that directory contains libbabl-0.1.dll.a and cygbabl-0.1-0.dll. I
even tried adding that directory to my PATH to make sure the right
cygbabl-0.1-0.dll would be found, but that didn't help.
This might possibly be related to the problem described in the comment for:
https://github.com/mesonbuild/meson/pull/2880/commits/8a27c08b05e4537d5061d30ddd8aad9dc52cf1c4
Yeah, this looks extremely plausible, there seem to be no GObject derived
types in babl's interface.
It might be possible to work around this by patching in a dummy GObject
derived type which does nothing.
I'll have to see if I can find my notes about how I debugged this before.
By the way, in case you're wondering why I disabled the building of docs,
it's because I was getting a build failure there too. I don't know if
this is related to the introspection failure. The failing command there is
/usr/bin/meson --internal exe --unpickle
/tmp/cygbabl/babl-0.1.74-2.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/meson-private/meson_exe_env_7bf39b99114d34540b83d26a5d8f097e05882836.dat
cp: target 'docs/index.html.tmp' is not a directory
I don't know why it's not showing me the actual cp command that fails.
I believe it's is an infelicity in meson that it doesn't echo the actual
failing command here.
Noted here:
https://github.com/mesonbuild/meson/pull/3716#issuecomment-395746838
The corresponding information in docs/meson.build is
Reference_html = custom_target('Reference.html',
input : [
'Reference-static.html',
'toc',
index_html_tmp,
],
output: [ 'Reference.html', ],
command: [
env_bin,
'cp', '@INPUT0@', '@OUTPUT@',
'&&', xml_insert, '@OUTPUT@', 'TOC', '@INPUT1@',
'&&', xml_insert, '@OUTPUT@',
Re: Help needed with gobject-introspection
On 5/24/2020 11:56 AM, Jon Turney wrote:
On 21/05/2020 18:07, Ken Brown via Cygwin-apps wrote:
On 5/21/2020 11:48 AM, Jon Turney wrote:
On 21/05/2020 16:13, Ken Brown via Cygwin-apps wrote:
On 5/21/2020 9:24 AM, Jon Turney wrote:
On 20/05/2020 15:50, Ken Brown via Cygwin-apps wrote:
On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote:
I would like to adopt gimp and related packages. At the moment I'm
having trouble with babl, which is needed for gegl0.4, which is needed
for gimp. The problem involves gobject-introspection.
If I disable introspection, the build works fine. This would be OK,
since babl has been built without introspection for several years. But
then the gegl0.4 build complains about the missing babl introspection
files, so I would have to disable introspection there too, which hasn't
been done in the past.
So my preference is to figure out what the problem is and get the babl
build working with introspection. I'm attaching my cygport file and patch.
Here's the failing command...
/usr/bin/g-ir-scanner -I/usr/include/gobject-introspection-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT
--no-libtool --namespace=Babl --nsversion=0.1 --warn-all --output
babl/Babl-0.1.gir --c-include=babl.h
'--identifier-filter-cmd=/usr/bin/python3
/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl/identfilter.py'
-DBABL_IS_BEING_COMPILED
-I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl
-I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
-I./. -I../. -I./babl/base/. -I../babl/base/.
--filelist=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl/4170c83@@babl-0.1@sha/Babl_0.1_gir_filelist
--cflags-begin -fno-unsafe-math-optimizations
-Wdeclaration-after-statement -Winit-self -Wmissing-declarations
-Wmissing-prototypes -Wold-style-definition -Wpointer-arith -mmmx -msse
-mfpmath=sse -I./. -I../. -I./babl/base/. -I../babl/base/. --cflags-end
--library babl-0.1
-L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
--extra-library=m --extra-library=dl --extra-library=lcms2
...and the error message:
g-ir-scanner: link: gcc -o
/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.exe
-ggdb -O2 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fstack-protector-strong --param=ssp-buffer-size=4
-fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/build=/usr/src/debug/babl-0.1.74-1
-fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74=/usr/src/debug/babl-0.1.74-1
/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.o
-L. -lbabl-0.1 -lm -ldl -llcms2
-L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
-Wl,-rpath,/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
-lgio-2.0 -lgobject-2.0 -Wl,--export-all-symbols -lgmodule-2.0 -lglib-2.0
-lintl
ERROR: can't resolve libraries to shared libraries: babl-0.1
I don't understand the error message, because the command line contains
-L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
and that directory contains libbabl-0.1.dll.a and cygbabl-0.1-0.dll. I
even tried adding that directory to my PATH to make sure the right
cygbabl-0.1-0.dll would be found, but that didn't help.
This might possibly be related to the problem described in the comment for:
https://github.com/mesonbuild/meson/pull/2880/commits/8a27c08b05e4537d5061d30ddd8aad9dc52cf1c4
Yeah, this looks extremely plausible, there seem to be no GObject derived types
in babl's interface.
It might be possible to work around this by patching in a dummy GObject derived
type which does nothing.
I'll have to see if I can find my notes about how I debugged this before.
By the way, in case you're wondering why I disabled the building of docs,
it's because I was getting a build failure there too. I don't know if
this is related to the introspection failure. The failing command there is
/usr/bin/meson --internal exe --unpickle
/tmp/cygbabl/babl-0.1.74-2.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/meson-private/meson_exe_env_7bf39b99114d34540b83d26a5d8f097e05882836.dat
cp: target 'docs/index.html.tmp' is not a directory
I don't know why it's not showing me the actual cp command that fails.
I believe it's is an infelicity in meson that it doesn't echo the actual
failing command here.
Noted here:
https://github.com/mesonbuild/meson/pull/3716#issuecomment-395746838
The corresponding information in docs/meson.build is
Reference_html = custom_target('Reference.html',
input : [
'Reference-static.html',
'toc',
index_html_tmp,
],
output: [ 'Reference.html', ],
command: [
env_bin,
'cp', '@INPUT0@', '@OUTPUT@',
'&&', xml_insert, '@OUTPUT@', 'TOC', '@INPUT1@',
'&&', xml_insert, '@OUTPUT@', 'BablBase', '@INPUT2@',
],
build_by_default: true,
)
Re: upload with "previous"
On 21/05/2020 20:58, Jon Turney wrote: On 21/05/2020 19:27, Thomas Wolff wrote: I wanted to upload mintty 3.1.6 with a specific setup.hint containing curr: 3.1.6 prev: 3.1.4 but got it wrong so the upload was "normal" instead. I've now uploaded just the setup.hint (mintty-3.1.6-1.hint) and !ready files manually. Will that work or should I repeat the complete upload? These 'curr' and prev' key are only valid in an override.hint file: https://cygwin.com/packaging-hint-files.html#override.hint Correction: per [1], 'prev:' isn't actually valid in override.hint anymore, since it didn't actually do anything much. So all you are really saying here is 'curr: 3.1.6', which calm is capable of working out anyhow, and will be wrong when the next version is uploaded (and require you to remember to remove it then). So, um, yeah. [1] https://cygwin.com/pipermail/cygwin-apps/2020-March/039948.html (It's unclear how these should be interpreted if they were present with different values in the hints for different versions) However, in this case since you simply wish to withdraw 3.1.5-1, I'd suggest you use the provided mechanism to delete that version: https://cygwin.com/package-upload.html#deleting
Re: Help needed with gobject-introspection
On 21/05/2020 18:07, Ken Brown via Cygwin-apps wrote:
On 5/21/2020 11:48 AM, Jon Turney wrote:
On 21/05/2020 16:13, Ken Brown via Cygwin-apps wrote:
On 5/21/2020 9:24 AM, Jon Turney wrote:
On 20/05/2020 15:50, Ken Brown via Cygwin-apps wrote:
On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote:
I would like to adopt gimp and related packages. At the moment
I'm having trouble with babl, which is needed for gegl0.4, which
is needed for gimp. The problem involves gobject-introspection.
If I disable introspection, the build works fine. This would be
OK, since babl has been built without introspection for several
years. But then the gegl0.4 build complains about the missing babl
introspection files, so I would have to disable introspection
there too, which hasn't been done in the past.
So my preference is to figure out what the problem is and get the
babl build working with introspection. I'm attaching my cygport
file and patch.
Here's the failing command...
/usr/bin/g-ir-scanner -I/usr/include/gobject-introspection-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT
--no-libtool --namespace=Babl --nsversion=0.1 --warn-all --output
babl/Babl-0.1.gir --c-include=babl.h
'--identifier-filter-cmd=/usr/bin/python3
/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl/identfilter.py'
-DBABL_IS_BEING_COMPILED
-I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl
-I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
-I./. -I../. -I./babl/base/. -I../babl/base/.
--filelist=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl/4170c83@@babl-0.1@sha/Babl_0.1_gir_filelist
--cflags-begin -fno-unsafe-math-optimizations
-Wdeclaration-after-statement -Winit-self -Wmissing-declarations
-Wmissing-prototypes -Wold-style-definition -Wpointer-arith -mmmx
-msse -mfpmath=sse -I./. -I../. -I./babl/base/. -I../babl/base/.
--cflags-end --library babl-0.1
-L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
--extra-library=m --extra-library=dl --extra-library=lcms2
...and the error message:
g-ir-scanner: link: gcc -o
/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.exe
-ggdb -O2 -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong
--param=ssp-buffer-size=4
-fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/build=/usr/src/debug/babl-0.1.74-1
-fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74=/usr/src/debug/babl-0.1.74-1
/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.o
-L. -lbabl-0.1 -lm -ldl -llcms2
-L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
-Wl,-rpath,/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
-lgio-2.0 -lgobject-2.0 -Wl,--export-all-symbols -lgmodule-2.0
-lglib-2.0 -lintl
ERROR: can't resolve libraries to shared libraries: babl-0.1
I don't understand the error message, because the command line
contains
-L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
and that directory contains libbabl-0.1.dll.a and
cygbabl-0.1-0.dll. I even tried adding that directory to my PATH
to make sure the right cygbabl-0.1-0.dll would be found, but that
didn't help.
This might possibly be related to the problem described in the
comment for:
https://github.com/mesonbuild/meson/pull/2880/commits/8a27c08b05e4537d5061d30ddd8aad9dc52cf1c4
Yeah, this looks extremely plausible, there seem to be no GObject
derived types in babl's interface.
It might be possible to work around this by patching in a dummy GObject
derived type which does nothing.
I'll have to see if I can find my notes about how I debugged this before.
By the way, in case you're wondering why I disabled the building of
docs, it's because I was getting a build failure there too. I
don't know if this is related to the introspection failure. The
failing command there is
/usr/bin/meson --internal exe --unpickle
/tmp/cygbabl/babl-0.1.74-2.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/meson-private/meson_exe_env_7bf39b99114d34540b83d26a5d8f097e05882836.dat
cp: target 'docs/index.html.tmp' is not a directory
I don't know why it's not showing me the actual cp command that fails.
I believe it's is an infelicity in meson that it doesn't echo the
actual failing command here.
Noted here:
https://github.com/mesonbuild/meson/pull/3716#issuecomment-395746838
The corresponding information in docs/meson.build is
Reference_html = custom_target('Reference.html',
input : [
'Reference-static.html',
'toc',
index_html_tmp,
],
output: [ 'Reference.html', ],
command: [
env_bin,
'cp', '@INPUT0@', '@OUTPUT@',
'&&', xml_insert, '@OUTPUT@', 'TOC', '@INPUT1@',
'&&', xml_insert, '@OUTPUT@', 'BablBase', '@INPUT2@',
],
build_by_default: true,
)
There are several such custom
Re: help compilation qemu
Dear Juan Carlos: I think by "command" we mean the full command line, plus information about the version of the compiler, etc. Regards - Eliot Moss -- 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: help compilation qemu
Hi Caba, I know qemu-system-i386 because the official binary is that size.As for the command used I use this:x86_64-w64-mingw32- this way it compiles perfectly except for the file sizes, if I add the option - s the error Bash option -s unknown, I use 64-bit El dom., 24 may. 2020 11:32, Csaba Ráduly via Cygwin escribió: > > Hi Juan Carlos, > > On 24/05/2020 02:08, Juan carlos Rebate via Cygwin wrote: > ... > > > 1 the compiler is extremely slow, gcc on Linux is about 10 times > > faster, How could I speed up the compilation process?. > > Unfortunately, Cygwin's emulation of fork() is slow compared to the native > Linux > implementation (I've seen 1000x difference once, in a test launching the > same > program repeatedly). There's not much you can do about it, except getting > faster > hardware. A C++ build involves lots and lots of programs being forked. > > > 2 the executables produced are too fat, for example qemu-system-i386 is > 65 > > MB, but it should be 10.5 MB, if I use the -s option in configure returns > > an unknown error message, how could I fix it? Thank you > > Why do you think qemu-system-i386 "should be 10.5 MB" ? > Are you using 32-bit or 64-bit Cygwin? 64-bit executables are usually > bigger > than their 32-bit counterparts (although rarely six times as big). > > You really need to give us more information if you hope to get help, like > the > actual commands you used and the exact error message. > > Without those, we can only guess, and my crystal ball is not very reliable. > > If you want to strip the resulting executables, you could try setting the > LDFLAGS environment variable to '-s' before running configure > > Csaba > -- > You can get very substantial performance improvements > by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler > So if you're looking for a completely portable, 100% standards-conformat > way > to get the wrong information: this is what you want. - Scott Meyers > (C++TDaWYK) > -- > 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 > -- 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 doesn't support IO_REPARSE_TAG_APPEXECLINK
Adam Dinwoodie writes: > Outlook is singularly bad for letting you use this style of email > reply; True, but you _can_ configure it away from that default, although almost nobody does it and yes it's not very obvious and needs changes in at least three different corners of the settings maze. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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 doesn't support IO_REPARSE_TAG_APPEXECLINK
On Sun, 24 May 2020 at 10:51, Kagami Rosylight via Cygwin wrote: > > Sorry for not keeping the standard style . Which email client do you use to > do the "bottom posting"? I copied the whole body from Outlook to my IDE and > added ">" to write this, is this what you are doing? It seems there should be > more straightforward way as all mailing list users are using this style. Outlook is singularly bad for letting you use this style of email reply; I'd go so far as to argue it's primarily responsible for the shift away from this style of reply that was, for a long time in the history of the internet, very much the standard form. If you're able to use some other email client to interact with this mailing list (and mailing lists for other open source projects, which, IME, mostly also prefer this sort of reply format) you might find that easier. Personally, when I do have to use Outlook to interact with a mailing list, I end up copying the email into Vim, writing my reply there, and copying it back. (But even then, Outlook mangled your message something rotten: your email has a bunch of unnecessary Microsoft-proprietary headers, is base64 encoded for no good reason, and didn't automatically wrap the text lines at a sensible line length. Which, to be clear, is me having a grump about Outlook, not about anything you've done, other than use an email application that you might reasonably think would be able to send emails without mangling things so badly.) -- 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: XWin problem (xinit launche twice)
Am 21.05.2020 um 21:38 schrieb Marco Atzeri via Cygwin: > On 21.05.2020 20:07, Franz Fehringer wrote: >> There is maybe a race (condition) i just managed starting xinit only >> once (where it was started twice all the time). >> > > A race it is possible. > > Sometimes I see xinit or Xwin stuck and I need to kill X, > while the second time goes fine. > > May be in your case the first is stuck and a second istance is > risen again. > > > Running starxwin from mintty is more likely to work for me > the first time. I assume the AV is causing a delay in loading > the libraries and the second repetition takes less time and avoid the > race. > > Regards > Marco Hi Marco, Thx again for your advice and effort. There seemingly is not much i can do. What mechanism would start a second xinit instance? I start clean (no xinit / XWin around) and have two xinitS in the next second already. Best regards Franz -- 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 doesn't support IO_REPARSE_TAG_APPEXECLINK
On 24.05.2020 11:51, Kagami Rosylight via Cygwin wrote: From: Marco Atzeri `Reply always with mailing list in copy, please and bottom posting as standard have you tested "cygstart /cygdrive/c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8.exe " ? Regards Marco That works by opening a new window. MSYS2 doesn’t have it by default and I can’t add conditional cygstart calls everywhere just to workaround this issue, though. Sorry for not keeping the standard style . Which email client do you use to do the "bottom posting"? I copied the whole body from Outlook to my IDE and added ">" to write this, is this what you are doing? It seems there should be more straightforward way as all mailing list users are using this style. -- I am usually using Thunderbird, but it works also with Gmail web interface with a bit of patience and after setting for NOT using HTML mail format. Regards Marco -- 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 doesn't support IO_REPARSE_TAG_APPEXECLINK
From: Marco Atzeri > `Reply always with mailing list in copy, please > and bottom posting as standard > > On 23.05.2020 18:34, Kagami Rosylight wrote: > > Hi Marco, > > > > >Not clear why you expect that a Windows specific tag as > > IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ? > > > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fgit%2F%3Fp%3Dnewlib-cygwin.git%3Ba%3Dblob%3Bf%3Dwinsup%2Fcygwin%2Fpath.cc%3Bh%3D36aa8278fd8495bdfe5ec82b8c36d7d3d7881ebb%3Bhb%3Drefs%2Fheads%2Fmaster%23l2473data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435%7C1%7C0%7C637259096391494659sdata=Llf8pBA7JBtDEThlvynB7Di1E71xjJnLVUJsEI1N6u8%3Dreserved=0 > > > > > > Because Cygwin already supports common reparse points (such as symlinks) > > and APPEXECLINK is also a common one used by Microsoft Store. This issue > > causes some CLI tools depending on MSYS2 (which again on Cygwin) to fail > > calling system Python executable. > > > > > that seems a bit short to help third party in properly using it. > > > > Good point, and that’s why I only could provide the prior works. > > REPARSE_DATA_BUFFER_APPEXECLINK in the PowerShell patch shows how the > > structure look like, but this definitely needs an official > > documentation. I don’t think it’s a strict blocker given that there are > > public working patches, though. > > > > -Kagami > > > > *From: *Marco Atzeri > > *Sent: *Saturday, 23 May 2020 5:50 PM > > *To: *cygwin@cygwin.com , sascha...@outlook.com > > *Subject: *Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK > > > > On 23.05.2020 17:09, Kagami Rosylight via Cygwin wrote: > > > Hi Cygwin community, > > > > > > I found that Cygwin can’t run UWP based CLI tools, as they expose > > their executables as reparse points with the tag > > IO_REPARSE_TAG_APPEXECLINK which Cygwin does not support. > > > > > > Way to reproduce this issue on Cygwin: > > > > > > 1. Install Python from Microsoft Store: > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fp%2Fpython-38%2F9mssztt1n39ldata=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435%7C1%7C0%7C637259096391494659sdata=tJ4DeDmHrHFYPrXIDzLiXZ6vQivQbZVV703SfOqMT%2BM%3Dreserved=0 > > (assuming you don’t already have python3.8 on your PATH.) > > > 2. Try running `python3.8` on Cygwin. It will say > > “/cygdrive/c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8: > > Permission denied” > > > 3. Check it’s real path by `get-childitem -path > > C:/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8.exe` on > > PowerShell. It’s `C:\Program > > Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1008.0_x64__qbz5n2kfra8p0\python3.8.exe`. > > > 4. Try running python again with that path. This succeeds. > > > > > > I posted this issue on MSYS2 GitHub repo > > (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmsys2%2FMSYS2-packages%2Fissues%2F1943data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435%7C1%7C0%7C637259096391494659sdata=9DVvWYnNcgR26LR7p%2FdX2n7uXI8rnL%2BE1nO7ct9ZBF0%3Dreserved=0) > > but I think Cygwin is the right place to file this. > > > > > > Relevant prior works: > > > > > > * Python > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fcommit%2Fdf2d4a6f3d5da2839c4fc11d31511c8e028daf2cdata=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435%7C1%7C0%7C637259096391494659sdata=PHB5ChU1IX4gfc7NF3XMJqghyoVBic4CJ5fDP1W7LAM%3Dreserved=0 > > > * libuv > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flibuv%2Flibuv%2Fcommit%2Fe7ebae26247d2fee0a04547eb7f9aa8f78d4a642data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435%7C1%7C0%7C637259096391504645sdata=rA4UuMyybOHo35N6qPF0OYVxFLk0usYuviUH0NjymlU%3Dreserved=0 > > > * PowerShell > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPowerShell%2FPowerShell%2Fpull%2F10331data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435%7C1%7C0%7C637259096391504645sdata=cW19cfgbotWpc1loOfYJHoIIvFh2zdSSPhdbeRnIGnw%3Dreserved=0 > > > > > > Thanks, > > > > > > -Kagami > > > > > > > Not clear why you expect that a Windows specific tag as > > IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ? > > > > Moreover all the documentation from MS seems > > > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-fscc%2Fc8e77b37-3909-4fe6-a4ea-2b9d423b1ee4data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435%7C1%7C0%7C637259096391504645sdata=EsAOzkEfbTP3RxYcFVsWuGax0s2dh2nf38%2FhfW%2Frre8%3Dreserved=0 > > > > that seems a bit short to help third party in properly using it. > > > > Regards > > Marco > >
Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK
Reply always with mailing list in copy, please and bottom posting as standard On 23.05.2020 18:34, Kagami Rosylight wrote: Hi Marco, Not clear why you expect that a Windows specific tag as IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ? https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/path.cc;h=36aa8278fd8495bdfe5ec82b8c36d7d3d7881ebb;hb=refs/heads/master#l2473 Because Cygwin already supports common reparse points (such as symlinks) and APPEXECLINK is also a common one used by Microsoft Store. This issue causes some CLI tools depending on MSYS2 (which again on Cygwin) to fail calling system Python executable. > that seems a bit short to help third party in properly using it. Good point, and that’s why I only could provide the prior works. REPARSE_DATA_BUFFER_APPEXECLINK in the PowerShell patch shows how the structure look like, but this definitely needs an official documentation. I don’t think it’s a strict blocker given that there are public working patches, though. -Kagami *From: *Marco Atzeri *Sent: *Saturday, 23 May 2020 5:50 PM *To: *cygwin@cygwin.com , sascha...@outlook.com *Subject: *Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK On 23.05.2020 17:09, Kagami Rosylight via Cygwin wrote: > Hi Cygwin community, > > I found that Cygwin can’t run UWP based CLI tools, as they expose their executables as reparse points with the tag IO_REPARSE_TAG_APPEXECLINK which Cygwin does not support. > > Way to reproduce this issue on Cygwin: > > 1. Install Python from Microsoft Store: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fp%2Fpython-38%2F9mssztt1n39ldata=02%7C01%7C%7Ca89ae101a11349ad859008d7ff3113b0%7C84df9e7fe9f640afb435%7C1%7C0%7C637258458551804597sdata=NnwQ27A9WsjWdilY6nqF3WR0WnGUvzzeHoajB3onPpo%3Dreserved=0 (assuming you don’t already have python3.8 on your PATH.) > 2. Try running `python3.8` on Cygwin. It will say “/cygdrive/c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8: Permission denied” > 3. Check it’s real path by `get-childitem -path C:/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8.exe` on PowerShell. It’s `C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1008.0_x64__qbz5n2kfra8p0\python3.8.exe`. > 4. Try running python again with that path. This succeeds. > > I posted this issue on MSYS2 GitHub repo (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmsys2%2FMSYS2-packages%2Fissues%2F1943data=02%7C01%7C%7Ca89ae101a11349ad859008d7ff3113b0%7C84df9e7fe9f640afb435%7C1%7C0%7C637258458551804597sdata=9Othhu3kprUrr7PcweU%2BXyj3Srqb47nK4vLNhgBI%2FlQ%3Dreserved=0) but I think Cygwin is the right place to file this. > > Relevant prior works: > > * Python https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fcommit%2Fdf2d4a6f3d5da2839c4fc11d31511c8e028daf2cdata=02%7C01%7C%7Ca89ae101a11349ad859008d7ff3113b0%7C84df9e7fe9f640afb435%7C1%7C0%7C637258458551804597sdata=k6HtZ2Sl51OgudNjdbdmhcC12c6FTMM8%2F%2BoEv8gNlN0%3Dreserved=0 > * libuv https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flibuv%2Flibuv%2Fcommit%2Fe7ebae26247d2fee0a04547eb7f9aa8f78d4a642data=02%7C01%7C%7Ca89ae101a11349ad859008d7ff3113b0%7C84df9e7fe9f640afb435%7C1%7C0%7C637258458551804597sdata=ulo1a%2Fy4iwjUK6BRAAi88VEMrXNlU8fIxxLptA6Y3uU%3Dreserved=0 > * PowerShell https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPowerShell%2FPowerShell%2Fpull%2F10331data=02%7C01%7C%7Ca89ae101a11349ad859008d7ff3113b0%7C84df9e7fe9f640afb435%7C1%7C0%7C637258458551804597sdata=OhuYhKsNYkfCEB3trhdm6QF1wdzAhGdqRRTQi8V350w%3Dreserved=0 > > Thanks, > > -Kagami > Not clear why you expect that a Windows specific tag as IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ? Moreover all the documentation from MS seems https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-fscc%2Fc8e77b37-3909-4fe6-a4ea-2b9d423b1ee4data=02%7C01%7C%7Ca89ae101a11349ad859008d7ff3113b0%7C84df9e7fe9f640afb435%7C1%7C0%7C637258458551814592sdata=IdYc3OG4UdvTo2IJeSmwsSvaqcAFdsM3ZmhV2RicMqA%3Dreserved=0 that seems a bit short to help third party in properly using it. Regards Marco PS: Python 3.8 is available as Cygwin binary have you tested "cygstart /cygdrive/c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8.exe " ? Regards Marco -- 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: help compilation qemu
Hi Juan Carlos, On 24/05/2020 02:08, Juan carlos Rebate via Cygwin wrote: ... 1 the compiler is extremely slow, gcc on Linux is about 10 times faster, How could I speed up the compilation process?. Unfortunately, Cygwin's emulation of fork() is slow compared to the native Linux implementation (I've seen 1000x difference once, in a test launching the same program repeatedly). There's not much you can do about it, except getting faster hardware. A C++ build involves lots and lots of programs being forked. 2 the executables produced are too fat, for example qemu-system-i386 is 65 MB, but it should be 10.5 MB, if I use the -s option in configure returns an unknown error message, how could I fix it? Thank you Why do you think qemu-system-i386 "should be 10.5 MB" ? Are you using 32-bit or 64-bit Cygwin? 64-bit executables are usually bigger than their 32-bit counterparts (although rarely six times as big). You really need to give us more information if you hope to get help, like the actual commands you used and the exact error message. Without those, we can only guess, and my crystal ball is not very reliable. If you want to strip the resulting executables, you could try setting the LDFLAGS environment variable to '-s' before running configure Csaba -- You can get very substantial performance improvements by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler So if you're looking for a completely portable, 100% standards-conformat way to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK) -- 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: STACKDUMP - mintty - Multiply crashes experienced following upgrade to mintty 3.1.5 - x86_64-pc-cygwin
On Thu 2020-05-21 16:42:39 +0100, Olaf Sulla wrote: > Apologies, > > Additional info: > > Build: > CYGWIN_NT-6.1 shackleton 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin > Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1 > > Redacted cygcheck report attached. > > > > On Thu 2020-05-21 16:13:08 +0100, Olaf Sulla wrote: > > Hi, > > > > I am now experiencing multiple crashes in mintty following the installation > > of > > mintty v3.1.5 earlier this morning. > > > > Typical stackdump: > > > > Exception: STATUS_INTEGER_DIVIDE_BY_ZERO at rip=00100438534^M > > rax=03E8 rbx=401C0001 rcx=^M > > rdx= rsi=000D rdi=0001004CB540^M > > r8 =BFA8 r9 =000180321C90 r10=^M > > r11=0202 r12=4000 r13=76F256E4^M > > r14= r15=00050576^M > > rbp=000180321C90 rsp=BFB0^M > > program=C:\cygwin64\bin\mintty.exe, pid 1791, thread main^M > > cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B^M > > Stack trace:^M > > FrameFunctionArgs^M > > 00180321C90 00100438534 (00076F078EC, 000, 001, > > 000C458)^M > > 000C3A0 00100440135 (02F0058, 00076F1908A, 00180132457, > > 001802BEDF0)^M > > 000C5C0 00076F19BBD (0010043F780, 001004CB9E0, 092EB10, > > 00D)^M > > 000C5C0 00076F198C2 (00076F139B0, 0010043F780, 00076F532B8, > > 0080001)^M > > 000C5C0 0010045133C (02F, 000, 0018022D780, > > 00180294A00)^M > > 000CCD0 0018004A826 (000, 000, 000, > > 000)^M > > 000 00180048353 (000, 000, 000, > > 000)^M > > 000FFF0 00180048404 (000, 000, 000, > > 000)^M > > End of stack trace > > > > > > Scenario: > > > > The crashes occur if while moving the cursor it reaches or is near the > > bottom > > of the screen. Crashes have occurred in vim, mutt, and man since installing > > this version. > > > > > > Regards, > > Hi, Installed Mintty v3.1.6 (x86_64-pc-cygwin) earlier this morning. There has been no observed repeat of the crashes of Mintty with scrolling using repeat key entry with the new package. I think therefore that the v3.1.6 package resolves the issue I was observing. Many thanks to all concerned. Regards. -- Mutt 1.14.0 (2020-05-02) -- 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
