From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) by sourceware.org (Postfix) with ESMTPS id 335D6386F81D for ; Fri, 20 Nov 2020 09:37:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 335D6386F81D Received: by mail-lj1-x22b.google.com with SMTP id h23so9334086ljg.13 for ; Fri, 20 Nov 2020 01:37:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=MvIKNAaG3TU9/yHZImR6fk9xwjTnt0B0ZrpwTk3mxr0=; b=uULiuuGJtt/iYVcc9KXHkfRefUUbRZXVpWMcfBXAJuGivvq8rGt5DKAAIHnFNDQaqV sQzlsWFypGw6PeGyaauUiZSF7ZRxreNAI9TglcceWDpLAHWteRd+0klP8OrC3fWlIoVi 6aJFQL7KGD3BSspYkN36P+ervb9SMomVH2Kl2KTF6Eio1UhEk5b93c6R0irZ5Ko2g4rd TWH92q/AuJf8Qydr/5c6L5yliidTijBbFnZMpt1FaXdmr3UyLz3i/WY2EpNs47dCmmK2 ApAflW9e+E3DQNAyds3WNtUvA1y2Bk5xvWHmdVruExNV48kgG8U7fz3H92ZHEJzr5oET badw== X-Gm-Message-State: AOAM533rbtXrxQh8ZZqmQ8xoRWTXlmKJt9aYY3tMUtGDRI+KHqWCadSj hwIwMwo2xvftPt6afs4/yR5TCMnJ/hs= X-Google-Smtp-Source: ABdhPJxAdwqMYpcPye9BSCoNVvs9ifdsNukTK9Dl9Inultzpfv8X9mA4xOlJlZVshQx3mCpz3gTv1g== X-Received: by 2002:a2e:b536:: with SMTP id z22mr7804983ljm.177.1605865072525; Fri, 20 Nov 2020 01:37:52 -0800 (PST) Received: from JOKK (87-249-176-245.ljusnet.se. [87.249.176.245]) by smtp.gmail.com with ESMTPSA id r20sm230455ljk.97.2020.11.20.01.37.51 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2020 01:37:51 -0800 (PST) From: To: References: <000a01d6be5b$3808cad0$a81a6070$@gmail.com> <15d2b3e5-cbb8-0008-e99a-3922ff4a5f3b@SystematicSw.ab.ca> In-Reply-To: <15d2b3e5-cbb8-0008-e99a-3922ff4a5f3b@SystematicSw.ab.ca> Subject: Sv: Sv: g++ and c++17 filesystem Date: Fri, 20 Nov 2020 10:37:51 +0100 Message-ID: <000801d6bf20$d0ce0670$726a1350$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIMEcHDzo+EBBrhHHj3sFlr53GwtQIBqNbVAy9h9QUBKn/4X6kzNpzQ X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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@cygwin.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: , X-List-Received-Date: Fri, 20 Nov 2020 09:37:56 -0000 [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=E2=80=99t 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 = =E2=80=9Cspecial=E2=80=9D > >> 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 ? >=20 > 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. >=20 > 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: >=20 > https://pubs.opengroup.org/onlinepubs/9699919799/ >=20 > 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. Tnx Brian 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) ? 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 Best regards, Kristian > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada >=20 > 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