Libretro compilation

[audetto]

From gouchi:

Sorry to bother you. I was wondering how to compile AppleWin libretro core but without success.

I tried to follow : https://github.com/audetto/AppleWin/blob/master/linux.md#ra2

But the documentation should be

cmake -DLIBRETRO_COMMON_PATH=/path/to/libretro-common

not

cmake -DLIBRETRO_PATH=/path/to/libretro-common

According to : https://github.com/audetto/AppleWin/blob/master/source/frontends/libretro/CMakeLists.txt#L3

But when I tried I got this issue :

cmake -DLIBRETRO_COMMON_PATH=/tmp/libretro-common .. CMAKE_BUILD_TYPE: CMAKE_CXX_FLAGS: CMAKE_CXX_FLAGS_RELEASE: -O3 -DNDEBUG CMAKE_CXX_FLAGS_DEBUG: -g CMAKE_CXX_FLAGS_RELWITHDEBINFO: -O2 -g -DNDEBUG -- Found Boost: /usr/lib64/cmake/Boost-1.76.0/BoostConfig.cmake (found version "1.76.0") -- Found Boost: /usr/lib64/cmake/Boost-1.76.0/BoostConfig.cmake (found version "1.76.0") found components: program_options CMake Error at /usr/lib64/cmake/Qt5/Qt5Config.cmake:28 (find_package): Could not find a package configuration file provided by "Qt5Gamepad" with any of the following names:

Qt5GamepadConfig.cmake
qt5gamepad-config.cmake

Add the installation prefix of "Qt5Gamepad" to CMAKE_PREFIX_PATH or set "Qt5Gamepad_DIR" to a directory containing one of the above files. If "Qt5Gamepad" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): source/frontends/qt/CMakeLists.txt:7 (find_package)

Why Libretro core needs QT5 ?

Thank you for your help.

Kind regards,

[audetto]

I will fix the doc.

Re: QT5: there are no switches to include / exclude frontends. It always compiles them all (except libretro).

So, for now you have to comment out these lines:

https://github.com/audetto/AppleWin/blob/1a302935f01b8c48ffeed5c57737fb509aaed65d/CMakeLists.txt#L43-L45

Remember that the integration with libretro is not great

1. the core is good and very happy (*)
2. installing the core and browsing the games is not easy. the game database seems to be hardcoded and cannot detect new games on the fly.
3. if you understand how to use it, please tell me

(*) have to not used for a while, so YMMV, but will fix anything you report.

[gouchi]

Hi,

Thank you for your reply.

I could compile it but unfortunately I got this issue :

retroarch -L ./libappleii.so test.dsk

[INFO] RetroArch 1.9.13 (Git a93a2e3366)
[INFO] === Build =======================================
[INFO] CPU Model Name: Intel(R) Core(TM) i5 CPU         760  @ 2.80GHz
[INFO] Capabilities:  MMX MMXEXT SSE SSE2 SSE3 SSSE3 SSE4 SSE4.2
[INFO] Built: Nov  7 2021
[INFO] Version: 1.9.13
[INFO] Git: a93a2e3366
[INFO] =================================================
[INFO] [Input]: Found input driver: "udev".
[INFO] [Core]: Loading dynamic libretro core from: "./libappleii.so"
[ERROR] Failed to load symbol: "retro_init"
[ERROR] Fatal error received in: "init_libretro_symbols()"
[INFO] [Core]: Content ran for a total of: 00 hours, 00 minutes, 00 seconds.
[INFO] [Core]: Unloading core symbols..
[INFO] [Video]: Does not have enough samples for monitor refresh rate estimation. Requires to run for at least 4096 frames.

If you are using only libretro.h If you are ok we can switch to Makefile only for Libretro core ? To avoid to clone libretro-common repository only for the header libretro.h

For the playlist, we will have to add Apple II database to Libretro database then we can scan the file to be detected by the scanner.

[audetto]

time to test it again. leave it with me.

[audetto]

