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
Re: [BUG] try..catch does not work if compiled with clang 8.0
On 17/12/2019 17:29, Brian Inglis wrote:
On 2019-12-17 02:35, Pavel Fedin wrote:
I haven't upgraded for a while and today i finally decided to do so. After
rebuilding by project with clang++ 8.0 i found out that try...catch construct
doesn't work. The program just gets silently aborted.
Switched back to old clang++ 5.0 and it works.
Also an old bug which i reported some (a while) time ago persists: uncaught
throw does not print anything.
OS is Windows 10 x86/64.
It is unlikely that try/catch does not work in the general case for clang++8,
and your post has insufficient information to reproduce the problem.
a.k.a. https://www.chiark.greenend.org.uk/~sgtatham/bugs.html#respect
WJFFM
$ cat catcher.cpp
#include
#include
int pitcher()
{
throw std::runtime_error{"Ouch"};
}
int main()
{
try {
return pitcher();
}
catch (std::exception const) {
std::cout << "Caught a " << typeid(e).name() << " - " << e.what()
<< '\n';
return 42;
}
}
$ g++ -v -Wall -Wpedantic -Wextra -g catcher.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-8.3.0-1.x86_64/src/gcc-8.3.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-8.3.0-1.x86_64/src/gcc-8.3.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --enable-libitm
--enable-libquadmath --enable-libquadmath-support --disable-libssp
--enable-libada --disable-symvers --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
--with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts
Thread model: posix
gcc version 8.3.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wpedantic' '-Wextra' '-g' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/cc1plus.exe -quiet -v -idirafter
/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../lib/../include/w32api -idirafter
/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api
catcher.cpp -quiet -dumpbase catcher.cpp -mtune=generic -march=x86-64 -auxbase
catcher -g -Wall -Wpedantic -Wextra -version -o /tmp/cczG1NcE.s
GNU C++14 (GCC) version 8.3.0 (x86_64-pc-cygwin)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/include"
ignoring duplicate directory
"/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/include/c++
/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/include/c++/x86_64-pc-cygwin
/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/include/c++/backward
/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/include
/usr/local/include
/usr/include
/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../lib/../include/w32api
End of search list.
GNU C++14 (GCC) version 8.3.0 (x86_64-pc-cygwin)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: bed998889edfd32f5c9a3f3c8baa420d
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wpedantic' '-Wextra' '-g' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/bin/as.exe -v
-o /tmp/ccCNGYho.o /tmp/cczG1NcE.s
GNU assembler version 2.29.1 (x86_64-pc-cygwin) using BFD version (GNU Binutils)
2.29.1.20171006
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/:/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/:/usr/lib/gcc/x86_64-pc-cygwin/:/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/:/usr/lib/gcc/x86_64-pc-cygwin/:/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/bin/
Re: How to install gcc and g++ 6 on cygwin which are not on the setup.exe
Hi José, On 16/05/2019 18:47, Jose Isaias Cabrera wrote: Csaba Raduly, on Thursday, May 16, 2019 03:36 AM, wrote... > >Hi José, >Another option is to download the source and build it yourself. Yep. Going with this option. Seems the most logical one for now. After running ./configure, got this error, configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+. So, now I am building GMP, then MPFR and then MPC. It's going to be a lot of work, so... :-) :Let's hope is worth it. Thanks for your help. Building GMP, MPFR and MPC seems like overkill. The following packages are available for Cygwin: libgmp-devel 6.1.2 libmpfr-devel 4.0.2 libmpc-devel 1.1.0 BTW, if you're trying to build Bedrockdb, G++ 6 is likely unable to help you. The Bedrockdb developers seem to suffer a bit from "all the world is Linux" syndrome. 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: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Building Bedrockdb in cygwin
On 14/05/2019 19:11, Jose Isaias Cabrera wrote: (snip) However, having jumped that huddle, I encountered a new one, which is probably easier to deal with. The make command does a lot of work, but once it's going to start compiling, I get, [good stuff clipped] CCutil/pem2der.c CCutil/strerror.c CCx509/cert_app.c CCx509/crl_app.c CCx509/cert_req.c CCx509/cert_write.c CCx509/req_app.c make[2]: Leaving directory '/home/e608313/Bedrock/mbedtls/programs' make[1]: Leaving directory '/home/e608313/Bedrock/mbedtls' g++-6 -g -std=c++14 -fpic -O2 -Wall -Werror -Wformat-security -DGIT_REVISION=ce62c88 -I/home/e608313/Bedrock -I/home/e608313/Bedrock/mbedtls/include -MMD -MF libstuff/libstuff.d -MT libstuff/libstuff.h.gch -c libstuff/libstuff.h make: g++-6: Command not found make: *** No rule to make target 'libstuff/libstuff.d', needed by '.build/libstuff/libstuff.d'. Stop. So, it appears that I need something called g++-6. I have both gcc and g++ $ ls /usr/bin/g++* /usr/bin/g++.exe* So, the question is, what is g++-6, and how to I get it? I tried to find it with cygwin's setup, but it's not on the distro. I tried to duckduckgo it, but I didn't get anything useful. Thoughts? Thanks g++-6 is version 6 of the C++ compiler in the GNU Compiler Collection. Cygwin's gcc and g++ is version 7.4.0: $ g++.exe -dumpversion 7.4.0 Bedrockdb's makefile begins with: # Set the compiler, if it's not set by the environment. ifndef GXX GXX = g++-6 endif ifndef CC CC = gcc-6 endif so the C++ compiler (GXX) is set to g++-6 unless GXX is set explicitly. You need to run make like this: CC=gcc GXX=g++ make This will force make to use g++ instead of g++-6 Hope this helps, 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: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: libxml2 2.9.9-2
On 26/03/2019 05:08, Marvin Eisenberg wrote: Please remove me from mailing list ... Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^^^ Hope this helps, 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: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: antrun versus wsl versus cygwin
On 17/02/2019 12:11, Franz Fehringer wrote: Hi all (half off topic), I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only the Windows component, no real Linux distribution yet). This scenario gives me a strange problem with antrun: With i always get the WSL bash instead of the Cygwin one, although Cygwin is first in PATH (both Cygwin PATH and Windows PATH), even so if C:/Windows/System32 (location of WSL bash) is not in the (Cygwin) PATH at all. Is this a Cygwin ant or a Windows ant ? 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: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: problem building with cmake under cygwin (need clang)
On 16-07-26 06:52 PM, LMH wrote: Thanks you for the clarification. I implemented your steps, $ ls src/ CMakeLists.txt include README.md src test $ mkdir build $ cd build/ $ cmake -DCMAKE_CXX_COMPILER=clang ../src Stop doing that---^^ CMakeLists.txt is in the root of the project. Point cmake to it, like this: $ cmake -DCMAKE_CXX_COMPILER=clang++ .. I get the following output, which is the same error output I was getting before. It is different then the errors you are specifying. -- The C compiler identification is GNU 4.9.3 -- The CXX compiler identification is unknown (snip) It looks like it is still using gnu for the compiler and not clang. There are two different compilers cmake knows about: the C compiler (CMAKE_C_COMPILER) and the C++ compiler (CMAKE_CXX_COMPILER). You only set the C++ compiler; cmake is using its default for the C compiler. For quickhull, CMAKE_C_COMPILER probably doesn't matter. > It looks like it can't identify the c++ compiler at all. I tried this, cmake -DCMAKE_CXX_COMPILER=clang++ ../src For clang, it makes no difference (clang++ is usually a symlink to clang). because I think that CXX is the c++ compiler, but this doesn't make any difference. I have attached the cmake error and output logs in case that is useful. It just looks like there is something missing or misconfigured in my installation. The which clang and which clang++ commands return the expected values. If cmake isn't able to build a test app, then there is something wrong at that end I think. This is what cmake tried: Run Build Command:"/usr/bin/make.exe" "cmTC_29d2e/fast" /usr/bin/make -f CMakeFiles/cmTC_29d2e.dir/build.make CMakeFiles/cmTC_29d2e.dir/build make[1]: Entering directory '/cygdrive/g/shared_data/SMD/ATomilov_quickhull/build/CMakeFiles/CMakeTmp' Building CXX object CMakeFiles/cmTC_29d2e.dir/testCXXCompiler.cxx.o /usr/bin/clang++ -o CMakeFiles/cmTC_29d2e.dir/testCXXCompiler.cxx.o -c /cygdrive/g/shared_data/SMD/ATomilov_quickhull/build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx CMakeFiles/cmTC_29d2e.dir/build.make:65: recipe for target 'CMakeFiles/cmTC_29d2e.dir/testCXXCompiler.cxx.o' failed make[1]: Leaving directory '/cygdrive/g/shared_data/SMD/ATomilov_quickhull/build/CMakeFiles/CMakeTmp' Makefile:126: recipe for target 'cmTC_29d2e/fast' failed make[1]: *** [CMakeFiles/cmTC_29d2e.dir/testCXXCompiler.cxx.o] Error 127 make: *** [cmTC_29d2e/fast] Error 2 Try to run those commands manually: $ cd '/cygdrive/g/shared_data/SMD/ATomilov_quickhull/build/CMakeFiles/CMakeTmp' $ /usr/bin/clang++ -o CMakeFiles/cmTC_29d2e.dir/testCXXCompiler.cxx.o -c /cygdrive/g/shared_data/SMD/ATomilov_quickhull/build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx What is the output? Csaba -- Life is complex, with real and imaginary parts. The Tao of math: The numbers you can count are not the real numbers. -- 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
