Trouble building

[Auria]

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 :



...
...
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

[nmn]

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:


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


OBJ_X86 =
to make sure the recompiler is not compiled.

[Auria]

Hi,

thanks for answering. I tried the fix you proposed, to no avail

The full build log (well i stripped a good deal of underfined symbols but everything else is there) can found there : http://pastebin.com/m1f68b5e4

[nmn]

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:


# 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.

[Auria]

Hi,

great we seem to be getting closer :)



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

[nmn]

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?

[Auria]

edit: Have you tried make clean before running these solutions?

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

[nmn]

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.

[Auria]

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 ;)

[nmn]

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...

[Richard42]

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.

[nmn]

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 ;)

[ebenblues]

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 ;)
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?

[nmn]

WTF?!

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

[Richard42]

WTF?!

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

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.

[Auria]

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.

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

[Richard42]

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


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!

[Auria]

Hi Richard42,

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

I just meet this problem when building glade64



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:


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)

[Richard42]

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


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.

[Auria]

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 :


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 :


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 : http://www.mediafire.com/imgbnc.php/858a514d5eeb3c68b8e18ba415aa23232g.jpg (http://www.mediafire.com/imageview.php?quickkey=rx1bjnyy5mt&thumb=4)

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

[nmn]

Warning: Unknown UCODE!!!
[...]
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

This dialog does not work. Some 2D games I've tried have had this problem (i.e. Puyo Puyo 4) and the dialog freezes the whole emulator. Your best bet is to use a different plugin once they become available.

On the flip side, the blank screen is not right. I'm going to guess the core is screwing up badly, or glN64 is not doing anything. Or both. How we tell is a new problem... How would we? anyone have ideas as to how?

[Auria]

Well if that dialog does indeed freeze the whole emulator, then there's no need to search any further, I get it everytime i try to run something, that would be the (perhaps indirect) cause of the problems

[nmn]

Hold up, I think I know what's going on. If you get it every time, it must be falling to the bug glN64 had a while back. I think there is some data that needs/needn't be byte swapped that is being used wrong.

The fix I do not know. I didn't fix it the first time, I spent a very long time trying...

[Richard42]

Hold up, I think I know what's going on. If you get it every time, it must be falling to the bug glN64 had a while back. I think there is some data that needs/needn't be byte swapped that is being used wrong.

The fix I do not know. I didn't fix it the first time, I spent a very long time trying...

I was planning on someday doing a diff between mupen64 0.5 and the Mac OSX version of 0.5. I bet the fix is in there.