Diego Biurrun | 2 Nov 21:43 2003
Picon

[BUG] compilation error in libfaad2/output.c

Hi!

Both Cygwin and MinGW currently break in libfaad2/output.c with the 
following error:

cc -c -I. -g -O4 -march=k6-3 -mcpu=k6-3 -pipe -ffast-math 
-fomit-frame-pointer -D__CYGWIN__  -o output.o output.c
output.c: In function `dither_output':
output.c:204: warning: integer constant is too large for "long" type
output.c:204: warning: integer constant is too large for "long" type
output.c:209: warning: integer constant is too large for "long" type
output.c:209: warning: integer constant is too large for "long" type
output.c:215: warning: integer constant is too large for "long" type
output.c:215: warning: integer constant is too large for "long" type
{standard input}: Assembler messages:
{standard input}:1005: Error: value of -131 too large for field of 1 
bytes at 1698
{standard input}:1121: Error: value of -133 too large for field of 1 
bytes at 1995
make: *** [output.o] Error 1

System is latest Cygin/MinGW with gcc 3.3.1.  Any clues?

Diego
Bojan | 7 Nov 20:02 2003
Picon

mencoder gui for windows

Hello. I made mencoder gui for windows.

Gulmencoder.
http://vuks.da.ru
in the programs section.

--
http://vuks.da.ru
dbojan
Diego Biurrun | 8 Nov 17:13 2003
Picon

Re: [BUG] compilation error in libfaad2/output.c

Diego Biurrun writes:
 > Both Cygwin and MinGW currently break in libfaad2/output.c with the 
 > following error:
 > 
 > cc -c -I. -g -O4 -march=k6-3 -mcpu=k6-3 -pipe -ffast-math 
 > -fomit-frame-pointer -D__CYGWIN__  -o output.o output.c
 > output.c: In function `dither_output':
 > output.c:204: warning: integer constant is too large for "long" type
 > output.c:204: warning: integer constant is too large for "long" type
 > output.c:209: warning: integer constant is too large for "long" type
 > output.c:209: warning: integer constant is too large for "long" type
 > output.c:215: warning: integer constant is too large for "long" type
 > output.c:215: warning: integer constant is too large for "long" type
 > {standard input}: Assembler messages:
 > {standard input}:1005: Error: value of -131 too large for field of 1 
 > bytes at 1698
 > {standard input}:1121: Error: value of -133 too large for field of 1 
 > bytes at 1995
 > make: *** [output.o] Error 1
 > 
 > System is latest Cygin/MinGW with gcc 3.3.1.  Any clues?

Doesn't seem to happen any more..  Dunno wtf changed, but I won't
complain.

Diego
Joey Parrish | 10 Nov 03:05 2003

call for cygwin help

First off,
Yes, I know, send this to the -cygwin list.  CC'd.

If anything I describe below sounds familiar, or if you have any
workarounds or debug techniques to recommend, then please do.
Otherwise, feel free to ignore.

I'm working on cygwin mplayer again, and I feel like I've made a fair
amount of progress with my packages.  However, my latest builds are
all messed up.  They work fine from a cygwin bash prompt, but given
identical arguments from explorer, it gets really strange.  I'm seeing
lots of bitrot in the input system, it seems.  When I press 'f' to
toggle fullscreen, it acts as if I just slammed my face on the keyboard.

Now, these latest packages are built under latest cygwin using (sadly)
latest gcc for cygwin. (3.3.1-3)  I thought it might be a compiler bug,
but I can only downgrade as far back as 3.2 without compiling gcc
myself.  All the versions of gcc I can try with prebuilt packages (3.2,
3.3.1-2, and 3.3.1-3) all produce these results on my system. (Crusoe
laptop running XP.)  Older packages I made during the summer work fine
under the same conditions on the same system.  (Even with same cygwin
DLL.)

If I hadn't just written so much code and spent so much time organizing
the patchset, I'd just give up.  I'm so frustrated.  Any help, comments,
or suggestions is appreciated.

--Joey

--

-- 
(Continue reading)

Diego Biurrun | 10 Nov 11:03 2003
Picon

Re: call for cygwin help

Joey Parrish writes:
 > Now, these latest packages are built under latest cygwin using (sadly)
 > latest gcc for cygwin. (3.3.1-3)  I thought it might be a compiler bug,
 > but I can only downgrade as far back as 3.2 without compiling gcc
 > myself.  All the versions of gcc I can try with prebuilt packages (3.2,
 > 3.3.1-2, and 3.3.1-3) all produce these results on my system. (Crusoe
 > laptop running XP.)

There is gcc-2.95.3-10 available for Cygwin, maybe try that one?

Diego
Joey Parrish | 12 Nov 19:21 2003

Re: call for cygwin help

On Mon, Nov 10, 2003 at 11:03:32AM +0100, Diego Biurrun wrote:
> Joey Parrish writes:
>  > Now, these latest packages are built under latest cygwin using (sadly)
>  > latest gcc for cygwin. (3.3.1-3)  I thought it might be a compiler bug,
>  > but I can only downgrade as far back as 3.2 without compiling gcc
>  > myself.  All the versions of gcc I can try with prebuilt packages (3.2,
>  > 3.3.1-2, and 3.3.1-3) all produce these results on my system. (Crusoe
>  > laptop running XP.)
> 
> There is gcc-2.95.3-10 available for Cygwin, maybe try that one?

Yes, but it is no longer available to download in many places.  I just
found the package yesterday.  It took me a whole week.  Maybe I'm just a
putz, though.  What helped, though, was knowing the entire version name.
Searching for 2.95.3-10 finally found me a mirror with a copy.

