Solaris access for porting S-nail (a MUA)?

[Steffen Nurpmeso via buildfarm]

Hello!

Dagobert Michelsen <dam at opencsw.org> wrote:
 |Am 20.05.2015 um 15:31 schrieb Steffen Nurpmeso <sdaoden at yandex.com>:
 |> Dagobert Michelsen <dam at opencsw.org> wrote:
 |>|Am 20.05.2015 um 13:10 schrieb Steffen Nurpmeso <sdaoden at yandex.com>:
 |>|> I'm maintaining S-nail, an extended mailx(1)-like MUA.  I came
 |>|> along OpenCSW via an announcement from Ingo Schwarze and would be
 |>|> very interested in gaining access to the Solaris operating system
 |>|> for compile-testing (and "make test"ing) this program!  (I'm also

 |You should be able to do
 |  ssh sdaoden at login.opencsw.org
 |Please make sure to read /etc/SETUP. Just let me know if you need anything.

Once more i want to thank you for giving me this option!
Nothing more than some name shadowing warnings on the code side.
The build system of S-nail however required quite a lot of work to
be able to get us going here, on at least 5.10 and 5.11.

And i have to admit i remain having problems that seem to
originate in the gcc(1) installations and also in OpenSSL; i have
spend this entire day on your systems and wasted an immense amount
of CPU time without being able to improve this situation.
Excerpt of our [master] INSTALL:

  . Solaris <http://opencsw.org/>
    * First of all: thanks to OpenCSW.org for offering SSH access to
      their Solaris build cluster!

Yes.  Yes.  Yes!

    - According to standards(5) we require the /usr/xpg4 environment, and
      will bail if we cannot find it.
    - I couldn't get us going on SunOS 5.9: the build system had to be
      extended to check for UINTPTR_MAX being defined as the empty string
      and similar very special things.

I first worked around that on the Sun via __UINTPTR_MAX__, but on
x86 that wouldn't have helped, so i removed that hack again.
Otherwise nothing much should prevent us.

    - With WANT_AUTOCC: we try to use Sun cc(1) whenever we find it.
      If your gcc(1) installation is doing alright you have to turn
      WANT_AUTOCC off and use $CC, $CFLAGS and $LDFLAGS.

Yeah!  (+_°)

    - I will never get iconv(3) right for Solaris it seems.

Just like for DragonFly we'd had to do a dance around "char",
"const char", "char restrict" and whatever combinations are
possible.  (Maybe the build system will at a later time check
-Werror and generate test programs to do that really right by not
causing compiler warnings.)

    - In order to be able to run the tests you will need a cksum that
      supports CRC-32 (POSIX).  We look into /opt/csw/gnu/cksum, but if
      that is not there you have to adjust cksum (see above) to something
      that works.  (A future version of S-nail will use different
      testing, but until then: Sorry!)

A later version of S-nail will include expected-/real-result
comparison, but i didn't make it to this one yet.  (Of course we
could do so today for what we have, but the entire MIME code will
be replaced and then all of that will have to be changed anyway.
I searched for a quick-and-dirty approach once i took
maintainership, facing this situation, and then i didn't expect
any problems with cksum(1) a.k.a. CRC-32.  And including a CRC-32
tester isn't worth it either with the upcoming changes in mind.)

    SunOS 5.10 Generic_150400-17 sun4v sparc SUNW,SPARC-Enterprise-T5220
    - gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
      + A lot of warnings on longjmp() clobbering.
      + S/MIME tests fail with "OpenSSL 1.0.1j 15 Oct 2014 (Library:
        OpenSSL 1.0.1m 19 Mar 2015)":
          behave:s/mime:sign/verify:
          Error creating the PKCS#7 signing object: \
            error:21083097:lib(33):func(131):reason(151)

"login".  This error we now produce, so something seems to have
been broken -- since, on "login", S-nail already ran last Friday,
and back then we didn't produce this error!

    SunOS 5.10 Generic_150400-17 sun4v sparc SUNW,SPARC-Enterprise-T5220
    - cc: Sun C 5.9 SunOS_sparc Patch 124867-16 2010/08/11
      + Some harmless warnings.
      + S/MIME tests fail with "OpenSSL 1.0.1m 19 Mar 2015":
          behave:s/mime:sign/verify:
          Error creating the PKCS#7 signing object: \
            error:21083097:lib(33):func(131):reason(151)

Ouch!  The same.  Something must have been broken on the
installation?

    SunOS 5.10 Generic_147441-19 i86pc i386 i86pc
    - cc: Sun C 5.9 SunOS_i386 Patch 124868-15 2010/08/11
      + Some harmless warnings.

Fine beside that.

    SunOS 5.11 11.2 sun4u sparc SUNW,SPARC-Enterprise
    - (GCC) 4.9.2
      + We forcefully disable stack protectors on SunOS/gcc because of
        linking errors:
          Undefined                       first referenced
           symbol                             in file
          __stack_chk_fail                    accmacvar.o
          __stack_chk_guard                   accmacvar.o
          ld: fatal: symbol referencing errors

It works just fine if we don't use -fstack-protector-X.
Internet suggests we will have to link in -lssp manually.
That is good enough for now, i'll check that when i release
v14.8.1 in a month with the final codebase.

      + Quite some (false) warnings on maybe-uninitialized.
    SunOS 5.11 11.0 i86pc i386 i86pc
    - gcc (GCC) 4.9.2
      + Couldn't link:
        Undefined                       first referenced
         symbol                             in file
        __builtin_stdarg_start              auxlily.o

Here i do believe this is a gcc(1) installation issue?
Do you have any hints on how to circumvent that?
I can't get around to thank you once again.
Ciao!

--steffen