devkitPro / newlib

fork from sourceware git://sourceware.org / newlib-cygwin.git
https://devkitpro.org
GNU General Public License v2.0
22 stars 16 forks source link

devkitA64: termios.h compilation error #8

Open kbhomes opened 6 years ago

kbhomes commented 6 years ago

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 includes termios.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 this termios.h file, since in its current state can only cause compilation errors when included? Short of fully implementing sys/termios.h, should a blank sys/termios.h file be created; termios.h be changed to do nothing; remove termios.h altogether?

WinterMute commented 6 years ago

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.

kbhomes commented 6 years ago

I guess I should say that I already completed porting it a few weeks ago which was when I first discovered the termios.h issue. You can see what I did here, used for my Moonlight Switch port (the original source uses OpenSSL, hence why I went ahead with porting it). Down the line I'm sure it could be switched out for mbedtls, but for my purposes it suffices.

Implementing termios.h makes the most sense long-term of course. Haven't a clue how much time would be needed to undertake that, not sure I'd be able to get to it myself.

WinterMute commented 6 years ago

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 - https://github.com/devkitPro/pacman-packages/issues/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.

kbhomes commented 6 years ago

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: sudo dkp-pacman -Syl | grep "expat" is blank for me. Opus appears to work just fine so I'll submit a PR for that shortly. Is OpenSSL something that would ever be accepted in the Switch repository, or should I assume that only mbedtls will be supported?

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.

WinterMute commented 6 years ago

Modifying a toolchain install is unacceptable

https://github.com/kbhomes/moonlight-switch/blob/master/dependencies/dependencies.sh#L18-L22

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.

WinterMute commented 6 years ago

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.

kbhomes commented 6 years ago

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.

rsn8887 commented 5 years ago

I just came across this compilation error:

/opt/devkitpro/devkitA64/aarch64-none-elf/include/termios.h:4:10: fatal error: sys/termios.h: No such file or directory #include <sys/termios.h>

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.

WinterMute commented 5 years ago

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.

rsn8887 commented 5 years ago

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.

WinterMute commented 5 years ago

dm me your discord userid on twitter.