Building 0.93 and the 0902 snapshot fails on OS X /w Intel processors. I
also tried the latest patch in subversion for detect_cpu_asm.s. See
attached build.log.
Sorry Mark, i though you had updated from 0.9.3 to current lately that is why the new
pmkcfg.sh is not in sync.
You have two solutions: getting the latest snapshot from PMK which is snap 20061028
(which is just waiting a fix to your problem to become 0.10) or i can send you a patch to
fix pmkcfg.sh of the 0.9.3 version.
Let me know what you prefer.
Damien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh that's my fault, I should have said. If you wouldn't mind sending a patch for 0.93 that would be great. The
reason is I want to update a pmk MacPort (formerly DarwinPorts), and they prefer versioned tarballs when
possible. Thanks a lot.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've attached the diff to update AS override in pmkcfg.sh of
the 0.9.3 version.
As soon as you confirm that the problem is fixed, i'll start
the release process of pmk 0.10.
This means that you should be able to update the Darwin port
in the next days with all the new features and improvements
we added since 0.9.3 (more than one year ago).
Crossing fingers,
Damien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Argh ! The C compiler does the same thing than the assembler.
I'm sorry but i do not see any solution now. The chaintool
does not do it's work correctly. Projects that mix assembly
and C code must all fail on MacOS X Intel machines.
Do you know if MPlayer can compile ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well you gave it a heroic effort. I am not a programmer so I can't answer about other ports that mix assembler
and c, but funny you'd ask about Mplayer because MPlayer 1.0rc1 was committed to MacPorts hours ago and this
is supposed to now compile on OS X Intel. A few more hours and I should be able to try it. If I can run any tests
for you with mplayer let me know. Thanks for your efforts.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Mark,
I'll look at what has been done on MPlayer as this is a port
that should have about the same build process.
Concerning the efforts, i'm not feeling as a hero because
PMK is a project that has been founded with portability and
standards in mind. And also as it's a tool that is aimed to
help other projects to be more portable, it's better that it
builds on most POSIX systems ;-)
Thanks for your patience too,
Damien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bad news,
MPlayer no longer uses an assembly file but use C embedded
assembly instead.
This must be why they can compile their assembly stuff
without the problem we have.
But at the same time they had another building problem where
somebody told them that toolchain is broken :
'Since mplayer.c does not contain any assembler code, this
line: > {standard input}:6244:operands given don't match any
known 386 instruction means that your assembler can not
parse the output of your compiler. Removing "-O4
-march=pentium3 -mtune=pentium3" from the CFLAGS might help,
but it is just a workaround around a bug in yout toolchain
(incompatible versions of gcc and binutils). So not a
MPlayer bug.'
That comment is from April 2006, but i think there is still
something wrong in the toolchain.
I must digg to find a darwin porter that could give me some
tips about the new Intel architecture ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1348514
I've attached logs of both methods. Thanks so much for your efforts.
output of build using as=c99
build log using cflags
Logged In: YES
user_id=1606330
Ah ! Finaly i see the light on the other side of the tunnel.
Please replace your pmkcfg.sh with the one i attached to the
tracker.
Then use AS="c99 -c" sh pmkcfg.sh and i think it should
finaly work !
The problem was that i didn't take account of the override
for AS.
Damien
new config script with better AS support
Logged In: YES
user_id=1348514
Damien,
The new pkmcfg.sh changed this and that file isn't there. I changed it back to the original form. Is that correct?
-tmpl_list="Makefile.pmk compat/compat.h.in tests/Makefile.pmk"
+tmpl_list="Makefile.pmk compat/config.h.pmk tests/Makefile.pmk"
Then when the build starts I get this. I tried setting those variables but perhaps I didn't do it right. It seems they have
no defaults.
c99 -o pmk @LDFLAGS@ autoconf.o cfgtool.o common.o compat.o detect.o dynarray.o func.o functool.o hash.o
hash_tools.o parse.o pmk_obj.o pathtools.o pkgconfig.o pmk.o @LGEN_FLAGS@
i686-apple-darwin8-gcc-4.0.1: @LDFLAGS@: No such file or directory
i686-apple-darwin8-gcc-4.0.1: @LGEN_FLAGS@: No such file or directory
make: *** [pmk] Error 1
Mark
Related
pmk: pmk
Logged In: YES
user_id=1606330
Sorry Mark, i though you had updated from 0.9.3 to current lately that is why the new
pmkcfg.sh is not in sync.
You have two solutions: getting the latest snapshot from PMK which is snap 20061028
(which is just waiting a fix to your problem to become 0.10) or i can send you a patch to
fix pmkcfg.sh of the 0.9.3 version.
Let me know what you prefer.
Damien
Logged In: YES
user_id=1348514
Oh that's my fault, I should have said. If you wouldn't mind sending a patch for 0.93 that would be great. The
reason is I want to update a pmk MacPort (formerly DarwinPorts), and they prefer versioned tarballs when
possible. Thanks a lot.
Logged In: YES
user_id=1606330
I've attached the diff to update AS override in pmkcfg.sh of
the 0.9.3 version.
As soon as you confirm that the problem is fixed, i'll start
the release process of pmk 0.10.
This means that you should be able to update the Darwin port
in the next days with all the new features and improvements
we added since 0.9.3 (more than one year ago).
Crossing fingers,
Damien
pmkcfg.sh diff to fix AS override
Logged In: YES
user_id=1348514
Damien,
I applied the patch to 0.9.3 but I still get the undefined symbols error.
Mark
AS="c99 -c" sh pmkcfg.sh
Autodetecting POSIX shell
Using /bin/sh pmkcfg.sh
USERMODE OFF.
Getting 'CFLAGS' value : ''
Getting 'LDFLAGS' value : ''
Checking binary 'cc' : yes
Checking binary 'cpp' : yes
AS defined, skipping assembler.
Checking function 'strlcpy' in header 'string.h' : yes
Checking function 'strlcat' in header 'string.h' : yes
Checking type '_Bool' : yes
Checking type 'blkcnt_t' in header 'sys/types.h' : yes
Checking header 'stdbool.h' : yes
Checking header 'libgen.h' : yes
Checking function 'isblank' in header 'ctype.h' : yes
Checking function 'mkstemps' in header 'unistd.h' : yes
Checking function 'dirname' in library 'lgen' : no
mark:~/Desktop/pmk-0.9.3 mduling$ make
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o autoconf.o -c autoconf.c
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o cfgtool.o -c cfgtool.c
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o common.o -c common.c
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o compat.o -c compat.c
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o detect.o -c detect.c
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o dynarray.o -c dynarray.c
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o func.o -c func.c
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o functool.o -c functool.c
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o hash.o -c hash.c
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o hash_tools.o -c hash_tools.c
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o parse.o -c parse.c
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o pmk_obj.o -c pmk_obj.c
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o pathtools.o -c pathtools.c
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o pkgconfig.o -c pkgconfig.c
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o pmk.o -c pmk.c
/usr/bin/cc -o pmk autoconf.o cfgtool.o common.o compat.o detect.o dynarray.o func.o functool.o hash.o
hash_tools.o parse.o pmk_obj.o pathtools.o pkgconfig.o pmk.o
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o detect_cpu.o -c detect_cpu.c
/usr/bin/cpp detect_cpu_asm.s | sed '/^#/d' > tmp_asm.s
c99 -c -o detect_cpu_asm.o tmp_asm.s
tmp_asm.s:51:Alignment too large: 15. assumed.
rm tmp_asm.s
/usr/bin/cc -DSYSCONFDIR=\"/etc\" -DCONFDIR=\"/etc/pmk\" -DDATADIR=\"/usr/local/share/pmk\" -
DPRIVSEP_USER=\"nobody\" -o pmksetup.o -c pmksetup.c
/usr/bin/cc -o pmksetup common.o compat.o dynarray.o hash.o parse.o pmk_obj.o detect_cpu.o
detect_cpu_asm.o pmksetup.o
/usr/bin/ld: Undefined symbols:
_x86_check_cpuid_flag
_x86_cpu_reg_eax
_x86_cpu_reg_ebx
_x86_cpu_reg_ecx
_x86_cpu_reg_edx
_x86_exec_cpuid
collect2: ld returned 1 exit status
make: *** [pmksetup] Error 1
Logged In: YES
user_id=1606330
Argh ! The C compiler does the same thing than the assembler.
I'm sorry but i do not see any solution now. The chaintool
does not do it's work correctly. Projects that mix assembly
and C code must all fail on MacOS X Intel machines.
Do you know if MPlayer can compile ?
Logged In: YES
user_id=1348514
Damien,
Well you gave it a heroic effort. I am not a programmer so I can't answer about other ports that mix assembler
and c, but funny you'd ask about Mplayer because MPlayer 1.0rc1 was committed to MacPorts hours ago and this
is supposed to now compile on OS X Intel. A few more hours and I should be able to try it. If I can run any tests
for you with mplayer let me know. Thanks for your efforts.
Mark
Logged In: YES
user_id=1606330
Thanks Mark,
I'll look at what has been done on MPlayer as this is a port
that should have about the same build process.
Concerning the efforts, i'm not feeling as a hero because
PMK is a project that has been founded with portability and
standards in mind. And also as it's a tool that is aimed to
help other projects to be more portable, it's better that it
builds on most POSIX systems ;-)
Thanks for your patience too,
Damien
Logged In: YES
user_id=1606330
Bad news,
MPlayer no longer uses an assembly file but use C embedded
assembly instead.
This must be why they can compile their assembly stuff
without the problem we have.
But at the same time they had another building problem where
somebody told them that toolchain is broken :
'Since mplayer.c does not contain any assembler code, this
line: > {standard input}:6244:operands given don't match any
known 386 instruction means that your assembler can not
parse the output of your compiler. Removing "-O4
-march=pentium3 -mtune=pentium3" from the CFLAGS might help,
but it is just a workaround around a bug in yout toolchain
(incompatible versions of gcc and binutils). So not a
MPlayer bug.'
That comment is from April 2006, but i think there is still
something wrong in the toolchain.
I must digg to find a darwin porter that could give me some
tips about the new Intel architecture ...