Failure cpu detect on OS X i386
Brought to you by:
coudercd
Menu
▾
▴
Build log
Logged In: YES
user_id=1606330
Hi mduling,
first sorry for the late response but pmk's tracker was
broken for some time.
As i've no OSX box under the hand i need more info to fix
the problem :
- output of uname -a
- the output of as -v or as -V if available
- the version of pmk sources (see in premake.h)
Thanks for your feedback,
Damien
Logged In: YES
user_id=1348514
Hello Damien,
Thank you for responding. Below is the info.
Best regards,
Mark
uname -a
Darwin A005955.local 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/
RELEASE_I386 i386 i386
as -v
Apple Computer, Inc. version cctools-622.3.obj~2, GNU assembler version 1.38
as -V
+ /usr/libexec/gcc/darwin/i386/as -V
^CInterrupted by signal 2
Not sure what you mean by version of pmk sources. Here is what is at the top of the premake.h file of the 0.93 stable:
/* $Id: premake.h,v 1.119.2.1 2005/04/25 20:49:19 mipsator Exp $ */
Logged In: YES
user_id=1606330
Hi again,
i'm suspecting that the output of the preprocessed file is
not what we expect.
In order to verify it could you send me the output of
"/usr/bin/cpp detect_cpu_asm.s" ?
Thanks,
Damien
Logged In: YES
user_id=1348514
Damien,
Ok, I attached the output log you requested.
Thanks.
Mark
output log of "/usr/bin/cpp detect_cpu_asm.s"
Logged In: YES
user_id=1606330
Ok that's what i thought, the preprocessor doesn't seem to
know about architecture macros so it does not output code.
The problem is that GNU tools take .s files as assembly
files without macros and .S as assembly files to preprocess.
But i think this behavior is not standard on other assemblers.
I've tried to cheat by copying the file with .tmp and using
gcc -E but it doesn't want to work with unknown file
extension. Man, those GNU tools are so lame :/
So i must find if there is a macro for i386 MacOSX that the
preprocessor accept.
Else i'll try to see if .S is accepted by all the compilers
we know.
The third solution would be to copy with .c to pass through
gcc -E but it's a so ugly hack ...
Logged In: YES
user_id=1606330
A little update about this problem.
First i've been too quick in my previous reply, the assembly file is correctly
preprocessed.
I suspect that the object generated by the assembler has not the same symbols that the C
compiler is looking for. Could you provide the output of 'nm detect_cpu_asm.o' ?
I'm already working on such issue to be sure it will be fixed as soon as possible if you
confirm the problem.
Logged In: YES
user_id=1348514
The requested output is below. I really appreciate your hard work. Let me know if you need anything else.
Mark
nm detect_cpu_asm.o
00000000 T x86_check_cpuid_flag
0000003e D x86_cpu_reg_eax
00000042 D x86_cpu_reg_ebx
00000046 D x86_cpu_reg_ecx
0000004a D x86_cpu_reg_edx
0000001a T x86_exec_cpuid
Logged In: NO
Ok so we have now the problem clearly identified : the C
objects are waiting for leading underscores in front of
symbols while assembly object doesn't have them.
The solution now is to have the same symbol format in all
object files.
The fastest solution i see yet would be to use c99 (which i
think should be gcc) instead of as (that is gas in the info
you gave me) to compile assembly code. Then i think that gcc
should output symbols in the same way for both C and assembly.
To do that you just have to override AS in pmkcfg.sh like
the following : AS=c99 sh pmkcfg.sh
Tell me if it works.
Another way to do that should be to give
-fno-leading_underscores to c99 (again if c99 is gcc
disguised) to force it to remove leading underscores. The
opposite may be done with as if this one is accepting the
-fleading_underscore.
Anyway this problem is weird, all the chain tool should
behave in the same manner. Have you ever heard something
about such problem ?
BTW, are you aware of something similar to HP testdrive that
would permit me to access to MacOSX hosts for development
purposes ?
Logged In: NO
Ok so we have now the problem clearly identified : the C
objects are waiting for leading underscores in front of
symbols while assembly object doesn't have them.
The solution now is to have the same symbol format in all
object files.
The fastest solution i see yet would be to use c99 (which i
think should be gcc) instead of as (that is gas in the info
you gave me) to compile assembly code. Then i think that gcc
should output symbols in the same way for both C and assembly.
To do that you just have to override AS in pmkcfg.sh like
the following : AS=c99 sh pmkcfg.sh
Tell me if it works.
Another way to do that should be to give
-fno-leading_underscores to c99 (again if c99 is gcc
disguised) to force it to remove leading underscores. The
opposite may be done with as if this one is accepting the
-fleading_underscore.
Anyway this problem is weird, all the chain tool should
behave in the same manner. Have you ever heard something
about such problem ?
BTW, are you aware of something similar to HP testdrive that
would permit me to access to MacOSX hosts for development
purposes ?
Logged In: YES
user_id=1606330
Hi again,
it looks like i had some problem on another host with
firefox 2 so you had the previous mail anonymous.
Does the given solution has better results ?
Logged In: YES
user_id=1348514
Hi Damien,
I forgot to answer a previous questions. I don't know of any OS X development hosts anywhere. Also, I'm not technical
enough to have heard of this type of problem so I can't help there, sorry.
Yes, c99 is gcc.
c99 i686-apple-darwin8-gcc-4.0.1
gcc i686-apple-darwin8-gcc-4.0.1
'AS=c99 sh pmkcfg.sh' did not help. Did I do that right? The other method, should the -fno-leading_underscores be
given as 'CPPFLAGS=-fno-leading_underscores'? I tried that and it didn't work but maybe I didn't do it right.
Mark
Logged In: YES
user_id=1606330
Hello Mark,
could you send me the log of the session with AS=c99 so i
could know how it fails ?
For the second method it should be
"CFLAGS=-fno-leading-underscores sh pmkcfg.sh".
Thank you,
Damien