Get __gthread_getspecific errors even with single-threaded code unless -athread is set

[ksdhans]

I'm getting threading related linker errors when compiling code that is single threaded, unless I set -athread=single (or native). This is with existing code that compiled fine with previous GCC versions.

Yes, I could add -athread=single to the makefile. However, then the code won't compile with older versions of GCC. That's a big problem, since we're talking about example code that may even be built by someone using the GCC that comes with the SDK.

It would be very useful if compiling and linking worked even without the -athread parameter.

[ksdhans]

Oops! This is with GCC 8.1. Let me retest with the latest version.

[ksdhans]

Tested with the most recent adtools available here (from 2018/12/11 - 695): https://dl.bintray.com/sba1/adtools-native/

That one reports as GCC 8.1.0.

Incidentally, I'm compiling with the runtime library set as default, so no -mcrt option.

[kas1e]

@Hans Maybe that is problems with native builds from the bintray.com, but i build myself latest version from adtools on cygwin, and it definately shows 8.2.0 when i call "ppc-amigaos-gcc -v", see:

$ ppc-amigaos-gcc -v
Using built-in specs.
COLLECT_GCC=ppc-amigaos-gcc
COLLECT_LTO_WRAPPER=/usr/local/amiga/libexec/gcc/ppc-amigaos/8.2.0/lto-wrapper.exe
Target: ppc-amigaos
Configured with: /amiga/adtools/gcc/repo/configure --with-bugurl=https://github.com/sba1/adtools/issues --with-pkgversion='adtools build 8.2.0' --target=ppc-amigaos --prefix=/usr/local/amiga --enable-languages=c,c++,objc,obj-c++,fortran --enable-haifa --enable-sjlj-exceptions --disable-libstdcxx-pch --disable-tls --enable-threads=amigaos
Thread model: amigaos
gcc version 8.2.0 (adtools build 8.2.0)

But you are right anyway, at least -athread=single model should be as default , and when one need he can choice -athread=native , or -athread=posix/pthreads

[sba1]

Am 2019-02-07 10:04, schrieb kas1e:

@hans [1] Maybe that is problems with native builds from the bintray.com, but i build myself latest version from adtools on cygwin, and it definately shows 8.2.0 when i call "ppc-amigaos-gcc -v", see:

$ ppc-amigaos-gcc -v Using built-in specs. COLLECT_GCC=ppc-amigaos-gcc COLLECT_LTO_WRAPPER=/usr/local/amiga/libexec/gcc/ppc-amigaos/8.2.0/lto-wrapper.exe Target: ppc-amigaos Configured with: /amiga/adtools/gcc/repo/configure --with-bugurl=https://github.com/sba1/adtools/issues --with-pkgversion='adtools build 8.2.0' --target=ppc-amigaos --prefix=/usr/local/amiga --enable-languages=c,c++,objc,obj-c++,fortran --enable-haifa --enable-sjlj-exceptions --disable-libstdcxx-pch --disable-tls --enable-threads=amigaos Thread model: amigaos gcc version 8.2.0 (adtools build 8.2.0)

But you are right anyway, at least -athread=single model should be as default , and when one need he can choice -athread=native , or -athread=posix/pthreads

There is no default yet because the whole thing is beta and the implications are not clear yet, especially if one would try to compile shared objects. Therefore, at least for now, it is better to make the threading explict.

One doesn't need it for C programs if I'm not mistaken.

[kas1e]

But if make by default -athread=single, then it will works fine fir shared objects and for all other stuff just like older gcc. And if one need, he can set native/posix if need it.

[sba1]

Am 2019-02-08 11:26, schrieb kas1e:

But if make by default -athread=single, then it will works fine fir shared objects and for all other stuff just like older gcc. And if one need, he can set native/posix if need it.

The -athread=single is not the same single as before. Before, you would get compile time errors if you attempt to use a thread stuff, now they are runtime problems, which may be even more confusing. Currently, one has to least think about the possible choices. For very basic stuff, the threading is not relevant I think.

Also I think that "single" needs to be removed in the future, it was intended only as an interim solution. Hence, it doesn't make sense to enable it by default.

