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

Dagobert Michelsen via buildfarm buildfarm at lists.opencsw.org
Wed May 27 18:58:06 CEST 2015


Hi Steffen,

> Am 26.05.2015 um 20:51 schrieb Steffen Nurpmeso <sdaoden at yandex.com>:
> 
> 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!

Sure, glad I could help.

> 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!  (+_°)

The path what somewhat standardized to /opt/SUNWspro for earlier
versions and
/opt/sunstudio12.1
/opt/solarisstudio12.3
/opt/solarisstudio12.4
for newer versions where the prefixes are hardcoded in the installer.

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

This is also a speciality with Sun Studio which is very strict on „const“
issues.

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

This gcc is really old and shipped with Solaris. I suggest not to use it.

> "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 have never seen this issue.


Best regards and keep up porting!

  — Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2418 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/buildfarm/attachments/20150527/9adab2bd/attachment.p7s>


More information about the buildfarm mailing list