Snes9x - Portable Super Nintendo Entertainment System (TM) emulator
This is the official source code repository for the Snes9x project.
Please check the Wiki for additional information.
This project forked from snes9xgit/snes9x
Snes9x - Portable Super Nintendo Entertainment System (TM) emulator
Home Page: http://www.snes9x.com
License: Other
Snes9x - Portable Super Nintendo Entertainment System (TM) emulator
This is the official source code repository for the Snes9x project.
Please check the Wiki for additional information.
BS-Zelda MottZilla Patch (v0.95) only shows a black screen in the libretro version of snes9x, but does work properly in the mainline release (latest testbuild).
It does work as intended in the snes9x-next core.
I thought this core didn't support sufami turbo games while the problem comes from the no-intro set I was using.
It has .sfc and just gives a black screen.
With another set with .smc (probably GoodSet?) every game run fine.
Not sure if no-intro would be supposed to work or if it's an upstream issue.
I'm using Retropie with lr-snes9x 1.54.1 build 9fec2d2 built from source. Sooner or later, I get a garbled screen. You can fight him in the third match of the world circuit.
I'm trying to compile for libretro on the raspberry pi. They build goes fine up until it starts compiling tile.ccp. Then it spits out a dozen warnings and hands.
I cloned from the repository, opened libretro, and compiled with a plain "make".
g++ -I../libretro -I.. -I../apu/ -I../apu/bapu -O3 -DNDEBUG -fomit-frame-pointer -fno-exceptions -fno-rtti -pedantic -Wall -W -Wno-unused-parameter -fPIC -DHAVE_STRINGS_H -DHAVE_STDINT_H -DRIGHTSHIFT_IS_SAR -D__LIBRETRO__ -c -o ../tile.o ../tile.cpp
In file included from ../tile.cpp:1356:0,
from ../tile.cpp:818,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1376:0,
from ../tile.cpp:818,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:818:0,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1420:0,
from ../tile.cpp:818,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1441:0,
from ../tile.cpp:818,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1451:0,
from ../tile.cpp:818,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1356:0,
from ../tile.cpp:925,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1376:0,
from ../tile.cpp:925,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:925:0,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1420:0,
from ../tile.cpp:925,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1441:0,
from ../tile.cpp:925,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1451:0,
from ../tile.cpp:925,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1356:0,
from ../tile.cpp:971,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1376:0,
from ../tile.cpp:971,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:971:0,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1420:0,
from ../tile.cpp:971,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1441:0,
from ../tile.cpp:971,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1451:0,
from ../tile.cpp:971,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1356:0,
from ../tile.cpp:1006,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1376:0,
from ../tile.cpp:1006,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1006:0,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1420:0,
from ../tile.cpp:1006,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1356:0,
from ../tile.cpp:1281,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1376:0,
from ../tile.cpp:1281,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1281:0,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1420:0,
from ../tile.cpp:1281,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1356:0,
from ../tile.cpp:1291,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1376:0,
from ../tile.cpp:1291,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1291:0,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1420:0,
from ../tile.cpp:1291,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1356:0,
from ../tile.cpp:1311,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1376:0,
from ../tile.cpp:1311,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1311:0,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1420:0,
from ../tile.cpp:1311,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1356:0,
from ../tile.cpp:1321,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1376:0,
from ../tile.cpp:1321,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1321:0,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:1420:0,
from ../tile.cpp:1321,
from ../tile.cpp:479:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
In file included from ../tile.cpp:479:0:
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
../tile.cpp:1402:1: warning: multi-line comment [-Wcomment]
With last nightly (1.4.0) at the time of the post.
Fast forwarding works fine but if I go into settings > frame throttle (or something, sorry if I don't remember the name well) > enable rewind and put it ON, then fast forwarding doesn't work anymore. Rewind works fine though and is awesome !
Sorry if this is intended / to be expected
50%=underclocking?(if so should this an option?)
100%=normal?
150%=starts to really overclock it?(etc. and so on)
I can't find anything on here or online explaining this.
As I was told by a dev what this issue exactly is "overscan padding is all at the bottom in RetroArch instead of evenly distributed at the top and bottom"
To reproduce the error make sure Crop Overscan is turned off.
All other SNES emulator cores seem fine, its just SNES9x itself, here is some screenshots.
https://imgur.com/pTxNGyq,Q7MPoTr#0
First image is SNES9x Next and the second is SNES9x .
Deae Tonosama Appare Ichiban (Japan)
=> this game does launch. However it goes straight to a very weird animated screen with an even weirder character and.. that's all. Pushing buttons does nothing. It does work with Snes9x1.53 & 1.54.1 Windows x64 (upstream), no weird screen to be seen here.
Hi, trying to use runahead latency option at 1 frame (second core both on/off) but seems to behave badly with this game. Screen will randomly freeze but game will continue normally (sounds, cutscenes, button pushes). Not sure if this is fixable but it's a great invention. Thanks!
I've tested all Multitap games using the snes9x core and all seem to work with the exception of:
Looney Tunes B-Ball -- The multiplayer options are grayed out, even with Multitap enabled
Virtual Soccer - No multiplayer game options availble with Multitap enabled
Dino Dini's Soccer! -- Multitap works on Genesis and I've read it's available for SNES but doesn't seem available on snes9x with Multitap enabled
Thanks
An mentioned above, yoshi's Island states lockup of they are loaded after closing and re-opening content.
The same saves work fine if loaded immediately.
When you load a save state of a MSU-1 game there is no audio at all.
I've noticed that some of the games still pop/skip quite a bit, but this is not the case with the most recent build of SNES9x with MSU support (downloadable here: http://dl.qwertymodo.com/snes9x.zip )
The game in particular that made me decide to test the RetroArch core against the SNES9x standalone version was the recent "Street Fighter 2 Turbo MSU Hack." The youtube page is here, and it has links to all of the required files for the MSU enhancements. https://www.youtube.com/watch?v=Ji3G3GKH5X4
If you start a 1 player game and choose Ryu, when you go to the Zangief stage for your first fight, the track skips noticeably. Also, if you press start to skip the 'capcom' sound effects to the title screen when you first boot the game.
A lot of improvements have been made to the code by qwertymodo apparently. Everything works beautifully on his most recent build.
I think if someone were to update the code for MSU support one more time, it would be perfect and probably wouldn't need tweaked again.
Hello could you please add MSU-1 in Snes9x support please for RETRIX?
RetroArch Supports MSU-1
Hello, can you add reading .zip with .mgd .sfc .smc files inside. The emulator does not read .zip files and content.
Thank you!
Just a suggestion list: todo stuff or reasonable features. Nothing may get done but just compiling.
If games are broken, please check upstream first and report there.
https://github.com/snes9xgit/snes9x/issues
** done - removed **
Stunt race doesn't boot any more, Star Fox exhibits some corruption, Yoshi's Island got some heavy flickering...
Hi, can there be feature to randomize memory when on bootup? Some games like Super Off Road are known to use uninitialized ram as a seed for random number generator. This controls bonus placements, ai nitro behavior, and some other things -- makes game more unpredictable. iirc other games do this for random weather behavior or showing random characters on splash screens. Thanks!
I think upstream has this option, so it'd be great to have it available here for nice transparency in KDL3 like you can get in the higan core with it's blur option. I know there are shaders that can do this, but it can be a pain to figure out how to combine them with multi pass CRT shaders.
While testing the latest RetroArch on Mac OS (High Sierra) with the latest snes9x code as of the time of this message, Runahead Second Instance seems to instantly make the video and audio go crazy or produce garbled output, rendering the content unplayable.
It's needed for some fan patches to softpatch.
output isn't anything different, except a eternal blackscreen. 'good' (without header) md5 is
6efc477d6203ed2b3b9133c1cd9e9c5d
and with is
d35fcf90c273d4bc12eed59120954e58
For the purpose of testing, i renamed the ips patch so it wouldn't apply anyway. Needless to say, hanging headered roms is even worse than not presenting them on the playlist after a scan, which already happens.
In the stand-alone version of snes9x is a display setting which is called blend-Hi-Res Images.
This option is needed for optimiseg dithering (e.g. Kirby Dreamland 3). Nor shader can currently simulate this behavior. Therefore it would be useful to add this option into the core options.
I'm not sure why but when I play a MSU-1 game with my headphones I hear a crackling sound from the right speaker. I'm not having this problem with standalone snes9x or even when I'm using my PC speaker. My guess is because my speakers are stereo and my headphone are 5.1 surround but I couldn't tell.
Hi, I am using Retrix version 2.1.0.0 and the snes core has some missing sounds e.g. after a while the weapons sounds on Aliens 3 get muted.
Alright! Think I've found the cause of the goofy lightgun cursor problem. Logs show that when I move the cursor for just 1 frame, it calls report_buttons twice. This adds relative mouse coordinates (input_state_cb) twice which causes the "sticky" and "overmoving" problems.
So a normal movement of (-1,0) = (0 runahead) becomes (-2,0) distance moved (1 runahead). This adds up pretty fast. Do any libretro wizards know of a way to handle this?
The briefing screens in A.S.P. Air Strike Patrol have a graphical corruption at the top of the screen in the libretro version of snes9x, but do display properly in the mainline release (latest testbuild).
It does work as intended in the snes9x-next core.
I understand that the SNES supports a few resolutions between 256x224 and 512x448, but when a game changes resolution should the frontend be notified? Is this a case for RETRO_ENVIRONMENT_SET_GEOMETRY
? Or generally speaking, should the dimensions of frontend display always match those of the last video_refresh callback
? I'm not just complaining, I would be happy to make improvements to this core.
save states do not work when trying to reload them after closing the app, it just says "100% Loading State" and continues to run the game normally without loading the save state.
The rom boots fine on the platform (NES Classic/SNES Classic) But, it can't pass the RTC test of the SPC7110. This is definitely an inclusion that would make many people happy. Thanks!
The snes cart has the SPC7110 chip that it is emulated by snes9x but its real time clock is not supported. Because of that RTC, the game is not passing the initial self test.
The code change for the working snes9x Windows version is here:
http://www.mediafire.com/file/lxlf5dkj50mhlpq/CodeChangeTmz.rar
``<cartridge region="NTSC">
<rom>
<map mode='shadow' size='0x100000' address='00-0f:8000-ffff'/>
<map mode='shadow' size='0x100000' address='80-bf:8000-ffff'/>
<map mode='linear' size='0x100000' address='c0-cf:0000-ffff'/>
<map mode='linear' offset='0x600000' address='40-4f:0000-ffff'/>
</rom>
<spc7110>
<ram size='0x2000'>
<map mode='linear' address='00:6000-7fff'/>
<map mode='linear' address='30:6000-7fff'/>
</ram>
<mmio>
<map address='00-3f:4800-483f'/>
<map address='80-bf:4800-483f'/>
</mmio>
<mcu offset='0x100000'>
<map address='d0-ff:0000-ffff' offset='0x100000' size='0x500000'/>
</mcu>
<dcu>
<map address='50:0000-ffff'/>
</dcu>
<rtc>
<map address='00-3f:4840-4842'/>
<map address='80-bf:4840-4842'/>
</rtc>
</spc7110>
In Super Metroid on Tourian Map, specifically, in mother brain attempt If you load the "VAR" beam, then release the secret weapon you will see an error that I don't see and another one, example {higan} or SNES real console.
Finally, expected behavior, like on real snes
4
BTW, my English is not my mother language if you see any mistake.
new pr in queue will add controller support for this game. asking for feedback on how well it works. note that using runahead seems to do poorly when using lightguns.
as other m.a.c.s. cartridges are not publically available (1994 version or moving simulator), won't bother working on any bugs they might have.
if using a physical lightgun device, you can go into retroarch options and adjust the aim manually.
From 03c8bad ....
This "Verified" git stuff broke the launchpad code import... :/
https://help.github.com/articles/about-gpg-commit-and-tag-signatures/
http://launchpadlibrarian.net/272633750/libretro-libretro-snes9x-libretro.log
https://bugs.launchpad.net/ubuntu/+source/bzr-git/+bug/1084403
It seems this is a long standing launchpad bug.
The PPA is infact important I would advise to remove GPG signatures from
commits to for the time being or at least provide a workaround
We should find a workaround, or another solution.
I've been running into System Memory Errors very frequently in my work on RetroArch; and I've been driving myself nuts trying to figure it out. However, I've isolated the problem to this core.
There's some magic that happens when switching cores on WiiU. I don't fully understand it, but based on a discord convo with @aliaspider, it seems like the SME can occur if certain sensitive bits of memory are written to by mistake, causing the loader to feed invalid data to the RPX loader which, in turn, sets off the OS' "bad executable" handler (the 160-2203 message).
Lots and lots of testing.
The reproduction process looks like this:
It tends to vary, but I usually end up getting the System Memory Error within 5-6 switches (i.e. maybe 2 or 3 SNES games).
I've done this same stress-test using nestopia, snes9x2005, and mednafen_ngp cores with no issues.
snes9x has always been crashy on WiiU, so I don't know if there even is a point in time where it didn't crash.
On mission briefing screens there is a flickering crushed overlay(it is the same image thats on the screen) on the top 1/4 of the screen.
This does not happen in snes9x2010.
RetroArch: 1.6.0 stable
Snes9x: 1.54.1 3fb8977
OS: Mac
I was just trying out Microsoft Application Verifier, and it is reporting a memory leak somewhere. (Looks like some 64K size block isn't getting freed?)
This is in the libretro_get_system_info
phase of Load Core, where it loads the core DLL file, queries for file support, then unloads the DLL file.
Snes9x 2010, 2005, and 2002 do not trigger the memory leak upon loading and unloading the DLL.
edit:
Found the leak: (in smp.cpp)
SMP::SMP() {
apuram = new uint8[64 * 1024];
}
There's no corresponding delete.
@kps501
After recent commits I got a black screen (most of the time, can be random), game is still running with sound in the background, if I have core option "Preferred Aspect Ratio" on "auto".
Log shows:
[INFO] SET_GEOMETRY: 256x224, aspect: 1.#IO.
It seems fine on other ratio values.
Win7 x64, Nvidia GTX770, current Retroarch Nightly, snes9x e9f5178 and ac4b54c
Currently the core automatically switches between outputting a 240 or 480 framebuffer depending on if a game is using high res mode or not. That should stay the default, but I think an option to always output 240 would be useful for shaders. The higan core lets you set the internal res to 240 and doesn't auto switch to 480 when high res stuff is onscreen in something like SD3. The high res text looks a little weird, but is still readable and I like how the rest of the image stays consistent with a CRT shader. There could be an option to always output 480 too, but I'm not sure if there is any benefit to doing that in SNES9x.
I can't figure out how to do a pull request, so I'll just leave this here: snes9xgit@8dba3d4
Truly exceptional work on the direct loading of BS-X and Sufami Turbo Games! I released the latest Commits for users on SNES/NES Classic Systems. There are a couple minor conflicts. One: If BIOS for BS-X are not present on a game that wants to use them, the game fails to load. Having a toggle ability so they are completely ignored will be there for those who do not want to run the BS-X BIOS. Two: This conflict does not apply to PC/RetroPie/Other Formats. It is entirely specific to the SNES Classic. SNES Games are converted into a special .Sfrom format that run natively with the default Emulator that comes with the SNES Classic (Canoe Emulator). If BIOS for BS-X are being used, .Sfroms will not work. If BIOS for BS-X are not used, .Sfroms do work. So, this is another thing that is incredibly helpful for those who do not want to use workarounds to bypass the .Sfrom Conversion, and maintain the original .sfc, etc formats. Thanks so much for reading. Hope this can be implemented as a Core Option, as it will ensure those who want to use them and those who do not want to use them will both be happy:)
Is there any possibility to offer a core specific option under controls that lets players toggle mouse or light-gun emulation from the "emulate pointer" architecture to something similar to the standalone emulator's or the desmume-libretro core's "touch-based emulation" architecture?
I.e.- Instead of displaying a crosshair that moves asynchronously from the mouse regardless of whether or not it's overlapping with the core's window, offer a toggle switch to detecting mouse input relevant to X+Y coordinates on the window?
Essentially, are Snes9x core setting equivalents for DeSmuME's desmume_pointer_mouse boolean and desmume_pointer_type mouse/touch options a possibility? There might not be a high demand for it, seeing how compatible games with these inputs are below double digits.
Raspberry Pi 3 / Raspbian Jessie / armv7l / Kernel 4.9.35-v7+ / gcc 4.9.2
Launching a ROM gives a black screen. RetroArch is running, but nothing is rendered.
Building with make -C libretro clean; make -C libretro platform=armvneon -j4
Git Bisected to - 75ed73b
75ed73b2503698acb491e76e7e0dd888622c06f4 is the first bad commit
commit 75ed73b2503698acb491e76e7e0dd888622c06f4
Author: Sérgio Benjamim <[email protected]>
Date: Wed Apr 26 22:44:25 2017 -0300
Makefile cleanup
:040000 040000 ae3a901fbb34ac9df716439a93a83da6d877b37a 8d3b60147f360e22a0e68173480804cd86e8a140 M libretro
Not complaining, just reporting. It's inevitable that it won't work in all games, but I'm pleased it works on most of the I've tried, and fixed the slowdown in Demon Crest. Finally, the final boss can be challenged without slowdown!
The only games that don't seem to work with OC is Quintet games. Likely just the engine they used, and might require romhacking the games directly to make it compatible. The game either doesn't start, or the audio doesn't play.
Games that don't work:
I just compiled the libretro version of snes9x for the rpi.
Tried to start Super Bomberman 2 and it just tells me my joystick loaded at the bottom of the screen, then halts at a black screen. No audio.
/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-snes9x/libretro.so ~/RetroPie/roms/snes/Super\ Bomberman\ 2\ \(USA\).zip
Sound buffer size: 2048 (512 samples)
RetroArch [WARN] :: patch_content :: Did not find a valid content patch.
Map_HiROMMap
RetroArch [WARN] :: gl_glsl_init :: [GL]: Stock GLSL shaders will be used.
Thoughts?
https://itunes.apple.com/app/id982939500
This guy is selling Snes9x, GenplusGX and other emulators plus some indie ("homebrew") games on the Apple store. It is said to be RetroArch iOS with Snes9x, GenplusGX and other cores. I believe Snes9x and Genplus GX have non-commercial clauses preventing their use in commercial products correct?
The Content Dispute Form is here:
http://www.apple.com/legal/internet-services/itunes/appstorenotices/
Also posted:
snes9xgit#73
the glitch only occurs in the original version of Mega Man X - After beating the intro stage, select any stage and within a minute or so(sometimes it doesn't glitch until mid boss fights, its random),the screen goes black and returns with "you got a new weapon" screen, and starts you sometimes on the intro level and sometimes back on the level select screen.
I'm carefully and thoroughly testing games with this core on Retropie latest version (on RPi3). Everything is being up to date on my system (including Raspbian packages). It went well so far except with the following games:
The emulator name in the core metadata is spelled as SNES9x even though it's spelled as Snes9x almost everywhere in the official resources of the original emulator. It is sometimes spelled as Snes9X there and in the UI, which is an issue I've made an entry in the emulator's issue tracker about, which is a different story. The point is, this spelling is pretty much incorrect and can potentially cause some, albeit small, confusion.
This issue is relevant to Snes9x Next too, though it's probably more excusable for a fork.
I'm trying to cross-compile the libretro-snes9x core to an arm board.
I'm using buildroot for this extent, but I'm getting the following error:
BEGIN-----------------------------------------
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking build system type... x86_64-unknown-linux-gnu
checking host system type... arm-buildroot-linux-gnueabihf
checking target system type... arm-buildroot-linux-gnueabihf
checking for arm-buildroot-linux-gnueabihf-gcc... arm-buildroot-linux-gnueabihf-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether arm-buildroot-linux-gnueabihf-gcc accepts -g... yes
checking for arm-buildroot-linux-gnueabihf-gcc option to accept ISO C89... none needed
checking for arm-buildroot-linux-gnueabihf-g++... arm-buildroot-linux-gnueabihf-g++
checking whether we are using the GNU C++ compiler... yes
checking whether arm-buildroot-linux-gnueabihf-g++ accepts -g... yes
checking whether g++ accepts -O3... configure: error: cannot run test program while cross compiling
END-----------------------------------------
I checked the unix/configure script, and in line 3422 when checking for -O3 there is this:
if test "$cross_compiling" = yes; then
Is this done intentionally to prevent snes9x to be cross-compied?
If not, I removed the if but the test for O3 fails ( ${snes9x_cv_option_o3+set} ), but this should'nt fail, as both g++ and arm-buildroot-linux-gnueabihf-g++, supports O3 (don't if the one evaluated should be g++ or arm-buildroot-linux-gnueabihf-g++).
Extre info:
The tooldchaing is built by buildroot, and is not an external one, with g++ enabled.
thank you
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.