Re: Strange behavior of Python Package Index
> I have selected python38-tkinter package for the Cygwin setup. > Tkinter is available when I start python3.8, but when I try to check list of > packages installed with pip3.8, > tkinter is not listed. > It seems that all packages selected from Cygwin setup are missing. > Only packages installed with command pip3.8 install are listed. python?? python??-devel python??-test python??-tkinter python??-debuginfo idle?? are all built from the CPython source. None of the corresponding files would be recognized by pip on any platform, as they are part of base python, rather than third-party extensions. |pip3.8 list| will also not recognize python38 as being installed, no matter what setup.exe tells you, for much the same reason. All other python??-* packages ([1]) were installed using pip, so |pip list| will find them just fine. Short version: Cygwin package != PyPI package, and pip only cares about the latter [1] except the python??-*-debuginfo packages -- 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
cpp /usr/include/threads.h fails; modfl segfaults
Hello,
I have two reports. A brief description of the system:
$ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
The first report:
$ cpp /usr/include/threads.h
# 1 "/usr/include/threads.h"
# 1 ""
# 1 ""
# 1 "/usr/include/threads.h"
/usr/include/threads.h:30:10: fatal error: machine/_threads.h: No such
file or directory
30 | #include
| ^~~~
compilation terminated.
$ cygcheck -p machine/_threads.h
Found 0 matches for machine/_threads.h
$ cygcheck -f /usr/include/threads.h
cygwin-devel-3.1.7-1
$ cygcheck -c cygwin-devel
Cygwin Package Information
Package Version Status
cygwin-devel 3.1.7-1 OK
I'm not sure what to do from here. I don't remember where I ran into this,
but this feels like something that shouldn't happen
The second report:
$ cat test.c
#include
#include
#include
int main(int argc, char *argv[]) {
long double a, b, c;
char *num_end = NULL;
a = b = c = 0.0L;
if (argc != 2) {
fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
exit(1);
}
a = strtold(argv[1], &num_end);
b = modfl(a, &c);
printf("%Lf %Lf %Lf\n", a, b, c);
return 0;
}
$ gcc -Og -ggdb -g3 -Wall -Wextra -std=c99 -pedantic test.c -o test.exe
$ ./test.exe 123.456
Segmentation fault (core dumped)
$ gdb --args ./test.exe 123.456
GNU gdb (GDB) (Cygwin 8.3.1-1) 8.3.1
...
Reading symbols from ./test.exe...
(gdb) break modfl
(gdb) run
Starting program: /home/Daniel/test.exe 123.456
[New Thread 13960.0x3cf4]
[New Thread 13960.0xbdc]
[New Thread 13960.0x4028]
[New Thread 13960.0x3224]
[New Thread 13960.0x3810]
[New Thread 13960.0x1ae4]
[New Thread 13960.0x3714]
[Thread 13960.0x4028 exited with code 3697672192]
[Thread 13960.0x3714 exited with code 0]
Thread 1 "test" hit Breakpoint 1, modfl (value=,
iptr=iptr@entry=0xcbd0) at
/usr/src/debug/cygwin-3.1.7-1/winsup/cygwin/math/modfl.c:16
16 asm ("subq $8, %%rsp\n"
(gdb) step
38 if (iptr)
(gdb) step
39 *iptr = int_part;
(gdb) step
40 return (isinf (value) ? 0.0L : value - int_part);
(gdb) step
0 [main] test 28439 cygwin_exception::open_stackdumpfile: Dumping
stack trace to test.exe.stackdump
[Thread 13960.0x3b5c exited with code 35584]
[Thread 13960.0x1ae4 exited with code 35584]
[Thread 13960.0x3810 exited with code 35584]
[Thread 13960.0xbdc exited with code 35584]
[Thread 13960.0x3cf4 exited with code 35584]
[Inferior 1 (process 13960) exited with code 0105400]
(gdb)
isinf and isinfl both work just fine, so I'm not sure what's going on there.
Please let me know if you need more information.
--
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: cpp /usr/include/threads.h fails; modfl segfaults
On 8/29/2020 1:57 PM, Ken Brown wrote:
> On 8/29/2020 8:52 AM, airplanemath via Cygwin wrote:
>> Hello,
>>
>> I have two reports.� A brief description of the system:
>> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
>> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64
>> Cygwin
>
> In the future, please use two separate emails for two unrelated bug
> reports.
Will do.
>
>> The first report:
>>
>> $ cpp /usr/include/threads.h
>> # 1 "/usr/include/threads.h"
>> # 1 ""
>> # 1 ""
>> # 1 "/usr/include/threads.h"
>> /usr/include/threads.h:30:10: fatal error: machine/_threads.h: No such
>> file or directory
>> ��� 30 | #include
>> ������ |��������� ^~~~
>> compilation terminated.
>>
>> $ cygcheck -p machine/_threads.h
>> Found 0 matches for machine/_threads.h
>
> It looks like /usr/include/threads.h is a Newlib header that's
> intended for RTEMS.� Here's the commit where it was introduced:
>
> commit c98d01ee0cbc6eb7bbca8f2cde4a46b90ded3784
> Author: Jeff Johnston
> Date:�� Tue Oct 13 17:52:34 2015 -0400
>
> ��� Import from latest FreeBSD.
>
> ��� - Move types and defines to
> ����� so that it can be customized per target.
>
> ����������� * libc/include/threads.h: New.
> ����������� *
> libc/sys/rtems/include/machine/_threads.h: Likewise.
>
> There's no machine/_threads.h in the repository for any platform other
> than RTEMS.�
> My guess is that it shouldn't be included in the Cygwin distro.
Okay.� I can work on convincing whatever program wanted this that the
header doesn't
exist and see what happens, assuming I can remember which program wanted
this.
>
>> The second report:
>>
>> $ cat test.c
>> #include
>> #include
>> #include
>>
>> int main(int argc, char *argv[]) {
>> �� long double a, b, c;
>> �� char *num_end = NULL;
>> �� a = b = c = 0.0L;
>> �� if (argc != 2) {
>> ���� fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
>> ���� exit(1);
>> �� }
>> �� a = strtold(argv[1], &num_end);
>> �� b = modfl(a, &c);
>> �� printf("%Lf %Lf %Lf\n", a, b, c);
>> �� return 0;
>> }
>>
>> $ gcc -Og -ggdb -g3 -Wall -Wextra -std=c99 -pedantic test.c -o test.exe
>>
>> $ ./test.exe 123.456
>> Segmentation fault (core dumped)
>>
>> $ gdb --args ./test.exe 123.456
>> GNU gdb (GDB) (Cygwin 8.3.1-1) 8.3.1
>> ...
>> Reading symbols from ./test.exe...
>> (gdb) break modfl
>> (gdb) run
>>
>> Thread 1 "test" hit Breakpoint 1, modfl (value=,
>> iptr=iptr@entry=0xcbd0) at
>> /usr/src/debug/cygwin-3.1.7-1/winsup/cygwin/math/modfl.c:16
>> ...
>> 40������� return (isinf (value) ?� 0.0L : value - int_part);
>> (gdb) step
>> ������ 0 [main] test 28439 cygwin_exception::open_stackdumpfile:
>> Dumping
>> ...
>> (gdb)
>>
>> isinf and isinfl both work just fine, so I'm not sure what's going on
>> there.
>
> I built a version of cygwin1.dll without optimization in the hopes of
> making debugging easier, but the problem doesn't occur with that DLL.�
> So this is somehow tied up with optimization.� BTW, isinf is a macro
> that expands to __builtin_isinf_sign, again suggesting that
> optimization is involved.
>
> That's as far as I can take it.
Stepping back through Cygwin releases, I find:
$ gcc -Og -ggdb -g3 -Wall -Wextra -std=c99 -pedantic test.c -o test.exe
$ ./test.exe 123.456
123.456000 0.456000 123.00
$ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
CYGWIN_NT-10.0 ${HOSTNAME} 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
$ gcc --version
gcc (GCC) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.� There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
3.1.5 crashed the same way as 3.1.7.� There's nothing obvious in the
3.1.5 announcement [1],
so I'm stuck again.
>
> Ken
[1] https://cygwin.com/pipermail/cygwin-announce/2020-June/009561.html
--
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: cpp /usr/include/threads.h fails; modfl segfaults
Corinna Vinschen writes:
> On Aug 29 08:52, airplanemath via Cygwin wrote:
>> Hello,
>>
>> I have two reports. A brief description of the system:
>> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
>> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
>>
>> The first report:
>>
>> $ cpp /usr/include/threads.h
>> # 1 "/usr/include/threads.h"
>> # 1 ""
>> # 1 ""
>> # 1 "/usr/include/threads.h"
>> /usr/include/threads.h:30:10: fatal error: machine/_threads.h: No such
>> file or directory
>>30 | #include
>> | ^~~~
>> compilation terminated.
>
> The reason for this is, as Ken already pointed out, that
> machine/_threads.h only existed for RTEMS, not for any other target
> supported by newlib. Worse, Cygwin never got around to implement the
> C11 threads functions yet.
>
> I added these functions as wrappers around pthread functionality, code
> taken from FreeBSD. I ran the glibc testsuite on them, and after fixing
> the bugs in the glibc testsuite (d'oh), the tests ran successfully.
>
The header makes it through the preprocessor for me now. Thank you.
>> $ cat test.c
>> #include
>> #include
>> #include
>>
>> int main(int argc, char *argv[]) {
>> long double a, b, c;
>> char *num_end = NULL;
>> a = b = c = 0.0L;
>> if (argc != 2) {
>> fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
>> exit(1);
>> }
>> a = strtold(argv[1], &num_end);
>> b = modfl(a, &c);
>> printf("%Lf %Lf %Lf\n", a, b, c);
>> return 0;
>> }
>
> This is a bug in the assembler code taken from Mingw-w64. The bug has
> been fixed upstream, so I just pulled in the upstream fixes.
The test program now finishes without segfaulting, and gives the
expected answer. Thanks again.
>
> Thus, both of the above problems should be fixed now. I created a
> developer snapshot and uploaed it to https://cygwin.com/snapshots/ You
> need to grab the full tar file and install at least the following files
> to your installation after backing up the original files from 3.1.7:
>
> usr/bin/cygwin1.dll (this is pre-release 3.2.0)
> usr/lib/libcygwin.a
> usr/include/limits.h
> usr/include/pthread.h
> usr/include/machine/_threads.h
>
Is it okay to leave these in place to be overwritten by 3.2.0, or should
I move the old versions back?
> Thanks for the report.
>
Thanks for the prompt response.
>
> Corinna
--
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
sqrtl behavior inconsistent with sqrt and sqrtf
Compiling and running the attached program with the command line below
produces the output below:
#include
#include
int main() {
long double a, b;
double c, d;
float f, g;
a = (long double) -INFINITY;
c = (double) -INFINITY;
f = (float) -INFINITY;
b = sqrtl(a);
d = sqrt(c);
g = sqrtf(f);
printf("Long double: %4Lf %4Lf\n", a, b);
printf("Double: %4lf %4lf\n", c, d);
printf("Float: %4f %4f\n", f, g);
return 0;
}
$ gcc -O0 -Og test_sqrt.c -o test_sqrt && ./test_sqrt
Long double: -inf -inf
Double: -inf -nan
Float: -inf -nan
I suspect the behavior for long double should be the same as for double
and float (sqrt(-inf) = nan), but I'm not sure where to change that.
I'm running a snapshot of Cygwin 3.2.0, if that's important.
--
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: sqrtl behavior inconsistent with sqrt and sqrtf
airplanemath via Cygwin writes:
> Compiling and running the attached program with the command line below
> produces the output below:
>
> $ gcc -O0 -Og test_sqrt.c -o test_sqrt && ./test_sqrt
> Long double: -inf -inf
> Double: -inf -nan
> Float: -inf -nan
>
> I suspect the behavior for long double should be the same as for double
> and float (sqrt(-inf) = nan), but I'm not sure where to change that.
> I'm running a snapshot of Cygwin 3.2.0, if that's important.
The mail archive says I'm bad at attaching things.
Program source included below:
#include
#include
int main() {
long double a, b;
double c, d;
float f, g;
a = (long double) -INFINITY;
c = (double) -INFINITY;
f = (float) -INFINITY;
b = sqrtl(a);
d = sqrt(c);
g = sqrtf(f);
printf("Long double: %4Lf %4Lf\n", a, b);
printf("Double: %4lf %4lf\n", c, d);
printf("Float: %4f %4f\n", f, g);
return 0;
}
--
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
gfortran problems with equivalence statement in module
module test
integer, parameter :: rb = kind(1.0)
real(kind=rb) :: ka(5,13,10) , absa(65,10)
real(kind=rb) :: kb(5,13:59,10), absb(235,10)
equivalence (ka(1,1,1),absa(1,1)), (kb(1,13,1),absb(1,1))
end module test
Compiling the attached fortran code with "gfortran -c test_compile.f90"
fails, citing an internal compiler error due to a segmentation fault.
Downgrading gcc-fortran to 7.3.0-3 or using the Mingw-w64 7.4.0-0
gfortran allows the compilation to complete and produce a .o file.
Running as "${host}-gfortran -c -wrapper gdb,--args test_compile.f90"
seems to indicate that the Mingw-w64 compiler does not have the line
that causes the problem in the cygwin-native compiler:
attributes = gfc_add_attributes_to_decl (com->head->attr, NULL_TREE);
where *com is initialized to zeros (so that com->head is NULL), and
there does not seem to be any place between the creation of *com and
the call above that would set com->head to something other than NULL.
I seem to be missing something here, but I have no idea what that might
be. Can someone point out to me what it is I've missed?
Thanks for any help you may be able to give, and for providing cygwin
all these years.
--
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
liblapack-devel seems to be missing liblapack0 dependency
To whom it may concern, An automated script started failing yesterday, apparently because it could not find the lapack and blas DLLs. On investigation, only liblapack-devel was installed, not liblapack0. Should we be updating scripts to explicitly install liblapack0 when using some executable linked with liblapack-devel? -- 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: [ANNOUNCEMENT] TeX Live collections 20210118-1
texlive-collection-latexrecommended contains "/usr/share/texmf-dist/tex/latex/ragged2e/ragged2e.sty". On line 145, this file uses everysel.sty, which appears to have been dropped from the 2021 rebuild: $ cygcheck -p everysel.sty Found 5 matches for everysel.sty texlive-collection-langjapanese-20190509-1 - texlive-collection-langjapanese: TeX Live japanese language support texlive-collection-langjapanese-20200406-1 - texlive-collection-langjapanese: TeX Live japanese language support texlive-collection-langjapanese-20210118-1 - texlive-collection-langjapanese: TeX Live japanese language support texlive-collection-latexrecommended-20190509-1 - texlive-collection-latexrecommended: TeX Live latexrecommended package collection texlive-collection-latexrecommended-20200406-1 - texlive-collection-latexrecommended: TeX Live latexrecommended package collection One of my LaTeX files uses ragged2e, and broke. Running "tlmgr --usermode install everysel" fixed the problem and allowed ragged2e to finish loading. Was this intentional? Am I missing something? -- 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
hypotl(LDBL_MAX, 0.0L) = inf
Given that hypot(DBL_MAX, 0.0) = DBL_MAX and hypotf(FLT_MAX, 0.0f) =
FLT_MAX, I suspect this is a problem in hypotl. Am I missing something?
There is a similar difference in cabsl compared to cabs and cabsf, which
probably has a similar cause.
I attached my test case, which I compile with
gcc -Og -O0 test_cabs_hypot.c -o test_cabs_hypot
What should I expect here?
#include
#include
#include
#include
int main(void) {
_Complex long double test_cabsl = LDBL_MAX + 0.0L * _Complex_I;
long double test_hypotl1 = LDBL_MAX, test_hypotl2 = 0.0L;
_Complex double test_cabs = DBL_MAX + 0.0L * _Complex_I;
double test_hypot1 = DBL_MAX, test_hypot2 = 0.0L;
_Complex float test_cabsf = FLT_MAX + 0.0L * _Complex_I;
float test_hypotf1 = FLT_MAX, test_hypotf2 = 0.0L;
printf("cabsl(%Lg%+Lgi) = %Lg\n", creall(test_cabsl), cimagl(test_cabsl), cabsl(test_cabsl));
printf("hypotl(%Lg, %Lg) = %Lg\n\n", test_hypotl1, test_hypotl2, hypotl(test_hypotl1, test_hypotl2));
printf("cabs(%lg%+lgi) = %lg\n", creal(test_cabs), cimag(test_cabs), cabs(test_cabs));
printf("hypot(%lg, %lg) = %lg\n\n", test_hypot1, test_hypot2, hypot(test_hypot1, test_hypot2));
printf("cabsf(%g%+gi) = %g\n", crealf(test_cabsf), cimagf(test_cabsf), cabsf(test_cabsf));
printf("hypotf(%g, %g) = %g\n\n", test_hypotf1, test_hypotf2, hypotf(test_hypotf1, test_hypotf2));
return 0;
}
--
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: hypotl(LDBL_MAX, 0.0L) = inf
On Mon, Apr 19 2021, Corinna Vinschen via Cygwin wrote: > On Apr 17 10:02, airplanemath via Cygwin wrote: >> Given that hypot(DBL_MAX, 0.0) = DBL_MAX and hypotf(FLT_MAX, 0.0f) = >> FLT_MAX, I suspect this is a problem in hypotl. Am I missing >> something? > > No. This is a bug in newlib's hypotl. Newlib mainly targest embedded > systems and as such wasn't very much interested in long double > arithmetic for a long time. > > Having said that, there's an easier way out for Cygwin: We just use > the hypotl function from Mingw-w64 for Cygwin as well. > > I pushed this patch and uploaded new developer snapshots to > https://cygwin/snapshots/ > > Please give it a try. Thank you. This fixes that problem and a related one for me. > > > Thanks, Corinna -- 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: [ANNOUNCEMENT] Updated: lapack-3.10.0-1
On Tue, Nov 30 2021, Marco Atzeri via Cygwin-announce via Cygwin wrote: > New versions 3.10.0-1 of > > liblapack0 > liblapack-devel > liblapack-doc > > are available in the Cygwin distribution. The shared libraries seem to be in /usr/bin rather than /usr/lib/lapack now. I don't remember the discussion of this change on the list; was this on IRC perhaps? $ cygcheck -l liblapack0 /etc/profile.d/lapack0.csh /etc/profile.d/lapack0.sh /usr/bin/cygblas-0.dll /usr/bin/cyglapack-0.dll $ cygcheck -l libopenblas /usr/bin/cygblas-0.dll -- 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: [ANNOUNCEMENT] Updated: python 3.9 packages
On Tue, Dec 21 2021, Marco Atzeri via Cygwin-announce wrote:
> Several python packages have been added to the Cygwin distribution
> and at the same time the updated packages for 3.6/3./3.8
> have been uploaded.
>
> python39-pillow 8.4.0-1
Is this replacing python3[6-9]-imaging{,-tk}? They look similar:
$ cygcheck -cd python39-imaging{,-tk} python39-pillow
Cygwin Package Information
Package Version
python39-imaging 8.4.0-1
python39-imaging-tk 8.4.0-1
python39-pillow 8.4.0-1
$ mkfifo pipe1 pipe2
$ cygcheck -l python39-imaging{,-tk} | sort >pipe1 &
[1] 869
$ cygcheck -l python39-pillow | sort >pipe2 &
[2] 872
$ diff -u pipe1 pipe2
--- pipe1 2021-12-22 08:39:44.449869300 -0500
+++ pipe2 2021-12-22 08:39:44.449869300 -0500
@@ -382,6 +382,6 @@
/usr/lib/python3.9/site-packages/Pillow-8.4.0.dist-info/top_level.txt
/usr/lib/python3.9/site-packages/Pillow-8.4.0.dist-info/WHEEL
/usr/lib/python3.9/site-packages/Pillow-8.4.0.dist-info/zip-safe
-/usr/share/doc/python39-imaging/CHANGES.rst
-/usr/share/doc/python39-imaging/LICENSE
-/usr/share/doc/python39-imaging/README.md
+/usr/share/doc/python39-pillow/CHANGES.rst
+/usr/share/doc/python39-pillow/LICENSE
+/usr/share/doc/python39-pillow/README.md
[1]- Donecygcheck -l python39-imaging{,-tk} | sort > pipe1
[2]+ Donecygcheck -l python39-pillow | sort > pipe2
https://cygwin.com/pipermail/cygwin-announce/2021-December/010357.html
--
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: python-numpy (1.22.0-1) can't be imported
On Wed, Jan 12 2022, Marco Atzeri wrote: > On 12.01.2022 12:47, ggl329 wrote: >> Hi Marco, >> I upgraded python39-numpy to 1.22.0-1, and failed to import numpy. >> It seems that mtrand.cpython-39-x86_64-cygwin.dll does not have >> PyInit_mtrand. >> Could you check if numpy can be imported in your environment? >> > > working on it. > In theory I have not changed the build between the two versions > but there was a patch in 1.19.4-1 for similar issue. > > Regards > Marco I have the same problems with the distribution NumPy package, but I can use a locally-compiled NumPy with no patches. It doesn't look like your build has any patches either: https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fpython-numpy-src%2Fpython-numpy-1.22.0-1-src&grep=numpy so that's fun. Out of curiousity, what options are you passing for cpu-baseline and cpu-dispatch? https://numpy.org/devdocs/reference/simd/build-options.html I don't see the newest cygport in the Cygwin package repository. -- 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: python-numpy (1.22.0-1) can't be imported
On Sat, Jan 22 2022, Masamichi Hosoda wrote: >> It is something like that, but "-Wl,--export-all-symbols" >> is not used on 1.21.4 and is not needed for most of the other >> modules on 1.22.x >> >> so I am looking for a less extreme action. >> Also to understand how it can impact other python subpackages > > If I understand correctly, I've found the root cause of the issue. > I've sent a pull request to numpy. > https://github.com/numpy/numpy/pull/20874 Based on that pull request, it looks like it's related to the patches used to avoid python C-extension modules with only one exported function mentioned a year ago: https://cygwin.com/pipermail/cygwin/2021-January/247211.html https://cygwin.com/pipermail/cygwin/2021-January/247216.html >From a glance at the Python C API docs, it looks like Python C extension modules are supposed to have only one exported function: https://docs.python.org/3/extending/extending.html#the-module-s-method-table-and-initialization-function https://docs.python.org/3/extending/extending.html#providing-a-c-api-for-an-extension-module The NumPy CFFI tests seem to want to use a few C extension modules as normal shared libraries, which requires that the functions the tests want to use to be exported from the DLL, but this seems to be a somewhat unusual case. I tend to compile my own versions of Cython (without patches), which may have been picked up when I compiled the new version of NumPy. -- 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
Weird results from PyIter_Check
PyIter_Check appears to be the C-level equivalent of isinstance(..., collections.abc.Iterator), testing whether the python next() or the C PyIter_Next will succeed. However, PyIter_Check disagrees with collections.abc.Iterator and next about whether a given object is an iterator. $ cat test_iterator.pyx from cpython.iterator cimport PyIter_Check def is_iterator(obj: object) -> bool: """Check whether obj is an iterator. Should agree with isinstance(obj, collections.abc.Iterator). Parameters -- obj : object Returns --- bool """ return PyIter_Check(obj) $ cythonize --build --inplace test_iterator.pyx running build_ext $ python Python 3.9.10 (main, Jan 20 2022, 21:37:52) [GCC 11.2.0] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import test_iterator, os, fractions, collections.abc >>> test_iterator.is_iterator(os.environ) True >>> isinstance(os.environ, collections.abc.Iterator) False >>> next(os.environ) Traceback (most recent call last): File "", line 1, in TypeError: '_Environ' object is not an iterator >>> test_iterator.is_iterator(fractions.Fraction(0, 1)) True >>> isinstance(fractions.Fraction(0, 1), collections.abc.Iterator) False >>> next(fractions.Fraction(0, 1)) Traceback (most recent call last): File "", line 1, in TypeError: 'Fraction' object is not an iterator On Linux, the test function using PyIter_Check agrees with collections.abc.Iterator and next. The test case that led me to this behaviour works the same in Windows as on Linux. Is this expected behavior? -- 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: Possible xpdf packaging error?
On Thu, Apr 07 2022, Eliot Moss wrote: > Dear Cygwin-ers -- > > Today I had use for pdftotext. It man page is installed, but the program > itself is missing. On Ubuntu (etc.) it is part of the xpdf package, the > Cygwin version of which I have installed. pdftotext.cc is in the source > package, but its executable is not present in the binary package. > $ cygcheck -p bin/pdftotext Found 6 matches for bin/pdftotext poppler-debuginfo-0.88.0-1 - poppler-debuginfo: Debug info for poppler poppler-debuginfo-0.88.0-2 - poppler-debuginfo: Debug info for poppler poppler-debuginfo-21.01.0-1 - poppler-debuginfo: Debug info for poppler poppler-0.88.0-1 - poppler: PDF manipulation utilities poppler-0.88.0-2 - poppler: PDF manipulation utilities poppler-21.01.0-1 - poppler: PDF manipulation utilities Try installing poppler > So I am wondering if this is intentional (is pdftotext somewhere else?) or an > oversight. The situation seems the same from at least the 4.01.01 release > onward to 4.03 (current) release. This looks to be intentional, given the mention in the last several announcements, e.g. https://cygwin.com/pipermail/cygwin-announce/2021-February/009922.html > > I suppose I can try getting all the necessary dependencies and building from > source, if need be, but though this worth asking about. > > Regards - Eliot Moss Other ways to check are cygcheck -p pdftotext.exe or https://cygwin.com/cgi-bin2/package-grep.cgi?grep=bin%2Fpdftotext&arch=x86_64, -- 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
PyIter_Check false positives
I found this problem running the tests for pandas, but can reproduce it more simply. Compile the following cython file to create a thin wrapper around the C-API function: > from cpython.iterator cimport PyIter_Check > > def is_iterator(obj: object) -> bool: > return PyIter_Check(obj) with `cythonize --build --inplace test_iterator.pyx` (probably requires python39-cython), changing the name if needed, then try the following in Python: >>> from collections.abc import Iterator >>> from fractions import Fraction >>> from os import environ >>> from test_iterator import is_iterator >>> isinstance(environ, Iterator) False >>> is_iterator(environ) True >>> next(environ) Traceback (most recent call last): File "", line 1, in TypeError: '_Environ' object is not an iterator >>> isinstance(Fraction(0, 1), Iterator) False >>> is_iterator(Fraction(0, 1)) True >>> next(Fraction(0, 1)) Traceback (most recent call last): File "", line 1, in TypeError: 'Fraction' object is not an iterator >From the Python documentation [1], it appears that `PyIter_Check` is intended to return True only if the `PyIter_Next` will work, and `PyIter_Next` is the C equivalent of the python `next` function. That is, `isinstance(thing, Iterator)` and `is_iterator(thing)` should agree with each other, and should return True only if `next(thing)` works (produces an element or says there aren't any). On Linux, both checks agree with each other, returning False, and the attempts to advance the iterator with `next` still fail. As seen above, on (my) Cygwin, PyIter_Check disagrees with `collections.abc.Iterator` and succeeds in cases where `next` produces a TypeError. I can reproduce this with python3.9 and with python2.7 on Cygwin. Am I missing something in the documentation? Is this a side-effect of working on top of Windows? In case it's relevant, I'm using an unpatched Cython with the distribution Python packages. [1] https://docs.python.org/3/c-api/iter.html#c.PyIter_Check from cpython.iterator cimport PyIter_Check def is_iterator(obj: object) -> bool: """Check whether obj is an iterator. Should agree with isinstance(obj, collections.abc.Iterator). Parameters -- obj : object Returns --- bool """ return PyIter_Check(obj) -- 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
