#1880 /bin/sh.exe takes TWO SECONDS to start up on wine

MSYS
open
current? (14)
Feature
none
Unknown
False
2013-02-15
2009-01-12
No

installed msys under wine.
pick a package, any package.
run ./configure
sit back... and wait for... well over one hour, possibly two to three, whilst every incarnation of /bin/sh.exe takes two seconds to start up.

using strace, it can be seen that over 200 truetype and other fonts are loaded (windows system fonts and fonts in /usr/share/); nssswitch is activated; x11 libraries are fired up - the list goes on.

over 40 dynamic libraries are loaded (both windows dlls and unix system libraries).

running a "blank" (basic hello world) application by contrast takes a few milliseconds.

it's well known that /bin/sh.exe takes forever to run (tenths of seconds) on windows, but _two seconds_ under wine makes it completely unusable.

Discussion

  • Keith Marshall

    Keith Marshall - 2009-01-12

    So, it takes two seconds. Tough. Live with it, or don't run MSYS sh under wine. You have a much more usable sh running natively on your *nix host anyway; use that instead, with appropriate cross-compilers if you need to target the MS-Windows host. I've no idea why you want to do this; you may well have a legitimate reason, but if you just want to do MS-Windows applications development on a GNU/Linux host, a Linux-hosted cross-MinGW is actually, IME, *faster* than natively hosted MinGW.

    Autoconf's testsuite takes seven and a half hours to run on MS-Windows, (in MSYS), compared to 35 minutes under GNU/Linux, on similarly specced hosts.

    Wine is not a supported host, for running MSYS. Is the issue even with MSYS, or with wine? Even if you can demonstrate that the issue is irrefutably with MSYS, fixing it will not be granted priority.

     
  • Keith Marshall

    Keith Marshall - 2009-01-12
    • priority: 5 --> 1
     
  • Luke Kenneth Casson Leighton

    yep - i'm compiling python2.5 - it produces a basic python.exe which is then used to run setup.py to complete the rest of the build - to compile its modules. getting that process to understand cross-compiling is like... a total bitch. you have files that were built on linux, and now you have a python.exe that only understands C:\ and stuff.
    so the simplest option is to go the whole hog and build python under msys and mingw.

    the reason i am mentioning this is because it's well known that /bin/sh.exe takes forever even on win32 - and there has to be a solution.

    investigating this from under wine - using strace and using wine debug tracking - will allow you to narrow down what the heck is going on.

    purely on the basis of how damn slow /bin/sh.exe is on win32 this should be given priority, and as an added bonus those people who want to stay away from proprietary software, yet still do stuff that benefits users who don't have a choice about what they use, can do so.

     
  • Keith Marshall

    Keith Marshall - 2009-01-13

    Are you volunteering to put in the investigative and development effort, to follow this up? If not, it is unlikely to happen.

     
  • Keith Marshall

    Keith Marshall - 2009-01-13
    • labels: 380073 --> MSYS
     
  • Luke Kenneth Casson Leighton

    yep.
    i already looked for build instructions on msys - it was absolutely impossible to find anything, despite a significant search using both google and the wiki. i did find the "developer build" for "building tools _for_ msys not _with_ msys" but no instructions on where to go from there.

     
  • Earnie Boyd

    Earnie Boyd - 2013-02-15

    Ticket moved from /p/mingw/feature-requests/62/

     
  • Earnie Boyd

    Earnie Boyd - 2013-02-15
    • labels: MSYS --> current?
    • assigned_to: Cesar Strauss
    • milestone: --> MSYS
    • type: --> Feature
    • resolution: --> none
    • category: --> Unknown
    • patch_attached: --> False
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks