Discussion:
[Pearpc-devel] compilation problems under intel imac
Panayotis Katsaloulis
2006-03-01 13:21:01 UTC
Permalink
Hello

I was trying to compile pearpc under the intel imac, but this is not possible.
It looks like a linking problem, which is really strange.

configuration results:

================================================================================
Configuration summary
================================================================================

cpu emulation method: cpu_jitc_x86
compiled for architecture: x86
compiled for OS-API: posix
compiled for UI system: x11
enable debug: no
enable profiling: no
make release build: yes
omit frame pointer: yes
final C compiler flags: -Wundef -Wall -fsigned-char -O2
-fomit-frame-pointer -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -pipe
final C++ compiler flags: -Wundef -Wall
-Woverloaded-virtual -fsigned-char -O2 -fomit-frame-pointer
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -pipe
final linker flags: -L/usr/X11R6/lib
final linker add: -lX11

================================================================================


Here is where compilation breaks:

g++ -Wundef -Wall -Woverloaded-virtual -fsigned-char -O2
-fomit-frame-pointer -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -pipe
-o ppc -L/usr/X11R6/lib main.o ppc_img.o ppc_font.o
ppc_button_changecd.o configparser.o cpu/cpu_jitc_x86/libcpu.a
io/graphic/libgraphic.a io/ide/libide.a system/ui/x11/libui.a
debug/libdebug.a io/libio.a io/prom/libprom.a io/prom/fs/libfs.a
io/prom/fs/hfs/libhfs.a io/prom/fs/hfsplus/libhfsplus.a
io/pic/libpic.a io/pci/libpci.a io/macio/libmacio.a
io/nvram/libnvram.a io/cuda/libcuda.a io/3c90x/lib3c90x.a
io/rtl8139/librtl8139.a io/usb/libusb.a tools/libtools.a
system/libsystem.a system/arch/x86/libsarch.a
system/osapi/posix/libsosapi.a -lX11
/usr/bin/ld: Undefined symbols:
_ppc_cpu_atomic_raise_dec_exception
_ppc_start_jitc_asm
_ppc_no_fpu_exception_asm
_ppc_no_vec_exception_asm
_ppc_program_exception_asm
_ppc_dsi_exception_special_asm
_ppc_cpu_atomic_cancel_ext_exception
_ppc_cpu_atomic_raise_ext_exception
_ppc_mmu_tlb_invalidate_all_asm
_ppc_opc_lswi_asm
_ppc_opc_stswi_asm
_ppc_read_effective_byte_asm
_ppc_read_effective_dword_asm
_ppc_read_effective_half_s_asm
_ppc_read_effective_half_z_asm
_ppc_read_effective_qword_asm
_ppc_read_effective_word_asm
_ppc_write_effective_byte_asm
_ppc_write_effective_dword_asm
_ppc_write_effective_half_asm
_ppc_write_effective_qword_asm
_ppc_write_effective_word_asm
_ppc_flush_flags_asm
_ppc_heartbeat_ext_rel_asm
_ppc_mmu_tlb_invalidate_entry_asm
_ppc_new_pc_asm
_ppc_new_pc_rel_asm
_ppc_new_pc_this_page_asm
_ppc_opc_icbi_asm
_ppc_sc_exception_asm
_ppc_set_msr_asm
_ppc_cpuid_asm
_x86_convert_2be555_to_2le555
_x86_convert_2be555_to_2le565
_x86_convert_2be555_to_4le888
_x86_convert_4be888_to_4le888
collect2: ld returned 1 exit status
make[3]: *** [ppc] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2



Even if I changer the CPU type to "generic", compilation still breaks
with this information:

g++ -Wundef -Wall -Woverloaded-virtual -fsigned-char -O2
-fomit-frame-pointer -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -pipe
-o ppc -L/usr/X11R6/lib main.o ppc_img.o ppc_font.o
ppc_button_changecd.o configparser.o cpu/cpu_generic/libcpu.a
io/graphic/libgraphic.a io/ide/libide.a system/ui/x11/libui.a
debug/libdebug.a io/libio.a io/prom/libprom.a io/prom/fs/libfs.a
io/prom/fs/hfs/libhfs.a io/prom/fs/hfsplus/libhfsplus.a
io/pic/libpic.a io/pci/libpci.a io/macio/libmacio.a
io/nvram/libnvram.a io/cuda/libcuda.a io/3c90x/lib3c90x.a
io/rtl8139/librtl8139.a io/usb/libusb.a tools/libtools.a
system/libsystem.a system/arch/x86/libsarch.a
system/osapi/posix/libsosapi.a -lX11
/usr/bin/ld: Undefined symbols:
_x86_convert_2be555_to_2le555
_x86_convert_2be555_to_2le565
_x86_convert_2be555_to_4le888
_x86_convert_4be888_to_4le888
collect2: ld returned 1 exit status
make[3]: *** [ppc] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


