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

[Dave Yeo]

On 11/28/10 03:36 pm, Georgi Petrov wrote:
> On Sun, Nov 28, 2010 at 11:45 PM, Carl Eugen Hoyos<cehoyos at ag.or.at>  wrote:
>> Georgi Petrov<gogothebee<at>  gmail.com>  writes:
>>
>>>> Have you tried to find the exact svn revision that broke linking?
>>>
>>> No, I haven't.
>>>
>>> I think that this will be too much work without some type of
>>> automation.
>>
>> It is certainly by far the fastest method to solve your problem (and will not
>> take a whole day, but a few hours at most).
>> (Additionally, I expect it will improve your ld bug-report significantly.)
>
> Hi Carl,
>
>> From another perspective you might be right. It will take me several
> hours to set up the procedure, but it won't be 100% automated. I will
> have to learn some things I don't know now, but it is pretty doable.
>
> Let me introduce my point why it might be useless.
>
> So far I've figured out that the success/failure of the linking
> process depends on the number of arguments to ld.exe. Or the sum (in
> bytes) of all object files. One of these two! Nothing else! Tommorow
> I'll be more specific.
>
> I have one particular test case, where the statement
>
> gcc -o mplayer.exe a.o b.o c.o
>
> is shortened (by means of .o files). The important part is that it is
> shortened by a pretty exact number of .o arguments. I've found the
> exact number of .o arguments which is the threshold between:
>
> 1) ld complaining that many functions are missing (because of the .o
> files I've removed) and exits cleanly
> 2) ld hangs
>
> It definitely took me some time :)
>
> In my particular example I have behavior 1, but If I add another
> random .o file, the behavior changes to 2. And it doesn't matter which
> .o file exactly I add. Or which .o file from the "hang-causing
> statement" list I change for another .o file.
>
> My point is that in some point of MPlayer development, the .o/.a list
> grew past some magic number and ld began hanging.
>
> As this .o/.a files list (or the sum of object files in bytes) grows
> constantly, if this is the root cause, it doesn't depend on MPlayer
> itself. I might just find he SVN version, which adds the fatal .o, .a
> or sum of object bytes, which triggers the behavior switch from clean
> linking to hanging.
>
> What do you guys think about my theory?

What about if you use wildcards, eg *.o *.a or use a response file? 
Response file has a @ prefix, eg @foo and one argument per line and 
invoked as ld @foo. I don't know if your build of ld supports either 
response files or wildcards.
Dave