GNU pth during djgpp build time?

[janezz55]

I know a port exists, but for all I know it's an add-on to an already existing djgpp install, so no <thread> header becomes available after installing it. But if pth could be built during build-time of djgpp, <thread> would become available. Does any build script (for linux) feature this? I tried to do the hack myself, but it took too much time. Maybe there's an alternative to GNU pth to get <thread>?

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

On 2022-05-02 05:49, janezz55 (jane...@gmail.com) [via dj...@delorie.com] wrote:
> I know a port exists, but for all I know it's an add-on to an already existing djgpp install, so no <thread> header becomes available after installing it. But if pth could be built during build-time of djgpp, <thread> would become available. Does any build script (for linux) feature this? I tried to do the hack myself, but it took too much time. Maybe there's an alternative to GNU pth to get <thread>?
>

Hi,

Installing GNU pth before building libstdc++ is an interesting idea, I might
experiment with that sometime. If I ever get anywhere with that I'll let you
know.

Although, pth uses cooperative scheduling, so any existing code that you might
want to port (if that is your goal) will have to be modified to call
this_thread::yield() at regular intervals.

Another thought, when libstdc++ detects thread support then things like
std::shared_ptr will be accessed via mutexes, that overhead may be undesirable.

For now, I have std::thread and std::jthread implementations in my dpmi
library [0], you may find that useful. It is cooperative like pth, but
pre-emptive scheduling could be implemented without much effort. So far I
haven't had any use for that though.

[0] https://github.com/jwt27/libjwdpmi/blob/experimental/include/jw/thread.h

[janezz55]

Perhaps my insight will help you:
1. I have found gnu pth supported the largest subset of pthreads of all alternatives, but it requires wattcp in order to build,
2. zlib is a dependency of wattcp, so it needs to be built first,
3. both zlib and wattcp require hacks to build,
4. gnu pth itself requires hacks to build, alas too many for me.

I stopped at 4th step.

[Frank Sapone (emoaddict15@gmail.com) [via djgpp@delorie.com]]

