Building in Solaris 11.4

Building in Solaris 11.4

[Michele Denber]

[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]

While trying to run configure in Solaris 11.4, I quickly run into:

root@hemlock:~/qemu-5.0.0# ./configure
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
grep: illegal option -- e
Usage: grep [-c|-l|-q] -bhinsvw pattern file . . .
./configure[62]: local: not found [No such file or directory]

ERROR: "cc" either does not exist or does not work

root@hemlock:~/qemu-5.0.0# gcc --version
gcc (GCC) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

root@hemlock:~/qemu-5.0.0#

Line 62 is

     local compiler="$1"

I'm not familiar with this construct.  What does "local" do?  It wasn't
in the configure file for QEMU 2.12.  (And I already said "cc=gcc")

             - Michele


[-- Attachment #2: Type: text/html, Size: 3107 bytes --]

Re: Building in Solaris 11.4

[Eric Blake]

On 6/24/20 4:31 PM, Michele Denber wrote:
> While trying to run configure in Solaris 11.4, I quickly run into:
> 
> root@hemlock:~/qemu-5.0.0# ./configure
> ./configure[62]: local: not found [No such file or directory]

> grep: illegal option -- e
> Usage: grep [-c|-l|-q] -bhinsvw pattern file . . .
> ./configure[62]: local: not found [No such file or directory]

You've uncovered multiple portability issues, where even though 
configure expects to run with #!/bin/sh, it uses some non-POSIX-isms.


> Line 62 is
> 
>      local compiler="$1"
> 
> I'm not familiar with this construct.  What does "local" do?  It wasn't
> in the configure file for QEMU 2.12.  (And I already said "cc=gcc")

local is a bash-ism (ksh has it to) that changes how variables are 
scoped within shell functions.  The options to fix it are to either: 
avoid local and use global variables everywhere (and worrying about 
naming collisions when one function calls another), or to tweak 
configure so that it re-exec's itself under bash if it detects that 
/bin/sh is not up to our usage expectations.  (configure scripts 
generated by Autoconf do the latter, but qemu doesn't use autoconf).

grep -e is also a non-portable construct; it might be possible to change 
that line to call egrep instead, or to rewrite the regex to not need 
extended regex.

As a short-term workaround, you can always do:

/path/to/bash ./configure

to run it under a shell that won't choke on our use of non-posix constructs.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: Building in Solaris 11.4

[Eric Blake]

On 6/24/20 4:48 PM, Eric Blake wrote:

> grep -e is also a non-portable construct; it might be possible to change 
> that line to call egrep instead, or to rewrite the regex to not need 
> extended regex.
> 
> As a short-term workaround, you can always do:
> 
> /path/to/bash ./configure
> 
> to run it under a shell that won't choke on our use of non-posix 
> constructs.
> 

that will avoid the problems with local, but not necessarily the problem 
with a missing 'grep -e'.  A common approach there is to set $GREP up 
front to something capable, but then you have to scrub for uses of grep 
in configure to be replaced with $GREP.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: Building in Solaris 11.4

[Michele Denber]

[-- Attachment #1: Type: text/plain, Size: 2260 bytes --]

Subject: 	Re: Building in Solaris 11.4
Date: 	Wed, 24 Jun 2020 16:48:51 -0500
From: 	Eric Blake <eblake@redhat.com>
Organization: 	Red Hat, Inc.
To: 	Michele Denber <mdenber@gmx.com>, qemu-devel@nongnu.org



>
> As a short-term workaround, you can always do:
>
> /path/to/bash ./configure
Ah yes, thank you.  I now recall having that problem building 2.12  in
Solaris 10 a few years ago.  The default bash in Solaris 11.4 is
/usr/bin/bash and that won't work.  I used /opt/csw/bin/bash instead and
that took care of the "local" problem.

Similarly, the default Solaris grep is missing the -e option so I
changed grep to ggrep in configure.  POSIX was always problematic in
Solaris because, I believe of Sun's efforts to maintain backward
compatibility.

So now I've got:

root@hemlock:~/qemu-5.0.0# /opt/csw/bin/bash ./configure --cc=gcc

ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
        You probably need to set PKG_CONFIG_LIBDIR
        to point to the right pkg-config files for your
        build target
root@hemlock:~/qemu-5.0.0#

I fixed that by saying

# LD_LIBRARY_PATH
=/usr/openwin/lib:opt/csw/lib:/usr/local/lib:/lib:/opt/sfw/lib:/opt/csw/gxx/lib:/usr/X11/lib
#
PKG_CONFIG_PATH=/opt/csw/lib/pkgconfig:/usr/local/lib/pkgconfig:/opt/sfw/lib/pkgconfig:/usr/lib/pkgconfig
#
PKG_CONFIG_LIBDIR=/opt/csw/lib/pkgconfig:/usr/local/lib/pkgconfig:/opt/sfw/lib/pkgconfig:/usr/lib/pkgconfig
# /opt/csw/bin/bash ./configure --cc=gcc  --extra-cflags="-m32"

(Thankfully I still have some notes from building QEMU 2.12.)

That gave me a successful configure ending with:

The QEMU project intends to remove support for this host OS in
a future release if nobody volunteers to maintain it and to
provide a build host for our continuous integration setup.
configure has succeeded and you can continue to build, but
if you care about QEMU on this platform you should contact
us upstream at qemu-devel@nongnu.org.

So I hereby volunteer.  I have an 8 core 64 thread 2.85 GHz. Sun T4-1
with 64 GB and three 900 GB disks and a 500 MB/50 MB fiber Internet
connection..

Anyway, that's enough for one day.  On to the gmake.  I'm sure I'll have
more questions soon :-)

             - Michele



[-- Attachment #2: Type: text/html, Size: 4563 bytes --]

Re: Building in Solaris 11.4

[Michele Denber]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

Well the make ran for a while and then stopped here:


root@hemlock:~/qemu-5.0.0# gmake -j16
...
   CC      util/bitops.o
util/qemu-openpty.c:56:12: error: static declaration of
\u2018openpty\u2019 follows non-static declaration
  static int openpty(int *amaster, int *aslave, char *name,
             ^~~~~~~
In file included from /usr/include/termios.h:8:0,
                  from util/qemu-openpty.c:48:
/usr/include/sys/termios.h:538:12: note: previous declaration of
\u2018openpty\u2019 was here
  extern int openpty(int *, int *, char *, struct termios *, struct
winsize *);
             ^~~~~~~
gmake: *** [/export/home/denber/qemu-5.0.0/rules.mak:69:
util/qemu-openpty.o] Error 1

Interestingly, I ran across this openpty issue last year while building
QEMU 2.12 in Solaris 10, here: https://bugs.launchpad.net/qemu/+bug/1777252

It looks like the change to fix that issue (missing openpty in Solaris)
is having some trouble.  I'm not a good enough C programmer to figure it
out.  Remove the openpty declaration from util/openpty.c perhaps?

             - Michele



[-- Attachment #2: Type: text/html, Size: 2118 bytes --]

Re: Building in Solaris 11.4

[Michele Denber]

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

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



[-- Attachment #2: Type: text/html, Size: 4135 bytes --]

Re: Building in Solaris 11.4

[Peter Maydell]

On Sat, 27 Jun 2020 at 23:05, Michele Denber <denber@mindspring.com> wrote:
>
> 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.

No, that doesn't sound right. The code in qemu-openpty.c
for Solaris assumes that solaris does not provide
openpty(), and so it provides its own implementation.
This is a very old bit of portability-workaround. It
sounds like at least some Solaris versions do provide
a system openpty() in termios.h (in libc, or perhaps
needing an extra -lsomething?), in which case we want
to detect that and use it (not compiling the QEMU
code for solaris-without-openpty).

The first thing to do here would be to find out which
versions of Solaris provide openpty(), and which header
and library need to be used to compile code that uses it.
The gnulib docs think it is missing on Solaris 11.3:
do we care about supporting that as a host OS?
https://www.gnu.org/software/gnulib/manual/html_node/openpty.html

Then you'd need to improve configure so that it looked for
"does the system provide openpty() via termios.h" and defined
CONFIG_OPENPTY_IN_TERMIOS to indicate that; then if that is
set we qemu-openpty.c can make solaris use the "system has
openpty()" codepath rather than "system doesn't have that".
If it turns out that all Solaris versions new enough that we
might care about them do have openpty() we could also delete
the handling code for systems that don't.

> 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.

Ah, the Haiku folks just ran into exactly this issue.
Their fix should also be good for Solaris:
https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg08800.html
(This whole file is for using a Linux-specific feature so there's
no point even compiling it for other OSes.)

thanks
-- PMM

Re: Building in Solaris 11.4

[Peter Tribble]

[-- Attachment #1: Type: text/plain, Size: 3167 bytes --]

On Sun, Jun 28, 2020 at 2:23 PM Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Sat, 27 Jun 2020 at 23:05, Michele Denber <denber@mindspring.com>
> wrote:
> >
> > 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.
>
> No, that doesn't sound right. The code in qemu-openpty.c
> for Solaris assumes that solaris does not provide
> openpty(), and so it provides its own implementation.
> This is a very old bit of portability-workaround. It
> sounds like at least some Solaris versions do provide
> a system openpty() in termios.h (in libc, or perhaps
> needing an extra -lsomething?), in which case we want
> to detect that and use it (not compiling the QEMU
> code for solaris-without-openpty).
>
> The first thing to do here would be to find out which
> versions of Solaris provide openpty(), and which header
> and library need to be used to compile code that uses it.
> The gnulib docs think it is missing on Solaris 11.3:
> do we care about supporting that as a host OS?
> https://www.gnu.org/software/gnulib/manual/html_node/openpty.html
>

I think you need to support older versions that don't ship openpty(),
as 11.4 dropped support for a lot of older hardware so people with
existing (older but working) hardware won't be able to upgrade to it.

Also, illumos doesn't (yet) have openpty.


> Then you'd need to improve configure so that it looked for
> "does the system provide openpty() via termios.h" and defined
> CONFIG_OPENPTY_IN_TERMIOS to indicate that; then if that is
> set we qemu-openpty.c can make solaris use the "system has
> openpty()" codepath rather than "system doesn't have that".
> If it turns out that all Solaris versions new enough that we
> might care about them do have openpty() we could also delete
> the handling code for systems that don't.
>
> > 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.
>
> Ah, the Haiku folks just ran into exactly this issue.
> Their fix should also be good for Solaris:
> https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg08800.html
> (This whole file is for using a Linux-specific feature so there's
> no point even compiling it for other OSes.)
>
> thanks
> -- PMM
>
>

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

[-- Attachment #2: Type: text/html, Size: 4620 bytes --]

Re: Building in Solaris 11.4

[Thomas Huth]

On 27/06/2020 18.24, Michele Denber wrote:
> Well the make ran for a while and then stopped here:
> 
> 
> root@hemlock:~/qemu-5.0.0# gmake -j16
> ...
>    CC      util/bitops.o
> util/qemu-openpty.c:56:12: error: static declaration of 
> \u2018openpty\u2019 follows non-static declaration
>   static int openpty(int *amaster, int *aslave, char *name,
>              ^~~~~~~
> In file included from /usr/include/termios.h:8:0,
>                   from util/qemu-openpty.c:48:
> /usr/include/sys/termios.h:538:12: note: previous declaration of 
> \u2018openpty\u2019 was here
>   extern int openpty(int *, int *, char *, struct termios *, struct 
> winsize *);
>              ^~~~~~~
> gmake: *** [/export/home/denber/qemu-5.0.0/rules.mak:69: 
> util/qemu-openpty.o] Error 1
> 
> Interestingly, I ran across this openpty issue last year while building 
> QEMU 2.12 in Solaris 10, here: https://bugs.launchpad.net/qemu/+bug/1777252
> 
> It looks like the change to fix that issue (missing openpty in Solaris) 
> is having some trouble.  I'm not a good enough C programmer to figure it 
> out.  Remove the openpty declaration from util/openpty.c perhaps?

It's not the same bug as last year, but a new one: Seems like newer 
versions of Solaris now have this functions in their libraries! So what 
you want is something like this (completely untested):

diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -5159,10 +5159,14 @@ extern int openpty(int *am, int *as, char *name, 
void *termp, void *winp);
  int main(void) { return openpty(0, 0, 0, 0, 0); }
  EOF

-if ! compile_prog "" "" ; then
+have_openpty="no"
+if compile_prog "" "" ; then
+  have_openpty="yes"
+else
    if compile_prog "" "-lutil" ; then
      libs_softmmu="-lutil $libs_softmmu"
      libs_tools="-lutil $libs_tools"
+    have_openpty="yes"
    fi
  fi

@@ -7407,6 +7411,9 @@ fi
  if test "$have_broken_size_max" = "yes" ; then
      echo "HAVE_BROKEN_SIZE_MAX=y" >> $config_host_mak
  fi
+if test "$have_openpty" = "yes" ; then
+    echo "HAVE_OPENPTY=y" >> $config_host_mak
+fi

  # Work around a system header bug with some kernel/XFS header
  # versions where they both try to define 'struct fsxattr':
diff --git a/util/qemu-openpty.c b/util/qemu-openpty.c
--- a/util/qemu-openpty.c
+++ b/util/qemu-openpty.c
@@ -52,7 +52,8 @@
  #endif

  #ifdef __sun__
-/* Once Solaris has openpty(), this is going to be removed. */
+
+#if !defined(HAVE_OPENPTY)
  static int openpty(int *amaster, int *aslave, char *name,
                     struct termios *termp, struct winsize *winp)
  {
@@ -93,6 +94,7 @@ err:
          close(mfd);
          return -1;
  }
+#endif

  static void cfmakeraw (struct termios *termios_p)
  {

  HTH,
   Thomas

Re: Building in Solaris 11.4

[Michele Denber]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On 06-29-2020 8:12 AM, Thomas Huth wrote:
> ...
> It's not the same bug as last year, but a new one: Seems like newer
> versions of Solaris now have this functions in their libraries!
Yes - I just checked. Solaris 10 does not have openpty, but Solaris 11.4
indeed does have it
> So what you want is something like this (completely untested):

So just to make sure I have this right - I save that code into a patch
file and then apply it where?  At the qemu-5.0.0 level?  Then run
configure again?

Right now I'm looking at that "struct dirent" problem in gmake I
mentioned a few days ago.  I will try the Haiku patch offered by PMM.

             - MIchele


[-- Attachment #2: Type: text/html, Size: 1328 bytes --]

Re: Building in Solaris 11.4

[Thomas Huth]

On 29/06/2020 22.25, Michele Denber wrote:
> On 06-29-2020 8:12 AM, Thomas Huth wrote:
>> ...
>> It's not the same bug as last year, but a new one: Seems like newer 
>> versions of Solaris now have this functions in their libraries!
> Yes - I just checked. Solaris 10 does not have openpty, but Solaris 11.4 
> indeed does have it
>> So what you want is something like this (completely untested):
> 
> So just to make sure I have this right - I save that code into a patch 
> file and then apply it where?  At the qemu-5.0.0 level?

Yes. I used the current git master branch, but I assume that it will 
also still apply to the 5.0 release.

>  Then run  configure again?

Yes. Please let me know if it works, then I can try to get the patch 
submitted.

  HTH,
   Thomas