mplayer-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Original]

Re: [MPlayer-users] rant


To: mplayer-users@xxxxxxxxxxxxxx
Subject: Re: [MPlayer-users] rant
From: André Dahlqvist <andre.dahlqvist@xxxxxxxxx>
Date: Mon, 8 Oct 2001 18:13:28 +0200
In-reply-to: <200110081551.RAA14408@thot.banki.hu>
References: <Pine.LNX.4.33.0110081840250.14589-100000@Paradise.NotHere> <200110081551.RAA14408@thot.banki.hu>
User-agent: Mutt/1.3.22i

Arpi <arpi@xxxxxxxxxxxxx> wrote:

> we need a gcc option.

Then, like Guillaume Serre pointed out, gcc -v will work:

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20010902 (Debian prerelease)



> 
> > that gives for me:
> >     gcc-2.96-94
> > 94 is the significant number. Anything above 85 will work fine. For less
> > than 85 I don't know. gcc-2.96-85 is a RECCOMENDED RedHat 7.x update.
> > -94 is the rawhide version.
> > 
> > 
> > > Old versions come in 8.0 and redhat 7.x are buggy. And we can't make
> > > the difference (neither test which works and which no) as all gcc reports
> > > 2.96. Isn't the version number used by redhat people? It should be gcc
> > > 2.96.x and x is the release (so we can change the check to allow for 
> > > example
> > > 2.96.85 but don't allow 2.96.81)
> > 
> > they relay on the Build number for versioning.
> > 
> if gcc 2.96-85 and 2.96-94 differs in _functinality_ then it should be
> different version (2.96 and 2.96.1 for example).
> same version number must cover the same functionality (but allow different
> builds, for example updates for different glibc or kernel etc)
> 
> 
> A'rpi / Astral & ESP-team
> 
> --
> mailto:arpi@xxxxxxxxxxxxx
> http://esp-team.scene.hu
> _______________________________________________
> MPlayer-users mailing list
> MPlayer-users@xxxxxxxxxxxx
> http://mplayerhq.hu/mailman/listinfo/mplayer-users

-- 

André Dahlqvist <andre.dahlqvist@xxxxxxxxx>


[Prev in Thread] Current Thread [Next in Thread]