[MPlayer-dev-eng] MPlayer linking takes forever on MinGW

[Clément Bœsch]

On Sun, Nov 28, 2010 at 12:35:51PM +0200, Georgi Petrov wrote:
> 16+ hours trying to fix this issue and counting...
> 
> The problem is that in the linking phase ld.exe cycles forever. Using
> Sysinternals procmon I was able to detect that ld.exe writes the same
> bytes over and over again in mplayer.exe at the same offset.
> 
> Things I've tried:
> * Win 7 compatibility settings for XP SP2 to various GNU toolchain
> executables (ld.exe, gcc.exe, collect2.exe and so on)
> * Admin permissions
> * Older mingw/msys (happens on GCC3 and GCC4, seems unrelated)
> * TDM-GCC (still the same problem)
> * Adding and/or removing every single ld parameters I could think of
> * Running the final linking command line without some libraries only
> to find that it is a general problem, not caused by any particular
> library.
> * Changing directory paths to the shortest possible (some problems in
> the past were fixed that way)
> * Many other small things I don't remember.
> 
> It is very counter productive, because EVERY time it hangs, ld.exe
> can't be killed and it generates over 100MB/s trying to write into
> mplayer.exe. The process can't be killed Task Manager. Logging in/out
> doesn't help either. The only way to kill it is to restart the whole
> machine, otherwise it becomes unresponsive (too much HDD activity)
> otherwise.
> 
> I've done more than 80 restarts in the last 2 days :(
> 
> The same problem doesn't occur under XP in VMware. Working under XP
> isn't an option, because eventually I'll develop for DxVA/Win7.
> Compiling under XP running in VMware is too stupid and is not a
> solution for a project that will take half a year.
> 
> If somebody has any idea, it will be welcome. So far I've worked 3
> days and my productivity is close to zero.

I don't have any windows system so I can't confirm your issue, but this
may be related:

http://www.mail-archive.com/debian-alpha@lists.debian.org/msg24306.html

-- 
Clément B.
Not sent from a jesusPhone.