Win64 and Android Test Builds

General Development
#561

Except for Windows, mingw/mingw64 doesn’t natively have libdl, I can compile it and put it in my toolchain but others may not. Also MESS on Win64 has issues with D__LIBRETRO__, see the previous posts my AndresSM & myself. I was able to get it to compile quick & dirty for Win64 by doing this:

# add SQLite3 library
ifneq ($(findstring win32,$(TARGETOS)),)
SQLITE3_LIB = $(OBJ)/libsqlite3.a
else
SQLITE3_LIB = $(OBJ)/libsqlite3.a -ldl
endif

and changing #ifndef LIBRETRO to #ifndef WIN32_LIBRETRO I can’t figure out why #if !defined(LIBRETRO) || !defined(WIN32_LIBRETRO) doesn’t work

#562

I spoke a little too soon, MAME compiled just fine but now MESS is failing the same way UME has for about a month or so now:

Makefile.libretro:882: recipe for target 'obj//mess/mess/liboptional.a' failed
make: *** [obj//mess/mess/liboptional.a] Error 87

I also realized after my previous post that this would probably be cleaner code for the libdl issue:

# add SQLite3 library
ifeq ($(TARGETOS), win32)
SQLITE3_LIB = $(OBJ)/libsqlite3.a
else
SQLITE3_LIB = $(OBJ)/libsqlite3.a -ldl
endif
#563

For the -D__LIBRETRO__ , i dont understand why it’s a problem All core use LIBRETRO so we have to do the same , so #ifndef WIN32_LIBRETRO are not very appropriate. I used them on LINUX/WIN64 and ANDROID and never have a problem with it. could you please explain what is exaclty the pb with LIBRETRO .

Strange no pb to build ume on linux ( just tested on hour ago)

For lib DL ok , mine was a quick linux fix, yours seem to be ok . i ll push it on github


# add SQLite3 library
ifeq ($(TARGETOS), win32)
SQLITE3_LIB = $(OBJ)/libsqlite3.a
else
SQLITE3_LIB = $(OBJ)/libsqlite3.a -ldl
endif
#564

Strange no pb to build ume on linux ( just tested on hour ago)

For lib DL ok , mine was a quick linux fix, yours seem to be ok . i ll push it on github


# add SQLite3 library
ifeq ($(TARGETOS), win32)
SQLITE3_LIB = $(OBJ)/libsqlite3.a
else
SQLITE3_LIB = $(OBJ)/libsqlite3.a -ldl
endif

[/quote] LIBRETRO causes problems with MESS when it’s freeing memory.it works but we get lots of errors on the console.

#565

Ok that strange ,then we have to found why…

For the error e=87 , we can just to split liboptional in two line like :

In emu.mak


$(LIBOPTIONAL): $(CPUOBJS) $(SOUNDOBJS) $(VIDEOOBJS) $(MACHINEOBJS) $(BUSOBJS) $(NETLISTOBJS)

to


$(LIBOPTIONAL): $(CPUOBJS) $(SOUNDOBJS) $(VIDEOOBJS)
$(LIBOPTIONAL2): $(MACHINEOBJS) $(BUSOBJS) $(NETLISTOBJS)

and in makefile.libretro


LIBOPTIONAL = $(OBJ)/$(TARGET)/$(SUBTARGET)/liboptional.a
...
$(EMULATOR): $(EMUINFOOBJ) $(DRIVLISTOBJ) $(DRVLIBS) $(LIBOSD) $(LIBBUS) $(LIBOPTIONAL) ...

to


LIBOPTIONAL = $(OBJ)/$(TARGET)/$(SUBTARGET)/liboptional.a
LIBOPTIONAL2 = $(OBJ)/$(TARGET)/$(SUBTARGET)/liboptional2.a
...
$(EMULATOR): $(EMUINFOOBJ) $(DRIVLISTOBJ) $(DRVLIBS) $(LIBOSD) $(LIBBUS) $(LIBOPTIONAL) $(LIBOPTIONAL2) ...
#566

are you gonna push those to the repo or should I do?

#567

It still fails for me with MingW64 under windows, trying to build MESS.

obj//libemu.a(luaengine.o):luaengine.c:(.text+0x146b): undefined reference to `m
g_start_thread'
collect2.exe: error: ld returned 1 exit status
Makefile.libretro:828: recipe for target 'mess' failed
make: *** [mess] Error 1

That’s right at the end during the creation of mess_libretro.dll.

#568

Obviously , it’s because they don’t use LIBRETRO for win build . but WIN32_LIBRETRO So in luaengine.c for win build you have to change :


void lua_engine::initialize()
{
#ifndef __LIBRETRO__
mg_start_thread(::serve_lua, this);
#endif
}

By somethings like

void lua_engine::initialize()
{
#if !defined(__LIBRETRO__) && !defined( __WIN32_LIBRETRO__)
mg_start_thread(::serve_lua, this);
#endif
}
#569

Thanks that’s working!

#570

I’m having some trouble compiling bsnes cores (among others…). I’m using this toolchain https://www.dropbox.com/sh/91sakv0qdyxj … c-4.8.2.7z on 64bit Windows 7. Intel i7 processor.

bsnes c++98: Appears to compile, but no core is left.

bsnes (perf/balanced/accuracy): Using these lines to compile:

cd libretro-bsnes/perf
make ui='target-libretro' profile='performance' clean
make ui='target-libretro' profile='performance' -j4

Terminates on line 31 of the Makefile. It looks like it’s trying to compile bsnes_libretro.so when it stops.


.../x86_64-w64-mingw32/bin/ld.exe: cannot find -ldl
collect2.exe: error: ld returned 1 exit status
target-libretro/Makefile:31: recipe for target 'build' failed
make: *** [build] Error 1

How do I fix this?

#571

there must be somewhere a things like in makefile : LDFLAGS += -ldl and this should not apply to the WIN build .

So something like this could be more right ifneq ($(platform), win) LDFLAGS += -ldl endif

#572

If it’s trying to compile a *.so, it thinks you’re in Linux instead of Windows. Are the Windows build scripts separate? If so, you’ll want to use those instead. I don’t know because I don’t use libretro-super very often.

#573

I didn’t notice the so , and as i never use libretro-super i don’t know about it too.

BTW, if someone want to test the android UME based on the upstream repro . you can download the so here : http://dl.free.fr/lGONbxTiI ( based on SVN R31095)

#574

Sorry guys, recovery from my latest eye surgery is taking much longer than I anticipated and atm I am still limited to what I can do.

#575

No problem, dude. Take your time. Your health/recovery is way more important than nightlies :slight_smile:

#576

Your health is most important! Take your time to your recovery.

#577

AWESOME! Does this UME Core has the MESS part? I really want to test it…but I don’t know where to place the ume_libretro.so, I even can’t found the Retroarch’s libs dir… :rolleyes:

#578

if you have a rooted device you have to put the so in /data/data/com.retroarch/cores/

#579

Thanks for your message! I have a rooted gamepad =D

And I found the path put the .so in it, I use lordashram’s night build 5-15. RGUI Read the so,but when I load content it crashed anyway =(

Should I set rompath according blog article :MAME/MESS/UME cores (http://www.libretro.com/index.php/mamemessume-cores/) ?

#580

Yes , it’s weird . i ve tested with my LG G2 no pb to report . i ve test few mame games and few mess system like pce and it works fine .

But i’ve tested also with my old android phone ( ICS 4.04 ) and it just crash . i get this error :


I/RetroArch [ERROR] :: (10090): dylib_load() failed: "Cannot load library: link_image[1913]:  1438 missing essential tables".
I/RetroArch [ERROR] :: (10090): Failed to open dynamic library: "/data/data/com.retroarch/cores/ume_libretro.so"

I’ve compiled the core on an other system so can’t say exactly what NDK standalone toolchain i’ve used. maybe 9d 4.8 gcc. i’m not sure.

if i done ld with an old 4.4.3 toolchain i get :


arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ld -rpath-link  ./myICS_systemlib/ ume_libretro.so
: warning: cannot find entry symbol _start; defaulting to 00008248
ume_libretro.so: undefined reference to `driver_rampart2p'
ume_libretro.so: undefined reference to `driver_rampartj'
ume_libretro.so: undefined reference to `driver_rampart'

but if i done the same with 4.8 tc , i get no undefined ref :


android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-ld -rpath-link ./myICS_systemlib/  ume_libretro.so

So I’m not sure what is the pb , and why there is some mismatch with runtime lib.