Should work now. But if you are familiar with retroarch and think the integration could be improved, please shout.

[audetto]

retroarch -L ./libappleii.so test.dsk

Anyway, this is not correct. I fixed the doc https://github.com/audetto/AppleWin/blob/master/linux.md#ra2

See there how to run it.

[audetto]

If you are using only libretro.h If you are ok we can switch to Makefile only for Libretro core ? To avoid to clone libretro-common repository only for the header libretro.h

not sure I understand. I can definitely add the file to this repo and avoid the external path.

For the playlist, we will have to add Apple II database to Libretro database then we can scan the file to be detected by the scanner.

I saw it, and it feels complicated. Can the database be generated locally? With the disks being writeable, no checksum will ever match, and it would be a limitation.

Otherwise, someone could download the entire asimov website and prepare the database.

[gouchi]

Thank you, I could launch some games and change to Monochrome, color...

But it seems controller is not working for the game and audio seems strange.

I will try to provide Makefile.

We will have to add dat file so that we can create rdb file then you can download it from RetroArch Main Menu > Online Updater > Update Databases. At last, you can use the scanner and the game will added to the playlist.

[audetto]

Which game did you try?

[gouchi]

Super Bunny

[audetto]

You will have to excuse me, I am embarrassed, I have developed a core, but I cant run retroarch :-)

I cant seem to be able to run retroarch any longer.

I run as in the doc, but I always get

[ERROR] RetroArch is built for dynamic libretro cores, but libretro_path is not set. Cannot continue.
[ERROR] Fatal error received in: "init_libretro_sym()"
[ERROR] This core requires a content file, could not load content.

I have tried with my own compiled retroarch and with Ubuntu's but it is the same.

How do you run retroarch?

[audetto]

Fixed it again. It simply means "file not found"...

[audetto]

Fixed the controller issue (in master). Audio works well for me.

I normally try with Karateka.

[gouchi]

Audio is working fine now.

But it is seems controller is still not working. I can change the display, restart the game but direction and buttons seem not to be working ?

[audetto]

run it with -v and copy here the output

[Sanaki]

Just built and tested the libretro core on x86_64 Linux. Results:

