Menu
What's new
By:
Filters

Trouble building

A

Auria

New member
Hi everyone,

I quite new here so first hi everyone :)

I'm trying to build mupen1.3 and/or SVN (both fail) and get something like this :

Code: 
...
...
r4300/recomp.o: In function `RDSUB':
recomp.c:(.text+0x149c): undefined reference to `gendsub'
r4300/recomp.o: In function `RDSUBU':
recomp.c:(.text+0x1518): undefined reference to `gendsubu'
r4300/recomp.o: In function `RTGE':
recomp.c:(.text+0x156c): undefined reference to `genni'
r4300/recomp.o: In function `RTGEU':
recomp.c:(.text+0x15c0): undefined reference to `genni'
r4300/recomp.o: In function `RTLT':
recomp.c:(.text+0x1614): undefined reference to `genni'
...
...
many dozens of those.

I am currently on Ubuntu 7.04, on a PPC architecture. I realise PPC is not the main target, however I saw that the makefiles seem to detect PPC processors therefore am I right when I assume it should be supported?
I take it these missing symbols are that from native recompilers, which do not exist on PPC. I'm pretty sure i read somewhere on these boards there is generic implementations of all native assembly functions, however I can't seem to find that again. Is it right, and if so, how can I activate them?

thanks
 
N

nmn

Mupen64Plus Dev.
While this most likely is not going to go so well on PPC, please hang in there. We'd love to add PPC support in, and there is a general lack of people who can help us out with it. (Well, I thought I might have a way, but as it turns out, I do not.)

Now.... I believe the problem is somewhat related to an improper interpretation of the Makefile, since it appears some routines necessary are not getting compiled at all. (Obviously a shot in the dark as I have no idea.) Please provide a complete log and put it on Pastebin or something. In the meantime, I don't see exactly why this is happening... But I might check out the makefile and see if there are any obvious reasons.

edit: Try disabling the recompiler. You can delete the relavant code and replace it with a single line to fully disable it. Ex, grab:
Code: 
ifeq ($(CPU), X86)
  ifeq ($(ARCH), 64BITS)
    DYNAREC = x86_64
  else
    DYNAREC = x86
  endif
  OBJ_X86 = \
    r4300/$(DYNAREC)/assemble.o \
    r4300/$(DYNAREC)/debug.o \
    r4300/$(DYNAREC)/gbc.o \
    r4300/$(DYNAREC)/gcop0.o \
    r4300/$(DYNAREC)/gcop1.o \
    r4300/$(DYNAREC)/gcop1_d.o \
    r4300/$(DYNAREC)/gcop1_l.o \
    r4300/$(DYNAREC)/gcop1_s.o \
    r4300/$(DYNAREC)/gcop1_w.o \
    r4300/$(DYNAREC)/gr4300.o \
    r4300/$(DYNAREC)/gregimm.o \
    r4300/$(DYNAREC)/gspecial.o \
    r4300/$(DYNAREC)/gtlb.o \
    r4300/$(DYNAREC)/regcache.o \
    r4300/$(DYNAREC)/rjump.o
else
  OBJ_X86 =
endif
and replace it with
Code: 
OBJ_X86 =
to make sure the recompiler is not compiled.
 
Last edited:
N

nmn

Mupen64Plus Dev.
Alrighty, I seem to have found the source of the problem itself, the fact that the current code is unfit to exclude the recompiler. For now, you can again try the hardcoded solution to test:
Code: 
# list of object files to generate
OBJ_CORE = \
    main/main.o \
    main/util.o \
    main/translate.o \
    main/guifuncs.o \
    main/config.o \
    main/adler32.o \
    main/ioapi.o \
    main/md5.o \
    main/mupenIniApi.o \
    main/plugin.o \
    main/rom.o \
    main/savestates.o \
    main/unzip.o \
    main/volume.o \
    memory/dma.o \
    memory/flashram.o \
    memory/memory.o \
    memory/pif.o \
    memory/tlb.o \
    r4300/r4300.o \
    r4300/bc.o \
    r4300/compare_core.o \
    r4300/cop0.o \
    r4300/cop1.o \
    r4300/cop1_d.o \
    r4300/cop1_l.o \
    r4300/cop1_s.o \
    r4300/cop1_w.o \
    r4300/exception.o \
    r4300/interupt.o \
    r4300/profile.o \
    r4300/pure_interp.o \
    r4300/special.o \
    r4300/regimm.o \
    r4300/tlb.o
