[request] MUSL support - Githubissues

johnny-mac commented 6 years ago

Hello, I would like to build PCSX2 for Void Linux MUSL, however there are a number of errors that stop me from doing so, perhaps some 32-bit libraries must be built for MUSL, I'm unsure of where to begin with such a thing, so I'm hoping someone here can help me along in my mission.

cmake -DCMAKE_TOOLCHAIN_FILE=cmake/linux-compiler-i386-multilib.cmake ..
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- broken
CMake Error at /usr/share/cmake-3.12/Modules/CMakeTestCCompiler.cmake:52 (message):
  The C compiler

    "/usr/bin/cc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /home/user/Compiles/pcsx2/build/CMakeFiles/CMakeTmp

    Run Build Command:"/usr/bin/make" "cmTC_a9750/fast"
    /usr/bin/make -f CMakeFiles/cmTC_a9750.dir/build.make CMakeFiles/cmTC_a9750.dir/build
    make[1]: Entering directory '/home/user/Compiles/pcsx2/build/CMakeFiles/CMakeTmp'
    Building C object CMakeFiles/cmTC_a9750.dir/testCCompiler.c.o
    /usr/bin/cc -m32    -o CMakeFiles/cmTC_a9750.dir/testCCompiler.c.o   -c /home/user/Compiles/pcsx2/build/CMakeFiles/CMakeTmp/testCCompiler.c
    Linking C executable cmTC_a9750
    /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_a9750.dir/link.txt --verbose=1
    /usr/bin/cc -m32      -rdynamic CMakeFiles/cmTC_a9750.dir/testCCompiler.c.o  -o cmTC_a9750 
    /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-musl/8.2.0/libgcc.a when searching for -lgcc
    /usr/bin/ld: cannot find -lgcc
    /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-musl/8.2.0/../../../../lib/libgcc_s.so.1 when searching for libgcc_s.so.1
    /usr/bin/ld: skipping incompatible /lib/../lib/libgcc_s.so.1 when searching for libgcc_s.so.1
    /usr/bin/ld: skipping incompatible /usr/lib/../lib/libgcc_s.so.1 when searching for libgcc_s.so.1
    /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-musl/8.2.0/../../../libgcc_s.so.1 when searching for libgcc_s.so.1
    /usr/bin/ld: skipping incompatible /lib/libgcc_s.so.1 when searching for libgcc_s.so.1
    /usr/bin/ld: skipping incompatible /usr/lib/libgcc_s.so.1 when searching for libgcc_s.so.1
    /usr/bin/ld: cannot find libgcc_s.so.1
    /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-musl/8.2.0/libgcc.a when searching for -lgcc
    /usr/bin/ld: cannot find -lgcc
    collect2: error: ld returned 1 exit status
    make[1]: *** [CMakeFiles/cmTC_a9750.dir/build.make:87: cmTC_a9750] Error 1
    make[1]: Leaving directory '/home/user/Compiles/pcsx2/build/CMakeFiles/CMakeTmp'
    make: *** [Makefile:121: cmTC_a9750/fast] Error 2

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)

-- Configuring incomplete, errors occurred!
See also "/home/user/Compiles/pcsx2/build/CMakeFiles/CMakeOutput.log".
See also "/home/user/Compiles/pcsx2/build/CMakeFiles/CMakeError.log".

willkuer commented 6 years ago

So apparently pcsx2 is shipped with a test program checking whether your system is able to build pcsx2 in something like a smoke test. I wasn‘t even aware of this.

So that helps you already enormously. Try to fix building of this test program and you‘ll get much closer to build pcsx2. There is a flag mentioned, some line number in the cmake file and an incompatibility package warning. Googling these errors or code leading to those errors in the context of musl should lead you.

dariusc93 commented 5 years ago

Honestly, I do not feel musl should be directly supported. This is due to some limitations on musl end which would require changes in plugins as well (eg musl doesnt support dlopen or similar commands, though correct me if they decide to change that). On top of that, it would add another thing requiring debugging if something breaks and im pretty sure there is a lot more the devs want to do than to worry about adding support for musl (unless youre willing to contribute and maintain the support then they may be open to PR).

avih commented 5 years ago

The C compiler "/usr/bin/cc" is not able to compile a simple test program.

This message does not appear to be related to PCSX2. Cmake just tries the compiler and fails. It sounds like either cmake is not setup correctly on your system, or there's some specific need of PCSX2 which cmake (or the compiler) on your system does not satisfy.

To test the former assumption, try to use cmake with another project on your system. On the latter case it might be related to multilib and the fact that PCSX2 needs to be built as a 32 bit applications.

Honestly, I do not feel musl should be directly supported

