search

FreddieChopin / bleeding-edge-toolchain

All-in-one script to build bleeding-edge-toolchain for ARM microcontrollers
71 stars 24 forks source link

runtime dll copy #22

Open Trass3r opened 5 years ago

Trass3r commented 5 years ago

I'm not sure what this is supposed to do: https://github.com/FreddieChopin/bleeding-edge-toolchain/blob/7061c04a520e826c6d03c76c33e3f7ad4baf73b9/build-bleeding-edge-toolchain.sh#L1061

FreddieChopin commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.