Re: llvm/clang packages
On Sun, 13 Apr 2025, Takashi Yano via Cygwin-apps wrote: > > Yes. However, see my previous mail for the strange issue I ran into > > trying to do this (strange because it works fine on MSYS2 but fails on > > Cygwin) > > The same happens for me as well... Maybe you'll have some luck debugging it. I really don't use Cygwin (the software distribution), but rather MSYS2 (and indirectly Cygwin the DLL as msys2-runtime). The fact that this doesn't happen on MSYS2 is very strange and probably a good start to trying to narrow it down.
Re: llvm/clang packages
On Sat, 12 Apr 2025, Jeremy Drake via Cygwin-apps wrote: > On Sun, 13 Apr 2025, Takashi Yano via Cygwin-apps wrote: > > > > Yes. However, see my previous mail for the strange issue I ran into > > > trying to do this (strange because it works fine on MSYS2 but fails on > > > Cygwin) > > > > The same happens for me as well... > > Maybe you'll have some luck debugging it. I really don't use Cygwin (the > software distribution), but rather MSYS2 (and indirectly Cygwin the DLL as > msys2-runtime). The fact that this doesn't happen on MSYS2 is very > strange and probably a good start to trying to narrow it down. OK, here's my theory: #12 0x7ffda3510f9a in free ( p=0x100557010 , std::allocator >::_Rep::_S_empty_rep_storage>) p is in the address space of the exe (0x0001004e210e) , not cygstdc++-6 (0x0003fb09c960). So it seems that it inlined the _S_empty_rep_storage[] when it shouldn't have. Looking at /usr/lib/gcc/13.3.0/include/c++/bits/basic_string.tcc (on MSYS2): // Inhibit implicit instantiations for required instantiations, // which are defined via explicit instantiations elsewhere. #if _GLIBCXX_EXTERN_TEMPLATE // The explicit instantiation definitions in src/c++11/string-inst.cc and // src/c++17/string-inst.cc only instantiate the members required for C++17 // and earlier standards (so not C++20's starts_with and ends_with). // Suppress the explicit instantiation declarations for C++20, so C++20 // code will implicitly instantiate std::string and std::wstring as needed. # if __cplusplus <= 201703L && _GLIBCXX_EXTERN_TEMPLATE > 0 extern template class basic_string; # elif ! _GLIBCXX_USE_CXX11_ABI // Still need to prevent implicit instantiation of the COW empty rep, // to ensure the definition in libstdc++.so is unique (PR 86138). extern template basic_string::size_type basic_string::_Rep::_S_empty_rep_storage[]; # elif _GLIBCXX_EXTERN_TEMPLATE > 0 // Export _M_replace_cold even for C++20. extern template void basic_string::_M_replace_cold(char *, size_type, const char*, const size_type, const size_type); # endif You could check what some of these defines are on Cygwin, but I'm guessing https://cygwin.com/cgit/cygwin-packages/gcc/tree/gcc.cygport?h=main&id=3b18f0b66c716fd70492f55ebebd5680a611739c#n171 (--with-default-libstdcxx-abi=gcc4-compatible). MSYS2 does not do this, it's small enough that we can plausibly rebuild every MSYS2-packages package that links against msys-stdc++-6.dll for an ABI break. Cygwin doesn't have that luxury, since it could be that 3rd parties are shipping Cygwin binaries.
Re: Test: libcares-devel/2 1.34.5 (TEST) - Curl Asynchronous RESolver library
Hi folks, This package underlies most of the Cygwin downloaders I am aware of and maintain, and also a lot of other async or parallel network packages, including cygport, git, TeXlive, and other doc packages. This large version jump with no .so version/ABI/DLL change and *without Google gmock/gtest test suite* carries a lot of risks: Version Arch Size Date Status Files 1.16.1-1 src 1343 KiB 2024-11-10 16:51 stable https://cygwin.com/packages/x86_64/c-ares-src/c-ares-1.16.1-1-src 1.34.5-0 src 992 KiB 2025-04-12 18:07 test https://cygwin.com/packages/x86_64/c-ares-src/c-ares-1.34.5-0-src A full set of release notes has been included in the announcement (copied below) due to the many versions skipped, and the many packages impacted: $ cygcheck-dep -qN libcares2 libcares2: is recursively needed for ( aria2 asciidoc biber cygcheck-dep cygport dblatex djvulibre docbook-utils geoipupdate gnome-common gtk-doc html2ps libcares-devel nghttp2 preview-latex pwget texinfo-tex texlive-collection-basic texlive-collection-bibtexextra texlive-collection-binextra texlive-collection-fontsextra texlive-collection-fontsrecommended texlive-collection-fontutils texlive-collection-formatsextra texlive-collection-htmlxml texlive-collection-latex texlive-collection-latexextra texlive-collection-latexrecommended texlive-collection-mathscience texlive-collection-pictures texlive-collection-plaingeneric texlive-collection-xetex wget xhtml2ps xmlto ) Please try to make time to rebuild affected packages and rerun their test suites with the test -devel and DLL packages installed. If for any reason anyone wants to rebuild c-ares from src, it requires Takashi's latest patch to sys/unistd.h, which stops me from building yet on Scallywag CI until that is promoted in a stable release! [CCed Jari as he may no longer be following the lists and pwget may be impacted] On 2025-04-12 15:01, Cygwin cares Maintainer via Cygwin-announce wrote: Curl Asynchronous RESolver library for applications which need to perform DNS queries without blocking, or need to perform multiple DNS queries in parallel. Primary applications are servers with multiple clients and GUI programs. For more information see the project home page: https://c-ares.org/ The following *TEST* packages have been released in the Cygwin distribution: - libcares-devel1.34.5 - libcares2 1.34.5 No build check is possible as Google gtest and gmock are required but not available for Cygwin. Please test these packages as extensively as possible (especially if you are a Cygwin package maintainer) as libcares is used in many libraries and utilities, including all network downloaders and their libraries: aria2c, curl, wget, wget2; and many TeXlive packages. Package maintainers should install this test release and rerun checks of as many libraries and packages depending on libcares as possible. I have it locally installed so it is getting used by commands, scripts, cron jobs, and cygport builds, and has and is getting frequent exercise with no apparent issues so far. If no issues are reported within a couple of weeks the package will be upgraded to current. As there are many versions since the previous Cygwin release, see below or: https://c-ares.org/changelog.html 08 Apr 2025 1.34.5 This is a security release. Security: - CVE-2025-31498. A use-after-free bug has been uncovered in read_answers() that was introduced in v1.32.3. Please see https://github.com/c-ares/c-ares/security/advisories/GHSA-6hxc-62jh-p29v Changes: - Restore Windows XP support. Bugfixes: - A missing mutex initialization would make busy polling for configuration changes (platforms other than Windows, Linux, MacOS) eat too much CPU - Pkgconfig may be generated wrong for static builds in relation to `-pthread` - Localhost resolution can fail if only one address family is in `/etc/hosts` 14 Dec 2024 1.34.4 This is a bugfix release. Changes: - QNX Port: Port to QNX 8, add primary config reading support, add CI build. Bugfixes: - Empty TXT records were not being preserved. - docs: update deprecation notices for `ares_create_query()` and `ares_mkquery()`. - license: some files weren't properly updated. - Fix bind local device regression from 1.34.0. - CMake: set policy version to prevent deprecation warnings. - CMake: shared and static library names should be the same on unix platforms like autotools uses. - Update to latest autoconf archive macros for enhanced system compatibility. 09 Nov 2024 1.34.3 This is a bugfix release. Changes: - Build the release package in an automated way so we can provide provenance as per [SLSA3](https://slsa.dev/). Bugfixes: - Some upstream servers are non-compliant with EDNS options, resend queries without EDNS. - Android: <=7 needs sys/system_properties.h - Android: CMake needs `-D_GNU_SOURCE` and others. - TSAN warns on missing lock, but lock isn't ac
Re: llvm/clang packages
Takashi Yano via Cygwin-apps writes: > Now I am trying to build llvm for cygwin. For now, it fails with > ld: error: export ordinal too large: x > in dll linkage. > > If you could give me a suggestion, I would greatly appreciate it. That usually happens if the linker tries to export all symbols from the objects (which is the default if it doen't get told otherwise). Check to see if there's a linker script available and actually use that during the DLL creation. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: llvm/clang packages
On Sat, 12 Apr 2025 08:30:52 -0700 (PDT) Jeremy Drake wrote: > On Sat, 12 Apr 2025, Takashi Yano via Cygwin-apps wrote: > > > Thanks for the advice. I was trying to build DLL with gcc. > > Now I can successfully build llvm without DLL using gcc. > > > > Next step I am trying is building clang using gcc. It seems > > that clang is the same, I mean, DLL should be disabled in > > the first step using gcc. > > Yes. Also use -DLIBCLANG_BUILD_STATIC=ON > > > Then build clang again using clang built in the first > > step, right? > > Yes. However, see my previous mail for the strange issue I ran into > trying to do this (strange because it works fine on MSYS2 but fails on > Cygwin) The same happens for me as well... -- Takashi Yano
Re: llvm/clang packages
On Sat, 12 Apr 2025, Jeremy Drake via Cygwin-apps wrote: > On Sat, 12 Apr 2025, Jeremy Drake via Cygwin-apps wrote: > > > On Sun, 13 Apr 2025, Takashi Yano via Cygwin-apps wrote: > > > > > > Yes. However, see my previous mail for the strange issue I ran into > > > > trying to do this (strange because it works fine on MSYS2 but fails on > > > > Cygwin) > > > > > > The same happens for me as well... > > > > Maybe you'll have some luck debugging it. I really don't use Cygwin (the > > software distribution), but rather MSYS2 (and indirectly Cygwin the DLL as > > msys2-runtime). The fact that this doesn't happen on MSYS2 is very > > strange and probably a good start to trying to narrow it down. > > OK, here's my theory: > #12 0x7ffda3510f9a in free ( > p=0x100557010 , > std::allocator >::_Rep::_S_empty_rep_storage>) > > p is in the address space of the exe (0x0001004e210e) , not > cygstdc++-6 (0x0003fb09c960). So it seems that it inlined the > _S_empty_rep_storage[] when it shouldn't have. Looking at > /usr/lib/gcc/13.3.0/include/c++/bits/basic_string.tcc (on MSYS2): > > // Inhibit implicit instantiations for required instantiations, > // which are defined via explicit instantiations elsewhere. > #if _GLIBCXX_EXTERN_TEMPLATE > // The explicit instantiation definitions in src/c++11/string-inst.cc and > // src/c++17/string-inst.cc only instantiate the members required for C++17 > // and earlier standards (so not C++20's starts_with and ends_with). > // Suppress the explicit instantiation declarations for C++20, so C++20 > // code will implicitly instantiate std::string and std::wstring as needed. > # if __cplusplus <= 201703L && _GLIBCXX_EXTERN_TEMPLATE > 0 > extern template class basic_string; > # elif ! _GLIBCXX_USE_CXX11_ABI > // Still need to prevent implicit instantiation of the COW empty rep, > // to ensure the definition in libstdc++.so is unique (PR 86138). > extern template basic_string::size_type > basic_string::_Rep::_S_empty_rep_storage[]; > # elif _GLIBCXX_EXTERN_TEMPLATE > 0 > // Export _M_replace_cold even for C++20. > extern template void > basic_string::_M_replace_cold(char *, size_type, const char*, > const size_type, const size_type); > # endif > > > You could check what some of these defines are on Cygwin, but I'm guessing > https://cygwin.com/cgit/cygwin-packages/gcc/tree/gcc.cygport?h=main&id=3b18f0b66c716fd70492f55ebebd5680a611739c#n171 > (--with-default-libstdcxx-abi=gcc4-compatible). MSYS2 does not do this, > it's small enough that we can plausibly rebuild every MSYS2-packages > package that links against msys-stdc++-6.dll for an ABI break. Cygwin > doesn't have that luxury, since it could be that 3rd parties are shipping > Cygwin binaries. > # define _GLIBCXX_EXTERN_TEMPLATE 1 Below differs from MSYS2 #ifndef _GLIBCXX_USE_CXX11_ABI # define _GLIBCXX_USE_CXX11_ABI 0 #endif Maybe setting -DCMAKE_CXX_STANDARD=20 would work around this? It would at least take a different path in that if/elif block in basic_string. But I think we need to figure out why the extern template isn't working regardless.
Re: [ITP] stress-ng 0.18.04
Jeremy Drake via Cygwin-apps wrote: On Fri, 11 Apr 2025, Jon Turney via Cygwin-apps wrote: Many thanks. I posted the patches to incorporate this in our CI here: https://cygwin.com/pipermail/cygwin-patches/2025q2/013646.html I'm not crazy about using pskill, not least because because it's a bit awkward to get into place. Does taskkill /f not work? Of course it works, see related patch on cygwin-patches. For some unknown reason, I forgot about this tool. Thanks for the reminder. -- Thanks, Christian
Re: GCL and dependencies on cygwin
Greetings! I'm wondering if you had any thoughts on the best way to proceed outlined in my previous email. I am having trouble reproducing the build failure on my virtualbox Windows 10. The recently released gcl 2.7.1, inspired by this cygport effort, now supports out-of-source builds, so once the basics are clear I will clean up the cygport file. Take care, Jon Turney writes: > On 26/03/2025 11:25, Camm Maguire via Cygwin-apps wrote: >> Greetings, and thanks again so much! >> Alas the autobuild failed. I tested with a virtualbox running >> Windows >> 10 and what I believe is up to date stable cygwin and it succeeded. Two >> questions: >> 1) How can I ensure my test environment is as close as possible to >> the >> one on the autobuilder? (In Debian there are unstable chroots) > > In theory, it's just a Windows VM with a fresh cygwin installation in it. > >> 2) Can one ssh into the failing job for up to 6 hours to investigate? >> If so how does ssh need to be setup in the cygport file? (A GCL >> contributor pointed out this possibility on macports, which I think uses >> the same machinery.) > While this is is a technical possibility, we don't have any mechanism > for doing this at the moment. > > > Fortunately, this failure reproduces locally for me, so I could take a > little look (at first I thought this was broken by some problems in > the new 3.6.0 Cygwin DLL, but this doesn't seem to be the case). More > on that in a subsequent email. > > > I also have a few comments on your cygport file, so maybe you could > post it here for review. > > I am also confused why you didn't start with an empty repo (created by > 'git init'), rather than copying an existing one and removing all the > files (bringing it's unwanted and potentially confusing history with > it). > > > > -- Camm Maguirec...@maguirefamily.org == "The earth is but one country, and mankind its citizens." -- Baha'u'llah
Re: llvm/clang packages
On Fri, 11 Apr 2025 10:16:22 -0700 (PDT) Jeremy Drake wrote: > On Fri, 11 Apr 2025, Takashi Yano via Cygwin-apps wrote: > > > On Thu, 10 Apr 2025 12:45:06 -0700 (PDT) > > Jeremy Drake wrote: > > > We (@mati865 and I) just managed to get llvm/clang 20.1.2 building and > > > targeting Cygwin over at MSYS2, and I was wondering if you had anyone > > > interested in these patches to update the package(s) in Cygwin? I'm not > > > particularly interested in taking on more responsibilities, but I guess I > > > could take a look at this if nobody else wants to. > > > > > > MSYS2 package: > > > https://github.com/msys2/MSYS2-packages/tree/master/llvm > > > > > > Note that we wound up punting on LLD support for Cygwin targets: there's > > > currently no way to tell the difference in the LLD driver between Cygwin > > > and MinGW targets, and trying to adapt to Cygwin broke the ability to use > > > that LLD for MinGW cross-compiling. Given that it was all pretty hacky > > > anyway, it seemed better to keep the working MinGW cross-compiling support > > > than trade it in for still-somewhat-broken Cygwin support when we can just > > > keep using GNU ld for the Cygwin target. > > > > Amazing! > > > > Now I am trying to build llvm for cygwin. For now, it fails with > > ld: error: export ordinal too large: x > > in dll linkage. > > > > If you could give me a suggestion, I would greatly appreciate it. > > Are you using the patches and cmake options from > https://github.com/msys2/MSYS2-packages/tree/master/llvm ? > > I noticed one (0101-hack-dynamically-resolve-G-include-dir.patch) has an > "msys" that will need to be changed to "cygwin". > > The export ordinal too large error is because there are too many symbols > for export-all-symbols to export from the DLLs (the DLL export table uses > an unsigned short, so you only get 65535 exports). With GCC, it can only > build static libraries, see > https://github.com/msys2/MSYS2-packages/blob/4813abedafbbe1343ca287fded18b14f1f792198/llvm/PKGBUILD#L175-L189 > > Once you have clang built, you can use it to rebuild llvm with dynamic > libs. Clang has a workaround that hooks up ELF-style visibility "hidden" > to exclude symbols from auto-export, so there are not too many symbols for > a DLL. Thanks for the advice. I was trying to build DLL with gcc. Now I can successfully build llvm without DLL using gcc. Next step I am trying is building clang using gcc. It seems that clang is the same, I mean, DLL should be disabled in the first step using gcc. Then build clang again using clang built in the first step, right? -- Takashi Yano
Re: llvm/clang packages
On Sat, 12 Apr 2025, Takashi Yano via Cygwin-apps wrote: > Thanks for the advice. I was trying to build DLL with gcc. > Now I can successfully build llvm without DLL using gcc. > > Next step I am trying is building clang using gcc. It seems > that clang is the same, I mean, DLL should be disabled in > the first step using gcc. Yes. Also use -DLIBCLANG_BUILD_STATIC=ON > Then build clang again using clang built in the first > step, right? Yes. However, see my previous mail for the strange issue I ran into trying to do this (strange because it works fine on MSYS2 but fails on Cygwin)
