Package Details: mingw-w64-environment 1-5

Git Clone URL: (read-only, click to copy)
Package Base: mingw-w64-environment
Description: Script providing common environment variables and functions for MinGW (mingw-w64)
Upstream URL:
Licenses: BSD
Submitter: xantares
Maintainer: xantares
Last Packager: xantares
Votes: 8
Popularity: 0.000072
First Submitted: 2019-12-02 20:45 (UTC)
Last Updated: 2023-10-30 17:08 (UTC)

Latest Comments

1 2 Next › Last »

xantares commented on 2023-10-30 17:11 (UTC)

sure, done

xexaxo commented on 2023-10-30 11:34 (UTC)

Big thanks for the -static tips.

Any chance we can get the -D_FORTIFY_SOURCE=3 in? The RFC has landed ~9 months ago.

Martchus commented on 2023-01-19 16:55 (UTC)

If this RFC gets though we might want to add the change here as well.

Martchus commented on 2022-12-08 16:12 (UTC)

The binaries may link against libstdc++, they are not guaranteed to do so.

That's why I said if C++ is involved. (And yes, technically you're right - even then a different or no std lib might be used.)

In addition, in my testing it's impossible to static link ssp.

I'm actually doing this all the time, e.g. binaries of my apps like Syncthing Tray are linking statically against all DLLs not part of Windows itself (see e.g. To achieve this, I'm simply adding -static -static-libgcc -static-libstdc++ to the linker flags. Note that despite -static it will still link against Windows API DLLs dynamically (instead of aborting with an error) so that flag is totally ok to use (for Windows, to create a self-contained exe). In my CMake build scripts I'm adding these flags via target_link_libraries and CMake just does "the right thing" which supposedly is to add the mentioned flags directly to the g++ invocation as-is (no -Wl, prefixes).

Note that if you disagree with any of these flags you can simply create your own version of that package. Since all other packages are pulling flags from there you shouldn't need to have to adjust other packages.

xexaxo commented on 2022-12-08 13:44 (UTC)

The binaries may link against libstdc++, they are not guaranteed to do so. In addition, in my testing it's impossible to static link ssp. If you have some examples that work, that would be appreciated.

Neither of the following options work: '-l:libssp.a', '-Wl,-Bstatic -lssp -Wl,-Bdynamic', '-Wl,-Bstatic,--whole-archive -lssp -Wl,--no-whole-archive'.

Seems like libssp pulls in ligcc_s*, which in turn pulls libssp. Even if we add them all within a --whole-archive block, the compiler chokes and share-links them.

Martchus commented on 2022-12-04 18:14 (UTC) (edited on 2022-12-04 18:15 (UTC) by Martchus)

Resulting binaries will link to GCC's library anyways and if C++ is involved then also against libstdc++. If you want to create a self-contained binary you can also link against those libraries statically (including the ssp library).

xexaxo commented on 2022-12-04 15:47 (UTC)

Seems like the '--param=ssp-buffer-size=4' and '-fstack-protector' options, are resulting in binaries linked against libssp-0.dll aka the package is not self contained.

Can we make these options an opt-in of sorts?

xantares commented on 2021-11-08 19:02 (UTC)

yes, done

patlefort commented on 2021-11-05 11:07 (UTC) (edited on 2021-11-05 11:08 (UTC) by patlefort)

I ran into a problem when I installed your mingw-w64-clang-git package. Some packages have a configure script that detect clang first before gcc, so they get compiled with clang. Would it be possible to specify the default compiler to be gcc?

Maybe something like:

if [ -n "$MINGW_CC" ]; then
if [ -n "$MINGW_CXX" ]; then

I could then define these variables in my makepkg.conf.

edscott commented on 2021-02-07 14:50 (UTC)

Depends on fakeroot and binutils.