-
-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
devkitA64: termios.h compilation error #8
Comments
I'm not sure that porting openssl is a great idea tbh. There was some work being done on mbedtls recently, I'll chase that up. ideally I think termios.h should be implemented if possible, there are some other things I'd like to see ported that make use of it but haven't had time to look at properly. |
I guess I should say that I already completed porting it a few weeks ago which was when I first discovered the Implementing |
I'd rather people didn't do this - https://github.com/kbhomes/moonlight-switch/tree/master/dependencies expat is already in our packages, you don't need that. If libopus builds clean then submit a PR to https://github.com/devkitPro/pacman-packages libavcodec is part of ffmpeg which we're currently working on here - devkitPro/pacman-packages#30 Providing packages which conflict with the devkitPro supplied packages will cause problems for everyone eventually. Replacing a cmake based build system with a Makefile is a terrible idea. Ultimately it would be much better to make the build system work rather than replacing it with something less functional. There is the basis of a toolchain file at https://github.com/devkitPro/pacman-packages/blob/master/pkgbuild-scripts/devkita64.cmake which is part of the devkitpro-pkgbuild-helpers package. Ultimately though it looks to me like moonlight would be much more suited to switch-linux rather than attempting to get it portable enough to run on bare metal. |
I understand your concern about conflicting packages, and my apologies for not recognizing that earlier, so I'm going to be changing my dependencies/build script to not use pacman to install the ones that I've built myself. I saw expat was in the packages source but it didn't (and doesn't) appear for me using pacman: Normally I'd agree with not replacing Cmake with Makefiles, but I don't think that's applicable here because there are no optional features or libraries to include for multiple platforms. Unlike the original project that I forked from, this port has one platform target with hard dependencies and libraries being found in one standard location. I'm certainly not losing anything by switching away from Cmake since this was not intended to be merged back upstream. I also disagree that Moonlight is more suited to Linux, I'm sure I'm not alone in not wanting to have to use Linux on my Switch in order to get a Moonlight client to stream games. Additionally, my Moonlight port is already "functional" in that input, audio, and video are streaming with software decoding; all that is missing for usability purposes is hardware acceleration which is a target of the Switch homebrew scene whether or not a Moonlight client exists. |
Modifying a toolchain install is unacceptable If you do that & we do provide termios functions then pacman will be unable to install it and then, congratulations you just broke the toolchain for everyone who used your git repo to build moonlight. This, I know from bitter experience, will cause endless repercussions. Please don't do it. |
switch-expat should be available now, looks like the repo wasn't updated for it. libopus would be appreciated. really, really not keen on openssl - there's a reason why there are several commercial alternatives for embedded work. It's really not a very clean package being yet another configure script that isn't actually a configure script. https://github.com/kbhomes/moonlight-switch/blob/master/dependencies/switch-openssl/PKGBUILD#L25 is a bodge. devkitA64 is a newlib based bare metal compiler, it's not linux & telling packages that it is linux leads to more bodges to compensate for code paths that are linux dependent. mbedtls is @ https://github.com/devkitPro/pacman-packages/tree/mbedtls/switch/mbedtls although we're currently trying to figure out some issues with curl. |
You're right, really sorry about that, I'm in the process of removing the toolchain modifications and the pacman installations, and using switch-libexpat. I also just put in a libopus PR. Once ffmpeg and mbedtls are up and working in the official package I can switch those in as well. |
I just came across this compilation error:
When I looked, indeed sys/termios.h is nowhere to be found. Why is termios.h included in dkp when sys/termios.h is missing? Can this be fixed? EDIT: Nevermind, I guess I don't really need it unless I want to enable networking, which has a slew of other problems. |
devkitPro is not software. Nothing is "included in devkitPro. We are an organisation who provide toolchains & libraries. Please do not attempt to bodge your way around missing headers without talking to us directly. Attempting to port things and maintain them independently causes major headaches for everyone. See https://devkitpro.org/wiki/Community_Portal Newlib includes many headers that are used on some ports but not others. Some ports are built on top of an OS which provides other headers necessary for particular functionality. Any software which checks for the existence of termios.h without also checking that compilation using it works is broken. |
Ok. I don’t like discussing these things on github. Is there a Discord server or only IRC? IRC is just not an option for me. I keep missing messages on irc whenever my network isn’t active and/or whenever I use my vpn, which is blocked by efnet. |
dm me your discord userid on twitter. |
The file
newlib/libc/include/termios.h
of the devkitA64 branch (maybe others?) includes<sys/termios.h>
which is not included or defined anywhere, which causes code that includestermios.h
to fail compilation.I was in the process of porting OpenSSL to devkitA64 in which I found that the path of least resistance to getting the port compiling was to simply create a blank
sys/termios.h
file. What do you think is the best approach for handling thistermios.h
file, since in its current state can only cause compilation errors when included? Short of fully implementingsys/termios.h
, should a blanksys/termios.h
file be created;termios.h
be changed to do nothing; removetermios.h
altogether?The text was updated successfully, but these errors were encountered: