Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#68033 - [mingw-w64-gcc] consider removing/splitting unused languages

Attached to Project: Community Packages
Opened by Emil (xexaxo) - Monday, 28 September 2020, 15:29 GMT
Last edited by freswa (frederik) - Monday, 28 September 2020, 19:34 GMT
Task Type Bug Report
Category Packages
Status Assigned
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Description:

The package was reintroduced (after living in AUR for 2.5 years) for building wine. Wine uses C/C++, yet the package also includes support for ada, objc/objc++ and fortran.

The package is over 800MB, while in reality we're using only 1/3-1/2 of it.

Can we disable the unused languages? Alternatively, we can split them in separate packages akin to gcc{,-ada,-objc,-fortran}.

Additional info:
* package version(s)
10.2.0-1


Steps to reproduce:
- rebuild the package with "--enable-languages=c,c++,lto"
- observe successful build of wine/wine-staging/other official packages
This task depends upon

Comment by Emil (xexaxo) - Tuesday, 29 September 2020, 02:51 GMT
Another possibility - be that instead of the above idea or in parallel to it:
Separate the compiler (some 750MiB) and runtime (rest 100ish MiB) - akin to gcc{,-ada,-objc,-fortran} vs gcc-libs.

Although currently, we force-move the runtime from lib -> bin (in package()) so odd are that nobody, outside the mingw toolchain, actually uses it.
If so, a better solution may be to use mingw-w64-gcc as makedepend in the wine package?
Comment by Emil (xexaxo) - Monday, 05 October 2020, 10:19 GMT
Oops mingw-w64-gcc is indeed a makedepend (for wine). Had a bit of a silly moment - pardon for the noise o/
Comment by Emil (xexaxo) - Tuesday, 02 May 2023, 13:46 GMT
The package has grown recently and overall the initial sentiment remains.

Any applications build with -fstack-protector or other options can end up pulling DLLs like - libatomic/libgcc_s/libssp - at runtime.

Currently the only way to get the required runtime files (worth 10-15M), one needs to install the whole toolchain. Namely:
- mingw-w64-gcc 12.2.0-1 - 211.2 MB/935.6 MB
- mingw-w64-crt 10.0.0-1 - 5.8 MB/150.5 MB
- mingw-w64-binutils 2.38-3 - 4.1 MB/36.6 MB
- mingw-w64-headers 10.0.0-1 - 9.9 MB/118.2 MB

Overall, one need to download ~230M of packages and use ~1.2G of disk space... Only to run a simple Hello World, compiled with -fstack-protector.

Can we please get split the runtime libraries to a gcc-libs like package? Thanks in advance.
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.
Comment by Emil (xexaxo) - Tuesday, 12 September 2023, 09:00 GMT
Issue is still relevant. In a way McBugFace is a nice addition ... hope it doesn't turn our like the Github bot.

Loading...