Replace the current OBJ_CORE list with this one.
 
OP
A

Auria

New member
Hi,

great we seem to be getting closer :)

Code: 
gcc main/main.o main/util.o main/translate.o main/guifuncs.o main/config.o main/adler32.o main/ioapi.o main/md5.o main/mupenIniApi.o main/plugin.o main/rom.o main/savestates.o main/unzip.o main/volume.o memory/dma.o memory/flashram.o memory/memory.o memory/pif.o memory/tlb.o r4300/r4300.o r4300/bc.o r4300/compare_core.o r4300/cop0.o r4300/cop1.o r4300/cop1_d.o r4300/cop1_l.o r4300/cop1_s.o r4300/cop1_w.o r4300/exception.o r4300/interupt.o r4300/profile.o r4300/pure_interp.o r4300/special.o r4300/regimm.o r4300/tlb.o main/gui_gtk/main_gtk.o main/gui_gtk/aboutdialog.o main/gui_gtk/configdialog.o main/gui_gtk/rombrowser.o main/gui_gtk/romproperties.o main/gui_gtk/dirbrowser.o  -lz -lm -lpng `sdl-config --libs` -L/usr/X11R6/lib -lGL `pkg-config gtk+-2.0 --libs` -Wl,-export-dynamic -lpthread -ldl -o mupen64plus
main/main.o: In function `stopEmulation':
main.c:(.text+0xc48): undefined reference to `stop_it'
memory/memory.o: In function `init_memory':
memory.c:(.text+0x5a9e): undefined reference to `fast_memory'
memory.c:(.text+0x5aa6): undefined reference to `fast_memory'
memory/memory.o: In function `update_SP':
memory.c:(.text+0x6eca): undefined reference to `fast_memory'
memory.c:(.text+0x6ed2): undefined reference to `fast_memory'
r4300/r4300.o: In function `FIN_BLOCK':
r4300.c:(.text+0x2d0): undefined reference to `dyna_jump'
r4300.c:(.text+0x378): undefined reference to `dyna_jump'
r4300/r4300.o: In function `NOTCOMPILED':
r4300.c:(.text+0x84e8): undefined reference to `recompile_block'
r4300.c:(.text+0x861c): undefined reference to `recompile_block'
r4300.c:(.text+0x86bc): undefined reference to `recompile_block'
r4300.c:(.text+0x86f4): undefined reference to `dyna_jump'
r4300/r4300.o: In function `jump_to_func':
r4300.c:(.text+0x89d8): undefined reference to `init_block'
r4300.c:(.text+0x8a2c): undefined reference to `dyna_jump'
r4300/r4300.o: In function `init_blocks':
r4300.c:(.text+0x8fdc): undefined reference to `init_block'
r4300/compare_core.o: In function `display_error':
compare_core.c:(.text+0x300): undefined reference to `stop_it'
r4300/exception.o: In function `TLB_refill_exception':
exception.c:(.text+0x570): undefined reference to `dyna_jump'
r4300/exception.o: In function `exception_general':
exception.c:(.text+0x84c): undefined reference to `dyna_jump'
r4300/interupt.o: In function `gen_interupt':
interupt.c:(.text+0xd54): undefined reference to `dyna_stop'
r4300/pure_interp.o: In function `prefetch':
pure_interp.c:(.text+0x10e00): undefined reference to `prefetch_opcode'
pure_interp.c:(.text+0x10e70): undefined reference to `prefetch_opcode'
pure_interp.c:(.text+0x10ec8): undefined reference to `prefetch_opcode'
collect2: ld returned 1 exit status
make: *** [mupen64plus] Error 1

weirdly enough, it seems like the "pure interpretation" implementation relies on functions from the recompiler (prefetch_opcode) ;)
As for dyna_jump, a quick grep seems to show that no generic implementation exists
 
N

nmn

Mupen64Plus Dev.
Well, The recompiler can't be generic because It uses assembly code. It must use assembly code for various reasons.

Unfortunatally, I am not aware of any fixes for this at this time. Your best bet is to play around. I will look for the switch in source if one exists and find a real fix.

edit: Have you tried make clean before running these solutions?
 
Last edited:
OP
A

Auria

New member
nmn said:
edit: Have you tried make clean before running these solutions?
Click to expand...

I did

Well I don't know anything about assembly, or writing virtual machines for the matter, so if there's currently no way mupen can be built without digging in that I'll probably just drop it...


thanks anyway
 
N

nmn

Mupen64Plus Dev.
I apologize. We will look into it, however. Richard42 and ebenblues know much more about the core, so they could probably get it fixed much faster than I.
 
OP
A

Auria

New member
ok :)

in any case I think the status needs to be clarified; either declare it totally unsupported, either fix it (or decalre it WIP, of course). after all you don't have PPC computers, but on your computer you can probably build a version with dynamic recompiler disabled, if your build system shall support it ;)
 
N

nmn

Mupen64Plus Dev.
Well, We do not want it to be unsupported. The reason it is not marked in SVN is obvious; because the SVN is a constant WIP. But the full release should had said something. Its hard not to break things when you can't tell whether they are broken or not; I think the new Makefile system may be contributing to this but I wouldn't be so quick to say it couldn't just be a lack of consideration for platforms without a recompiler implementation at this time. I think right now I'm about to stub one for PPC so you can try to compile it.

I've looked in the source to make sure nothing could be done. I did not notice any switches, or anything of the likes, or any reason there was no symbols for 'stop_it' and various others in the pure interpreter...
 
R

Richard42

Emulator Developer
I thought about this PPC build issue today but I didn't come up with any quick ways to get this built for you. I remember building an earlier version on a PS3 and getting it built but I don't remember how much I had to hack it up. There have been quite a few changes in the past few months of this project and now we also need to make sure that glide64 can build under PPC. I'll add an issue to the tracker. Can you test it for us whenever it's ready, Auria? I can make a note in the issue report to drop a line on Emutalk for you.
 
N

nmn

Mupen64Plus Dev.
I stubbed a PPC dynarec. Try building off of the very latest SVN and see how it goes. Remember not to actually use the dynamic recompiler though ;)
 
E

ebenblues

Mupen64Plus Dev.
nmn said:
I stubbed a PPC dynarec. Try building off of the very latest SVN and see how it goes. Remember not to actually use the dynamic recompiler though ;)
Click to expand...
Looking at your commit changes, it looks like you removed the 64-bit implementation of dynarec...Shouldn't you have created a r4300/ppc dir with stubs in there?
 
R

Richard42

Emulator Developer
nmn said:
WTF?!

I have no idea why it did that, that's not even close to my local layout.
Click to expand...

You should use "svn status -u" before committing to see a list of what will change when you make the commit.

I reverted the commit with the PPC stub code because I want to handle this a little differently by adding the capability to cleanly detach and not compile the dynarec. This will allow us to support any other architecture than x86 or amd64 as long as it's running linux. Nobody's going to write a PPC dynarec anytime soon anyway.

Auria, if you want to test this code to see if the PPC stub compiled (and report problems compiling the plugins), then you can check out rev 93.
 
OP
A

Auria

New member
Richard42 said:
You should use "svn status -u" before committing to see a list of what will change when you make the commit.

I reverted the commit with the PPC stub code because I want to handle this a little differently by adding the capability to cleanly detach and not compile the dynarec. This will allow us to support any other architecture than x86 or amd64 as long as it's running linux. Nobody's going to write a PPC dynarec anytime soon anyway.

Auria, if you want to test this code to see if the PPC stub compiled (and report problems compiling the plugins), then you can check out rev 93.
Click to expand...

Thanks. I would rather go your way

I might test that revision just for fun, but as already mentionned there's no one to maintain a PPC dynamic recompiler, and i'm not asking for one either. I think the goal here is processor-independence much more than PPC support - when/if you fix mupen to be able to compile with dynamic recompilers totally disabled, just drop a note here or to me and I'll test it

thanks
 
R

Richard42

Emulator Developer
Auria said:
when/if you fix mupen to be able to compile with dynamic recompilers totally disabled, just drop a note here or to me and I'll test it
Click to expand...

I just committed a change to the svn repository which should allow you to build with no errors on the PPC platform. There is a new makefile option "NO_ASM=1" and it's automatically set for the PPC. I'm pretty sure that Rice Video and Glide64 will have some problems on the PPC but there's a decent chance that glN64 will work. Give it a shot!
 
OP
A

Auria

New member
Hi Richard42,

it seems to go much better this time, great job :)

I just meet this problem when building glade64

Code: 
MiClWr16b.h: In function ‘void Clamp16bS(unsigned char*, DWORD, DWORD, DWORD, DWORD)’:
MiClWr16b.h:278: error: unknown register name ‘edx’ in ‘asm’
MiClWr16b.h:278: error: unknown register name ‘eax’ in ‘asm’

I removed asm code from that function (breaking it by the way but as you said this driver would probably not have worked anyway) just to try and see if the rest works.

then met this:
Code: 
3dmath.cpp: In function ‘void MulMatricesSSE(float (*)[4], float (*)[4], float (*)[4])’:
3dmath.cpp:181: error: ‘__builtin_ia32_loadups’ was not declared in this scope
3dmath.cpp:192: error: ‘__builtin_ia32_shufps’ was not declared in this scope
3dmath.cpp:211: error: ‘__builtin_ia32_storeups’ was not declared in this scope

I did the same again and continued building anyway - everything else built fine :D

the app opens fine. the only available graphics driver is glN64

In "options", the CPU is by default set to recompiler. however this seems to be chosen at compile time so i'm not sure what can actually be selected in the options?

i tried opening a few roms, unfortunately i only get a black screen and nothing happens

I get an error about unknown opcodes (0x7A4EF287) depending on which one i choose in the list i'm able to get random garbage on screen but not much more :) then of course it's necessary to tell i only have the open-source radeon driver. maybe it's not enough? (in any case, if it at least builds on PPC, i could always try building it on the OS X side where i have proper drivers... i would just need to find the OS X equivalent of linker flags you are using)
 
Last edited:
R

Richard42

Emulator Developer
Auria said:
Hi Richard42,
I did the same again and continued building anyway - everything else built fine :D

the app opens fine. the only available graphics driver is glN64

In "options", the CPU is by default set to recompiler. however this seems to be chosen at compile time so i'm not sure what can actually be selected in the options?

i tried opening a few roms, unfortunately i only get a black screen and nothing happens
Click to expand...

I fixed those build problems in rev 172 of svn. You won't be able to use the dynamic recompiler. If you start Mupen64Plus from the console and run a game, you should see which core is being used, and it should be either the interpreter or the pure interpreter. glN64 will be the only graphics plugin with a chance of working.. Let me know if you can get any games to run. There may be byte swapping problems on the big endian PPC processor.
 
OP
A

Auria

New member
Hi,

first good thing : it now builds fine :D

as for glide and rice, if ever you're interested, here's why they don't load at all :
Code: 
Couldn't load plugin 'ricevideo.so': /usr/local/share/mupen64plus/plugins/ricevideo.so: undefined symbol: _Z20ProcessVertexDataSSEjjj
Couldn't load plugin 'glide64.so': /usr/local/share/mupen64plus/plugins/glide64.so: R_PPC_REL24 relocation at 0x0d38837c for symbol `sqrtf' out of range
rom size: 6236135 bytes (or 5 Mb or 40 Megabits)

