Re: Sv: Sv: g++ and c++17 filesystem

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

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.]