check / Bugs / #97 Build fixes for Solaris

Branden Archer - 2014-05-07

Thanks for the bug report.

The issue with the -pedantic flag was mentioned, and is removed in check's SVN HEAD.

Is there a more portable sed expression that can be used instead? For example, does the sed on Solaris not like the :space: and :alnum: abbreviations, and may work if it was specified as [\t\r\n\v\f] and [a-zA-Z0-9] instead?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Branden Archer - 2014-05-08

Please give this patch a try and see if it resolves the issue with sed on Solaris.

0001-autotools-replace-sed-abbreviations.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Georg Sauthoff - 2014-05-08

No, this this patch does not work.

The original sed expression is even POSIX - thus in principle portable. The thing is just that Solaris is kind of fixated on backwards compatibility. Thus, most tools under /bin, /usr/bin are not POSIX conforming (including /bin/sh!).

Basically the standard conforming portable way to get the standard conforming sed is to do something like this:

$ PATH=`getconf PATH` which sed

For example on Solaris you get then this:

/usr/xpg4/bin/sed

And with that sed the original sed expression works:

$ /usr/xpg4/bin/sed -n -e 's/^..*CK_EXPORT[[:space:]][[:space:]]*$[[:alnum:]_][[:alnum:]_]*$..*$/\1/p' src/check.h.in check_major_version check_minor_version check_micro_version [..]

Alternatively, following pipe creates the same output:

$ /usr/bin/grep '^CK_DLL_EXP..*CK_EXPORT' src/check.h.in | /usr/bin/sed 's/^.*CK_EXPORT //' | /usr/bin/sed 's/[ (;].*$//'

There is also AC_PROG_SED - I'll test it to check if it fails on /usr/bin/sed (and perhaps even automatically finds the xpg4 version) under Solaris and report back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Georg Sauthoff - 2014-05-08

Ok, I've tested a little bit around - and it went better than expected.

The AC_PROG_SED macro does find gsed on Solaris 10. I've placed it here:

--- a/configure.ac +++ b/configure.ac @@ -126,6 +126,7 @@ esac], [enable_timer_replacement=autodetect ]) # Checks for programs. +AC_PROG_SED AC_PROG_AWK AC_PROG_CC # Automake wants this for per-target CFLAGS

Surprisingly, I get this configure output then:

checking for a sed that does not truncate output... /opt/csw/bin/gsed [..] checking for a sed that does not truncate output... (cached) /opt/csw/bin/gsed

When removing /opt/csw/bin from the PATH, it also finds seds which are compatible to the used sed expression, e.g.

checking for a sed that does not truncate output... /usr/xpg4/bin/sed

(But it does not error out when the PATH neither contains gsed nor /usr/xpg4/bin - it picks up /usr/bin/sed then, which is non-conforming - but still a huge improvement.)

That means that an explicit AC_PROG_SED is not needed - it is already implicitly executed (perhaps this is a autoconf default or dependency of another check).

The Fix

Anyway, following patch fixes the generation of exported.sym under Solaris 10:

--- a/src/Makefile.am +++ b/src/Makefile.am @@ -34,7 +34,7 @@ HFILES =\ EXPORT_SYM = exported.sym $(EXPORT_SYM): check.h.in - sed -n -e 's/^..*CK_EXPORT[[:space:]][[:space:]]*$[[:alnum:]_][[:alnum:]_]*$..*$$/\1/p' @top_srcdir@/src/check.h.in > $@ + $(SED) -n -e 's/^..*CK_EXPORT[[:space:]][[:space:]]*$[[:alnum:]_][[:alnum:]_]*$..*$$/\1/p' @top_srcdir@/src/check.h.in > $@ libcheck_la_DEPENDENCIES= $(EXPORT_SYM) libcheck_la_LDFLAGS = -no-undefined -export-symbols $(EXPORT_SYM)

(where the SED variable is set by the AC_PROG_SED check)

Implicit Defined Functions

Btw, I've noticed some implicit defined function warnings:

cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -g -c -o check_check-check_check_msg.o `test -f 'check_check_msg.c' || echo './'`check_check_msg.c "check_check_msg.c", line 64: warning: implicit function declaration: tr_free cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -DTIMEOUT_TESTS_ENABLED=0 -DMEMORY_LEAKING_TESTS_ENABLED=0 -g -c -o check_mem_leaks-check_mem_leaks.o `test -f 'check_mem_leaks.c' || echo './'`check_mem_leaks.c "check_mem_leaks.c", line 27: warning: implicit function declaration: make_sub_suite "check_mem_leaks.c", line 27: warning: improper pointer/integer combination: arg #1 "check_mem_leaks.c", line 41: warning: implicit function declaration: fork_setup "check_mem_leaks.c", line 43: warning: implicit function declaration: make_log_suite "check_mem_leaks.c", line 43: warning: improper pointer/integer combination: arg #1 "check_mem_leaks.c", line 44: warning: implicit function declaration: make_fork_suite "check_mem_leaks.c", line 44: warning: improper pointer/integer combination: arg #2 "check_mem_leaks.c", line 47: warning: implicit function declaration: make_exit_suite "check_mem_leaks.c", line 47: warning: improper pointer/integer combination: arg #2 "check_mem_leaks.c", line 50: warning: implicit function declaration: make_selective_suite "check_mem_leaks.c", line 50: warning: improper pointer/integer combination: arg #2

"check_mem_leaks.c", line 63: warning: implicit function declaration: fork_teardown

Following patch fixes those warnings:

--- a/tests/check_check_msg.c +++ b/tests/check_check_msg.c @@ -7,6 +7,8 @@ #include "check.h" #include "check_msg.h" #include "check_check.h" +#include <check_list.h> +#include <check_impl.h> START_TEST(test_send) { diff --git a/tests/check_mem_leaks.c b/tests/check_mem_leaks.c index 718c208..f240a9a 100644 --- a/tests/check_mem_leaks.c +++ b/tests/check_mem_leaks.c @@ -10,6 +10,7 @@ #include <string.h> #include <check.h> #include "config.h" +#include "check_check.h" int main (int argc, char **argv) {

make check

Now I am testing make check - which also reveals some portability issues.

First problem is that checkmk/test/check_checkmk has /bin/sh hard-coded. Which is ultimatively non-conforming under Solaris 10, i.e. it errors out on stuff like $(cmd).

Solaris 10 even comes with bash (and ksh 88 and a conforming sh which is under /usr/xpg4/bin/sh). I can fix this via:

--- a/checkmk/test/check_checkmk +++ b/checkmk/test/check_checkmk @@ -1,4 +1,4 @@ -#! /bin/sh +#!/bin/bash TESTS_RUN=0 TESTS_PASSED=0

Then I get other errors, e.g.:

/usr/bin/nawk: newline in character class ^[ ^L^K^M

I have to look into them into more detail.

Should I open a new ticket for this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Branden Archer - 2014-05-09
  
  We can keep the discussion in this bug/thread. It can now be the 'get check
  to work on Solaris' bug/thread. (:
  
  The change in finding and attempting to validate see sounds pretty
  reasonable. Is /usr/xpg4/bin in the PATH by default, or did you need to set
  that? (If Solaris gets working, then it may be useful to add a blurb about
  it here:
  http://check.sourceforge.net/web/install.html
  I would not be able to officially support it, as I do not have a VM of
  Solaris. However, I can certainly work with you to iron out any kinks so
  that it will work).
  
  I can take a look at the implicit defines in the unit test as well, thanks
  for pointing those out.
  
  A number of tests are really just shell scripts that use /bin/sh :
  
  http://sourceforge.net/p/check/code/HEAD/tree/trunk/tests/test_tap_output.sh
  http://sourceforge.net/p/check/code/HEAD/tree/trunk/tests/test_xml_output.sh
  http://sourceforge.net/p/check/code/HEAD/tree/trunk/tests/test_mem_leaks.sh
  http://sourceforge.net/p/check/code/HEAD/tree/trunk/tests/test_log_output.sh
  http://sourceforge.net/p/check/code/HEAD/tree/trunk/tests/test_check_nofork.sh
  
  Moving them to using bash instead of sh would maybe solve the problem for
  Solaris, but may cause issues for others; it would require users of check
  (that want to run unit tests) to have bash available. I believe that sh is
  more likely to be available.
  
  Is there an easy way to detect where sh or bash is in autotools, and if it
  is compliant? Maybe the location of sh or bash can be located, and that
  interpreter can be used to run the scripts during "make check".
  Alternatively, I wonder if it is portable to do something like this:
  
  !/usr/bin/env sh
  
  Does that find a compliant shell?
  
  On Thu, May 8, 2014 at 6:08 PM, Georg Sauthoff g_sauthoff@users.sf.netwrote:
  
  Ok, I've tested a little bit around - and it went better than expected.
  
  The AC_PROG_SED macro does find gsed on Solaris 10. I've placed it here:
  
  --- a/configure.ac+++ b/configure.ac@@ -126,6 +126,7 @@ esac], [enable_timer_replacement=autodetect ])
  
  # Checks for programs.+AC_PROG_SED
  AC_PROG_AWK
  AC_PROG_CC
  # Automake wants this for per-target CFLAGS
  
  Surprisingly, I get this configure output then:
  
  checking for a sed that does not truncate output... /opt/csw/bin/gsed[..]checking for a sed that does not truncate output... (cached) /opt/csw/bin/gsed
  
  When removing /opt/csw/bin from the PATH, it also finds seds which are
  compatible to the used sed expression, e.g.
  
  checking for a sed that does not truncate output... /usr/xpg4/bin/sed
  
  (But it does not error out when the PATH neither contains gsed nor
  /usr/xpg4/bin - it picks up /usr/bin/sed then, which is non-conforming -
  but still a huge improvement.)
  
  That means that an explicit AC_PROG_SED is not needed - it is already
  implicitly executed (perhaps this is a autoconf default or dependency of
  another check).
  The Fix
  
  Anyway, following patch fixes the generation of exported.sym under
  Solaris 10:
  
  --- a/src/Makefile.am+++ b/src/Makefile.am@@ -34,7 +34,7 @@ HFILES =\
  
  EXPORT_SYM = exported.sym
  $(EXPORT_SYM): check.h.in- sed -n -e 's/^..CK_EXPORT[[:space:]][[:space:]]([[:alnum:]][[:alnum:]])..$$/\1/p' @top_srcdir@/src/check.h.in > $@+ $(SED) -n -e 's/^..CK_EXPORT[[:space:]][[:space:]]([[:alnum:]][[:alnum:]])..$$/\1/p' @top_srcdir@/src/check.h.in > $@
  
  libcheck_la_DEPENDENCIES= $(EXPORT_SYM)
  libcheck_la_LDFLAGS = -no-undefined -export-symbols $(EXPORT_SYM)
  
  (where the SED variable is set by the AC_PROG_SED check)
  Implicit Defined Functions
  
  Btw, I've noticed some implicit defined function warnings:
  
  cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -g -c -o check_check-check_check_msg.o test -f 'check_check_msg.c' || echo './'check_check_msg.c"check_check_msg.c", line 64: warning: implicit function declaration: tr_freecc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -DTIMEOUT_TESTS_ENABLED=0 -DMEMORY_LEAKING_TESTS_ENABLED=0 -g -c -o check_mem_leaks-check_mem_leaks.o test -f 'check_mem_leaks.c' || echo './'check_mem_leaks.c"check_mem_leaks.c", line 27: warning: implicit function declaration: make_sub_suite"check_mem_leaks.c", line 27: warning: improper pointer/integer combination: arg #1"check_mem_leaks.c", line 41: warning: implicit function declaration: fork_setup"check_mem_leaks.c", line 43: warning: implicit function declaration: make_log_suite"check_mem_leaks.c", line 43: warning: improper pointer/integer combination: arg #1"check_mem_leaks.c", line 44: warning: implicit function declaration: make_fork_suite"check_mem_leaks.c", line 44: warning: improper pointer/integer combination: arg #2"check_mem_leaks.c", line 47: warning: implicit function declaration: make_exit_suite"check_mem_leaks.c", line 47: warning: improper pointer/integer combination: arg #2"check_mem_leaks.c", line 50: warning: implicit function declaration: make_selective_suite"check_mem_leaks.c", line 50: warning: improper pointer/integer combination: arg #2
  
  "check_mem_leaks.c", line 63: warning: implicit function declaration:
  fork_teardown
  
  Following patch fixes those warnings:
  
  --- a/tests/check_check_msg.c+++ b/tests/check_check_msg.c@@ -7,6 +7,8 @@
  #include "check.h"
  #include "check_msg.h"
  #include "check_check.h"+#include <check_list.h>+#include <check_impl.h></check_impl.h></check_list.h>
  
  START_TEST(test_send)
  {diff --git a/tests/check_mem_leaks.c b/tests/check_mem_leaks.cindex 718c208..f240a9a 100644--- a/tests/check_mem_leaks.c+++ b/tests/check_mem_leaks.c@@ -10,6 +10,7 @@
  #include <string.h>
  #include <check.h>
  #include "config.h"+#include "check_check.h"</check.h></string.h>
  
  int main (int argc, char **argv)
  {
  
  make check
  
  Now I am testing make check - which also reveals some portability issues.
  
  First problem is that checkmk/test/check_checkmk has /bin/sh hard-coded.
  Which is ultimatively non-conforming under Solaris 10, i.e. it errors out
  on stuff like $(cmd).
  
  Solaris 10 even comes with bash (and ksh 88 and a conforming sh which is
  under /usr/xpg4/bin/sh). I can fix this via:
  
  --- a/checkmk/test/check_checkmk+++ b/checkmk/test/check_checkmk@@ -1,4 +1,4 @@-#! /bin/sh+#!/bin/bash
  
  TESTS_RUN=0
  TESTS_PASSED=0
  
  Then I get other errors, e.g.:
  
  /usr/bin/nawk: newline in character class ^[ ^L^K^M
  
  I have to look into them into more detail.
  
  Should I open a new ticket for this?
  
  [bugs:#97] http://sourceforge.net/p/check/bugs/97/ Build fixes for
  Solaris*
  
  Status: open
  Group: v1.0 (example)
  Created: Wed May 07, 2014 08:15 AM UTC by Georg Sauthoff
  Last Updated: Thu May 08, 2014 09:07 AM UTC
  Owner: nobody
  
  I am working on getting Check packaged in OpenCSWhttp://www.opencsw.org/(a package repository for Oracle Solaris).
  
  There are 2 issues in the current Check release (0.9.12) when building it
  on Solaris:
  
  1) Check automatically sets -pedantic in the CFLAGS. Unfortunately, the
  Solaris Studio C compiler interprets it as -p which has a complete
  different meaning http://wiki.opencsw.org/porting-faq#toc8. That means
  that just using AX_CFLAGS_ADD([-pedantic]) is not enough because the
  Solaris Studio C compiler does not fail on it - although the build of the
  library fails later with undefined symbols.
  
  Because of this I am using following patch on Solaris:
  
  --- a/configure.ac+++ b/configure.ac@@ -145,7 +145,8 @@ AX_CFLAGS_ADD([-Wstrict-prototypes])
  AX_CFLAGS_ADD([-Wmissing-prototypes])
  AX_CFLAGS_ADD([-Wwrite-strings])
  AX_CFLAGS_ADD([-Wno-variadic-macros])-AX_CFLAGS_ADD([-pedantic])+# Check succeeds for Solris Studio cc - where -p has a rather different meaning+#AX_CFLAGS_ADD([-pedantic])
  AX_CFLAGS_ADD([-Wimport])
  AX_CFLAGS_ADD([-Wfatal-errors])
  AX_CFLAGS_ADD([-Wformat=2])
  
  Perhaps you want to use something different - e.g. only add -pedantic to
  the CFLAGS if a GCC was detected.
  
  2) The build scrips (the libtool part) invoke sed to generate the file
  exported.sym that is passed as argument to the libtool's -export-symbolsoption. The used sed expression is not understood by the Solaris
  sed such that the generated file is empty. And thus no symbols in the
  created libcheck shared library are exported - which leads to the failure
  of the testsuite (because of undefined symbols).
  
  My workaround is to make sure that GNU sed comes in my PATH first when
  building libcheck.
  
  But it would be great if the configure would check the available sed and
  provide an option for specifying an alternate sed binary (e.g. gsed).
  
  The 'unportable' sed expresision is this one:
  
  sed -n -e 's/^..CK_EXPORT[[:space:]][[:space:]]([[:alnum:]][[:alnum:]])..$/\1/p' ../src/check.h.in > exported.sym
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/check/bugs/97/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  Related
  
  Bugs: ~~#97~~
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Branden Archer - 2014-05-09
    
    Actually, when you do your evaluation, use the version of check in svn. It
    has the fixes you have mentioned thus far (except for /bin/sh), as well as
    other bug fixes.
    
    svn checkout svn://svn.code.sf.net/p/check/code/trunk check-code
    
    On Thu, May 8, 2014 at 11:11 PM, Branden Archer brarcher@users.sf.netwrote:
    
    We can keep the discussion in this bug/thread. It can now be the 'get check
    to work on Solaris' bug/thread. (:
    
    The change in finding and attempting to validate see sounds pretty
    reasonable. Is /usr/xpg4/bin in the PATH by default, or did you need to set
    that? (If Solaris gets working, then it may be useful to add a blurb about
    it here:
    http://check.sourceforge.net/web/install.html
    I would not be able to officially support it, as I do not have a VM of
    Solaris. However, I can certainly work with you to iron out any kinks so
    that it will work).
    
    I can take a look at the implicit defines in the unit test as well, thanks
    for pointing those out.
    
    A number of tests are really just shell scripts that use /bin/sh :
    
    http://sourceforge.net/p/check/code/HEAD/tree/trunk/tests/test_tap_output.sh
    
    http://sourceforge.net/p/check/code/HEAD/tree/trunk/tests/test_xml_output.sh
    http://sourceforge.net/p/check/code/HEAD/tree/trunk/tests/test_mem_leaks.sh
    
    http://sourceforge.net/p/check/code/HEAD/tree/trunk/tests/test_log_output.sh
    
    http://sourceforge.net/p/check/code/HEAD/tree/trunk/tests/test_check_nofork.sh
    
    Moving them to using bash instead of sh would maybe solve the problem for
    Solaris, but may cause issues for others; it would require users of check
    (that want to run unit tests) to have bash available. I believe that sh is
    more likely to be available.
    
    Is there an easy way to detect where sh or bash is in autotools, and if it
    is compliant? Maybe the location of sh or bash can be located, and that
    interpreter can be used to run the scripts during "make check".
    Alternatively, I wonder if it is portable to do something like this:
    !/usr/bin/env sh
    
    Does that find a compliant shell?
    
    On Thu, May 8, 2014 at 6:08 PM, Georg Sauthoff g_sauthoff@users.sf.net
    wrote:
    
    Ok, I've tested a little bit around - and it went better than expected.
    
    The AC_PROG_SED macro does find gsed on Solaris 10. I've placed it here:
    
    --- a/configure.ac+++ b/configure.ac@@ -126,6 +126,7 @@ esac], [enable_timer_replacement=autodetect
    ])
    
    Checks for programs.+AC_PROG_SED
    
    AC_PROG_AWK
    AC_PROG_CC
    
    Automake wants this for per-target CFLAGS
    
    Surprisingly, I get this configure output then:
    
    checking for a sed that does not truncate output... /opt/csw/bin/gsed[..]checking
    for a sed that does not truncate output... (cached) /opt/csw/bin/gsed
    
    When removing /opt/csw/bin from the PATH, it also finds seds which are
    compatible to the used sed expression, e.g.
    
    checking for a sed that does not truncate output... /usr/xpg4/bin/sed
    
    (But it does not error out when the PATH neither contains gsed nor
    /usr/xpg4/bin - it picks up /usr/bin/sed then, which is non-conforming -
    but still a huge improvement.)
    
    That means that an explicit AC_PROG_SED is not needed - it is already
    implicitly executed (perhaps this is a autoconf default or dependency of
    another check).
    The Fix
    
    Anyway, following patch fixes the generation of exported.sym under
    Solaris 10:
    
    --- a/src/Makefile.am+++ b/src/Makefile.am@@ -34,7 +34,7 @@ HFILES =\
    
    EXPORT_SYM = exported.sym
    $(EXPORT_SYM): check.h.in- sed -n -e 's/^..
    CK_EXPORT[[:space:]][[:space:]]([[:alnum:]][[:alnum:]])..$$/\1/p'
    @top_srcdir@/src/check.h.in > $@+ $(SED) -n -e 's/^..
    CK_EXPORT[[:space:]][[:space:]]([[:alnum:]][[:alnum:]])..$$/\1/p'
    @top_srcdir@/src/check.h.in > $@
    
    libcheck_la_DEPENDENCIES= $(EXPORT_SYM)
    libcheck_la_LDFLAGS = -no-undefined -export-symbols $(EXPORT_SYM)
    
    (where the SED variable is set by the AC_PROG_SED check)
    Implicit Defined Functions
    
    Btw, I've noticed some implicit defined function warnings:
    
    cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -g -c -o
    check_check-check_check_msg.o test -f 'check_check_msg.c' || echo './'check_check_msg.c"check_check_msg.c",
    line 64: warning: implicit function declaration: tr_freecc -DHAVE_CONFIG_H
    -I. -I.. -I../src -I../src -DTIMEOUT_TESTS_ENABLED=0
    -DMEMORY_LEAKING_TESTS_ENABLED=0 -g -c -o check_mem_leaks-check_mem_leaks.o test
    -f 'check_mem_leaks.c' || echo './'check_mem_leaks.c"check_mem_leaks.c",
    line 27: warning: implicit function declaration:
    make_sub_suite"check_mem_leaks.c", line 27: warning: improper
    pointer/integer combination: arg #1"check_mem_leaks.c", line 41: warning:
    implicit function declaration: fork_setup"check_mem_leaks.c", line 43:
    warning: implicit function declaration: make_log_suite"check_mem_leaks.c",
    line 43: warning: improper pointer/integer combination: arg
    
    1"check_mem_leaks.c", line 44: warning: implicit function declaration:
    
    make_fork_suite"check_mem_leaks.c", line 44: warning: improper
    pointer/integer combination: arg #2"check_mem_leaks.c", line 47: warning:
    implicit function declaration: make_exit_suite"check_mem_leaks.c", line 47:
    warning: improper pointer/integer combination: arg #2"check_mem_leaks.c",
    line 50: warning: implicit function declaration:
    make_selective_suite"check_mem_leaks.c", line 50: warning: improper
    pointer/integer combination: arg #2
    
    "check_mem_leaks.c", line 63: warning: implicit function declaration:
    fork_teardown
    
    Following patch fixes those warnings:
    
    --- a/tests/check_check_msg.c+++ b/tests/check_check_msg.c@@ -7,6 +7,8 @@
    
    include "check.h"
    
    include "check_msg.h"
    
    include "check_check.h"+#include +#include
    
    START_TEST(test_send)
    {diff --git a/tests/check_mem_leaks.c b/tests/check_mem_leaks.cindex
    718c208..f240a9a 100644--- a/tests/check_mem_leaks.c+++
    b/tests/check_mem_leaks.c@@ -10,6 +10,7 @@
    
    include
    
    include
    
    include "config.h"+#include "check_check.h"
    
    int main (int argc, char **argv)
    {
    
    make check
    
    Now I am testing make check - which also reveals some portability issues.
    
    First problem is that checkmk/test/check_checkmk has /bin/sh hard-coded.
    Which is ultimatively non-conforming under Solaris 10, i.e. it errors out
    on stuff like $(cmd).
    
    Solaris 10 even comes with bash (and ksh 88 and a conforming sh which is
    under /usr/xpg4/bin/sh). I can fix this via:
    
    --- a/checkmk/test/check_checkmk+++ b/checkmk/test/check_checkmk@@ -1,4
    +1,4 @@-#! /bin/sh+#!/bin/bash
    
    TESTS_RUN=0
    TESTS_PASSED=0
    
    Then I get other errors, e.g.:
    
    /usr/bin/nawk: newline in character class ^[ ^L^K^M
    
    I have to look into them into more detail.
    Should I open a new ticket for this?
    
    [bugs:#97] http://sourceforge.net/p/check/bugs/97/
    http://sourceforge.net/p/check/bugs/97/ Build fixes for
    Solaris*
    
    Status: open
    Group: v1.0 (example)
    Created: Wed May 07, 2014 08:15 AM UTC by Georg Sauthoff
    Last Updated: Thu May 08, 2014 09:07 AM UTC
    Owner: nobody
    
    I am working on getting Check packaged in OpenCSWhttp://www.opencsw.org/(a
    package repository for Oracle Solaris).
    
    There are 2 issues in the current Check release (0.9.12) when building it
    on Solaris:
    
    1) Check automatically sets -pedantic in the CFLAGS. Unfortunately, the
    Solaris Studio C compiler interprets it as -p which has a complete
    different meaning http://wiki.opencsw.org/porting-faq#toc8. That means
    
    that just using AX_CFLAGS_ADD([-pedantic]) is not enough because the
    Solaris Studio C compiler does not fail on it - although the build of the
    library fails later with undefined symbols.
    
    Because of this I am using following patch on Solaris:
    
    --- a/configure.ac+++ b/configure.ac@@ -145,7 +145,8 @@ AX_CFLAGS_ADD(
    [-Wstrict-prototypes])
    
    AX_CFLAGS_ADD([-Wmissing-prototypes])
    AX_CFLAGS_ADD([-Wwrite-strings])
    AX_CFLAGS_ADD([-Wno-variadic-macros])-AX_CFLAGS_ADD([-pedantic])+# Check
    succeeds for Solris Studio cc - where -p has a rather different
    meaning+#AX_CFLAGS_ADD([-pedantic])
    
    AX_CFLAGS_ADD([-Wimport])
    AX_CFLAGS_ADD([-Wfatal-errors])
    AX_CFLAGS_ADD([-Wformat=2])
    
    Perhaps you want to use something different - e.g. only add -pedantic to
    the CFLAGS if a GCC was detected.
    
    2) The build scrips (the libtool part) invoke sed to generate the file
    exported.sym that is passed as argument to the libtool's
    -export-symbolsoption. The used sed expression is not understood by the
    Solaris
    
    sed such that the generated file is empty. And thus no symbols in the
    created libcheck shared library are exported - which leads to the failure
    of the testsuite (because of undefined symbols).
    
    My workaround is to make sure that GNU sed comes in my PATH first when
    building libcheck.
    
    But it would be great if the configure would check the available sed and
    provide an option for specifying an alternate sed binary (e.g. gsed).
    
    The 'unportable' sed expresision is this one:
    
    sed -n -e 's/^..CK_EXPORT[[:space:]][[:space:]]([[:alnum:]][[:alnum:]]
    )..$/\1/p' ../src/check.h.in > exported.sym
    
    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/check/bugs/97/
    
    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/
    
    [bugs:#97] http://sourceforge.net/p/check/bugs/97/ Build fixes for
    Solaris*
    
    Status: open
    Group: v1.0 (example)
    Created: Wed May 07, 2014 08:15 AM UTC by Georg Sauthoff
    Last Updated: Thu May 08, 2014 10:08 PM UTC
    Owner: nobody
    
    I am working on getting Check packaged in OpenCSWhttp://www.opencsw.org/(a package repository for Oracle Solaris).
    
    There are 2 issues in the current Check release (0.9.12) when building it
    on Solaris:
    
    1) Check automatically sets -pedantic in the CFLAGS. Unfortunately, the
    Solaris Studio C compiler interprets it as -p which has a complete
    different meaning http://wiki.opencsw.org/porting-faq#toc8. That means
    that just using AX_CFLAGS_ADD([-pedantic]) is not enough because the
    Solaris Studio C compiler does not fail on it - although the build of the
    library fails later with undefined symbols.
    
    Because of this I am using following patch on Solaris:
    
    --- a/configure.ac+++ b/configure.ac@@ -145,7 +145,8 @@ AX_CFLAGS_ADD([-Wstrict-prototypes])
    AX_CFLAGS_ADD([-Wmissing-prototypes])
    AX_CFLAGS_ADD([-Wwrite-strings])
    AX_CFLAGS_ADD([-Wno-variadic-macros])-AX_CFLAGS_ADD([-pedantic])+# Check succeeds for Solris Studio cc - where -p has a rather different meaning+#AX_CFLAGS_ADD([-pedantic])
    AX_CFLAGS_ADD([-Wimport])
    AX_CFLAGS_ADD([-Wfatal-errors])
    AX_CFLAGS_ADD([-Wformat=2])
    
    Perhaps you want to use something different - e.g. only add -pedantic to
    the CFLAGS if a GCC was detected.
    
    2) The build scrips (the libtool part) invoke sed to generate the file
    exported.sym that is passed as argument to the libtool's -export-symbolsoption. The used sed expression is not understood by the Solaris
    sed such that the generated file is empty. And thus no symbols in the
    created libcheck shared library are exported - which leads to the failure
    of the testsuite (because of undefined symbols).
    
    My workaround is to make sure that GNU sed comes in my PATH first when
    building libcheck.
    
    But it would be great if the configure would check the available sed and
    provide an option for specifying an alternate sed binary (e.g. gsed).
    
    The 'unportable' sed expresision is this one:
    
    sed -n -e 's/^..CK_EXPORT[[:space:]][[:space:]]([[:alnum:]][[:alnum:]])..$/\1/p' ../src/check.h.in > exported.sym
    
    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/check/bugs/97/
    
    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/
    
    Related
    
    Bugs: ~~#97~~
    
    alternate
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Georg Sauthoff - 2014-05-09

No, unfortunately, /usr/xpg4/bin is not in the default PATH on Solaris 10 (the rationale again: it would break general backward compatibility ...). But I would bet that most people installing some piece of open source software under Solaris have a gsed (either via /opt/csw or a custom install) and/or /usr/xpg4/bin in their PATH.

Basically, if one wants standard conforming utilities under Solaris one is supposed to read the standards(5) man page which lists several PATH settings for different standard versions (POSIX different versions, SUSv3 etc.).

Adding some Solaris hints to the install information page/file would certainly be useful.

I don't know if there is an easy way to detect a conforming shell via autoconf, but e.g. the configure.ac of automake 11.14 goes into some length to find such a shell (and it works on Solaris). Unfortunately, it is not a simple autoconf check macro (see the usage of _AM_CHECK_CANDIDATE_SHELL, ac_cv_AM_TEST_RUNNER_SHELL).

There is also CONFIG_SHELL - thus one could tell people to use something like

CONFIG_SHELL=/bin/bash ./configure

on systems like Solaris. Or perhaps provide something like --with-sh=/bin/bash?

The env method works - depending on your PATH, of course, e.g.:

$ cat t.sh #!/usr/bin/env sh echo $(which sh) $ PATH=`getconf PATH` ./t /usr/xpg4/bin/sh

Alternatively, those test scripts could be explicitly started - as argument to the shell detected by configure or supplied to configure (e.g. via CONFIG_SHELL) such that the bang line is not needed, e.g.:

$CONFIG_SHELL test/check_checkmk

instead of

./test/check_checkmk

Ok, regarding make check I'll fetch the svn trunk and report back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Branden Archer - 2014-05-12
  
  The env method works - depending on your PATH, of course.
  
  I gave your suggestions a try. Not sure that the setting the shell
  explicitly may work; there is some automake magic which specifies the test
  programs, and it does not seem to like the shell being mentioned. Using the
  env program seems to be a good-enough solution. I will check later if this
  works out on the other platforms that Check works on.
  
  On Fri, May 9, 2014 at 5:29 PM, Georg Sauthoff g_sauthoff@users.sf.netwrote:
  
  No, unfortunately, /usr/xpg4/bin is not in the default PATH on Solaris 10
  (the rationale again: it would break general backward compatibility ...).
  But I would bet that most people installing some piece of open source
  software under Solaris have a gsed (either via /opt/csw or a custom
  install) and/or /usr/xpg4/bin in their PATH.
  
  Basically, if one wants standard conforming utilities under Solaris one is
  supposed to read the standards(5) man page which lists several PATH
  settings for different standard versions (POSIX different versions, SUSv3
  etc.).
  
  Adding some Solaris hints to the install information page/file would
  certainly be useful.
  
  I don't know if there is an easy way to detect a conforming shell via
  autoconf, but e.g. the configure.ac of automake 11.14 goes into some
  length to find such a shell (and it works on Solaris). Unfortunately, it is
  not a simple autoconf check macro (see the usage of
  _AM_CHECK_CANDIDATE_SHELL, ac_cv_AM_TEST_RUNNER_SHELL).
  
  There is also CONFIG_SHELL - thus one could tell people to use something
  like
  
  CONFIG_SHELL=/bin/bash ./configure
  
  on systems like Solaris. Or perhaps provide something like
  --with-sh=/bin/bash?
  
  The env method works - depending on your PATH, of course, e.g.:
  
  $ cat t.sh#!/usr/bin/env sh
  echo $(which sh)$ PATH=getconf PATH ./t/usr/xpg4/bin/sh
  
  Alternatively, those test scripts could be explicitly started - as
  argument to the shell detected by configure or supplied to configure (e.g.
  via CONFIG_SHELL) such that the bang line is not needed, e.g.:
  
  $CONFIG_SHELL test/check_checkmk
  
  instead of
  
  ./test/check_checkmk
  
  Ok, regarding make check I'll fetch the svn trunk and report back.
  
  [bugs:#97] http://sourceforge.net/p/check/bugs/97/ Build fixes for
  Solaris*
  
  Status: open
  Group: v1.0 (example)
  Created: Wed May 07, 2014 08:15 AM UTC by Georg Sauthoff
  Last Updated: Thu May 08, 2014 10:08 PM UTC
  Owner: nobody
  
  I am working on getting Check packaged in OpenCSWhttp://www.opencsw.org/(a package repository for Oracle Solaris).
  
  There are 2 issues in the current Check release (0.9.12) when building it
  on Solaris:
  
  1) Check automatically sets -pedantic in the CFLAGS. Unfortunately, the
  Solaris Studio C compiler interprets it as -p which has a complete
  different meaning http://wiki.opencsw.org/porting-faq#toc8. That means
  that just using AX_CFLAGS_ADD([-pedantic]) is not enough because the
  Solaris Studio C compiler does not fail on it - although the build of the
  library fails later with undefined symbols.
  
  Because of this I am using following patch on Solaris:
  
  --- a/configure.ac+++ b/configure.ac@@ -145,7 +145,8 @@ AX_CFLAGS_ADD([-Wstrict-prototypes])
  AX_CFLAGS_ADD([-Wmissing-prototypes])
  AX_CFLAGS_ADD([-Wwrite-strings])
  AX_CFLAGS_ADD([-Wno-variadic-macros])-AX_CFLAGS_ADD([-pedantic])+# Check succeeds for Solris Studio cc - where -p has a rather different meaning+#AX_CFLAGS_ADD([-pedantic])
  AX_CFLAGS_ADD([-Wimport])
  AX_CFLAGS_ADD([-Wfatal-errors])
  AX_CFLAGS_ADD([-Wformat=2])
  
  Perhaps you want to use something different - e.g. only add -pedantic to
  the CFLAGS if a GCC was detected.
  
  2) The build scrips (the libtool part) invoke sed to generate the file
  exported.sym that is passed as argument to the libtool's -export-symbolsoption. The used sed expression is not understood by the Solaris
  sed such that the generated file is empty. And thus no symbols in the
  created libcheck shared library are exported - which leads to the failure
  of the testsuite (because of undefined symbols).
  
  My workaround is to make sure that GNU sed comes in my PATH first when
  building libcheck.
  
  But it would be great if the configure would check the available sed and
  provide an option for specifying an alternate sed binary (e.g. gsed).
  
  The 'unportable' sed expresision is this one:
  
  sed -n -e 's/^..CK_EXPORT[[:space:]][[:space:]]([[:alnum:]][[:alnum:]])..$/\1/p' ../src/check.h.in > exported.sym
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/check/bugs/97/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  Related
  
  Bugs: ~~#97~~
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Branden Archer - 2014-06-15

Much of what was discussed thus far was included in the most recent release: check 0.9.13. Would you mind giving that a try to see if it resolves everything. If there is anything else that would need to be done, let me know what you find.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Georg Sauthoff - 2014-06-17

Hm, send a reply via email yesterday, but it seems that it didn't get through - now 2nd try sending it via sourceforge web interface.

On Sun, Jun 15, 2014 at 10:43:56PM +0000, Branden Archer wrote:

Much of what was discussed thus far was included in the most recent release: check 0.9.13. Would you mind giving that a try to see if it resolves everything. If there is anything
else that would need to be done, let me know what you find.

I've tested it under Solaris 10 Sparc, and there is a regression:

libtool: link: echo "{ global:" > .libs/libcheck.so.0.0.0.exp libtool: link: cat exported.sym | /opt/csw/bin/gsed -e "s/$.*$/\1;/" >> .libs/libcheck.so.0.0.0.exp libtool: link: echo "local: *; };" >> .libs/libcheck.so.0.0.0.exp libtool: link: cc -G -z defs -M .libs/libcheck.so.0.0.0.exp -h libcheck.so.0 -o .libs/libcheck.so.0.0.0 .libs/check.o .libs/check_error.o .libs/check_list.o .libs/check_log.o .libs/check_msg.o .libs/check_pack.o .libs/check_print.o .libs/check_run.o .libs/check_str.o -z allextract ../lib/.libs/libcompat.a -z defaultextract -lc -qlanglvl=stdc99 cc: Warning: Option -qlanglvl=stdc99 passed to ld, if ld is invoked, ignored otherwise ld: fatal: unrecognized option '-q' ld: fatal: use the -z help option for usage information Makefile:393: recipe for target 'libcheck.la' failed

The Solaris Studio 12.3 C compiler does not know the option -qlanglvl=stc99.

Googling for it shows that it is IBM XL C compiler for AIX option. I recall
some Check mailing list messages from an AIX user suggesting this option.

For 'normal' compiles Solaris C compiler ignores it, e.g.:

libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -g -qlanglvl=stdc99 -c check_run.c -KPIC -DPIC -o .libs/check_run.o cc: Warning: Option -qlanglvl=stdc99 passed to ld, if ld is invoked, ignored otherwise

The Solaris cc equivalent to GCC's -std=c99 is:

-xc99

But note that I did not need to specify -xc99 with previous versions of check under Solaris.

Perhaps there is an autoconf way such that -qlanglvl=stdc99 is only supplied on a AIX system with the XL C compiler?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Branden Archer - 2014-06-18
  
  Someone reported that by throwing the qlanglvl flag (with a few other small
  changes) Check would work on AIX. The flag was added in such a way that the
  configure script would check if the compiler took the flag or rejected it.
  On the other platforms and compilers it was tried on (Linux, MinGW, etc;
  gcc, clang, etc) the configure script properly rejected the flag. However,
  on Solaris the unrecognized flag was passed to the linker. That resulted in
  the flag being accepted by the configure script, but the build failing when
  it was attempted.
  
  A fix went in right after the latest release to only attempt that flag on
  AIX. That should be resolved now. Sorry about that. When the issue was
  originally reported I got confused and believed that the flag was for
  Solaris support. It was after the release I was corrected and informed that
  the flag actually hurt Solaris instead, and should only be attempted on AIX.
  
  If the current SVN HEAD of Check now works for Solaris, which includes all
  the unit tests working, let me know. If it is meaningful, the install help
  page can be updated with information on how best to get Check working on
  Solaris, and a release can be created for OpenCSW to use.
  
  Thanks for your help thus far!
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Branden Archer - 2014-06-18
    
    Additionally, looking at the OpenCSW site, they mention they now support
    continuous builds for interested projects:
    
    https://buildfarm.opencsw.org/buildbot/waterfall
    
    If you were interested in requesting a build for Check on their site, I
    could monitor it occasionally to make sure that Check continues to work on
    Solaris.
    
    alternate
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Georg Sauthoff - 2014-06-18

Regarding the build farm, I'll set it up when I have the package finished.

Then, I'll also provide some Solaris build instructions/hints for your manual/readme (like making sure that POSIX versions of system commands are reachable via PATH).

I've checked out SVN HEAD and the -qlanglvl issue is now resolved.

But I've noticed another issue - regarding the autoconf __floor() check.

As is, it yields following error on Solaris 10:

/bin/bash ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I.. -m64 -c -o libcompat.lo libcompat.c libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -m64 -c libcompat.c -KPIC -DPIC -o .libs/libcompat.o "libcompat.h", line 127: token not allowed in directive: $ cc: acomp failed for libcompat.c

This is because lines from configure.ac like

AC_DEFINE([HAVE_FLOOR], [$HAVE_FLOOR], [Does the system have floor()?])

yields basically this in config.h:

#define HAVE_FLOOR $HAVE_FLOOR

Because the corresponding echo statement in configure has the dollar sign quoted ..., i.e. something like:

echo "#define HAVE_FLOOR \$HAVE_FLOOR" > config.h

I've looked up the autoconf macros and modified configure.ac in the following way:

--- configure.ac (revision 1143) +++ configure.ac (working copy) @@ -189,15 +189,7 @@ CC="$PTHREAD_CC" # Check if floor is in the math library, and if so add -lm to LIBS -HAVE__FLOOR=0 -AC_SEARCH_LIBS([floor], [m], [HAVE_FLOOR=1], [HAVE_FLOOR=0]) -if test "x$HAVE_FLOOR" = "x0"; then - # floor() is not available in libm (e.g. using AIX platform's compiler). - # Maybe __floor() is defined instead - AC_CHECK_FUNCS(__floor) -fi -AC_DEFINE([HAVE_FLOOR], [$HAVE_FLOOR], [Does the system have floor()?]) -AC_DEFINE([HAVE___FLOOR], [$HAVE___FLOOR], [Does the system have __floor()?]) +AC_SEARCH_LIBS([floor], [m], [AC_DEFINE([HAVE_FLOOR], [1], [Does the system have floor()?])], [AC_CHECK_FUNCS(__floor, [AC_DEFINE([HAVE___FLOOR], [1], [Does the system have __floor()?])], [])]) # Check if clock_gettime, timer_create, timer_settime, and timer_delete are available in lib rt, and if so, # add -lrt to LIBS

After a autoreconf and configure the floor detection works as expected:

$ grep floor myconfigure.log checking for library containing floor... -lm $ grep -i floor config.h /* Does the system have floor()? */ #define HAVE_FLOOR 1 /* Does the system have __floor()? */ /* #undef HAVE___FLOOR */

With that patch it should also find __floor() if floor() is not available.

Although, I have to say, I don't believe that AIX does not provide floor(). I mean, it is both POSIX and ANSI-C. It is even in C89.

The AIX 6.1 man page:

http://www-01.ibm.com/support/knowledgecenter/ssw_aix_61/com.ibm.aix.basetrf1/floor.htm?lang=en

Using that patch I can successfully build the check libraries on Solaris 10/SPARC.

The test suite fails (i.e. gmake check).

The reason is that checkmk/test/check_checkmk uses following bang line:

1
#! /bin/sh

And (as discussed before) /bin/sh is horribly outdated and non-conforming under Solaris. On Solaris best thing would be to use bash if found in the PATH (either via a autogenerated bang line or via directly calling the shell script in question).

I'll look into this issue another time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Georg Sauthoff - 2014-06-18

I've added some support for configuring a suitable shell for executing shell scripts as part of make check.

With that the gmake check testsuite runs all tests successfully on Solaris 10.

The changes are:

--- checkmk/Makefile.am (revision 1143) +++ checkmk/Makefile.am (working copy) @@ -1,6 +1,6 @@ if INSTALL_CHECKMK bin_SCRIPTS = checkmk -TESTS = test/check_checkmk +TESTS = test/check_checkmk.local endif EXTRA_DIST = test examples doc/checkmk.1 CONFIG_STATUS_DEPENDENCIES = checkmk.in @@ -7,6 +7,13 @@ man_MANS = doc/checkmk.1 +# we can't rely on /bin/sh being a POSIX shell +# (e.g. on Solaris it is not - there we have to use +# /bin/bash or /usr/xpg4/bin/sh) +# thus, we use the one detected by configure +test/check_checkmk.local: test/check_checkmk + ( echo '#!'"$(SH_PATH)" ; cat test/check_checkmk ; ) > test/check_checkmk.local ; chmod u+x test/check_checkmk.local + clean-local: rm -rf test.out --- configure.ac (revision 1143) +++ configure.ac (working copy) @@ -318,6 +310,13 @@ HW_FUNC_VASPRINTF HW_FUNC_ASPRINTF +# we can't rely on /bin/sh being a POSIX shell +# (e.g. on Solaris it is not - there we have to use +# /bin/bash or /usr/xpg4/bin/sh) +# used in e.g. checkmk/Makefile.am +AC_ARG_VAR([SH_PATH],[POSIX sh]) +AC_PATH_PROGS(SH_PATH, bash sh, [*NO SH*]) + # Check for whether we can install checkmk (we have a usable awk) AC_ARG_VAR([AWK_PATH],[Awk interpreter command]) AC_PATH_PROG(AWK_PATH, $AWK, [*NO AWK*])

PS: test/check_checkmk.local should then also be removed by clean-local target.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Branden Archer - 2014-06-19
  
  But I've noticed another issue - regarding the autoconf __floor() check.
  
  Seems I've botched that fix.
  
  A user on AIX reported that there were problems building check due to
  floor() missing. The reason had something to do with math.h, not sure. It
  is not really clear what is really going on, but without a setup to play
  with it may remain a mystery.
  
  check-users email thread:
  http://sourceforge.net/p/check/mailman/check-users/thread/5382EF23.5020906%40mail.mcgill.ca/#msg32380378
  
  Forum posting about issue:
  https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000013835454
  
  Thanks for the configure script fix for this.
  
  I've added some support for configuring a suitable shell for executing
  
  shell scripts as part of make check.
  
  The other tests that rely on a shell were previously changed to use the
  following:
  
  !/usr/bin/env sh
  
  The check_checkmk script was missed. Would making this change to
  check_checkmk be sufficient?
  
  Both of the fixes mentioned in this email have been committed.
  
  Branden
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Georg Sauthoff - 2014-06-19

Ok, I've pulled the latest SVN head and now everything (configure, gmake, gmake check, gmake install) works out of the on Solaris 10.

That means that the /usr/bin/env change works on Solaris.

When do you plan to release the next check version?

I am asking, because I have to decide packaging 0.9.12 (+ some diff) or just the next release (assuming that it is based on the current SVN head).

PS: A solution similar to my AC_PATH_PROGS() based one (which uses bash if possible) from my last message has perhaps some puristic advantages.

This is because POSIX does not specify any file system locations at all. Thus, you can't even rely on env being located in /usr/bin/env. And if it is there than perhaps it is a non-conforming version ...

Apparently, there are actually some obscure systems where env is e.g. in /bin/env instead of /usr/bin/env.

(But on Solaris it is under /usr/bin/env.)

The bang-line mechanism is not standardized as well - thus, perhaps there are esoteric systems, where the argument passing does not work.

Looking for bash and sh has the advantage on Solaris that it also works for folks who don't have /usr/xpg4/bin in their PATH - since bash is in /usr/bin.

But for practical purposes the /usr/bin/env trick is perfectly fine, since it should work on - say - 99.9 % of all UNIX-like systems.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Branden Archer - 2014-06-20
  
  I've pulled the latest SVN head and now everything (configure, gmake, gmake
  check, gmake install) works out of the on Solaris 10.
  
  Yay
  
  When do you plan to release the next check version?
  
  If you can provide the instructions for compiling and installing on
  Solaris, I can put that on the webpage and make a release this weekend.
  When OpenCSW has a package available, give me details and I can put that on
  the webpage as well. For now, Check would not officially support Solaris,
  as I do not have access to a machine to test with. However, once an
  automated build is setup on OpenCSW, as long as that works Solaris can be
  on the list of OSs I check before a release.
  
  PS: A solution similar to my AC_PATH_PROGS() based one (which uses bash if
  
  possible) from my last message has perhaps some puristic advantages.
  
  Although probably unfounded, I am wondering if there would be a consequence
  for switching the shell that many platforms would use after the change (sh
  -> bash). It would mean that both shells would need to be checked, just in
  case. If it ever comes to it, the change can be made to use
  AC_PATH_PROGS(). For now, though, I may just keep it simple.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Branden Archer - 2014-06-20
    
    If you have a little more patience, the individual try to build on AIX
    discovered (hopefully) the underlying problem with using floor().
    
    AC_CHECK_LIB([m], [floor])
    
    finds floor() in libm, however due to some header file stuff
    (maybe) floor() cannot be used directly. This is a bug in some
    versions of AIX.
    
    Attached is a patch that (hopefully) detects this case and will allow Check
    to build on AIX. Can you check to see if SVN HEAD + this patch continues to
    work on Solaris? If so, and if it works on AIX, that will be committed and
    a release spun off. If not, then I will just do a release of the current
    SVN HEAD to benefit OpenCSW and help with AIX thereafter.
    
    --- a/configure.ac
    +++ b/configure.ac
    @@ -189,8 +189,17 @@ ACX_PTHREAD
    CC="$PTHREAD_CC"
    
    # Check if floor is in the math library, and if so add -lm to LIBS
    -AC_SEARCH_LIBS([floor], [m], [AC_DEFINE([HAVE_FLOOR], [1], [Does the
    system have floor()?])],
    -[AC_CHECK_FUNCS(floor, [AC_DEFINE([HAVE_FLOOR], [1], [Does the system
    have __floor()?])], [])])
    +AC_CHECK_LIB([m], [floor])
    +
    +# On some versions of AIX, although floor() is found in libm,
    +# it cannot be used directly. Instead __floor() must be used.
    +# This checks if this is the case.
    +AC_CHECK_FUNC([floor],
    + [AC_DEFINE([HAVE_FLOOR], [1], [Can the system use floor() directly?])],
    + [AC_CHECK_DECL([__floor],
    + [AC_DEFINE([HAVE___FLOOR], [1], [Does the system define __floor()
    instead?])],
    + [])
    + ])
    
    # Check if clock_gettime, timer_create, timer_settime, and timer_delete
    are available in lib rt, and if so,
    # add -lrt to LIBS
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Branden Archer - 2014-06-23
      
      When do you plan to release the next check version?
      
      I am asking, because I have to decide packaging 0.9.12 (+ some diff) or
      
      just the next release (assuming that it is based on the current SVN head).
      
      On second thought, if you want to get the package building soon, maybe go
      with 0.9.13 + patches (equaling up to SVN HEAD). A bug came in that I would
      like to release in the next version of check, and that will take additional
      time. Otherwise, you may end up checking several intermediate changsets
      before the package is available and an automated build for Solaris is setup.
      
      Branden
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
      - Georg Sauthoff - 2014-06-23
        
        Ok.
        
        Perhaps I'll also look into the buildbot setup before finishing the package.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Branden Archer - 2014-06-23
        
        The function getline() is POSIX 2008/_XOPEN_SOURCE >= 700 - and Solaris
        10 is too old for that, it only has POSIX 2001.
        
        I was hopeful that I would not need to have a replacement function
        available for getline(), but it appears that I will. Additionally, getline()
        is not available on MinGW (the automated builds pointed that after the
        change was committed) and likely MSVC will not have it available either.
        Probably the next thing I will do is resolve this.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Branden Archer - 2014-07-19
        
        The get line() replacement is in, as well as the bug fix I wanted to get
        in. Unless other bugs are reported in the meantime, what is on HEAD should
        be the code in the next check release.
        
        Georg, did you have an opportunity to investigate the buildbot setup?
        
        alternate
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Georg Sauthoff - 2014-07-22
        
        I've updated the trunk and it compiles and all tests run successfully now on Solaris.
        
        I've created a script that fetches the svn head, starts from a clean environment, builds everything and runs the test suite. I'll post an update when it is integrated into the openCSW buildbot instance (which shouldn't be a problem).
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Georg Sauthoff - 2014-07-25
        
        The buildbot jobs are now live:
        
        https://buildfarm.opencsw.org/buildbot/waterfall?builder=libcheck-solaris10-amd64&builder=libcheck-solaris10-i386&builder=libcheck-solaris10-sparc&builder=libcheck-solaris10-sparcv9&reload=6
        
        The job is setup for 4 different architectures (i386, x86_64, sparc, sparcv9) - all running Solaris 10.
        
        If you want to get notifications via mail, just send me an email to mail@georg.so.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Georg Sauthoff - 2014-06-23
      
      Ok, I've tested current SVN head (rev 1171) which seems to already include the above patch. On Solaris configure runs successfully:
      
      $ grep floor c.log checking for floor in -lm... yes checking for floor... yes $ grep -i floor config.h /* Can the system use floor() directly? */ #define HAVE_FLOOR 1 /* Does the system define __floor() instead? */ /* #undef HAVE___FLOOR */
      
      But with that SVN head I get following unrelated error:
      
      libtool: link: cc -m64 -m64 -o .libs/check_check_export check_check_export-check_check_sub.o check_check_export-check_check_master.o check_check_export-check_check_log.o check_check_export-check_check_fork.o check_check_export-check_check_export_main.o ../src/.libs/libcheck.so -lpthread ../lib/.libs/libcompat.a -lrt -lm -R/home/gms/local/check/lib Undefined first referenced symbol in file getline check_check_export-check_check_master.o ld: fatal: symbol referencing errors. No output written to .libs/check_check_export
      
      The function getline() is POSIX 2008/_XOPEN_SOURCE >= 700 - and Solaris 10 is too old for that, it only has POSIX 2001.
      
      Solaris 11 has it.
      
      Solaris 10 only has _XOPEN_SOURCE=600/POSIX.1-2001/SUSv3.
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Build fixes for Solaris

Group

Searches

Help

#97 Build fixes for Solaris

Related

Discussion

The Fix

Implicit Defined Functions

make check

!/usr/bin/env sh

Should I open a new ticket for this?

Related

Checks for programs.+AC_PROG_SED

Automake wants this for per-target CFLAGS

1"check_mem_leaks.c", line 44: warning: implicit function declaration:

include "check.h"

include "check_msg.h"

include "check_check.h"+#include +#include

include

include

include "config.h"+#include "check_check.h"

Related

Ok, regarding make check I'll fetch the svn trunk and report back.

Related

!/usr/bin/env sh