No subject

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?