On 5/2/2022 2:28 AM, janezz55 (jane...@gmail.com) [via

I don't recall zlib being needed to build wattcp and I don't recall it
being a hack to build for DJGPP either.  Did you read the docs?

[janezz55]

Don't worry about me, I too managed to get zlib to build:

sed -i -e 's,"zlib/zlib\.h",<zlib.h>,' pcdbug.c
sed -i -e '/define Z_PREFIX/ d' config.h

sed -i -e '
s,\tar,\t$(AR),
s,\.\./util/nasm32,\t$(NASM),
s,\.\./util/bin2c,\t$(BIN2C),
s,-O2,-Ofast,
' makefile.all zlib/makefile.all
sed -i -e "
/CFLAGS/ s,=,= -fno-strict-aliasing -fgnu89-inline -march=i586 -I${srcdir}/zlib-${_zlver},
" makefile.all zlib/makefile.all
bash "$srcdir/mkmake.bash" DJGPP RELEASE <makefile.all >djgpp.mak

I don't really recall why I needed zlib, though, it was a long time ago. I am only guessing wattcp.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

On 5/2/22, janezz55 (jane...@gmail.com) [via dj...@delorie.com]

<dj...@delorie.com> wrote:
> I don't really recall why I needed zlib, though, it was a long time ago. I
> am only guessing wattcp.

Zlib is a configurable wattcp option: see USE_GZIP_COMPR in config.h

[janezz55]

On Monday, May 2, 2022 at 4:23:26 PM UTC+2, Ozkan Sezer (sez...@gmail.com) [via dj...@delorie.com] wrote:
> > I don't really recall why I needed zlib, though, it was a long time ago. I
> > am only guessing wattcp.
> Zlib is a configurable wattcp option: see USE_GZIP_COMPR in config.h

I don't really care anymore, I only built it, because it is a gnu pth dependency and if you build wattcp, you might zlib just as well. But building gnu pth failed for sure. This was done using xgcc, during gcc build-time. Maybe one of you manages to build gnu pth as well and then there will be a <thread> header available and pthreads.

[Frank Sapone (emoaddict15@gmail.com) [via djgpp@delorie.com]]

On 5/2/2022 10:39 AM, janezz55 (jane...@gmail.com) [via

dj...@delorie.com] wrote:
>
> I don't really care anymore, I only built it, because it is a gnu pth dependency and if you build wattcp, you might zlib just as well. But building gnu pth failed for sure. This was done using xgcc, during gcc build-time. Maybe one of you manages to build gnu pth as well and then there will be a <thread> header available and pthreads.

Sorry you are getting frustrated.  I've never had to use pthreads under
DOS so I really have no idea if anyone has done it successfully and if
there's a precompiled port of it ready to go for your project.

[janezz55]

On Monday, May 2, 2022 at 4:55:00 PM UTC+2, Frank Sapone (emoad...@gmail.com) [via dj...@delorie.com] wrote:
> Sorry you are getting frustrated. I've never had to use pthreads under
> DOS so I really have no idea if anyone has done it successfully and if
> there's a precompiled port of it ready to go for your project.

I'm just the maintainer of the "dosbox-gcc" PKGBUILD and was sharing thoughts with the rest of you. There is a lot of room for improvement: OpenGL (mesa3d), <thread>, sockets, ...

[Frank Sapone (emoaddict15@gmail.com) [via djgpp@delorie.com]]

On 5/2/2022 11:17 PM, janezz55 (jane...@gmail.com) [via

I found the Arch Linux site for this but I am confused by the
description "djgpp cross-compiler for the dosbox environment". What does
this mean?  I thought DJGPP could run in dosbox as-is or am I mistaken?

[janezz55]

It's a cross-compiler, so it runs under arch linux. The default "djgpp-gcc" PKGBUILD targets the i686 IA, which is NOT supported by dosbox.

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

On 2022-05-02 05:49, janezz55 (jane...@gmail.com) [via dj...@delorie.com] wrote:
> I know a port exists, but for all I know it's an add-on to an already existing djgpp install, so no <thread> header becomes available after installing it. But if pth could be built during build-time of djgpp, <thread> would become available. Does any build script (for linux) feature this? I tried to do the hack myself, but it took too much time. Maybe there's an alternative to GNU pth to get <thread>?

Hi again,

I have some progress to report: it doesn't work :)

Surprisingly, configuring gcc with --enable-threads is actually possible, but
it did require a small patch to Pth. The executables it produces however, will
not run. A thread-aware libgcc will try to lock a mutex in
__register_frame_info(), which is invoked from crt0 before __crt1_startup().
But locking a mutex involves a whole series of libc functions that rely on
things like _dos_ds, which are only initialized from __crt1_startup().

Fixing this would involve reordering the crt0 startup logic. Or maybe libgcc
could be patched to not use a mutex at that point. If you (or anyone else)
want to experiment with that, you can use the following build scripts:

https://github.com/jwt27/build-gcc/tree/pth

Checkout branch 'pth', then first build a regular toolchain:

$ ./build-djgpp.sh --prefix=$HOME/djgpp djgpp-cvs binutils gcc

Then use that toolchain to compile Pth and build a second toolchain configured
with --enable-threads=posix (this is done automatically in one step):

$ PATH="$HOME/djgpp/bin:$PATH" \
./build-djgpp.sh --prefix=$HOME/djgpp-pth djgpp-cvs binutils gcc watt32 pth

Linking requires -lstdc++ -lpthread -lsocket, in that order.

[janezz55]

> Surprisingly, configuring gcc with --enable-threads is actually possible, but
> it did require a small patch to Pth. The executables it produces however, will
> not run. A thread-aware libgcc will try to lock a mutex in
> __register_frame_info(), which is invoked from crt0 before __crt1_startup().
> But locking a mutex involves a whole series of libc functions that rely on
> things like _dos_ds, which are only initialized from __crt1_startup().

patch libgcc? Why would it want to lock a mutex anyway?

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

As I understand it, __register_frame_info() is called to register .eh_frame
sections in a global list. This also happens on shared library loads, at which
point there may be multiple active threads. The same list is also accessed
whenever an exception is thrown. So it makes sense to use a mutex here, but
in our case it's just not necessary to do so on startup.

[janezz55]

> whenever an exception is thrown. So it makes sense to use a mutex here, but
> in our case it's just not necessary to do so on startup.

Yeah, I have a feeling you're already working on a patch :) So, we will have std::thread under dos, amazing.

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

I haven't looked further into it yet. Should be trivial to remove the mutex
access and see if any other issues pop up. But I don't like the idea of
requiring a custom patched gcc for this. Plus the whole thing seems far less
efficient than what I already have, and I think gcc will also generate overall
worse code with --enable-threads.