• Controller works once swapped to analog joypad. Default is standard joypad, which gives no input.
• Controller is currently non-configurable. Eventually would be preferable if that can be exposed fully.
• Memory is currently not exposed (I'm an admin of RetroAchievements, so that will be of interest later)
• libappleii.so is an external dependency of the core and can't currently be loaded from a local path (such as the system directory, where bioses and dependencies are usually loaded from when required). If possible, it should either be built into the core itself or loadable from system.
• Currently no save/load state support, and by extension no rewind or runahead support. Not mandatory, but would be a useful addition if possible.
• Not seeing a way to make the mouse function. Tried via Arkanoid, couldn't get any response.
• No disk control support yet, so currently single-disk games only.
• While I didn't directly test this one, I'm not seeing any sign of diff/duplicate save file creation, which implies attempts to save will modify the disk image directly. This also prevents games loaded from within archives from saving at all. This is something I'd hope can eventually be fixed, but is probably significant enough in terms of both impact and effort to get its own issue.

[audetto]

Just built and tested the libretro core on x86_64 Linux. Results:

Good, I need someone with a better knowledge of libretro.

* Controller works once swapped to analog joypad. Default is standard joypad, which gives no input.

Strange. I can use both a standard and an analog joypad. Try COLOR DEMOSOFT from the DOS 3.3 August 1980 and see if you can move the cursor.

The way the standard joypad works is that it will only give 3 possible values to each axis: -1, 0 or 1, while the analog allows for the full range.

* Controller is currently non-configurable. Eventually would be preferable if that can be exposed fully.

Not sure what that means.

* Memory is currently not exposed (I'm an admin of RetroAchievements, so that will be of interest later)

What is memory?

* `libappleii.so` is an external dependency of the core and can't currently be loaded from a local path (such as the system directory, where bioses and dependencies are usually loaded from when required). If possible, it should either be built into the core itself or loadable from system.

Yes, static compilation already works, but not really exposed. Moreover a few extra files needs to be available and currently the source path is hardcoded. Need to improve.

* Currently no save/load state support, and by extension no rewind or runahead support. Not mandatory, but would be a useful addition if possible.

Will see how to do it. AW supports save / load to a file, I will do it to /tmp/xyz.yaml and read it back.

* Not seeing a way to make the mouse function. Tried via Arkanoid, couldn't get any response.

No, a mouse controller is not supported. Will give it a go.

* No disk control support yet, so currently single-disk games only.

How should this work? Currently I try a floppy and if not a hard disk. A multi disk game, where should I insert the other disks?

* While I didn't directly test this one, I'm not seeing any sign of diff/duplicate save file creation, which implies attempts to save will modify the disk image directly. This also prevents games loaded from within archives from saving at all. This is something I'd hope can eventually be fixed, but is probably significant enough in terms of both impact and effort to get its own issue.

Repeat this one please. Floppies are read only, but AW does not expose this for HD.

[Sanaki]

Good, I need someone with a better knowledge of libretro.

I'm mostly a tester and end user rather than an actual programmer, so while I have a good amount of exposure to the general functionality and capabilities, there will be some gaps in my knowledge in terms of the code side of things. Regardless, I'm happy to help where I'm able, or potentially point someone more knowledgeable here if necessary.

• Controller works once swapped to analog joypad. Default is standard joypad, which gives no input.

Strange. I can use both a standard and an analog joypad. Try COLOR DEMOSOFT from the DOS 3.3 August 1980 and see if you can move the cursor.

I retested with Karateka and standard controller actually works fine. I'm no longer sure what I tested it on where it failed. Seems like that comment can be ignored for the time being, barring some future sign that it was sporadic behavior.

• Controller is currently non-configurable. Eventually would be preferable if that can be exposed fully.

Not sure what that means.

Libretro allows exposing not just a device index, but actual controls to the frontend. In the case of AppleWin, the only interaction is the ability to select device type (standard vs analog) and accept the frontend-supplied controller for port 1. Full exposure in this case would mean that individual buttons recognized by the controller are provided to the frontend, which can then be remapped at player discretion within the frontend. Rather than the frontend saying "this person pressed R1", it'd say "this person pressed the video mode button". Users could put that on any button they wanted, or even remove it from the controller entirely.

• Memory is currently not exposed (I'm an admin of RetroAchievements, so that will be of interest later)

What is memory?

System RAM, mapped to allow reading and potentially writing (optional, for cheat support) via frontend functions. In the case of RetroAchievements, we currently support a fork of AppleWin called RAppleWin, available here if you'd like to take a look, with a small collection of supported games thus far. Currently it's the only platform we can't support via libretro, hence my immediate interest when I found out about this core. Essentially achievements are triggered via watching specific addresses for changes, such as watching enemy health hit 0 while player health remains above 0.

• No disk control support yet, so currently single-disk games only.

How should this work? Currently I try a floppy and if not a hard disk. A multi disk game, where should I insert the other disks?

A couple options exist here, though which you'd want to use is a bit up in the air.

Option A: Use the frontend-provided disk control interface. Essentially you lock yourself to having only one floppy drive by doing this, but it allows the user to enter the frontend menu and change the disk index. Usually you would add support for m3u files for this purpose, consisting of raw text listing one relative file path per line. RetroArch in particular does support appending files in the disk interface without usage of an m3u, but not all libretro frontends will.

Option B: The QUASI88 core is a solid example of an alternative. It doesn't use disk control, but allows loading an m3u to be handled by the core directly. While holding L1 you can adjust floppy drive 1's disk index with the D-pad, and holding R1 allows you to adjust floppy drive 2's disk index in the same fashion. Releasing either button inserts the disk. By default, the first two entries in the m3u will be inserted into drives 1 and 2 respectively. Note that this does potentially complicate full exposure of control mapping.

Option C: Not something I've seen done, but potentially you could support both approaches via core option? I could be wrong though, it may not be possible to assess saved core options prior to enabling the disk control interface, and it may not be worth the hassle regardless.

• While I didn't directly test this one, I'm not seeing any sign of diff/duplicate save file creation, which implies attempts to save will modify the disk image directly. [...]

Repeat this one please. Floppies are read only, but AW does not expose this for HD.

This seems like it may have been user error on my part. I failed to find a game that saved to floppy to test, so I was operating on the assumption that Apple II floppies, as with many other computing systems of the era, were R/W. That has caused issues on other systems when in the process of a game saving, the core overwrites the scratch sections of the disk, causing a failure in file hashing for RetroAchievements on next launch, as well as damaging the pristine condition of a user's preserved games. If Apple II floppies were all R/O, this is a non-issue.

[Jamiras]

This seems like it may have been user error on my part. I failed to find a game that saved to floppy to test.

I know the Sierra games do this, but the ones I've played use a separate floppy for the save games (usually in drive 2, but you can swap it into drive 1 if you really want). They're also good examples for multi-disk testing.

Demon's Forge does write directly to the game disk.

[Jamiras]

Memory is currently not exposed (I'm an admin of RetroAchievements, so that will be of interest later)

What is memory?

This refers to implementing retro_get_memory_data and retro_get_memory_size, and/or environ_cb(RETRO_ENVIRONMENT_SET_MEMORY_MAPS). RetroAchievements expects the 64KB of system RAM to be exposed first, followed by up to 64KB of auxillary RAM. I'm not sure if any of the existing games rely on the auxillary RAM.

[Jamiras]

• Currently no save/load state support

Will see how to do it. AW supports save / load to a file, I will do it to /tmp/xyz.yaml and read it back.

This is handled by implementing retro_serialize_size, retro_serialize and retro_unserialize. I believe the default AW save support is just the RAM. You'll also want to capture modifications to the disk files here.

[audetto]

I have just pushed a few changes

• memory / achievements
• mouse support (see if you like it, I have seen libretrovice has a variable to tune the speed)

I have tried to implement multi disk, but I have not been able to trigger it from the gui. I have created a m3u file with a line per disk, but I cannot insert it. How do you do it?

Controller configuration: I remember spending ages to understand it, and the fact that everything is unsigned did not help. I need to find a decent example to follow, as the doc is pretty scarce.

[Jamiras]

I haven't actually tried compiling, but just looking at the commit, id in this case will be RETRO_MEMORY_SYSTEM_RAM or RETRO_MEMORY_SAVE_RAM. I'm doubtful that GetMemBankPtr will understand those constants.

You should be checking for id == RETRO_MEMORY_SYSTEM_RAM. Probably something like this:

void *retro_get_memory_data(unsigned id)
{
  if (id == RETRO_MEMORY_SYSTEM_RAM)
    return MemGetBankPtr(0);

  return NULL;
}

size_t retro_get_memory_size(unsigned id)
{
  if (id == RETRO_MEMORY_SYSTEM_RAM)
    return _6502_MEM_LEN;

  return 0;
}

[Jamiras]

I have tried to implement multi disk, but I have not been able to trigger it from the gui. I have created a m3u file with a line per disk, but I cannot insert it. How do you do it?

There should be a Disc Control submenu in the quick menu. You'll probably have to implement RETRO_ENVIRONMENT_SET_DISK_CONTROL_INTERFACE to make it show up.

[audetto]

I haven't actually tried compiling, but just looking at the commit, id in this case will be RETRO_MEMORY_SYSTEM_RAM or RETRO_MEMORY_SAVE_RAM. I'm doubtful that GetMemBankPtr will understand those constants.

fixed. this is what I mean when I say doc is very scarce.

why don't they add a quick notice here https://github.com/libretro/libretro-common/blob/996376e36d3f4f56eba202cb96230568628d2583/include/libretro.h#L3883 saying what the id means?

I am not constantly reading the whole 4000 lines of file.

[audetto]

There should be a Disc Control submenu in the quick menu. You'll probably have to implement RETRO_ENVIRONMENT_SET_DISK_CONTROL_INTERFACE to make it show up.

Found, and I can not trigger my code.

But I still do not understand the logic.

I have created a m3u8 file with 2 disks. How do I load it? Using the Disc Control menu I need to go and browse the disks. And still need to start with a disk as content. If I try to load a m3u8 it gets passed to my code which does not know how to handle it.

I cannot find exact instructions to load a playlist. Do you know how to do it?

Most of the documentation seems to indicate everything happens magically if a game database is present, but little is said about the steps to develop a core before the database exists.

[Jamiras]

The constants kind of hint at their usage, but yea, it would be nice if the functions referenced back to the constants.

[Jamiras]

After installing a whole bunch of cmake dependencies, I get the following error trying to build the core in Windows using MSYS2:

E:/Source/RetroAchievements/cores/AppleWin/source/linux/windows/strings.h:9:6: error: ambiguating new declaration of 'void strcpy_s(char*, size_t, const char*)'

The fact that linux appears in the path suggests this isn't supported.

After doing a similar exercise on my Linux VM, I did manage to get it to build. Here's a rudimentary implementation of m3u support that does make the Disc Control functionality work.

libretro.cpp.txt

Feel free to restyle-ize it to match your preferred coding standards.

Note that it's not very friendly, as you have to disable game mode (scroll lock), press f1 to bring up the menu, select eject disk, select current disk index, select the new disk, select insert disk, then re-enable game mode (scroll lock). But I think that's just a limitation of RetroArch.

[Jamiras]

It does look like the memory is being mapped correctly.

[audetto]

After installing a whole bunch of cmake dependencies, I get the following error trying to build the core in Windows using MSYS2:

In Ubuntu, PiOS, & Fedora you can just install from these lists

https://github.com/audetto/AppleWin/blob/master/source/linux/fedora.list.txt https://github.com/audetto/AppleWin/blob/master/source/linux/raspbian.list.txt

E:/Source/RetroAchievements/cores/AppleWin/source/linux/windows/strings.h:9:6: error: ambiguating new declaration of 'void strcpy_s(char*, size_t, const char*)'

The fact that linux appears in the path suggests this isn't supported.

Absolutely never tried. Unfortunately AppleWin uses tons of Windows only functions. I have contributed a lot of code to make it more portable, but numerous are still present.

I have to modularise the Windows compatibility layer, which is at the moment mandatory. But it won't be easy as I use this extra level of indirection to handle the data according to the frontend, which on a real Windows build would be impossible (e.g. audio).

After doing a similar exercise on my Linux VM, I did manage to get it to build. Here's a rudimentary implementation of m3u support that does make the Disc Control functionality work.

libretro.cpp.txt

I had already written it, but not pushed it (it is now). I will compare with yours to see if I misunderstood anything.

Feel free to restyle-ize it to match your preferred coding standards.

Note that it's not very friendly, as you have to disable game mode (scroll lock), press f1 to bring up the menu, select eject disk, select current disk index, select the new disk, select insert disk, then re-enable game mode (scroll lock). But I think that's just a limitation of RetroArch.

Yes, I read everywhere that one can create these famous m3u8 files, but nowhere is it explained out how to use them.

I will probably extend the load_game function and if I receive a m3u8 I simply insert all the images. This will make it super easy to select disks, bypassing RetroArch.

[audetto]

It does look like the memory is being mapped correctly.

Is the video RAM important? https://github.com/libretro/libretro-common/blob/996376e36d3f4f56eba202cb96230568628d2583/include/libretro.h#L313-L314

[Jamiras]

I will probably extend the load_game function and if I receive a m3u8 I simply insert all the images. This will make it super easy to select disks, bypassing RetroArch.

It's just m3u (https://en.wikipedia.org/wiki/M3U).

And how would "insert all images" apply to a game like King's Quest IV which has 17 images (8 double-sided disks + save disk)?

[Jamiras]

Is the video RAM important?

Not usually. Definitely not needed for achievement support.

[Sanaki]

The only distinct difference between m3u and m3u8 is that the latter supports unicode. Long as both extensions are supported, there's no harm in adding m3u8 support as well. But yes, generally it's just basic m3u used.

Mind you, there's nothing mandating that m3u doesn't support unicode. Can just support it under the one extension with no issue.

[audetto]

After installing a whole bunch of cmake dependencies, I get the following error trying to build the core in Windows using MSYS2:

E:/Source/RetroAchievements/cores/AppleWin/source/linux/windows/strings.h:9:6: error: ambiguating new declaration of 'void strcpy_s(char*, size_t, const char*)'

The fact that linux appears in the path suggests this isn't supported.

Discussion moved to https://github.com/audetto/AppleWin/issues/49.

[audetto]

I will probably extend the load_game function and if I receive a m3u8 I simply insert all the images. This will make it super easy to select disks, bypassing RetroArch.

It's just m3u (https://en.wikipedia.org/wiki/M3U).

And how would "insert all images" apply to a game like King's Quest IV which has 17 images (8 double-sided disks + save disk)?

Try now, if you start RetroArch passing a gamepath of a .m3u playlist (i.e. a file with one disk per line, # ignored), they will all be present in the DiscControl interface and the first inserted.

Then, if you switch to another one, when you restart, it will remember it.

All the above is only inserted in Disk 1. It would be easy to use .m3u metadata to select the Disk 1/2, but this would not be accessible via RetroArch gui.

[Jamiras]

Looks like you need to include the base path when resolving the m3u entries. When I try to load an m3u from another directory, it can't find the individual disk files:

[libretro INFO] Insert new disk: King's Quest I - Side A.nib -> 0
[libretro INFO] Game path: /home/brian/roms/appleii/King's Quest I.m3u -> 0

Note the full path in the m3u filename, but no path in the disk filename. It can't find the disk in the current directory (which I assume is the directory that RetroArch is running from). If I modify the m3u to use absolute paths, it does load, and I'm able to switch disks correctly.

Note: you'll probably need to support both relative and absolute m3u paths.

Then, if you switch to another one, when you restart, it will remember it.

This is undesirable. At least for the Sierra games, only the primary disk is bootable.

[Jamiras]

You should also add "m3u" to the supported extensions in retro_get_system_info.

[audetto]

Note: you'll probably need to support both relative and absolute m3u paths.

Makes sense

Then, if you switch to another one, when you restart, it will remember it.

This is undesirable. At least for the Sierra games, only the primary disk is bootable.

Unfortunately, this is the way RetroArch works. It is not me setting it, but libretro.h:

https://github.com/libretro/RetroArch/blob/05f95ad428ae09435f546caf01784db02b1b5c55/libretro-common/include/libretro.h#L2888-L2912

I am a bit reluctant to ignore it altogether, maybe it is meant to be used with save state, to get back in the exact same situation? Who would know?

[Jamiras]

I am a bit reluctant to ignore it altogether, maybe it is meant to be used with save state, to get back in the exact same situation? Who would know?

Just don't provide a retro_set_initial_image function.

https://github.com/libretro/RetroArch/blob/master/libretro-common/include/libretro.h#L2963

retro_set_initial_image_t set_initial_image; /* Optional - may be NULL */

[audetto]

Yes understood, but if every core took these random decisions, the overall user experience would become very frustrating.

[Sanaki]

Every core isn't expected to implement everything. It's a framework there to be utilized for the best fit with the core's functionality. For optical disc systems, games that can't boot from every disc are almost unheard of. If a floppy-based system has few games that can boot from more than one disk, it makes sense not to implement last used disk index.

[audetto]

Since it is 2 against 1, I have removed set_initial_image, I will look at other cores and see what they are doing.

And handle relative paths in playlists.

[audetto]

I have a question for you: how should Load/Save state handle the DiscControl?

Should I save it too?

Otherwise, if I save a state, then insert a different disk, and then load, the Disc Control is not synchronised.

[Jamiras]

I have a question for you: how should Load/Save state handle the DiscControl? Should I save it too? Otherwise, if I save a state, then insert a different disk, and then load, the Disc Control is not synchronised.

Yes. You should save any information that is required to get the emulator back into the same state it was in when the state was created.

The core manages the disc state. RetroArch will query it (via get_eject_state and get_image_index) when building the menu, and the set methods allow RetroArch to influence the state.

[audetto]

Added DiscControl to the save state.

• libappleii.so is an external dependency of the core and can't currently be loaded from a local path (such as the system directory, where bioses and dependencies are usually loaded from when required). If possible, it should either be built into the core itself or loadable from system.

It is all statically linked now. But a few external files are still required: their source path is encoded in the binary. Will have to fix this too.

[gouchi]

@audetto This issue can be closed as it compiles fine as a Libretro core using

mkdir build && cd build && cmake .. -DBUILD_LIBRETRO=ON && make -j$(nproc)

And the core will be available in build/source/frontends/libretro/applewin_libretro.so

Thank you.

[gouchi]

ldd applewin_libretro.so 
    linux-vdso.so.1 (0x00007ffeea2d4000)
    libyaml-0.so.2 => /usr/lib/libyaml-0.so.2 (0x00007fe964b7f000)
    libminizip.so.1 => /usr/lib/libminizip.so.1 (0x00007fe964b72000)
    libpcap.so.1 => /usr/lib/libpcap.so.1 (0x00007fe964b24000)
    libslirp.so.0 => /usr/lib/libslirp.so.0 (0x00007fe964b03000)
    libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007fe9649c7000)
    libz.so.1 => /usr/lib/libz.so.1 (0x00007fe9649ad000)
    libboost_program_options.so.1.78.0 => /usr/lib/libboost_program_options.so.1.78.0 (0x00007fe96493d000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fe964727000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007fe9645e3000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fe9645c8000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007fe9643fc000)
    libnl-genl-3.so.200 => /usr/lib/libnl-genl-3.so.200 (0x00007fe9643f3000)
    libnl-3.so.200 => /usr/lib/libnl-3.so.200 (0x00007fe9643ce000)
    libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007fe964379000)
    libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007fe964302000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fe9642e1000)
    librt.so.1 => /usr/lib/librt.so.1 (0x00007fe9642d6000)
    /usr/lib64/ld-linux-x86-64.so.2 (0x00007fe96505e000)
    libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x00007fe9641f8000)
    liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007fe9641cf000)
    libzstd.so.1 => /usr/lib/libzstd.so.1 (0x00007fe964120000)
    liblz4.so.1 => /usr/lib/liblz4.so.1 (0x00007fe9640fd000)
    libcap.so.2 => /usr/lib/libcap.so.2 (0x00007fe9640f1000)
    libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0x00007fe963fb5000)
    libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00007fe963f8c000)

All those libs are necessary for the Libretro port ?

[audetto]

yes and no. which one is a problem? they are available everywhere.

[gouchi]

We try to avoid having to many external libraries to get "crossplatform portability".

Try to avoid hard dependencies as much as possible, and in cases they can’t be avoided, bake them into the main program.

Source Libretro/RA design goals.

For example, the NeoCD Libretro port has some dependencies but they are "bake in".

That is why also we have libretro-common which are reusable coding blocks useful for Libretro core and frontend development.

Also, RetroArch tries to support as many platforms / operating systems as possible.

[audetto]

Which of the following is the goal

1. build a single binary .so and reuse it on many different (let's say) 64 bit Intel linux distributions?
2. have the source code build on many different systems
3. create a .deb or .rpm

?

From what you are saying, I guess you are going towards 1. If this is true, even the version of libc and libstdc++ will be of concern.

I will remove boost, and soon libpcap will go too, but I did not really have any plan to remove the others.