Well I removed the "static" from the line
static int openpty(int *amaster, int *aslave, char *name,
struct termios *termp, struct winsize *winp)
in util/qemu-openpty.c. I odn't know if that was the right thing to do
but it did allow it to compile. Now I'm stopped here:
...
CC monitor/trace.o
util/drm.c: In function 'qemu_drm_rendernode_open':
util/drm.c:41:16: error: 'struct dirent' has no member named 'd_type';
did you mean 'd_name'?
if (e->d_type != DT_CHR) {
^~~~~~
d_name
util/drm.c:41:26: error: 'DT_CHR' undeclared (first use in this
function); did you mean 'TH_CWR'?
if (e->d_type != DT_CHR) {
^~~~~~
TH_CWR
util/drm.c:41:26: note: each undeclared identifier is reported only once
for each function it appears in
gmake: *** [/export/home/denber/qemu-5.0.0/rules.mak:69: util/drm.o] Error 1
This looks like more "not in Solaris" POSIX stuff. See
https://stackoverflow.com/questions/35215109/struct-dirent-does-not-have-de-type-in-header-file
"The only fields in the dirent structure that are mandated by
POSIX.1 are: d_name[], of unspecified size, with at most NAME_MAX
characters preceding the terminating null byte; and (as an XSI
extension) d_ino. /The other fields are unstandardized, and not
present on all systems/; see NOTES below for some further details.
then continues
Only the fields d_name and d_ino are specified in POSIX.1-2001. The
remaining fields are available on many, but not all systems. Under
glibc, programs can check for the availability of the fields not
defined in POSIX.1 by testing whether the macros
_DIRENT_HAVE_D_NAMLEN, _DIRENT_HAVE_D_RECLEN, _DIRENT_HAVE_D_OFF, or
_DIRENT_HAVE_D_TYPE are defined.
*Other than Linux, the d_type field is available mainly only on BSD
systems.* This field makes it possible to avoid the expense of
calling lstat(2) if further actions depend on the type of the file.
If the _BSD_SOURCE feature test macro is defined, then glibc defines
the following macro constants for the value returned in d_type:"
But I'm not sure what to make of this.
- Michele
