1. Forum
  2. Usenet
  3. COMP.OS.MSDOS.DJGPP

  • GNU pth during djgpp build time?

    From janezz55@21:1/5 to All on Sun May 1 20:49:05 2022
    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>?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Mon May 2 06:47:56 2022
    On 2022-05-02 05:49, janezz55 (janezz55@gmail.com) [via djgpp@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From janezz55@21:1/5 to All on Sun May 1 23:28:02 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Mon May 2 08:03:12 2022
    On 5/2/2022 2:28 AM, janezz55 (janezz55@gmail.com) [via
    djgpp@delorie.com] wrote:
    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.

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From janezz55@21:1/5 to djgpp@delorie.com] on Mon May 2 07:09:10 2022
    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.

    On Monday, May 2, 2022 at 2:03:32 PM UTC+2, Frank Sapone (emoaddict15@gmail.com) [via djgpp@delorie.com] wrote:
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From janezz55@21:1/5 to djgpp@delorie.com] on Mon May 2 07:39:02 2022
    On Monday, May 2, 2022 at 4:23:26 PM UTC+2, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com on Mon May 2 17:23:03 2022
    On 5/2/22, janezz55 (janezz55@gmail.com) [via djgpp@delorie.com] <djgpp@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Mon May 2 10:54:47 2022
    On 5/2/2022 10:39 AM, janezz55 (janezz55@gmail.com) [via
    djgpp@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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From janezz55@21:1/5 to djgpp@delorie.com] on Mon May 2 20:17:22 2022
    On Monday, May 2, 2022 at 4:55:00 PM UTC+2, Frank Sapone (emoaddict15@gmail.com) [via djgpp@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, ...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Tue May 3 00:11:28 2022
    On 5/2/2022 11:17 PM, janezz55 (janezz55@gmail.com) [via
    djgpp@delorie.com] wrote:
    On Monday, May 2, 2022 at 4:55:00 PM UTC+2, Frank Sapone (emoaddict15@gmail.com) [via djgpp@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, ...

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From janezz55@21:1/5 to djgpp@delorie.com] on Mon May 2 21:40:11 2022
    On Tuesday, May 3, 2022 at 6:11:44 AM UTC+2, Frank Sapone (emoaddict15@gmail.com) [via djgpp@delorie.com] wrote:
    On 5/2/2022 11:17 PM, janezz55 (jane...@gmail.com) [via
    dj...@delorie.com] wrote:
    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?
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Wed May 25 18:54:22 2022
    On 2022-05-02 05:49, janezz55 (janezz55@gmail.com) [via djgpp@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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From janezz55@21:1/5 to All on Wed May 25 10:53:10 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Wed May 25 21:17:10 2022
    On 2022-05-25 19:53, janezz55 (janezz55@gmail.com) [via djgpp@delorie.com] wrote:
    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?

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From janezz55@21:1/5 to All on Wed May 25 14:04:52 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Sat May 28 16:24:33 2022
    On 2022-05-25 23:04, janezz55 (janezz55@gmail.com) [via djgpp@delorie.com] wrote:
    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)