[MPlayer-dev-eng] [PATCH] Paths for x86_64

[Martin Braun]

D Richard Felker III wrote:
> On Mon, Dec 27, 2004 at 05:28:25AM +0100, Martin Braun wrote:
> 
>>D Richard Felker III wrote:
>> this patch is blatently incorrect. lib64 should NOT BE USED BY
>>
>>>DEFAULT!!! it is a broken, nonstandard practice by broken distros!!!
>>>btw the shell code in the -dumpmachine parsing also has 5l nonsense in
>>>it.
>>>
>>>let me clarify: ANY patch containing lib64 crap will be rejected
>>>unless it satisfies the following conditions:
>>>
>>>- unobtrusive in the configure script, i.e. no bloated extra
>>> conditions or silly code that doesn't make sense.
>>>
>>>- unobtrusive with respect to not messing up compile on
>>> standars-compliant x86-64 systems. this means lib64 can never be
>>> selected unless the script detects you're using a broken system with
>>> libraries in the wrong places. how you detect that is up to you, but
>>> some ideas are either specific distro-detection, or checking for the
>>> presence of $prefix/lib64 in the filesystem.
>>>
>>
>>Did you read the right patch ? Among lots of other things the
>>presence of $prefix/lib is checked. If you missed that and do not
>>understand what the case "`$_cc -dumpmachine ...`" is for you should
>>ask a more knowledgable person to check the patch.
> 
> 
> sorry, i did miss the chack (for $prefix/lib64, not $prefix/lib). as
> for the test, it's like this:
> 
> 
>>+  case "`$_cc -dumpmachine | cut -d- -f1`" in
>>+  x86_64|x86-64|amd64)
> 
> 
> but after cut -d1 -f1, there's no way the result can still have a - in
> it. having impossible cases there makes the code confusing, and makes
> it look like there's a bug (if x86-64 was actually supposed to be a
> possibility). i would recommend the following instead:
> 
> case "`$_cc -dumpmachine`" in
> x86_64-*|amd64-*)
> 
> again sorry i missed the check for lib64 dir presence. i've just been
> really irritable over this while lib64 mess because i can't believe
> distros are doing something so stupid yet again... otherwise the patch
> looks basically good, so i'll shut up and stop complaining.
> 
You are right, the check for both 'x86_64' and 'x86-64' is not
neccessary in my check_linux_lib64 function, but it is needed elsewhere.
This is due to problem with the initialization of host_arch in
configure.
The initialization depends on the presence of a --target command line
parameter (see line 419 in configure current CVS). Autodetection works
just fine, but if configure is invoked using
`./configure --target=x86_64-redhat-linux-gnu  ...' (Fedora Core 3 rpm
macro %configure does that) the underscore in 'x86_64' gets converted
to a hyphen for reasons I fail to see (line 500).  Does someone have an
explanation for that ?
That value is later used for CPU detection (line 930).
My patch uses both 'x86_64' and 'x86-64' there but the right thing
would be a consistent initialization of host_arch.

Redgards,

Martin
> rich
> 
> 
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> 
>