Default should be -athread=native but until there is not enough evidence that it works, I do not wish to do that.

[ksdhans]

There is no default yet because the whole thing is beta and the implications are not clear yet, especially if one would try to compile shared objects. Therefore, at least for now, it is better to make the threading explict. One doesn't need it for C programs if I'm not mistaken. Understood. However, a side-effect of requiring explicit threading is that makefiles have to be updated in a manner that breaks for all previous GCC versions. That's a problem for me because some C++ code I have is example code for others, and so needs to compile with multiple versions of GCC.

[sba1]

Am 2019-02-08 11:49, schrieb ksdhans:

Understood. However, a side-effect of requiring explicit threading is that makefiles have to be updated in a manner that breaks for all previous GCC versions. That's a problem for me because some C++ code I have is example code for others, and so needs to compile with multiple versions of GCC.

But to be fair, previously, threading was not implemented at all before. If your project requires threading, then you cannot compile it with a previous version. Also, a default to "single" would not help much because you may want to choose different implementation.

I suggest to put the -athread stuff into a distinct makefile macro. This could even be automatically depend on gcc version if this really makes sense. But personally, I don't see why one want to to compile the same program with older gcc versions (except for the SPE stuff of course).

[ksdhans]

But to be fair, previously, threading was not implemented at all before. If your project requires threading, then you cannot compile it with a previous version. Also, a default to "single" would not help much because you may want to choose different implementation.

The code I'm talking about does NOT require threading. It's existing example code.

[ksdhans]

I suggest to put the -athread stuff into a distinct makefile macro. This could even be automatically depend on gcc version if this really makes sense. But personally, I don't see why one want to to compile the same program with older gcc versions (except for the SPE stuff of course).

Almost missed this. It's example code, as in code provided to other people as examples of how to use Warp3D Nova. As such, I have no idea what version of GCC they have installed.

[sba1]

Am 2019-02-11 10:17, schrieb ksdhans:

But to be fair, previously, threading was not implemented at all before. If your project requires threading, then you cannot compile it with a previous version. Also, a default to "single" would not help much because you may want to choose different implementation.

The code I'm talking about does NOT require threading. It's existing example code.

Well, in C++ sophisticated threading is nearly mandatory for even the basic things. I'm not even sure if recent C++ standard is defined for the single-threaded case. It could be that gcc's support for single is just for historic reasons (and because it supports C).

I don't expect that all code that worked with previous single thread model, will continue to work with the amigaos threading model linked with the single the same way (whole libstdc++ is compiled differently).

If you don't like the new behaviour, you have to build the compiler again using single thread model for your examples and use it. I'm afraid that gcc is not so flexible to truely support different models in the same installation and I'm reluctant to distribute different flavours.

To be honest, normal AmigaOS projects should use native and nothing else (only for porting work, pthread comes in handy). As said before, because the "native" and the threading model is new and binaries are incomptible with previous ones (especially with respect to shared objects), one has to make this explicit until it is proven to be stable and some better documentation exists.

[sba1]

Am 2019-02-11 10:18, schrieb ksdhans:

I suggest to put the -athread stuff into a distinct makefile macro. This could even be automatically depend on gcc version if this really makes sense. But personally, I don't see why one want to to compile the same program with older gcc versions (except for the SPE stuff of course).

Almost missed this. It's example code, as in code provided to other people as examples of how to use Warp3D Nova. As such, I have no idea what version of GCC they have installed.

You can tell them to use a version that works best in your expierence.

However, what I mean was to parse the 'gcc -v' output in the makefile. It tells about the thread model.

Ideally, we would have cmake or meson to cope with this though.

[cpm1]

I'm sorry, but suggesting Cmake, Meson or other monstrosities to be the solution to a simple default issue is kind of strange IMHO.

Why not make the default behaviour just like it was with previous GCC versions, i.e. no threading at all? That way, nobody would suffer from negative surprises and those who would like to use threading, would have to enabled it explicitly. Later you can change the default to "native" if you want.

For now, a simple Makefile should IMO be enough to get code (without any special threading needs) to compile on various GCC versions just like before.

My two cents as a total non-C++-expert.