Comments (17)
so, libstdc++ thread support without libwinpthread
is now in gcc-master!
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9149a5b7e0a66b7b94d5b7db3194a975d18dea2f
this means we will get libstdc++ thread support without libwinpthread
support in gcc-13!
from mingw-builds.
published: 15add2a
will merge it later.
from mingw-builds.
Yes. If you decided to apply the patch unconditionally, it'd be fine anyway because I could manually revert it if necessary. It's just that I would provide an option if I were you.
got it. I'll add the option.
What's your plan? Are you planning to release GCC 13 binaries with the patch and expecting it to be merged to GCC 14 or 15?
correct.
Or are you going to release GCC 12.2.0 binaries with the patch backported
no, let's leave 12.2.0 as is.
I will do it today or tomorrow.
thanks for your thoughts!
from mingw-builds.
My hands are shaking. I feel like a little child. Thousands of chickens were sacrificed to please the dark gods. Now we have one abstraction layer less, the programs will be smaller and faster.
Even grass is greener! Twenty years ago we had snow in the end of September, now we have it in the end of November!
Though, one question remains, niXman, you compiled with --threads=win32
, while LH proposes to compile it with --threads=mcf
. What is the difference between the two?
Why did you provide libwinpthread-1.dll
, while it's no longer required to build with std::thread
?
Does Fortran work? You built the toolchain with --enable-languages=c,c++,lto
, so, I can't test it.
g++.exe
and x86_64-w64-mingw32-g++.exe
are the same. Why do you not prefer symlinks? 7z preserves them. From here:
Starting with Windows 10 Insiders build 14972, symlinks can be created without needing to elevate the console as administrator.
from mingw-builds.
My hands are shaking. I feel like a little child. Thousands of chickens were sacrificed to please the dark gods. Now we have one abstraction layer less, the programs will be smaller and faster.
=)
Twenty years ago we had snow in the end of September, now we have it in the end of November!
I don't want snow in September, too early =)
Though, one question remains, niXman, you compiled with --threads=win32, while LH proposes to compile it with --threads=mcf. What is the difference between the two?
because LH proposed to replace winpthreads with mcfthreads and his proposal was not supported because it does not fix an existing problem, but is the same additional abstraction layer as winpthreads.
Why did you provide libwinpthread-1.dll, while it's no longer required to build with std::thread?
because of libgomp.dll
, it requires pthreads API.
Does Fortran work? You built the toolchain with --enable-languages=c,c++,lto, so, I can't test it.
hmm... I don't know, I din't try to build with fortran for now.
g++.exe and x86_64-w64-mingw32-g++.exe are the same. Why do you not prefer symlinks? 7z preserves them.
because locally im still using Win7 =)
from mingw-builds.
Win32 native std::thread
implementation is a long-awaited feature. Until that patch gets merged to GCC trunk, I would preserve the old win32 threading as-is, and would introduce a new threading model for this patch:
--threads=win32
: win32 without the patch--threads=win32-eric
: win32 with the patch
from mingw-builds.
Until that patch gets merged to GCC trunk
it will not be merged until it be tested, but no one reported back about any success/fail cases...
I think the only way to get any reports back is to deploy that patch as the current win32-threads builds and to wait for the reports =)
from mingw-builds.
I see. In that case, I would add an option (which is enabled by default) to apply the patch.
Actually, I prefer MCF threading over this patch, but MCF isn't without its problems.
from mingw-builds.
In that case, I would add an option (which is enabled by default) to apply the patch.
then for what that option needed if it will be enabled by default?
from mingw-builds.
I mean I still want a way to disable the patch.
from mingw-builds.
then it never be tested and accepted in GCC...
up
got it!
for some reason you need the ability to build without the patch?
from mingw-builds.
for some reason you need the ability to build without the patch?
Yes. If you decided to apply the patch unconditionally, it'd be fine anyway because I could manually revert it if necessary. It's just that I would provide an option if I were you.
What's your plan? Are you planning to release GCC 13 binaries with the patch and expecting it to be merged to GCC 14 or 15? Or are you going to release GCC 12.2.0 binaries with the patch backported and hoping it gets merged to GCC 13?
from mingw-builds.
from mingw-builds.
@starg2 well, how should we deal with --win32-threads-without-threads
option?
just to remove its use from gcc-13 and later?: https://github.com/niXman/mingw-builds/blob/develop/scripts/gcc-trunk.sh#L62
or we will use it for conditional use of --enable-libstdcxx-threads=yes
? : https://github.com/niXman/mingw-builds/blob/develop/scripts/gcc-trunk.sh#L97
from mingw-builds.
Now win32 native threading is fully supported by upstream, I think we can simply remove --win32-threads-without-threads
option entirely.
(BTW I didn't expect the patch to be merged so quickly.)
from mingw-builds.
we can simply remove --win32-threads-without-threads option entirely.
great, I will do it.
(BTW I didn't expect the patch to be merged so quickly.)
me too, but this is great news!
from mingw-builds.
done: 9e8a849
from mingw-builds.
Related Issues (20)
- No gdb tui? HOT 4
- Invoking gcc via symlink does not work HOT 19
- Toolchain updates are breaking build versions that were built normally HOT 3
- Could not build sjlj posix ucrt mingw-builds from the develop branch ! HOT 33
- Fetching sources fails HOT 12
- Building with --mode=gcc-12.2.0 fails
- configure: error: cannot find output from flex; giving up HOT 1
- any way to chnage 'msvcrt' to 'ucrt' using script? HOT 3
- `ld` does not work with non-ASCII file path HOT 6
- Please update GNU Make to 4.4.1
- Building a toolchain for Windows 2000? HOT 4
- Do you have any interest in the mcf thread model? HOT 7
- Not found level for patch HOT 1
- localization of GCC HOT 28
- C preprocessor "/lib/cpp" fails sanity check HOT 3
- not all compiling message in native language
- Update expat to 2.6.2 HOT 1
- GitHub took down xz-utils HOT 1
- Build with posix threads depends on libwinpthread-1.dll HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mingw-builds.