--
Δεν περιμένω τίποτ�
Jens von der Heydt
2006-03-01 13:45:30 UTC
Permalink
Post by Panayotis Katsaloulis
Even if I changer the CPU type to "generic", compilation still breaks
[..]
_x86_convert_2be555_to_2le555
_x86_convert_2be555_to_2le565
_x86_convert_2be555_to_4le888
_x86_convert_4be888_to_4le888
collect2: ld returned 1 exit status
make[3]: *** [ppc] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Hi,

reason for this is that the Darwin and / or OS X plattform that you
are compiling on
is not 100% supported by our make scripts. I will try to fix it -
though I can only
have a look at the generic core since I don't have an Intel Mac to my
dispossal.

Jens
Panayotis Katsaloulis
2006-03-01 13:51:52 UTC
Permalink
Post by Jens von der Heydt
Hi,
reason for this is that the Darwin and / or OS X plattform that you
are compiling on
is not 100% supported by our make scripts. I will try to fix it -
though I can only
have a look at the generic core since I don't have an Intel Mac to my
dispossal.
Jens
Thank you for the quick response
:-)

Is there any way I can help?
Like sending any type of information?
I don't know a lot about low level C programming, but I can even open
an ssh account in my machine if you want to have a look at it.


(PS: I always thought that x86 is always a x86 - I didn't suspect that
it might be any problem with this)

--
Δεν περιμένω τίποτε παρά μό
Jens von der Heydt
2006-03-01 13:48:56 UTC
Permalink
Post by Panayotis Katsaloulis
_x86_convert_2be555_to_2le555
_x86_convert_2be555_to_2le565
_x86_convert_2be555_to_4le888
_x86_convert_4be888_to_4le888
collect2: ld returned 1 exit status
make[3]: *** [ppc] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
At a second look those undefined symbols look like you have a build
problem with the assembler sources. Please check your build if it does
display problems with nasm. Perhaps you can post the complete output
of the make process.

Jens
Sebastian Biallas
2006-03-01 13:50:11 UTC
Permalink
Post by Panayotis Katsaloulis
Hello
I was trying to compile pearpc under the intel imac, but this is not possible.
Known problem. Should be fixed in CVS.

The jitc version still doesn't work (but at least compiles) but this is
a separate and complicated issue.

Sebastian
Jens von der Heydt
2006-03-01 13:58:11 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Panayotis Katsaloulis
Hello
I was trying to compile pearpc under the intel imac, but this is not possible.
Known problem. Should be fixed in CVS.
The jitc version still doesn't work (but at least compiles) but this is
a separate and complicated issue.
Sebastian
Where exactly is the problem there, Sebastian?

Jens
Sebastian Biallas
2006-03-01 14:07:18 UTC
Permalink
Post by Jens von der Heydt
Post by Sebastian Biallas
The jitc version still doesn't work (but at least compiles) but this is
a separate and complicated issue.
Where exactly is the problem there, Sebastian?
Apple. They have decided that all programs are implicitly compiled with
position independent code. Our asm-sources are not compatible with this.

Sebastian
Stefan Reinauer
2006-03-01 14:25:53 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Post by Jens von der Heydt
Where exactly is the problem there, Sebastian?
Apple. They have decided that all programs are implicitly compiled with
position independent code. Our asm-sources are not compatible with this.
Ouch, this is nasty. With a de facto stack machine (i.e. nearly no
registers) like x86 without amd64 opcodes, PIC hurts performance by 10-20%.

Stefan
Sebastian Biallas
2006-03-01 14:46:34 UTC
Permalink
Post by Stefan Reinauer
Post by Sebastian Biallas
Post by Jens von der Heydt
Where exactly is the problem there, Sebastian?
Apple. They have decided that all programs are implicitly compiled with
position independent code. Our asm-sources are not compatible with this.
Ouch, this is nasty. With a de facto stack machine (i.e. nearly no
registers) like x86 without amd64 opcodes, PIC hurts performance by 10-20%.
Maybe. But the have different PIC model than, say, Linux/ELF. The have
no reserved global pointer (IIRC %ebx on Linux/ELF) but make a "call
get_pc_thunk.bx" (which itself does "mov ebx, [esp]; ret") on every
function that needs global variables.

Sebastian

Stefan Reinauer
2006-03-01 14:29:32 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Jens von der Heydt
Post by Sebastian Biallas
The jitc version still doesn't work (but at least compiles) but this is
a separate and complicated issue.
Where exactly is the problem there, Sebastian?
Apple. They have decided that all programs are implicitly compiled with
position independent code. Our asm-sources are not compatible with this.
Have you tried using -fno-pic or -fno-PIC ?

Stefan
Loading...