when i run a game, i get this :
Code: 
memory initialized
[glN64]: (II) Initializing SDL video subsystem...
[glN64]: (II) Getting video info...
[glN64]: (II) Setting video mode 640x480...
[JttL's SDL Audio plugin] version 1.3 initalizing.
[JttL's SDL Audio plugin] Initializing SDL audio subsystem...
[JttL's SDL Audio plugin] Allocating memory for audio buffer: 65536 bytes.
Starting r4300 emulator
R4300 Core mode: Pure Interpreter
glN64: Warning - unknown ucode!!!

(mupen64plus:5089): GLib-WARNING **: g_main_context_check() called recursively from within a source's check() or prepare() member.
Warning: Unknown UCODE!!!
Warning: Unknown UCODE!!!
Warning: Unknown UCODE!!!
Warning: Unknown UCODE!!!
Warning: Unknown UCODE!!!
Warning: Unknown UCODE!!!
Warning: Unknown UCODE!!!
Warning: Unknown UCODE!!!
Warning: Unknown UCODE!!!
Warning: Unknown UCODE!!!
Warning: Unknown UCODE!!!

and the dialog you can see here :

this dialog gets in the way and will not close therefore it's hard to test the emulator
Apart from that i heard crackling sound (expected due to poor performance in pure interpretrer) but the OpenGL window does not even seem to be updated, it remains filled with random artifacts, mainly from other windows
 
You must log in or register to reply here.

Top