Home Page Forums MAME Non-Windows MAME Support MAME 0.257 make error on the Nobara 38. (Fedora)

Building driver list...
usage: makedep.py [-h] [-r <srcroot>] <command> ...
makedep.py: error: argument <command>: invalid choice: '0.257/' (choose from 'sourcesproject', 'filterproject', 'sourcesfilter', 'driverlist', 'reconcilelist')
make[2]: *** [mame.make:348: ../../../../generated/mame/mame/drivlist.cpp] Error 2
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [Makefile:1102: mame] Error 2
make: *** [makefile:1295: linux_x64_clang] Error 2

Working fine on the current source and the MAME 0.256 source. Not this release source. Weird.

I even download the mame0257s.exe same issue.

Typo? '0.257/'

Trying out mame0257 folder name. MAME 0.257 probably the issue.

///////////////////////////////////////////////////////////////////////////////////////////////////////////

My bad. Working now after rename it to mame0257. For now on no space on the folder.

Archiving liboptional.a...
Compiling src/mame/mame.cpp...
Building driver list...
Compiling generated/version.cpp...
39878 driver(s) found
Compiling generated/mame/mame/drivlist.cpp...
Linking mame...
Running post-build commands
Stripping symbols.
[mitchell@nobara-pc mame0257]$

This show up on the Aug 5th at night. I tried again after midnight. Something happen.

make OVERRIDE_CC=clang OVERRIDE_CXX=clang++ STRIP_SYMBOLS=1 REGENIE=1 -j17 && ./mame -listxml > mame.xml

Done. Generated 363/363 projects.
Creating ../../../../linux_clang/bin/x64/Release
Precompiling src/emu/emu.h...
In file included from ../../../../../src/emu/emu.h:24:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/list:73:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/bits/memory_resource.h:38:
/usr/bin/../lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/cstddef:50:10: fatal error: 'stddef.h' file not found
#include <stddef.h>
^~~~~~~~~~
1 error generated.
make[2]: *** [precompile.make:317: ../../../../linux_clang/obj/x64/Release/emu.h.gch] Error 1
make[1]: *** [Makefile:97: precompile] Error 2
make: *** [makefile:1294: linux_x64_clang] Error 2
[mitchell@nobara-pc mame]$

I removed OVERRIDE_CC=clang OVERRIDE_CXX=clang++ and then the problem went away. Clang not in use this time.

Anyone sees this error. Just remove these two. Make sure to do clean and git pull before try again.

There is a problem with your compiler installation. MAME builds fine on Fedora 38.

clang issue. Someone gave me a link. https://github.com/microsoft/vscode-cpptools/issues/9574

I'm not going to mess with the files. I don't want to screw up something.

clang-15.0.7-2.fc38.x86_64

Clang isn't really needed so far. MAME works fine.

Whoops I forgot to post this earlier.

echo 3971468 | sudo -S dnf install clang git gcc gcc-c++ SDL2-devel SDL2_ttf-devel libXi-devel libXinerama-devel qt5-qtbase-devel qt5-qttools expat-devel fontconfig-devel alsa-lib-devel pulseaudio-libs-devel -y

The linked error is specific to MS Visual Studio. MAME builds fine with Clang on Linux, it's one of the tests GitHub runs every time something is committed. You have a local error.

I will show GloriousEggroll the error. Might be something that they done on the Nobara. I have no clue. Like I said it was working. Starting to think the update broken it somehow. I did restall Nobara and the error still there.

You pointed out its fine on the Fedora. I trusted you.

I could use the Distrobox Fedora version to make the mame. Still will load on the Nobara. I should've thought of this before.

I had to add the QT_HOME=/usr/lib64/qt5 because of the Distrobox Fedora will throw up an error. So far it's working. make OVERRIDE_CC=clang OVERRIDE_CXX=clang++ STRIP_SYMBOLS=1 REGENIE=1 -j17 QT_HOME=/usr/lib64/qt5 && ./mame -listxml > mame.xml

How I link this onto the make command? stddef.h is found. Just for a test to see this will pick up.

[mitchell@nobara-pc mame]$ rpm -ql gcc |grep stddef
/usr/lib/gcc/x86_64-redhat-linux/13/include/stddef.h

It is a wild guess, but isn't trying to use GCC headers with clang the problem?
Other thing to check would be the version of clang. Fedora ships multiple versions AFAIK and the older compat versions might either not ship the headers at all or ship them in a non-standard location.

I found the issue.

Installed clang-15.0.7-2.fc38.x86_64 (installed:nobara-appstream) A C language family front-end for LLVM
Installed clang-libs-15.0.7-2.fc38.x86_64 (installed:nobara-appstream) Runtime library for clang
Installed clang-resource-filesystem-15.0.7-2.fc38.x86_64 (installed:nobara-appstream) Filesystem package that owns the clang resource directory
Installed clang15-libs-15.0.7-4.fc38.x86_64 (installed:anaconda) Runtime library for clang
Installed clang15-resource-filesystem-15.0.7-4.fc38.x86_64 (installed:anaconda) Filesystem package that owns the clang resource directory

I removed the last two. Now it working.

sudo dnf remove clang15-libs-15.0.7-4.fc38.x86_64 clang15-resource-filesystem-15.0.7-4.fc38.x86_64 -y

I don't know why those two are there. lol

R. Belmont yeah that confused the hell of it.

The latest clang version in Fedora 38 is clang 16 (clang package), clang 15 libs are shipped as clang15-libs as you noticed. Not sure why nobara ships clang 15 as clang, this is bound to cause issues.

LionHeartP replyed: "It's because Nobara is on llvm15. Because 16 causes issues with some games. Namely TF2."

I pointed these out to him. clang15-libs-15.0.7-4.fc38.x86_64 clang15-resource-filesystem-15.0.7-4.fc38.x86_64 I told him these two will throw errors when the Nebara install the older clang files. Stayed until using this command. sudo dnf remove clang15-libs-15.0.7-4.fc38.x86_64 clang15-resource-filesystem-15.0.7-4.fc38.x86_64 -y

He told me this. "Once that is fixed, we will migrate to 16"

The Nebara Dev's Team don't even have the Secure Boot enabled. https://nobaraproject.org/docs/faq/faq/

They has been breaking some things. I'm not worrying about it. Least I solved the issue on the clang. That's their fault.