Canadian cross toolchain for Windows depends on libwinpthread-1.dll

[abrodkin]

Some background: we build re-distributable Windows cross-toolchain (Elf or bare-metal, i.e. not Linux) which is supposed to cross-compile for some embedded processors (in our case these are ARC processors, but that doesn't matter). We use Linux build infrastructure for building toolchains and so we utilize the following 2-stage approach:

1. Build Windows MinGW cross-toolchain
2. Build Windows cross-toolchain for ARC, using Windows cross-toolchain built above (basically CT_CANADIAN=y & CT_HOST=i686-w64-mingw32 or CT_HOST=x86_64-w64-mingw32).

And the problem we recently bumped into was an additional dependency of Windows binaries on some libwinpthread-1.dll, see foss-for-synopsys-dwc-arc-processors/toolchain#495.

Basically, cross GCC and G++ fail to start because of the missing dependency: libwinpthread-1.dll.

The code execution cannot proceed because libwinpthread-1.dll was not found. Reinstalling the program may fix this problem.

Apparently, the reason for that additional dependency was CT_THREADS_POSIX=y set in crosstool-ng/samples/x86_64-w64-mingw32/crosstool.config and now after a8d2c2e in samples/i686-w64-mingw32/crosstool.config.

And while I'm not an expert in Windows runtime, even after reading of https://stackoverflow.com/questions/17242516/mingw-w64-threads-posix-vs-win32 I don't quite understand which problems if at all there might be if we use "native" Win32 threads implentation in the MinGW toolchain, which only purpose is to build cross-toolchains for Windows in the canadian cross manner.

That said, this is more of a memo for myself and a heads-up for those who might be interested in building Windows cross-toolchains as well. And I'm not sure if there's a point in suggesting to remove CT_THREADS_POSIX=y from all MinGW "samples" here in Crosstool-NG.

Interesting enough is @stilor did see a similar problem when he introduced that switch to Pthreads, see e082dd8 (which is a part of a bigger PR #484):

I see the resulting gcc executable has a DLL dependency on libiconv-2.dll, which is only installed into .build/.../buildtools.
This will be investigated/fixed separately.

So, it's not clear what would be the best solution here. From @stilor's comment it seems like Pthreads solved some problem of building x86_64-pc-linux-gnu (but I'm yet to figure out what was that, unfortunately there's no description provided in the corresponding commit message), but at the same time it makes built toolchain not re-distributable unless we package libwinpthread-1.dll in that toolchain, which I'm not sure if we really want to do.

[TommyMurphyTM1234]

but at the same time it makes built toolchain not re-distributable unless we package libwinpthread-1.dll in that toolchain, which I'm not sure if we really want to do.

Why not?

[abrodkin]

but at the same time it makes built toolchain not re-distributable unless we package libwinpthread-1.dll in that toolchain, which I'm not sure if we really want to do.

Why not?

Well, as usual I guess it makes sense to understand clearly why we need to do that [package some additional library]. And I don't like a lot such kind of explanation like "because this is needed by our built artifact". Especially when I know cases it might not be strictly needed. So why switching from native Win32 threads to Pthreads?

[modbw]

std:thread requires pthread library on Windows. Don't know If GCC or any other tools (like GDB) require std::thread

[TommyMurphyTM1234]

@abrodkin - have you tried removing CT_THREADS_POSIX=y (or explicitly setting it to n) for your build to see if that works and removes the dependency on libwinpthread-1.dll?

I do understand and agree with your point about wanting to understand the reason for this change. 🙂

[abrodkin]

@abrodkin - have you tried removing CT_THREADS_POSIX=y (or explicitly setting it to n) for your build to see if that works and removes the dependency on libwinpthread-1.dll?

I do understand and agree with your point about wanting to understand the reason for this change. 🙂

As a matter of fact, that's what we used to use for a long time. And a Windows cross-toolchain toolchain gets built, you may even try it - it's a part of ARC GNU IDE, see https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2022.09-rc1/arc_gnu_2022.09-rc1_ide_win_install.exe

It has both C & C++ compilers for ARC processors.

[QBos07]

I think we should package libwinpthreads-1.dll since windows doesn't have a good package managment. It's common practise to ship the own ddl's even if its something like a direct-x library (but not vcc redistributable for some reason sometimes). And if they duplicate only one is loaded so no problem there.