#151 windows autobuilds

open-remind
NightStrike
5
2010-09-22
2010-03-22
rubenvb
No

see https://sourceforge.net/projects/mingw-w64/forums/forum/723798/topic/3628186 post 11 (PS) and 12.
The "ln -s" command is copying a lot, while it doesn't have to (see sezero's builds, where it's not)

Discussion

  • NightStrike
    NightStrike
    2010-03-22

    What you describe in this bug is not what you describe in your thread. Either way, as written, I don't see any of it as a problem. Please clarify what you are trying to report.

     
  • rubenvb
    rubenvb
    2010-03-22

    What I was trying to summarize (and clearly didn't do well), are these things:
    ---
    > PS: I did notice some strangeness in the autobuilds:
    > - the gcc stddef and float headers are still in use and cause many win32 projects
    > to fail building (all of Qt for example) because MS specific stuff is not included
    > and these are found first

    I specifically patch gcc to exclude those headers
    form installation. Autobuilds doesn't patch gcc.

    > - the <root>/mingw folder, which I used for all my personal library build liike
    > zlib and openssl and stuff, is populated with all the gcc and mingw-w64 import
    > libs and dlls. I though they belonged in the <root>/include and <root>/lib(64/32)
    > folders?

    I think it is because of the 'ln -s' doing a full copy
    under windows, sigh.. I suggest you make that part
    a bug report under our tracker, so that our builders
    would deal with that.
    ---
    The stddef, float and another header I can't remember right now do not provide all the definitions and declarations the x86_64-w64-mingw32 headers do. When you #include <float.h>, it will use the gcc one missing important stuff. This is why sezero does not use these.
    Also; the mingw folder is supposed to be used for user libraries and should be kept clear from toolchain stuff. The autobuilds have it littered with (doubled) gcc libraries, while they should be installed in a directory higher (see sezero's build). This will also make the package a LOT smaller.

     
  • NightStrike
    NightStrike
    2010-04-30

    Well, first, the root/mingw directory is not for user libs. It shouldn't even exist. It's a holdover from a backwards design from mingw.org's original port of GCC to windows. It's a direct copy on windows platforms because windows doesn't support symlinks the way other file systems do. On linux, for example, root/mingw is just a symlink to root/x86_64-w64-mingw32 or root/i686-w64-mingw32, depending on the specific target in question. More generically, it's a symlink to $root/$target.

    That may shed some light on the purpose of this directory for you. It's a target lib directory for the compiler. I don't know where you got this idea:
    "the mingw folder is supposed to be used for user libraries and
    should be kept clear from toolchain stuff. The autobuilds have it littered
    with (doubled) gcc libraries, while they should be installed in a directory
    higher (see sezero's build)."

    ...but I disagree. It's a compiler target lib directory.

     
  • rubenvb
    rubenvb
    2010-04-30

    OK, then I misunderstood the purpose of the mingw/ directory.

    My point about sezero's builds having it empty still stands though. How come the autobuilds don't have it empty? Seems like a waste of space to me...

     
  • Some new/updated information pertaining the autobuilds vs sezero/TDM-GCC:
    - size on disk: autobuild is unnecessarily huge:
    -- the /mingw directory is superfluous and should be removed (see TDM-GCC)
    -- the libexec/gcc/<triplet>/<version>/*.exe files are huge +- 50MB each, where sezero's build has them at +- 8MB each. running strip on them does nothing (file size unchanged).
    - the gcc headers float.h, stdarg.h and stddef.h should be dealt with. sezero removes them, but this is only a workaround of course. Is this being handled upstream?

     
  • NightStrike
    NightStrike
    2010-06-30

    • status: open --> open-wont-fix
     
  • NightStrike
    NightStrike
    2010-06-30

    size: They are big for a number of reasons. But, it's 2010. Who cares if it's a 200M download?

    mingw dir: Please see my comment earlier in this bug report. If you'd like to work on patching GCC to remove this dependency, we'd love it.

    Big files: You can't just run strip on stuff. There's a specific "install-strip" make target that you have to use.

    Headers: The real fix is a unification of some sort between us and GCC. Would you like to help?

     
  • NightStrike
    NightStrike
    2010-06-30

    • assigned_to: nobody --> nightstrike
     

  • Anonymous
    2010-06-30

    (the previous post was mine, but I wasn't logged in ;) )

    @size: ok, but they might as well not be big... for developers who like USB sticks (+MSYS+MinGW-w64)as a portable development environment, it might matter, especially when using both -w32 and -w64. But if it's needed debug info of sorts, by all means keep it if you find it necessary. But please remember loading a large executable slows down execution/load time, and thus user compilation time.

    @mingw dir: can't you just delete the /mingw dir in the install process, nothing crashes or produces errors here when I do that manually (under Win64, using the i686 hosted toolchain). If it's needed only to build gcc, no need to distribute bloat...

    @headers: pretty extensive discussion here: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00861.html, including a patch by sezero to remedy the problem. Anything I do here will probably conflict with what they had in mind.

     
    Last edit: Anonymous 2014-04-05
  • NightStrike
    NightStrike
    2010-06-30

    I have not seen load times to be consequential.

    We certainly can look into it. I'll get some feedback from Kai as to what all of the dependencies on that annoying dir structure are. If it really is just a build dependency, then fine.

    The headers link looks like a dead discussion. You don't have to reinvent Ozkan's work, but it'd be awesome if you could help hammer the gcc list until someone takes notice.

     
  • Ozkan Sezer
    Ozkan Sezer
    2010-06-30

    > size: They are big for a number of reasons. But, it's 2010. Who
    > cares if it's a 200M download?
    >

    This is shameful. Size would matter for a number of reasons
    too and one may not have the fasttest connection available to
    him all time.

     
  • rubenvb
    rubenvb
    2010-09-22

    • status: open-wont-fix --> open-remind
     
  • rubenvb
    rubenvb
    2010-09-22

    I have the *exact* "solution" for this problem:
    - before packaging the toolchain, perform some simple steps:
    rm -rf $PREFIX/mingw
    strip $PREFIX/*.exe
    strip $PREFIX/*.dll
    strip $PREFIX/libexec/gcc/$TARGET/$GCC_VERSION/*.exe

    This trims offa total of about 200 MB of the unzipped toolchain (4 times ~40MB for the libexec, and ~40 MB for the unneeded /mingw folder, which is really only a build dependency, and a half-assed one too: for non-multilib builds, the /mingw/include folder only has to be *present*, I have built several toolchains with this setup. For multilib, it needs to contain the libs/headers for the non-native bitness)

    This would also save a lot of space on SF, uploading time, etc.

     
  • NightStrike
    NightStrike
    2010-11-16

    I got GCC to fix the missing install-strip make target, so now we can properly strip binaries. We still have to incorporate this into the buildbot system.