[PATCH] CPU detection related
Hi, cputable.h.diff contains information update, bug fixes and punctuation modifications to the original cputable.h. I suppose there's no reason to reject it:-) cpudetect.h.diff and cpudetect.c.diff together change the original behavior of mplayer: it first determines whether the CPU has a built-in namestring; if so, then the namestring is displayed and codenames in cputable.h aren't used; if not it'll fall back to the original behavior, looking up the cputable.h. I've explained the reasons for the last two patches in another thread. However, I don't go radical by removing cputable.h at all and depending on built-in namestring only, partly because only P4 or newer Intel CPUs have a namestring (all AMD CPUs supporting cpuid support namestring), and in memory of those who have collected all the odd codenames as well:-) The team are to decide whether to apply only cputable.h.diff, or apply all the three. In the latter case mplayer may contain dead codes and data, those that should never be executed or accessed on a commercially available CPU. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
Hi, On 10/16/05, Zuxy <zuxy.meng@gmail.com> wrote:
Hi,
cputable.h.diff contains information update, bug fixes and punctuation modifications to the original cputable.h. I suppose there's no reason to reject it:-)
cpudetect.h.diff and cpudetect.c.diff together change the original behavior of mplayer: it first determines whether the CPU has a built-in namestring; if so, then the namestring is displayed and codenames in cputable.h aren't used; if not it'll fall back to the original behavior, looking up the cputable.h.
I've explained the reasons for the last two patches in another thread. However, I don't go radical by removing cputable.h at all and depending on built-in namestring only, partly because only P4 or newer Intel CPUs have a namestring (all AMD CPUs supporting cpuid support namestring), and in memory of those who have collected all the odd codenames as well:-)
The team are to decide whether to apply only cputable.h.diff, or apply all the three. In the latter case mplayer may contain dead codes and data, those that should never be executed or accessed on a commercially available CPU.
I'd much prefer to rely on the built-in namestring whenever it's available. In my case, here's how the old: CPUDETECT: CPU: Advanced Micro Devices (Family: 15, Stepping: 0) and new: CPUDETECT: CPU: AMD Athlon(tm) 64 Processor 3400+ (Family: F, Model: C, Stepping: 0) CPU detection looks like. The new form is much-much better IMHO. The code looks Okay to me. Comments? Guillaume -- Reading doesn't hurt, really! -- Dominik 'Rathann' Mierzejewski
Hi Zuxy! On 2005.10.16 at 19:12:20 +0800, Zuxy wrote next:
cputable.h.diff contains information update, bug fixes and punctuation modifications to the original cputable.h. I suppose there's no reason to reject it:-)
Though I'm not a developer, I have some suggestions: 1) You'd better send text files with LF endings. People around here don't like text files in dos format ;) 2) WTF is "main.new\cpudetect.c"?? GNU patch (2.5.4) doesn't understand stuff like this, I had to convert them to "/" manually. I strongly suggest you to resend patch with correct dir separators. 3) You misunderstood the idea about splitting a patch to several small ones. You shouldn't make a separate patch for every file you modify; patch cpudetect.c.diff will break compilation if applied without cpudetect.h.diff - what's the point in splitting them then? It's confusing.. 4) Why don't you add a codename of my sempron processor too? ;) processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 44 model name : AMD Sempron(tm) Processor 2800+ stepping : 2 cpu MHz : 2663.728 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm bogomips : 5275.64 Right now without your patch mplayer detects it as CPU: Advanced Micro Devices (Family: 15, Stepping: 2) With your patch, it's CPU: AMD Sempron(tm) Processor 2800+ (Family: F, Model: 2C, Stepping: 2) Its codename is Paris, if I'm not mistaken. -- Vladimir
2005/10/16, Vladimir Mosgalin <mosgalin@vm10124.spb.edu>:
Hi Zuxy!
Though I'm not a developer, I have some suggestions: 1) You'd better send text files with LF endings. People around here don't like text files in dos format ;)
I really don't think so....CRLF isn't that bad, is it?
2) WTF is "main.new\cpudetect.c"?? GNU patch (2.5.4) doesn't understand stuff like this, I had to convert them to "/" manually. I strongly suggest you to resend patch with correct dir separators.
Just conventinal. I'm using mplayer under win32 and I'm developing under mingw32.
3) You misunderstood the idea about splitting a patch to several small ones. You shouldn't make a separate patch for every file you modify; patch cpudetect.c.diff will break compilation if applied without cpudetect.h.diff - what's the point in splitting them then? It's confusing..
I'm sorry about this....
4) Why don't you add a codename of my sempron processor too? ;) processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 44 model name : AMD Sempron(tm) Processor 2800+ stepping : 2 cpu MHz : 2663.728 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm bogomips : 5275.64
Right now without your patch mplayer detects it as CPU: Advanced Micro Devices (Family: 15, Stepping: 2) With your patch, it's CPU: AMD Sempron(tm) Processor 2800+ (Family: F, Model: 2C, Stepping: 2)
Its codename is Paris, if I'm not mistaken.
I've explained that in another thread, maintaining model->codename mapping is hell. I've dropped that. And from your reply I can see that even /proc/cpuinfo has dropped that either. You case isn't that simple. When looking for codename mplayer didn't care extended model (2 for your cpu), so it indexed into cputable with family 0xf and model 0xc, and what would it get? It would be "Athlon 64 Newcastle" which has model 0xc (not 0x2c). I'm much against this because two cpus with totally different models are treated alike, really confusing and may be misleading. Take a look at last line for AMD cpu (model 0xf) you'll know why I prefer namestring:-)BTW that line is far from complete since I didn't incorporate codenames for Opterons with model 0xf, and Semprons too, perhaps. Anyway if you prefer the old way you can just apply the first patch and discard the other two (should have been the other one:-)), and update cputable.h yourself and send it to the team. New codenames are always welcome; I just won't do it myself. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
Hi Zuxy! On 2005.10.16 at 20:43:27 +0800, Zuxy wrote next:
Though I'm not a developer, I have some suggestions: 1) You'd better send text files with LF endings. People around here don't like text files in dos format ;)
I really don't think so....CRLF isn't that bad, is it?
No, it was a joke. However, \ vs / issue is more of a problem, since patch has problems with it.
2) WTF is "main.new\cpudetect.c"?? GNU patch (2.5.4) doesn't understand stuff like this, I had to convert them to "/" manually. I strongly suggest you to resend patch with correct dir separators.
Just conventinal. I'm using mplayer under win32 and I'm developing under mingw32.
Conventional way is to use /, both windows and unix understand this. \, however, is windows-specific. Mingw/cygwin environments are unix-based anyway, they approve usage of / for portability. Also, only / must be used for patches in diff format - it's tradition. (not to mention that argument "I'm developing under win32" is inferior to the fact that developers who will be applying your patch are most likely are using linux)
processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 44 model name : AMD Sempron(tm) Processor 2800+ stepping : 2 cpu MHz : 2663.728 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm bogomips : 5275.64
Right now without your patch mplayer detects it as CPU: Advanced Micro Devices (Family: 15, Stepping: 2) With your patch, it's CPU: AMD Sempron(tm) Processor 2800+ (Family: F, Model: 2C, Stepping: 2)
Its codename is Paris, if I'm not mistaken.
I've explained that in another thread, maintaining model->codename mapping is hell. I've dropped that. And from your reply I can see that even /proc/cpuinfo has dropped that either.
Er.. what? If you are talking about "model name" string, it's just a string given by bios. After I upgraded to this CPU from A64 3000+ (Newcastle) old bios on the mobo knew nothing about this new cpu, and the string was "AMD Hammer Family - Model unknown" both on the boot screen and in cpuinfo. After I updated bios, it became like this. I don't think it's reliable to rely on such kind of information, but be it your way..
You case isn't that simple. When looking for codename mplayer didn't care extended model (2 for your cpu), so it indexed into cputable with family 0xf and model 0xc, and what would it get? It would be "Athlon 64 Newcastle" which has model 0xc (not 0x2c). I'm much against this because two cpus with totally different models are treated alike, really confusing and may be misleading.
But that is a problem of current detection code, the overall idea still works.. Especially with modern CPUs, you can precisely get its name and other information from cpuid.
Take a look at last line for AMD cpu (model 0xf) you'll know why I prefer namestring:-)BTW that line is far from complete since I didn't incorporate codenames for Opterons with model 0xf, and Semprons too, perhaps.
Anyway if you prefer the old way you can just apply the first patch and discard the other two (should have been the other one:-)), and update cputable.h yourself and send it to the team. New codenames are always welcome; I just won't do it myself.
No, I like the new too (but think about problem I described), it's just that I was surprised by the fact that you missed the model name of the CPU; from some older thread, I was under impression that you've been looking through AMD/Intel sites for information about processor models, and I thought that you updated cpu table from the latest model tables on both sites. Looks like I was wrong and you picked only several ones. By looking at the model number at /proc/cpuinfo, it wasn't clear at all what exactly should have I modified in cputable.h, that's why I sent cpuinfo contents and the codename to you. But if you don't feel like giving an example and vote for throwing away the whole codenames system, that's fine.. -- Vladimir
2005/10/17, Vladimir Mosgalin <mosgalin@vm10124.spb.edu>:
Hi Zuxy!
Er.. what? If you are talking about "model name" string, it's just a string given by bios. After I upgraded to this CPU from A64 3000+ (Newcastle) old bios on the mobo knew nothing about this new cpu, and the string was "AMD Hammer Family - Model unknown" both on the boot screen and in cpuinfo. After I updated bios, it became like this.
I don't think it's reliable to rely on such kind of information, but be it your way..
No it's not from BIOS. It's obtained directly from the CPU so we could give accurate information even for a future CPU. But AMD obviously provides a way for BIOS to modify such namestring through MSRs, so most possibly your old BIOS has changed the default namestring on boot, while your new BIOS leaves it untouched. I'm quite confused by AMD's decision. I see no good in modifying the default namestring and it may be utilized by remarkers. I'm for the Intel way, where the namestring's hardwired and can never be changed by software.
But that is a problem of current detection code, the overall idea still works.. Especially with modern CPUs, you can precisely get its name and other information from cpuid.
Absolutely if we have known the family, the extended family, the model, the extended model, the stepping, the cache information and maybe something else. That's what x86info and cpu-z do. But it's not mplayer's main focus and I'm lazy...sorry.
No, I like the new too (but think about problem I described), it's just that I was surprised by the fact that you missed the model name of the CPU; from some older thread, I was under impression that you've been looking through AMD/Intel sites for information about processor models, and I thought that you updated cpu table from the latest model tables on both sites. Looks like I was wrong and you picked only several ones.
Firstly, there are no official documents for codenames from either company. AMD in their docs will refer your CPU as "Sempron Processor Model 2C" instead of "Paris", so I have to get them from somewhere else. I knew there's Paris but I didn't know it means Model 2C until you told me:-) And lastly, if we use the namestring system AMD codenames simply get ignored because virtually all AMD CPUs support namestring (it means you won't get Paris if you've applied all the patches).
By looking at the model number at /proc/cpuinfo, it wasn't clear at all what exactly should have I modified in cputable.h, that's why I sent cpuinfo contents and the codename to you. But if you don't feel like giving an example and vote for throwing away the whole codenames system, that's fine..
cputable.h is simple and well commented, just an array indexed by vendors, families and models and filled with codenames. For you case, look for vendor "AuthenticAMD", family 'F' and model 'C' (the least significant nibble of your displayed model '2C') and add " ;Sempron Paris" after "Athlon 64 Newcastle". Use '/' to seperate multiple trademarks, use ',' to seperate multiple codenames and use '; ' to seperate a trademark from preceding codenames, like: Pentium 4/Celeron 4 Northwood; Xeon Prestonia,Gallatin for GeniuneIntel Family F Model 2. Again, if you are to maintain cputable.h you probably won't like the other patch because it effectively eliminates you work. Good luck! -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
On Sun, Oct 16, 2005 at 08:43:27PM +0800, Zuxy wrote:
2005/10/16, Vladimir Mosgalin <mosgalin@vm10124.spb.edu>:
Though I'm not a developer, I have some suggestions: 1) You'd better send text files with LF endings. People around here don't like text files in dos format ;)
I really don't think so....CRLF isn't that bad, is it?
It's annoying...
2) WTF is "main.new\cpudetect.c"?? GNU patch (2.5.4) doesn't understand stuff like this, I had to convert them to "/" manually. I strongly suggest you to resend patch with correct dir separators.
Just conventinal. I'm using mplayer under win32 and I'm developing under mingw32.
Then use Cygwin to create your patches. That's how I work on Windows boxes. Only compile under MinGW, do the rest under Cygwin. Patch rejected, I can't apply it. Resend something sane. Diego
No problem, here we go:-) Again, you can apply the first only without changing original behavior, or both. 2005/10/18, Diego Biurrun <diego@biurrun.de>:
On Sun, Oct 16, 2005 at 08:43:27PM +0800, Zuxy wrote:
Patch rejected, I can't apply it. Resend something sane.
-- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
On Tue, Oct 18, 2005 at 01:34:29PM +0800, Zuxy wrote:
No problem, here we go:-)
Again, you can apply the first only without changing original behavior, or both.
First patch applied. Diego P.S.: Please don't top-post.
2005/10/18, Diego Biurrun <diego@biurrun.de>:
On Sun, Oct 16, 2005 at 08:43:27PM +0800, Zuxy wrote:
Patch rejected, I can't apply it. Resend something sane.
Hi, 2005/10/18, Diego Biurrun <diego@biurrun.de>:
On Tue, Oct 18, 2005 at 01:34:29PM +0800, Zuxy wrote:
No problem, here we go:-)
Again, you can apply the first only without changing original behavior, or both.
Now before releasing pre8 I again suggest applying the second patch so users won't complain that pre8 can't recognize their brand new Core Duo or Pentium D 931 blah blah blah... -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
Hi, On 5/13/06, Zuxy Meng <zuxy.meng@gmail.com> wrote:
Hi,
2005/10/18, Diego Biurrun <diego@biurrun.de>:
On Tue, Oct 18, 2005 at 01:34:29PM +0800, Zuxy wrote:
No problem, here we go:-)
Again, you can apply the first only without changing original behavior, or both.
Now before releasing pre8 I again suggest applying the second patch so users won't complain that pre8 can't recognize their brand new Core Duo or Pentium D 931 blah blah blah...
I had it in my tree in the past, it worked all right, and provided some more usefull information about cpu than current system: current: CPUDETECT: CPU: Advanced Micro Devices (Family: 15, Stepping: 0) and new: CPUDETECT: CPU: AMD Athlon(tm) 64 Processor 3400+ (Family: F, Model: C, Stepping: 0) Thoughts? Comments? This is not likely to break anything, and indeed future-proofs our future release. Guillaume -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
On Sat, May 13, 2006 at 12:23:00PM +0800, Zuxy Meng wrote:
Now before releasing pre8 I again suggest applying the second patch so users won't complain that pre8 can't recognize their brand new Core Duo or Pentium D 931 blah blah blah...
This hunk has inconsistent indentation with the rest of the block: + while(*ptmpstr == ' ') + ptmpstr++; Also, your patch does not apply here, please resend: patching file cpudetect.c Hunk #1 succeeded at 118 (offset 4 lines). Hunk #2 FAILED at 144. Hunk #3 succeeded at 229 (offset 4 lines). Hunk #4 succeeded at 239 (offset 4 lines). 1 out of 4 hunks FAILED -- saving rejects to file cpudetect.c.rej Diego
Hi, 2006/5/14, Diego Biurrun <diego@biurrun.de>:
This hunk has inconsistent indentation with the rest of the block:
+ while(*ptmpstr == ' ') + ptmpstr++;
Also, your patch does not apply here, please resend:
patching file cpudetect.c Hunk #1 succeeded at 118 (offset 4 lines). Hunk #2 FAILED at 144. Hunk #3 succeeded at 229 (offset 4 lines). Hunk #4 succeeded at 239 (offset 4 lines). 1 out of 4 hunks FAILED -- saving rejects to file cpudetect.c.rej
I hope this works. Test with your K6-3+ first:-) It has builtin name string. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
On Sun, May 14, 2006 at 08:28:15PM +0800, Zuxy Meng wrote:
I hope this works. Test with your K6-3+ first:-) It has builtin name string.
before: CPU: Advanced Micro Devices K6-2+/K6-III+ Sharptooth (Family: 5, Stepping: 0) after: CPU: AMD-K6(tm)-III Processor (Family: 5, Model: 13, Stepping: 0) Hmm, there is a difference between a K6-III and a K6-III+, so a little bit of information got lost... Diego
2006/5/14, Diego Biurrun <diego@biurrun.de>:
On Sun, May 14, 2006 at 08:28:15PM +0800, Zuxy Meng wrote:
I hope this works. Test with your K6-3+ first:-) It has builtin name string.
before: CPU: Advanced Micro Devices K6-2+/K6-III+ Sharptooth (Family: 5, Stepping: 0)
after: CPU: AMD-K6(tm)-III Processor (Family: 5, Model: 13, Stepping: 0)
Hmm, there is a difference between a K6-III and a K6-III+, so a little bit of information got lost...
We now have the model number to compensate this. Besides, it's quite difficult to maintain a list of codenames. cputables.h has already been outdated for a while. BTW, a K6-III will say "AMD-K6(tm)-3D+ Processor" IIRC. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
Hi, On 5/14/06, Diego Biurrun <diego@biurrun.de> wrote:
On Sun, May 14, 2006 at 08:28:15PM +0800, Zuxy Meng wrote:
I hope this works. Test with your K6-3+ first:-) It has builtin name string.
before: CPU: Advanced Micro Devices K6-2+/K6-III+ Sharptooth (Family: 5, Stepping: 0)
after: CPU: AMD-K6(tm)-III Processor (Family: 5, Model: 13, Stepping: 0)
Hmm, there is a difference between a K6-III and a K6-III+, so a little bit of information got lost...
In a certain way, yes, but the triplet Family, Model, Stepping is enough if you need to really know what model you are using. Zuxy, do you think it could be possible to take the information from the table if they exist, and fallback to built-in name string? Guillaume -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
Hi, On 5/14/06, Guillaume POIRIER <poirierg@gmail.com> wrote:
Hi,
On 5/14/06, Diego Biurrun <diego@biurrun.de> wrote:
In a certain way, yes, but the triplet Family, Model, Stepping is enough if you need to really know what model you are using.
Zuxy, do you think it could be possible to take the information from the table if they exist, and fallback to built-in name string?
New test: old: CPU: Intel Pentium M Dothan (Family: 6, Stepping: 6) new: CPU: Intel(R) Celeron(R) M processor 1.30GHz (Family: 6, Model: 13, Stepping: 6) Your patch works beautifully, and needs to be merged, however, Since I like core codenames, I would love if we could have the best of both approaches (fallback to built-in string if table look up failed). Guillaume -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
2006/5/14, Guillaume POIRIER <poirierg@gmail.com>:
Hi,
New test:
old: CPU: Intel Pentium M Dothan (Family: 6, Stepping: 6) new: CPU: Intel(R) Celeron(R) M processor 1.30GHz (Family: 6, Model: 13, Stepping: 6)
Well, you're lucky here because you're using Intel's CPU so the codename's accurate (for now). But K8s' are not because AMD has been using extended models extensively. Just take a look at cputables.h:-)
Your patch works beautifully, and needs to be merged, however, Since I like core codenames, I would love if we could have the best of both approaches (fallback to built-in string if table look up failed).
-- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
Hi, On 5/14/06, Zuxy Meng <zuxy.meng@gmail.com> wrote:
I hope this works. Test with your K6-3+ first:-) It has builtin name string.
A little review of your patch: - char vendor[17]; + char vendor[13]; I imagine you have a good reason to diminish the size of this array. Could you please confirm that vendor string can't exceed 12+\0 chars? Guillaume -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
Hi, 2006/5/15, Guillaume POIRIER <poirierg@gmail.com>:
Hi,
A little review of your patch:
- char vendor[17]; + char vendor[13];
I imagine you have a good reason to diminish the size of this array. Could you please confirm that vendor string can't exceed 12+\0 chars?
Vendor string is returned in ebx, edx & ecx when executing cpuid with eax = 0. It's fixed in 128 bits. -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6
Hi, On 5/15/06, Zuxy Meng <zuxy.meng@gmail.com> wrote:
Hi,
2006/5/15, Guillaume POIRIER <poirierg@gmail.com>:
Hi,
A little review of your patch:
- char vendor[17]; + char vendor[13];
I imagine you have a good reason to diminish the size of this array. Could you please confirm that vendor string can't exceed 12+\0 chars?
Vendor string is returned in ebx, edx & ecx when executing cpuid with eax = 0. It's fixed in 128 bits.
Thanks, Applied Guillaume -- An Israeli man's life was saved when he was given a Palestinian man's heart in a heart transplant operation. The guy is doing fine, but the bad news is, he can't stop throwing rocks at himself. -- Jay Leno
Hi, On 10/18/05, Diego Biurrun <diego@biurrun.de> wrote:
On Sun, Oct 16, 2005 at 08:43:27PM +0800, Zuxy wrote:
2005/10/16, Vladimir Mosgalin <mosgalin@vm10124.spb.edu>:
Though I'm not a developer, I have some suggestions: 1) You'd better send text files with LF endings. People around here don't like text files in dos format ;)
I really don't think so....CRLF isn't that bad, is it?
It's annoying...
2) WTF is "main.new\cpudetect.c"?? GNU patch (2.5.4) doesn't understand stuff like this, I had to convert them to "/" manually. I strongly suggest you to resend patch with correct dir separators.
Just conventinal. I'm using mplayer under win32 and I'm developing under mingw32.
Then use Cygwin to create your patches. That's how I work on Windows boxes. Only compile under MinGW, do the rest under Cygwin.
Patch rejected, I can't apply it. Resend something sane.
The versions of patch that I use on my windows (mingw) or unix box have no problem dealing with CR/LF line ending and "/" or "\" as sub-directory separator. Guillaume -- Reading doesn't hurt, really! -- Dominik 'Rathann' Mierzejewski
On Tue, Oct 18, 2005 at 07:37:09AM +0200, Guillaume POIRIER wrote:
On 10/18/05, Diego Biurrun <diego@biurrun.de> wrote:
On Sun, Oct 16, 2005 at 08:43:27PM +0800, Zuxy wrote:
2005/10/16, Vladimir Mosgalin <mosgalin@vm10124.spb.edu>:
2) WTF is "main.new\cpudetect.c"?? GNU patch (2.5.4) doesn't understand stuff like this, I had to convert them to "/" manually. I strongly suggest you to resend patch with correct dir separators.
Just conventinal. I'm using mplayer under win32 and I'm developing under mingw32.
Then use Cygwin to create your patches. That's how I work on Windows boxes. Only compile under MinGW, do the rest under Cygwin.
Patch rejected, I can't apply it. Resend something sane.
The versions of patch that I use on my windows (mingw) or unix box have no problem dealing with CR/LF line ending and "/" or "\" as sub-directory separator.
Mine has and I cannot be bothered to investigate this in all details. Diego
On Tue, Oct 18, 2005 at 10:18:18AM +0200, Diego Biurrun wrote:
On Tue, Oct 18, 2005 at 07:37:09AM +0200, Guillaume POIRIER wrote:
On 10/18/05, Diego Biurrun <diego@biurrun.de> wrote:
On Sun, Oct 16, 2005 at 08:43:27PM +0800, Zuxy wrote:
2005/10/16, Vladimir Mosgalin <mosgalin@vm10124.spb.edu>:
2) WTF is "main.new\cpudetect.c"?? GNU patch (2.5.4) doesn't understand stuff like this, I had to convert them to "/" manually. I strongly suggest you to resend patch with correct dir separators.
Just conventinal. I'm using mplayer under win32 and I'm developing under mingw32.
Then use Cygwin to create your patches. That's how I work on Windows boxes. Only compile under MinGW, do the rest under Cygwin.
Patch rejected, I can't apply it. Resend something sane.
The versions of patch that I use on my windows (mingw) or unix box have no problem dealing with CR/LF line ending and "/" or "\" as sub-directory separator.
Mine has and I cannot be bothered to investigate this in all details.
On unix, all files are binary. A patch line that says: + [stuff here] ^M means add a line that actually contains a ^M at the end of it. If it didn't work this way patch would not work on binary files. On windows, text files are treated specially and using the basic text tools on binary files will break horribly.. Rich
participants (6)
-
Diego Biurrun -
Guillaume POIRIER -
Rich Felker -
Vladimir Mosgalin -
Zuxy -
Zuxy Meng