[MPlayer-users] intel os x crash using window codecs

[The Wanderer]

Dave Chand wrote:

> On Dec 1, 2006, at 7:20 AM, The Wanderer wrote:
> 
>> I said, NOT just 'bt full'; the output of the various commands
>> described in the "crashing bugs" section of
>> DOCS/HTML/en/bugreports.html. The  full correct bug-reporting
>> procedures can be found in that file and its relatives.
> 
> I will admit I perused the docs instead of "reading indepth".

For MPlayer especially, this is not a particularly good idea. We are not
necessarily as patient as I've seen people on some other projects be
with help requests and bug reports which omit information requested in
the documentation.

>> There's nothing wrong with that, but it is better to mention things
>> like that, so that people don't assume that you're just looking for
>> help.
> 
> No I am not looking for help as much as trying to understand how
> mplayer works, and to me it seems helping with a bug or problem is
> the way to go. Eventually I will get the process down.

Yep. A lot of people got their start that way; I think at least one or
two of the current developers came in from that direction.

Most of my own understanding of how MPlayer works has come from reading
these lists (in varying levels of lurk mode - including "so far into
negative lurk as to be noticeable from the far side of the equator")
since mid-2003. The rest, limited as it is, comes from reading both the
docs (some of which I think I helped write) and the source. The latter,
while a somewhat horrific experience at times, is probably the best
approach in some ways.

>> (Also, in case you weren't aware: the Win32 codecs are binary, and
>> as such are architecture-dependent. They may potentially be able to
>> work on an Intel Mac, but AFAIK they fundamentally cannot work on a
>> non-x86 system unless run via a full emulation layer.)
> 
> I know the codecs are binary.

And from that I infer that you are in fact running on an Intel Mac,
rather than a PowerPC Mac. This was not necessarily clear before.

>>> Some files with assembly optimizations needed to be compliled
>>> with - fomit-frame-pointer, in order for the compilation to go
>>> through.
>> 
>> If by this you mean "I didn't compile with --enable-debug because
>> of this problem", then all I have to say for the moment is that you
>> should have started out with a bug report of *that* problem, with
>> possibly a side note mentioning what you were trying to accomplish
>> which led  you to want to compile with --enable-debug.
> 
> No I meant what I said. I did recompile with --enable-debug, but
> apple gcc needs -gfull to be passed inorder for "all symbols to be
> emitted"

...then I don't know what you meant by the sentence I've quoted above.
If the absence of -fomit-frame-pointer is not a problem, then why did
you mention it? If it is a problem, but does not prevent compilation
from finishing, then what did you mean by "go through"?

Also, out of curiosity, what means did you use to add '-gfull' to the
compilation flags? Editing the Makefile directly, or something else?

It might be a good idea to do different things with --enable-debug,
depending on what system we are building on...

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.