Re: new git update fails with fatal: fetch-pack: invalid index-pack output
On 26/05/2024 14:03, Adam Dinwoodie via Cygwin wrote: On Sun, 26 May 2024 at 05:10, David Dyck via Cygwin wrote: I upgraded to the most recent git and I get the following error ( stable2.45.1-1x86_648597 KiB2024-05-25 18:58 ) $ git clone -v https://github.com/lxml/lxml.git Cloning into 'lxml'... POST git-upload-pack (175 bytes) POST git-upload-pack (gzip 8652 to 4281 bytes) remote: Enumerating objects: 33933, done. remote: Counting objects: 100% (3778/3778), done. remote: Compressing objects: 100% (1322/1322), done. remote: Total 33933 (delta 2356), reused 3471 (delta 2241), pack-reused 30155 Receiving objects: 100% (33933/33933), 20.19 MiB | 15.38 MiB/s, done. fatal: fetch-pack: invalid index-pack output when I downgraded to 2.43.0-1x86_648402 KiB2024-01-07 20:32 I was able to get the repository download $ git clone -v https://github.com/lxml/lxml.git Cloning into 'lxml'... POST git-upload-pack (175 bytes) POST git-upload-pack (gzip 8652 to 4281 bytes) remote: Enumerating objects: 33933, done. remote: Counting objects: 100% (3778/3778), done. remote: Compressing objects: 100% (1322/1322), done. remote: Total 33933 (delta 2356), reused 3471 (delta 2241), pack-reused 30155 Receiving objects: 100% (33933/33933), 20.19 MiB | 13.13 MiB/s, done. Resolving deltas: 100% (16518/16518), done. Thanks for the report. This is working fine for me locally. Me too $ git --version git version 2.45.1 $ git clone -v https://github.com/lxml/lxml.git Cloning into 'lxml'... POST git-upload-pack (175 bytes) POST git-upload-pack (gzip 8652 to 4282 bytes) remote: Enumerating objects: 33941, done. remote: Counting objects: 100% (3786/3786), done. remote: Compressing objects: 100% (1327/1327), done. remote: Total 33941 (delta 2361), reused 3474 (delta 2244), pack-reused 30155 Receiving objects: 100% (33941/33941), 20.20 MiB | 13.19 MiB/s, done. Resolving deltas: 100% (16523/16523), done. Csaba -- Life is complex, with real and imaginary parts. -- 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: native symlinks and non-existent targets
On 25/04/2024 15:15, Jon Turney via Cygwin wrote: On 24/04/2024 23:36, Christopher Layne via Cygwin wrote: [...] If it isn't true then this seems trivial to fix. This assertion is trivially disproven by the lack of a patch attached. :) I don't think this is worth a gold star, but a jester's cap is surely warranted :) Csaba -- Life is complex, with real and imaginary parts. -- 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: Suggestion: [setup] Add an option to allow user to add "Open Cygwin Terminal Here" to Right-click menu
On 14/02/2024 21:00, Brian Inglis via Cygwin wrote: Surely you mean (-v displays confirmation): Don't call me Shirley :) Csaba -- Life is complex, with real and imaginary parts. -- 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: MULTIPLE VULNERABILITY REPORT: Multiple DLL Hijacking Vulnerability in CygWin setup-x86_64.exe
On 06/02/2024 23:10, Kaz Kylheku via Cygwin wrote: On 2024-02-04 21:22, Suman Chakraborty via Cygwin wrote: 1. Executive Summary: The vulnerability pertains to not finding the profapi.dll, CFGMGR32.dll, edputil.dll, urlmon.dll, SspiCli.dll, Wldp.dll, MPR.dll, ServicingCommon.dll, TextShaping.dll, CRYPTBASE.DLL, PROPSYS.dll and insecure loading of dynamic link libraries (DLLs), specifically profapi.dll. If exploited, this vulnerability could allow an attacker to execute arbitrary code on a victim's machine, potentially leading to data breaches, system compromise, and other malicious activities. By what means is setup.exe probing these DLLs? I don't see any references to profapi.dll in its source tree (git grep -i profapi turns up nothing). According to Dependecy Walker, profapi.dll is a dependency of userenv.dll, which in turn is a dependency of sechost.dll, which in turn is a dependency of advapi32.dll I don't think setup-x86_64.exe has any say in how these dependencies are loaded. Csaba -- Life is complex, with real and imaginary parts. -- 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: Linking a native msvc dll library to CYGWIN g++ compiler
On 11/07/2023 08:47, Mümin A. via Cygwin wrote: Hi, I'm facing a problem while linking my native dll library into the g++ compiler. There is a name mangling problem when calling a msvc function from g++ compiler therefore linker gives an error undefined reference. Is there any method to directly link and call a function from native dll library from the cygwin compiler ? For example, I've a fooCls.h header file for a windows library, I add link the fooCls.dll to g++ compiler then, fooNameSpace::fooConnectionCls instance; instance.FooTest(); gives a linker error , undefined reference. Hi, GCC (and most compilers on Unix-like systems, even macOS) use the Itanium (IA64) ABI for C++ mangling: https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling MSVC uses a different scheme, so the name of the symbol (as seen by the linker) expected by the object file compiled by GCC is different from the symbol supplied by the object file compiled with MSVC. To link object files from GCC and MSVC together, you need to use C linkage (extern "C"). Csaba -- Life is complex, with real and imaginary parts. -- 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: Symbol visibility problems with -std=
On 13/05/2020 14:12, Marco Atzeri via Cygwin wrote: Am 13.05.2020 um 12:21 schrieb Pavel Fedin via Cygwin: (snip code using strdup) $ g++ test.cpp -o test - compiles OK $ g++ test.cpp -o test -std=c++14 - error: 'strdup' was not declared in this scope; did you mean 'strcmp'? strdup is an extension of C standard so strictly behaviour of Cgywin is correct, see /usr/include/sys/features.h for details Pavel, you may want to try -std=gnu++14 instead. 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: What is wrong with the name excel?
Hi Gerlach, On 17/04/2020 13:10, Gerlach van Beinum via Cygwin wrote: I made a program to read a csv file from Excel. I called it excel.c and it made an executable excel.exe If irun that executable with: ./excel.exe nothing happens, i.i. no output. Try running it under gdb. You should get a better description than "no output". If I rename it to a.exe it runs OK. What about this name excel?? It's used by a fairly popular application published by a legacy software vendor headquartered in Redmond, Washington. My Cygwin version is up-to-date. I believe it when I see it (the output of cygcheck -s -r -v, attached to the email). 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: Can I find where cygwin is installed (for automation purposes)
Hi Paul, On 15/04/2020 12:29, Paul Moore via Cygwin wrote: I'm trying to write an automation script that works on a number of machines. I know that on all machines Cygwin will be installed, but I cannot guarantee that (1) it will be in the same location on each PC, or (2) that it will be in PATH. There's HKCU\Software\Cygwin\Installations, but that seems to use \?? prefixes on the PATH, which I'm not sure how to interpret ... On my machine, I have a HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup key, which contains a string value named "rootdir" with the date "C:\cygwin64". 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: Missing new.h and broken comdef.h in cygwin32-w32api-headers (and the mingw header packages too)
On 07/04/2020 15:29, Hans de Ruiter via Cygwin wrote: Hi Hans, I've been trying to compile something that uses comutil.h, which in turn includes comip.h and comdef.h (amongst others). First, I get a missing header error: /usr/include/w32api/comip.h:21:10: fatal error: new.h: No such file or directory So, I copy new.h from the mingw headers (I'm using the cygwin compiler *not* mingw). Then, I get the following: Why do you think the mingw headers would work with Cygwin's compiler? From an API point of view, Cygwin is a POSIX system. If your software includes comutil.h/compip.h/comdep.h, that's a Windows application. You need a compiler which understands the Windows API and creates native Windows applications. Cygwin's GCC isn't such a compiler. You need either a Mingw compiler, or Cygwin's cross compiler (mingw64-i686-gcc-g++-9.2.0-2 ) 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: segfault on 32bit
On 07/04/2020 19:33, Marco Atzeri via Cygwin wrote: while trying to build the 32bit version on python, I hit this never seen before issue: checking for %zd printf() format support... make: *** No targets specified and no makefile found. Stop. *** ERROR: make failed 4 [main] sh 18479 D:\cygwin32\bin\sh.exe: *** fatal error in forked process - WFSO timed out after longjmp 4 [main] sh 18479 D:\cygwin32\bin\sh.exe: *** fatal error in forked proces s - WFSO timed out after longjmp 72365 [main] sh 18479 cygwin_exception::open_stackdumpfile: Dumping stack trac e to sh.exe.stackdump 72365 [main] sh 18479 cygwin_exception::open_stackdumpfile: Dumping stack trac e to sh.exe.stackdump $ uname -svr CYGWIN_NT-10.0-WOW 3.1.4(0.340/5/3) 2020-02-19 08:45 what is a WFSO ? WaitForSingleObject, presumably. 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
