runtime dll copy

[Trass3r]

I'm not sure what this is supposed to do:

bleeding-edge-toolchain/build-bleeding-edge-toolchain.sh

Line 1061 in 7061c04

dlls="$(find ${installFolder}/ -name '*.exe' -exec ${triplet}-objdump -p {} \; | sed -ne "s/^.*DLL Name: \(.*\)$/\1/p" | sort | uniq)"

• The sed part should use single quotes. Not sure how this ever worked.
• On Linux it's trying to copy dlls from /usr/x86_64-w64-mingw32/bin/ which don't exist of course.
• Will there ever be any runtime dlls required? Shouldn't it produce "static" executables?
• Otoh it does not copy sources/python-2.7.16.amd64/python27.dll which it probably should (?) to produce a self-contained package.

[FreddieChopin]

I'm not sure what this is supposed to do:

It tries to copy as many *.dll files required by executables as possible (;

The quotes are incorrect.

You need to be more specific, as in here it works perfectly fine (;

On Linux it's trying to copy dlls from /usr/x86_64-w64-mingw32/bin/ which don't exist of course.

Some of them exist - these are toolchain-specific and will be copied. Some of them don't exist - these are Windows-specific and won't be copied. This is fine.

Will there ever be any runtime dlls required? Shouldn't it produce "static" executables?

This may depend on your toolchain configuration. On ArchLinux (which I'm using) almost everything is dynamic. The command above copies just libwinpthread-1.dll now, but I'm almost sure some time ago it copied a little bit more. Maybe its because I now don't have mingw-w64-termcap installed?

Otoh it does not copy sources/python-2.7.16.amd64/python27.dll which it probably should (?) to produce a self-contained package.

To use python-enabled GDB you will need a full python installation anyway. At least that's my understanding, I never managed to use this python-enabled GDB variant on Windows, so I may be completely wrong. But I don't have any specific opinion here so I'm open to change that.

[Trass3r]

The quotes are incorrect.

You need to be more specific, as in here it works perfectly fine (;

Referring to the sed part. Updated it.

Will there ever be any runtime dlls required? Shouldn't it produce "static" executables?

This may depend on your toolchain configuration. On ArchLinux (which I'm using) almost everything is dynamic. The command above copies just libwinpthread-1.dll now, but I'm almost sure some time ago it copied a little bit more. Maybe its because I now don't have mingw-w64-termcap installed?

I see. Are there toolchains without a static winpthread? If not maybe one should pass something like -static -static-libgcc -static-libstdc++.

Otoh it does not copy sources/python-2.7.16.amd64/python27.dll which it probably should (?) to produce a self-contained package.

To use python-enabled GDB you will need a full python installation anyway. At least that's my understanding, I never managed to use this python-enabled GDB variant on Windows, so I may be completely wrong. But I don't have any specific opinion here so I'm open to change that.

Not sure about that either.

[FreddieChopin]

Are there toolchains without a static winpthread?

Well, there is /usr/i686-w64-mingw32/lib/libwinpthread.a in my toolchain, so maybe the options you propose would indeed help. Will try.