On that note, it turns out not to be a compiler bug giving me problems.
Additionally, gcc 2.95 doesn't even compile mplayer under cygwin.  I
remember now what it was like when I started trying to compile cygwin
mplayer way back when.  Gcc 2.95 under cygwin segfaults under conditions
I can't quite pinpoint.  It's usually fixed by changing the order of the
#include directives.  Grrrr.  So I'm back to 3.3.1.

What did turn out to be the problem is kind of interesting, though.
If you compile mplayer with -mwindows, then you get no console window.
It's still using the cygwin layer, but it just doesn't create a console
window.  As a side-effect, mplayer still runs fine under bash, but from
explorer the input system is completely broken.  I found that this can
be fixed by changing config.h to say I have no posix select().  Then the
fifo code is different, and then it works fine.  Isn't that odd?
(Continue reading)

Joey Parrish | 12 Nov 19:45 2003

MPlayer packages for windows

Hello,

So, I've been off this list for quite a while, now.
Grepping the archive, I see I was addressed once or twice and never
responded.  So:

Diego:
> I have two suggestions, though.

> 1) Could you add an option like "open fullscreen" to the context menu? 
> I think this would be a nice goodie.

I'll add it to my list.  The next time I release a (beta) package, then
this will be there.

> 2) Could you compile the package with --with-codecsdir=codecs and add a 
> codecs subdirectory to dir where MPlayer gets installed?  This way I 
> could easily drop codecs into that directory (or you might even provide 
> them with your package) and MPlayer could also play QT and Real files. 
> These file types should be added to the file type dialog on installation 
> then.

Yeah, this is something I've been aware of.  Some of my packages so far
have done exactly this.  In fact, I was even hacking at get_path to get
the path to the codecs folder relative to the mplayer executable.  I
think my latest packages have a much more solid solution, though.  I'll
get back to this.

S. Smith:
> I might have a bugreport for this (cvs), I have not been able to use 
(Continue reading)

Brian Dessent | 13 Nov 01:02 2003
Picon

Re: call for cygwin help

Joey Parrish wrote:

> Yes, but it is no longer available to download in many places.  I just
> found the package yesterday.  It took me a whole week.  Maybe I'm just a
> putz, though.  What helped, though, was knowing the entire version name.
> Searching for 2.95.3-10 finally found me a mirror with a copy.
> 
> On that note, it turns out not to be a compiler bug giving me problems.
> Additionally, gcc 2.95 doesn't even compile mplayer under cygwin.  I
> remember now what it was like when I started trying to compile cygwin
> mplayer way back when.  Gcc 2.95 under cygwin segfaults under conditions
> I can't quite pinpoint.  It's usually fixed by changing the order of the
> #include directives.  Grrrr.  So I'm back to 3.3.1.

That is in fact why it was removed and is now unsupported.  The last
packaged version has serious issues and is known to be broken.  Its
maintainer (Chris Faylor) does not want to support it anymore as no
Cygwin packages require it, thus its removal and unsupported-ness.

Brian
Sycotic Smith | 13 Nov 19:24 2003

Re: MPlayer packages for windows

> S. Smith:
> > I might have a bugreport for this (cvs), I have not been able to use 
> > [-fs|-vm|-zoom] without a sig11 as yet.  Switching works fine, tho.
> 
> This is because of a patch I added.  This behavior does not happen in
> normal cygwin mplayer.  Here's the issue for me:
> This package is intended to be used without any command line.
> So, in theory, you'd only ever have one movie running, perhaps on loop.
> (My latest hacks have optional playlist associations, though...)
> If you're looping a file, and during loop 1 you toggle fullscreen,
> then when loop 2 begins, it goes back to windowed mode.  My solution:
> comment out "fs = options & 1" from vo_directx.  This is _awful_ and
> I'll fix it before my next release.  It would be much better to have the
> first call to config set fs, then subsequent calls should leave it
> alone.  Or, even more correct would be if the caller of config took the
> time to check vo_fs state and pass that.  In any case, it all diverges
> from standard mplayer's way of doing things.  And since I'm working on
> packages for a special case, isn't a cheap hack okay in the short run?

I think you missed the operative word I put in there: CVS. I haven't tried your packages since I have no
problems compiling my own binary on my system. But, I haven't had time to see if it works now or not. And since
it won't let me gdb (my own problem), I can't do a full bugreport as needed. All I can do is give system specs
and mplayer mesgs to go from. I can start another thread on that if today's test doesn't work, maybe. (Due to
workload changes, I may not even be able to today.)

/S. Smith
--

-- 
______________________________________________
Check out the latest SMS services  <at>  http://www.linuxmail.org 
This allows you to send and receive SMS through your mailbox.
(Continue reading)

Joey Parrish | 13 Nov 19:55 2003

Re: MPlayer packages for windows

On Thu, Nov 13, 2003 at 10:24:49AM -0800, Sycotic Smith wrote:
> I think you missed the operative word I put in there: CVS. I haven't
> tried your packages since I have no problems compiling my own binary
> on my system. But, I haven't had time to see if it works now or not.
> And since it won't let me gdb (my own problem), I can't do a full
> bugreport as needed. All I can do is give system specs and mplayer
> mesgs to go from. I can start another thread on that if today's test
> doesn't work, maybe. (Due to workload changes, I may not even be able
> to today.)

Sorry, I did miss the word CVS.  In any case, I cannot reproduce.
In fact, I've just finished rewriting that change I was describing,
and -fs works fine for me in both the packages and plain vanilla CVS.

--Joey

--

-- 
"Of the seven dwarves, the only one who shaved was Dopey.
That should tell us something about the wisdom of shaving."

Gmane