X-Recipient: archive-cygwin AT delorie DOT com X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 14F11393BC27 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian DOT inglis AT systematicsw DOT ab DOT ca X-Authority-Analysis: v=2.4 cv=Q4RsX66a c=1 sm=1 tr=0 ts=5fb7e0df a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=uZvujYp8AAAA:8 a=8pif782wAAAA:8 a=yBR9Qs6oAAAA:8 a=MU4eybcMYzc-gjLx57oA:9 a=QEXdDO2ut3YA:10 a=SLzB8X_8jTLwj6mN0q5r:22 a=7C5qix1daMSKwVux_nGC:22 From: Brian Inglis Subject: Re: Sv: Sv: g++ and c++17 filesystem To: cygwin AT cygwin DOT com References:

<000a01d6be5b$3808cad0$a81a6070$@gmail.com> <15d2b3e5-cbb8-0008-e99a-3922ff4a5f3b AT SystematicSw DOT ab DOT ca> <000801d6bf20$d0ce0670$726a1350$@gmail.com> Organization: Systematic Software Message-ID: Date: Fri, 20 Nov 2020 08:29:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <000801d6bf20$d0ce0670$726a1350$@gmail.com> Content-Language: en-CA X-CMAE-Envelope: MS4xfLofjt9VUM1TKvbD0rkPDoh4166z9RAarrxuF86dsD/uOFyBQQKT4gFayCpuAGia3DuBPhBulXztqFJ7fyTjAEAd8cl0YeA6Xz/8qzhV4NwAZ0DfxT3z ngNt8bKnNZvAZJWUYZcaFxX/HFP+k6Z07DFWUBnxEvfQBMNMAHjrYaLjFnILMyPY44fCZ8s1fM0iBAQ0CGPrGgLVYnJbmHvpWwI= X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: cygwin AT cygwin DOT com Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: cygwin-bounces AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 0AKFU8hk027518 On 2020-11-20 02:37, Kristian Ivarsson via Cygwin wrote: > [snip] >>>> As stated earlier, it seems like using mingw g++/libstdc++ (from the >>>> cygwin-package-manager) it seems like it works better, but then you >>>> can’t mix with other posix/cygwin mechanism (that uses cygstdc++) >>>> without breaking ODR (and probably some memory models etc as well) so >>>> maybe someone do have some insightful info about this ? How “special” >>>> is cygstdc++ (compared to mingw:s libstdc++) ? Could this be fixable >>>> in cygstdc++ that library (cygstdc++)? >>> I might be totally wrong, so does anyone have any take on this ? >> >> Cygwin provides cross-tools like djgpp-gcc-core mingw64-i686-gcc-core, >> mingw64-x86_64-gcc-core, cygwin32-gcc-core, cygwin64-gcc-core, and djgpp- >> binutils, mingw64-i686-binutils, mingw64-x86_64-binutils, cygwin32- >> binutils, cygwin64-binutils so anyone has the freedom to choose to build >> DOS, Windows, or Cygwin apps targeting their respective APIs, under >> Cygwin, and also have the freedom to give away or sell those apps as long >> as they respect their licences. >> >> Cygwin's goal is to have everyone and everything believe it is running in >> a POSIX environment and provide interoperability within a Windows >> environment (including Wine) based on POSIX standards, system interfaces, >> toolchains, shells, utilities: >> >> https://pubs.opengroup.org/onlinepubs/9699919799/ >> >> system and network servers and services, plus GUI desktops (GNOME, KDE, >> LXDE, MATE, Plasma, Xfce desktops on X Window System), and apps (task and >> file managers, web browsers, PDF viewers and editors, graphics viewers and >> editors including GIMP). This is all ported and supported by volunteers >> who believe everyone should have a choice, even when for business or >> family reasons they use Windows. > I think The Cygwin-community is doing a great job but with some caveats, such as this > > We're in need of various posix-libraries and I guess they won't be available > if using the mingw-g++/libstdc++ (I guess cygstdc++ is needed then due to > some special memory models etc etc etc)? Unlikely - the (cross) tools handle the memory model differences. There are 400 mingw64 cross-development library and tool packages available for *each* architecture under Cygwin? > I can for sure try it out, but that would be quite cumbersome because the > and I guess it'll be a whole lot of hazzle to make it working > I'd rather help out or having a dialog of how to fix std::filesystem, i.e. > change the usage of the __CYGWIN__ macro in that implementation, but this > seems to be a part of the "real" GCC-distribution o I guess I need to be > involved in that open-source-community instead, but I guess it somehow is > invoked from this project somehow so I guess some people here do have some > real insights about this ? > The whole C/C++ community is striving for total cross-platform libraries (but > I guess we have a few years left for that) and std::filesystem was supposed > to take us all in that direction and I totally understand that > std::filesystem-library in Cygwin do think it is on a posix-filesystem (though > it's not) and I totally understand why the behaviour is as it is, but I don't > agree that is a good thing, considering that the underlaying > posix-implementation already today accepts Windows:ish-like-paths in some > circumstances, I'd like the whole package to be even more agnostic because most > applications don't have any wish to inspect the content of a path-object no more > than the value of a socket-descriptor > > Applications might wanna extract type, name, parent-folder, etc but do rarely > care about what kind of separator it has (/ or \) and the style of the root > directory etc and it would be very neat if the cygwin std::filesystem-library > became more agnostic in these regards Not a goal of this project, which is to provide Unix look/feel at all levels. Other projects have the goals of being cross-platform toolkits which you can use to work and/or look native and hide all differences; see: https://en.wikipedia.org/wiki/Cross-platform_software#Cross-platform_programming_toolkits_and_environments Which cross-development libraries/tools are you missing from the 400 mingw64 cross-development library and tool packages available for each architecture under Cygwin? You could probably use cygport to easily build any for mingw that are not yet available in the distro. You could also do all this on any Linux distro that offers Wine, and natively under some (especially Fedora/CentOS/EPEL/RHEL) that offer mingw packages, and even use cygport to do the builds: https://repology.org/projects/?search=mingw where one of those distros shown is Cygwin. -- 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 binary 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