Agreed, because musl expects the program to be correct, and then supposedly it should work without specific musl support.

eg musl doesnt support dlopen

Not sure where you got your info from, but it's clearly wrong. However, musl's dlopen may behave a bit differently, and supposedly more correctly than glibc's . Again, if dlopen is used correctly, there should be no need for specific support for musl.

dariusc93 commented 5 years ago

Not sure when you got your info, but it's clearly wrong. However, musl's dlopen may behave a bit differently, and supposedly more correctly than glibc's . Again, if dlopen is used correctly, there should be no need for specific support for musl.

With musl, everything is linked statically, and the last I used musl, dlopen didnt work. I believe there was a way to get it working but would be more complicated and would partially defeat the purpose of using musl but if things changed between the last time I've used it (which was late '16) to now, then feel free to correct me and point me to the documents supporting that so I can catch up on it.

avih commented 5 years ago

With musl, everything is linked statically

If everything is linked statically, then it's how your distro configured gcc. musl doesn't have any bias towards static or dynamic linking. If you want to try a distro which uses musl nicely, check Alpine linux .

I don't believe any of this changed since 2016 (and probably a lot earlier).

weirdbeardgame commented 5 years ago

https://docs.appimage.org/packaging-guide/hosted-services/travis-ci.html#ref-travis-ci so rather than making a flatpak image it'd probably be better to make an app image instead. Better support for automated builds and the like

gregory38 commented 5 years ago

Dynamic support is likely an option (disclaimer, I only know uclibc). And yes the message is from cmake. You might to need to tune some compiler options too.

pixelherodev commented 5 years ago

Dynamic support is definitely possible.

I'll see if I can make any progress on this issue. I recently switched my development laptop and my PC over to Alpine Linux, which uses musl.

The real biggest concern with MUSL support is that no distro that I'm aware of provides multilib-esque support. musl does itself support co-existing for multiple architectures, so x86 can exist alongside x86_64 without needing a chroot, but there's no system I'm aware of which actually provides this. Statically linking wouldn't get around this problem, because the ELF loader for x86 would still be missing.

pixelherodev commented 5 years ago

There are some dlopen differences, but only one that is likely to affect PCSX2:

Destructors will run on dlclose (as long as there are no remaining references) under glibc, and subsequent opens of the same library will run their constructors again. Under musl, constructors only run the first time a library is run, and destructors only run on exit.
Under glibc, the contents of all static storage in a library will be reset to its original state if the library is unloaded and reloaded. Under musl, it will never be reset.
Address space from a library remains tied up even after dlclose on musl, so opening and closing an infinite family of libraries will eventually consume the entire address space and other resources. However, as long as there’s only a finite set of libraries being opened and closed, address space usage will be bounded. Under glibc, address space from closed libraries is free to be used again.

Closing a plugin and then reopening it will not reset its variables, so the plugin interface might need an explicit reset function if one does not already exist.

pixelherodev commented 5 years ago

Regarding dynamic support: I have written a plugin-based emulator that runs perfectly fine under musl. My design was unaffected by any of these differences (though it was plenty buggy for other reasons), and used libdl under the hood (using a small C++ library I wrote which abstracts away the error checking and function access). I am 100% certain libdl is usable under musl.

dariusc93 commented 5 years ago

Yea after doing a little research after the discussion above I did see that musl had dlopen. Back when I used musl, it wouldve gave an error when using it so a lot have changed from that time to now so I would be interested in seeing how it would go under pcsx2.

On Fri, Mar 1, 2019 at 3:56 PM pixelherodev notifications@github.com wrote:

Dynamic support is definitely possible.

I'll see if I can make any progress on this issue. I recently switched my development laptop and my PC over to Alpine Linux, which uses musl.

The real biggest concern with MUSL support is that no distro that I'm aware of provides multilib-esque support. musl does itself support co-existing for multiple architectures, so x86 can exist alongside x86_64 without needing a chroot, but there's no system I'm aware of which actually provides this. Statically linking wouldn't get around this problem, because the ELF loader for x86 would still be missing.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/PCSX2/pcsx2/issues/2600#issuecomment-468808712, or mute the thread https://github.com/notifications/unsubscribe-auth/ADvIyIi43dXDM8bSSvvg1caMGv9v0Fgaks5vSZPmgaJpZM4Ww1So .

nekopsykose commented 1 year ago

aside from a single 1-line patch to fix an iovec redefine in iov.h (the guards don't guard against the redefinition because the things it checks don't exist on musl), it builds and runs on musl fine, playing whatever games i throw at it (qt6 frontend). looks complete to me

lightningterror commented 1 year ago

Guess it can be closed then.

PCSX2 / pcsx2

[request] MUSL support #2600