check

Hi Emil,

Thanks for the bug report.  check-users or check-devel is fine, there 
isn't a lot of traffic on either.

First of all, you could simply build the latest versions of autoconf, 
automake, and libtool in your home directory.  I do this often.

Second, try updating to the latest SVN version of check:

svn co https://check.svn.sourceforge.net/svnroot/check check

There has been some work in the portability area specifically since 
0.9.6 and your problem may have already been fixed.

Third, by all means let us know if you still have a problem.

Cheers,
Chris

Emil Hevald wrote:
> Oh, found a test flag in the changelog. And running the tests without 
> timeout tests will make the test suite compile, and run without errors. 
> If I build the check lib as described below.
> 
> --
> Br, Emil
> 
> 
>     ----- Ursprungligt Meddelande -----
>     *Ämne: *[Check-users] check 0.9.6 on Solaris?
>     *Från:  *Emil Hevald <emil.hevald@...>
>     *Till: *"check-users@..."
>     <check-users@...>
>     *Datum: *2009-01-21 8:51
> 
> 
>     Hello folks.
> 
>     I am new to this list, and not sure if this rather belong in
>     check-devel? I have been using check on Solaris before, some years
>     ago (0.9.5). And is about to try it out again, but have been unable
>     to build 0.9.6 on my Solaris system. Seem like there is something in
>     the makefiles since 0.9.5 do build on my system, at least the check
>     lib. The test code do not work since it uses [un]setenv while
>     Solaris only support putenv.
> 
>     <configure output>
>     checking for putenv... yes
>     checking for setenv... no
> 
>     I guess this could be solved with a check in the test code for
>     HAVE_SETENV. But that's not a big issue for me atm.
> 
>     Before going into details, I need to say that I do not have the
>     correct versions of autoconf and automake. But I am not sure if that
>     is the problem here? Since I use ./configure and gmake (GNU make),
>     and can get it to produce a lib in the end. Anyway....
> 
>     When doing ./configure;gmake I get an error when trying to build
>     check_run.c. The log below is just the error printed, not the entire
>     printout.
> 
>     check_run.c:145: error: storage size of `old_action' isn't known
>     check_run.c:146: error: storage size of `new_action' isn't known
> 
>     [old/new]_action is declared as struct sigaction, that should be in
>     signal.h. Looking in my signal.h file I can find the sigaction
>     struct . But the compiler seem to miss them. I guess there is some
>     #ifdef that break this for me.
> 
>     The gcc command that libtool create looks like this.
> 
>      gcc -DHAVE_CONFIG_H -I. -I.. -ansi -pedantic -g -O2 -Wall
>     -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -MT
>     check_run.lo -MD -MP -MF .deps/check_run.Tpo -c check_run.c  -fPIC
>     -DPIC -o .libs/check_run.o
> 
>     I removed -ansi and it compile as expected. But now it will not link
>     the lib.
> 
>     gcc -shared -Wl,-M -Wl,.libs/libcheck.so.0.0.0.exp -Wl,-h
>     -Wl,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  -lc
>     <path>/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:
>     file format not recognized; treating as linker script
>     <path>/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:1:
>     parse error
>     collect2: ld returned 1 exit status
> 
>     I don't know enough about Makefiles to understand this. But is seem
>     like .../bin/ld:.libs/.... is wrong? ld is the command and one would
>     expect that you might want to change the ":" to a " "?
> 
>     Doing a ./configure --disable-share;<removie -ansi>gmake will build
>     the lib.
> 
>     creating libcheck.la
> 
>     But I have not tried it yet to see if its working. Tweaking the test
>     code to make it build and running "gmake check" will make quite a
>     few tcs fail. But I did not put that much time into fixing the
>     testcases or looking at what they do. 
> 
>     The question really is, did anyone manage to build, and use the new
>     check lib on solaris? Will correct versions of automake and autoconf
>     fix these issues? I can't update these myself, therefor I have not
>     tried that yet. An my limited knowledge of make systems might make
>     this an easy fix by adding a magic flag to configure or something. :)
> 
>     --
>     BR, Emil
>     ------------------------------------------------------------------------------
>     This SF.net email is sponsored by:
>     SourcForge Community
>     SourceForge wants to tell your story.
>     http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
>     Check-users mailing list
>     Check-users@...
>     https://lists.sourceforge.net/lists/listinfo/check-users
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Check-users mailing list
> Check-users@...
> https://lists.sourceforge.net/lists/listinfo/check-users

Hi Chris. 
 I do not have access to svn (not installed), but I downloaded the
"GNU tarball" from
http://check.svn.sourceforge.net/viewvc/check.tar.gz?view=tar. I
guess that is "latest" source as well?
 I installed the latest version of automake, autoreconf and libtool
that I found, and tried on the source I downloaded. But there seem to
be a problem with my libtool installation.
 ~/check/check/trunk > autoreconf --version
 autoreconf (GNU Autoconf) 2.63
 ~/check/check/trunk > autoreconf -vif -W all
 autoreconf: Entering directory `.'
 autoreconf: configure.ac: not using Gettext
 autoreconf: running: aclocal --force -I m4
 autoreconf: configure.ac: tracing
 configure.ac:41: warning: The macro `AC_HELP_STRING' is obsolete.
 configure.ac:41: You should run autoupdate.
 ../../lib/autoconf/general.m4:209: AC_HELP_STRING is expanded
from...
 .....
 ..... A lot more of these kinds of warnings .
 .....
 configure.ac:84: error: possibly undefined macro: AC_PROG_LIBTOOL
       If this token and others are legitimate, please use
m4_pattern_allow.
       See the Autoconf documentation.
 autoreconf: ~/GNU/autoconf/bin/autoconf failed with exit status: 1
 After searching the web for an answers on this fault it seem that
people with similar faults hade old libtool installed. And I guess it
might find the old version that reside in the system here. 
 ~/check/check/trunk > libtool --version
 ltmain.sh (GNU libtool) 2.2.6
 But looking at this, it should find the correct one. The old libtool
should not even be in my PATH.
 Any suggestions on what could be the problem?
 Thanks in advance!
 --
 BR, Emil
 ----- Ursprungligt Meddelande -----
 Ämne: Re: [Check-users] check 0.9.6 on Solaris?
 Från:  Chris Pickett 
 Till: "Emil Hevald" 
 CC: "check-users@..." 
 Datum: 2009-01-22 2:36
 Hi Emil,
 Thanks for the bug report.  check-users or check-devel is fine,
there 
 isn't a lot of traffic on either.
 First of all, you could simply build the latest versions of
autoconf, 
 automake, and libtool in your home directory.  I do this often.
 Second, try updating to the latest SVN version of check:
 svn co https://check.svn.sourceforge.net/svnroot/check check
 There has been some work in the portability area specifically since 
 0.9.6 and your problem may have already been fixed.
 Third, by all means let us know if you still have a problem.
 Cheers,
 Chris
 Emil Hevald wrote:
 > Oh, found a test flag in the changelog. And running the tests
without 
 > timeout tests will make the test suite compile, and run without
errors. 
 > If I build the check lib as described below.
 > 
 > --
 > Br, Emil
 > 
 > 
 >     ----- Ursprungligt Meddelande -----
 >     *Ämne: *[Check-users] check 0.9.6 on Solaris?
 >     *Från:  *Emil Hevald 
 >     *Till: *"check-users@..."
 >     
 >     *Datum: *2009-01-21 8:51
 > 
 > 
 >     Hello folks.
 > 
 >     I am new to this list, and not sure if this rather belong in
 >     check-devel? I have been using check on Solaris before, some
years
 >     ago (0.9.5). And is about to try it out again, but have been
unable
 >     to build 0.9.6 on my Solaris system. Seem like there is
something in
 >     the makefiles since 0.9.5 do build on my system, at least the
check
 >     lib. The test code do not work since it uses [un]setenv while
 >     Solaris only support putenv.
 > 
 >     
 >     checking for putenv... yes
 >     checking for setenv... no
 > 
 >     I guess this could be solved with a check in the test code for
 >     HAVE_SETENV. But that's not a big issue for me atm.
 > 
 >     Before going into details, I need to say that I do not have
the
 >     correct versions of autoconf and automake. But I am not sure
if that
 >     is the problem here? Since I use ./configure and gmake (GNU
make),
 >     and can get it to produce a lib in the end. Anyway....
 > 
 >     When doing ./configure;gmake I get an error when trying to
build
 >     check_run.c. The log below is just the error printed, not the
entire
 >     printout.
 > 
 >     check_run.c:145: error: storage size of `old_action' isn't
known
 >     check_run.c:146: error: storage size of `new_action' isn't
known
 > 
 >     [old/new]_action is declared as struct sigaction, that should
be in
 >     signal.h. Looking in my signal.h file I can find the sigaction
 >     struct . But the compiler seem to miss them. I guess there is
some
 >     #ifdef that break this for me.
 > 
 >     The gcc command that libtool create looks like this.
 > 
 >      gcc -DHAVE_CONFIG_H -I. -I.. -ansi -pedantic -g -O2 -Wall
 >     -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -MT
 >     check_run.lo -MD -MP -MF .deps/check_run.Tpo -c check_run.c 
-fPIC
 >     -DPIC -o .libs/check_run.o
 > 
 >     I removed -ansi and it compile as expected. But now it will
not link
 >     the lib.
 > 
 >     gcc -shared -Wl,-M -Wl,.libs/libcheck.so.0.0.0.exp -Wl,-h
 >     -Wl,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  -lc
 >    
/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:
 >     file format not recognized; treating as linker script
 >    
/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:1:
 >     parse error
 >     collect2: ld returned 1 exit status
 > 
 >     I don't know enough about Makefiles to understand this. But is
seem
 >     like .../bin/ld:.libs/.... is wrong? ld is the command and one
would
 >     expect that you might want to change the ":" to a " "?
 > 
 >     Doing a ./configure --disable-share;gmake will build
 >     the lib.
 > 
 >     creating libcheck.la
 > 
 >     But I have not tried it yet to see if its working. Tweaking
the test
 >     code to make it build and running "gmake check" will make
quite a
 >     few tcs fail. But I did not put that much time into fixing the
 >     testcases or looking at what they do. 
 > 
 >     The question really is, did anyone manage to build, and use
the new
 >     check lib on solaris? Will correct versions of automake and
autoconf
 >     fix these issues? I can't update these myself, therefor I have
not
 >     tried that yet. An my limited knowledge of make systems might
make
 >     this an easy fix by adding a magic flag to configure or
something. :)
 > 
 >     --
 >     BR, Emil
 >    
------------------------------------------------------------------------------
 >     This SF.net email is sponsored by:
 >     SourcForge Community
 >     SourceForge wants to tell your story.
 >    
http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
 >     Check-users mailing list
 >     Check-users@...
 >     https://lists.sourceforge.net/lists/listinfo/check-users
 > 
 > 
 >
------------------------------------------------------------------------
 > 
 >
------------------------------------------------------------------------------
 > This SF.net email is sponsored by:
 > SourcForge Community
 > SourceForge wants to tell your story.
 > http://p.sf.net/sfu/sf-spreadtheword
 > 
 > 
 >
------------------------------------------------------------------------
 > 
 > _______________________________________________
 > Check-users mailing list
 > Check-users@...
 > https://lists.sourceforge.net/lists/listinfo/check-users

Hi Emil,

I guess I have one idea: if you try building the autoconf, automake, and 
libtool sources instead of using binary packages that you expand in your 
home directory, that might help.  Sometimes binaries are expected to be 
installed in standard locations, and have hardcoded paths, which is why 
they might be finding old versions.  It's really easy to build autoconf, 
automake, and libtool: just ./configure --prefix=$HOME/<somedir> && 
gmake && gmake install.

If that doesn't work, I think you need to contact bug-autoconf@...

Cheers,
Chris

Emil Hevald wrote:
> Hi Chris.
> 
> I do not have access to svn (not installed), but I downloaded the "GNU 
> tarball" from 
> http://check.svn.sourceforge.net/viewvc/check.tar.gz?view=tar. I guess 
> that is "latest" source as well?
> 
> I installed the latest version of automake, autoreconf and libtool that 
> I found, and tried on the source I downloaded. But there seem to be a 
> problem with my libtool installation.
> 
> ~/check/check/trunk > autoreconf --version
> autoreconf (GNU Autoconf) 2.63
> 
> ~/check/check/trunk > autoreconf -vif -W all
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal --force -I m4
> autoreconf: configure.ac: tracing
> configure.ac:41: warning: The macro `AC_HELP_STRING' is obsolete.
> configure.ac:41: You should run autoupdate.
> ../../lib/autoconf/general.m4:209: AC_HELP_STRING is expanded from...
> .....
> ..... A lot more of these kinds of warnings .
> .....
> configure.ac:84: error: possibly undefined macro: AC_PROG_LIBTOOL
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
> autoreconf: ~/GNU/autoconf/bin/autoconf failed with exit status: 1
> 
> After searching the web for an answers on this fault it seem that people 
> with similar faults hade old libtool installed. And I guess it might 
> find the old version that reside in the system here.
> 
> ~/check/check/trunk > libtool --version
> ltmain.sh (GNU libtool) 2.2.6
> 
> But looking at this, it should find the correct one. The old libtool 
> should not even be in my PATH.
> 
> Any suggestions on what could be the problem?
> 
> Thanks in advance!
> 
> --
> BR, Emil
> 
> 
> 
>     ----- Ursprungligt Meddelande -----
>     *Ämne: *Re: [Check-users] check 0.9.6 on Solaris?
>     *Från:  *Chris Pickett <chris.pickett@...>
>     *Till: *"Emil Hevald" <emil.hevald@...>
>     *CC: *"check-users@..."
>     <check-users@...>
>     *Datum: *2009-01-22 2:36
> 
> 
>     Hi Emil,
> 
>     Thanks for the bug report. check-users or check-devel is fine, there
>     isn't a lot of traffic on either.
> 
>     First of all, you could simply build the latest versions of autoconf,
>     automake, and libtool in your home directory. I do this often.
> 
>     Second, try updating to the latest SVN version of check:
> 
>     svn co https://check.svn.sourceforge.net/svnroot/check check
> 
>     There has been some work in the portability area specifically since
>     0.9.6 and your problem may have already been fixed.
> 
>     Third, by all means let us know if you still have a problem.
> 
>     Cheers,
>     Chris
> 
>     Emil Hevald wrote:
>      > Oh, found a test flag in the changelog. And running the tests
>     without
>      > timeout tests will make the test suite compile, and run without
>     errors.
>      > If I build the check lib as described below.
>      >
>      > --
>      > Br, Emil
>      >
>      >
>      > ----- Ursprungligt Meddelande -----
>      > *Ämne: *[Check-users] check 0.9.6 on Solaris?
>      > *Från: *Emil Hevald <emil.hevald@...>
>      > *Till: *"check-users@..."
>      > <check-users@...>
>      > *Datum: *2009-01-21 8:51
>      >
>      >
>      > Hello folks.
>      >
>      > I am new to this list, and not sure if this rather belong in
>      > check-devel? I have been using check on Solaris before, some years
>      > ago (0.9.5). And is about to try it out again, but have been unable
>      > to build 0.9.6 on my Solaris system. Seem like there is something in
>      > the makefiles since 0.9.5 do build on my system, at least the check
>      > lib. The test code do not work since it uses [un]setenv while
>      > Solaris only support putenv.
>      >
>      > <configure output>
>      > checking for putenv... yes
>      > checking for setenv... no
>      >
>      > I guess this could be solved with a check in the test code for
>      > HAVE_SETENV. But that's not a big issue for me atm.
>      >
>      > Before going into details, I need to say that I do not have the
>      > correct versions of autoconf and automake. But I am not sure if that
>      > is the problem here? Since I use ./configure and gmake (GNU make),
>      > and can get it to produce a lib in the end. Anyway....
>      >
>      > When doing ./configure;gmake I get an error when trying to build
>      > check_run.c. The log below is just the error printed, not the entire
>      > printout.
>      >
>      > check_run.c:145: error: storage size of `old_action' isn't known
>      > check_run.c:146: error: storage size of `new_action' isn't known
>      >
>      > [old/new]_action is declared as struct sigaction, that should be in
>      > signal.h. Looking in my signal.h file I can find the sigaction
>      > struct . But the compiler seem to miss them. I guess there is some
>      > #ifdef that break this for me.
>      >
>      > The gcc command that libtool create looks like this.
>      >
>      > gcc -DHAVE_CONFIG_H -I. -I.. -ansi -pedantic -g -O2 -Wall
>      > -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -MT
>      > check_run.lo -MD -MP -MF .deps/check_run.Tpo -c check_run.c -fPIC
>      > -DPIC -o .libs/check_run.o
>      >
>      > I removed -ansi and it compile as expected. But now it will not link
>      > the lib.
>      >
>      > gcc -shared -Wl,-M -Wl,.libs/libcheck.so.0.0.0.exp -Wl,-h
>      > -Wl,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 -lc
>      >
>     <path>/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:
>      > file format not recognized; treating as linker script
>      >
>     <path>/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:1:
>      > parse error
>      > collect2: ld returned 1 exit status
>      >
>      > I don't know enough about Makefiles to understand this. But is seem
>      > like .../bin/ld:.libs/.... is wrong? ld is the command and one would
>      > expect that you might want to change the ":" to a " "?
>      >
>      > Doing a ./configure --disable-share;<removie -ansi>gmake will build
>      > the lib.
>      >
>      > creating libcheck.la
>      >
>      > But I have not tried it yet to see if its working. Tweaking the test
>      > code to make it build and running "gmake check" will make quite a
>      > few tcs fail. But I did not put that much time into fixing the
>      > testcases or looking at what they do.
>      >
>      > The question really is, did anyone manage to build, and use the new
>      > check lib on solaris? Will correct versions of automake and autoconf
>      > fix these issues? I can't update these myself, therefor I have not
>      > tried that yet. An my limited knowledge of make systems might make
>      > this an easy fix by adding a magic flag to configure or something. :)
>      >
>      > --
>      > BR, Emil
>      >
>     ------------------------------------------------------------------------------
>      > This SF.net email is sponsored by:
>      > SourcForge Community
>      > SourceForge wants to tell your story.
>      >
>     http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
>      > Check-users mailing list
>      > Check-users@...
>      > https://lists.sourceforge.net/lists/listinfo/check-users
>      >
>      >
>      >
>     ------------------------------------------------------------------------
>      >
>      >
>     ------------------------------------------------------------------------------
>      > This SF.net email is sponsored by:
>      > SourcForge Community
>      > SourceForge wants to tell your story.
>      > http://p.sf.net/sfu/sf-spreadtheword
>      >
>      >
>      >
>     ------------------------------------------------------------------------
>      >
>      > _______________________________________________
>      > Check-users mailing list
>      > Check-users@...
>      > https://lists.sourceforge.net/lists/listinfo/check-users

Hi Chris. 
 I did build the tools from source. I guess I need to try to
understand autoconf a bit more. :)
 Thanks for your help. 
 --
 BR, Emil
 ----- Ursprungligt Meddelande -----
 Ämne: Re: [Check-users] check 0.9.6 on Solaris?
 Från:  Chris Pickett 
 Till: "Emil Hevald" 
 CC: "check-users@..." 
 Datum: 2009-01-22 18:49
 Hi Emil,
 I guess I have one idea: if you try building the autoconf, automake,
and 
 libtool sources instead of using binary packages that you expand in
your 
 home directory, that might help.  Sometimes binaries are expected to
be 
 installed in standard locations, and have hardcoded paths, which is
why 
 they might be finding old versions.  It's really easy to build
autoconf, 
 automake, and libtool: just ./configure --prefix=$HOME/ && 
 gmake && gmake install.
 If that doesn't work, I think you need to contact
bug-autoconf@...
 Cheers,
 Chris
 Emil Hevald wrote:
 > Hi Chris.
 > 
 > I do not have access to svn (not installed), but I downloaded the
"GNU 
 > tarball" from 
 > http://check.svn.sourceforge.net/viewvc/check.tar.gz?view=tar. I
guess 
 > that is "latest" source as well?
 > 
 > I installed the latest version of automake, autoreconf and libtool
that 
 > I found, and tried on the source I downloaded. But there seem to
be a 
 > problem with my libtool installation.
 > 
 > ~/check/check/trunk > autoreconf --version
 > autoreconf (GNU Autoconf) 2.63
 > 
 > ~/check/check/trunk > autoreconf -vif -W all
 > autoreconf: Entering directory `.'
 > autoreconf: configure.ac: not using Gettext
 > autoreconf: running: aclocal --force -I m4
 > autoreconf: configure.ac: tracing
 > configure.ac:41: warning: The macro `AC_HELP_STRING' is obsolete.
 > configure.ac:41: You should run autoupdate.
 > ../../lib/autoconf/general.m4:209: AC_HELP_STRING is expanded
from...
 > .....
 > ..... A lot more of these kinds of warnings .
 > .....
 > configure.ac:84: error: possibly undefined macro: AC_PROG_LIBTOOL
 >       If this token and others are legitimate, please use
m4_pattern_allow.
 >       See the Autoconf documentation.
 > autoreconf: ~/GNU/autoconf/bin/autoconf failed with exit status: 1
 > 
 > After searching the web for an answers on this fault it seem that
people 
 > with similar faults hade old libtool installed. And I guess it
might 
 > find the old version that reside in the system here.
 > 
 > ~/check/check/trunk > libtool --version
 > ltmain.sh (GNU libtool) 2.2.6
 > 
 > But looking at this, it should find the correct one. The old
libtool 
 > should not even be in my PATH.
 > 
 > Any suggestions on what could be the problem?
 > 
 > Thanks in advance!
 > 
 > --
 > BR, Emil
 > 
 > 
 > 
 >     ----- Ursprungligt Meddelande -----
 >     *Ämne: *Re: [Check-users] check 0.9.6 on Solaris?
 >     *Från:  *Chris Pickett 
 >     *Till: *"Emil Hevald" 
 >     *CC: *"check-users@..."
 >     
 >     *Datum: *2009-01-22 2:36
 > 
 > 
 >     Hi Emil,
 > 
 >     Thanks for the bug report. check-users or check-devel is fine,
there
 >     isn't a lot of traffic on either.
 > 
 >     First of all, you could simply build the latest versions of
autoconf,
 >     automake, and libtool in your home directory. I do this often.
 > 
 >     Second, try updating to the latest SVN version of check:
 > 
 >     svn co https://check.svn.sourceforge.net/svnroot/check check
 > 
 >     There has been some work in the portability area specifically
since
 >     0.9.6 and your problem may have already been fixed.
 > 
 >     Third, by all means let us know if you still have a problem.
 > 
 >     Cheers,
 >     Chris
 > 
 >     Emil Hevald wrote:
 >      > Oh, found a test flag in the changelog. And running the
tests
 >     without
 >      > timeout tests will make the test suite compile, and run
without
 >     errors.
 >      > If I build the check lib as described below.
 >      >
 >      > --
 >      > Br, Emil
 >      >
 >      >
 >      > ----- Ursprungligt Meddelande -----
 >      > *Ämne: *[Check-users] check 0.9.6 on Solaris?
 >      > *Från: *Emil Hevald 
 >      > *Till: *"check-users@..."
 >      > 
 >      > *Datum: *2009-01-21 8:51
 >      >
 >      >
 >      > Hello folks.
 >      >
 >      > I am new to this list, and not sure if this rather belong
in
 >      > check-devel? I have been using check on Solaris before,
some years
 >      > ago (0.9.5). And is about to try it out again, but have
been unable
 >      > to build 0.9.6 on my Solaris system. Seem like there is
something in
 >      > the makefiles since 0.9.5 do build on my system, at least
the check
 >      > lib. The test code do not work since it uses [un]setenv
while
 >      > Solaris only support putenv.
 >      >
 >      > 
 >      > checking for putenv... yes
 >      > checking for setenv... no
 >      >
 >      > I guess this could be solved with a check in the test code
for
 >      > HAVE_SETENV. But that's not a big issue for me atm.
 >      >
 >      > Before going into details, I need to say that I do not have
the
 >      > correct versions of autoconf and automake. But I am not
sure if that
 >      > is the problem here? Since I use ./configure and gmake (GNU
make),
 >      > and can get it to produce a lib in the end. Anyway....
 >      >
 >      > When doing ./configure;gmake I get an error when trying to
build
 >      > check_run.c. The log below is just the error printed, not
the entire
 >      > printout.
 >      >
 >      > check_run.c:145: error: storage size of `old_action' isn't
known
 >      > check_run.c:146: error: storage size of `new_action' isn't
known
 >      >
 >      > [old/new]_action is declared as struct sigaction, that
should be in
 >      > signal.h. Looking in my signal.h file I can find the
sigaction
 >      > struct . But the compiler seem to miss them. I guess there
is some
 >      > #ifdef that break this for me.
 >      >
 >      > The gcc command that libtool create looks like this.
 >      >
 >      > gcc -DHAVE_CONFIG_H -I. -I.. -ansi -pedantic -g -O2 -Wall
 >      > -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings
-MT
 >      > check_run.lo -MD -MP -MF .deps/check_run.Tpo -c check_run.c
-fPIC
 >      > -DPIC -o .libs/check_run.o
 >      >
 >      > I removed -ansi and it compile as expected. But now it will
not link
 >      > the lib.
 >      >
 >      > gcc -shared -Wl,-M -Wl,.libs/libcheck.so.0.0.0.exp -Wl,-h
 >      > -Wl,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 -lc
 >      >
 >    
/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:
 >      > file format not recognized; treating as linker script
 >      >
 >    
/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:1:
 >      > parse error
 >      > collect2: ld returned 1 exit status
 >      >
 >      > I don't know enough about Makefiles to understand this. But
is seem
 >      > like .../bin/ld:.libs/.... is wrong? ld is the command and
one would
 >      > expect that you might want to change the ":" to a " "?
 >      >
 >      > Doing a ./configure --disable-share;gmake will build
 >      > the lib.
 >      >
 >      > creating libcheck.la
 >      >
 >      > But I have not tried it yet to see if its working. Tweaking
the test
 >      > code to make it build and running "gmake check" will make
quite a
 >      > few tcs fail. But I did not put that much time into fixing
the
 >      > testcases or looking at what they do.
 >      >
 >      > The question really is, did anyone manage to build, and use
the new
 >      > check lib on solaris? Will correct versions of automake and
autoconf
 >      > fix these issues? I can't update these myself, therefor I
have not
 >      > tried that yet. An my limited knowledge of make systems
might make
 >      > this an easy fix by adding a magic flag to configure or
something. :)
 >      >
 >      > --
 >      > BR, Emil
 >      >
 >    
------------------------------------------------------------------------------
 >      > This SF.net email is sponsored by:
 >      > SourcForge Community
 >      > SourceForge wants to tell your story.
 >      >
 >    
http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
 >      > Check-users mailing list
 >      > Check-users@...
 >      > https://lists.sourceforge.net/lists/listinfo/check-users
 >      >
 >      >
 >      >
 >    
------------------------------------------------------------------------
 >      >
 >      >
 >    
------------------------------------------------------------------------------
 >      > This SF.net email is sponsored by:
 >      > SourcForge Community
 >      > SourceForge wants to tell your story.
 >      > http://p.sf.net/sfu/sf-spreadtheword
 >      >
 >      >
 >      >
 >    
------------------------------------------------------------------------
 >      >
 >      > _______________________________________________
 >      > Check-users mailing list
 >      > Check-users@...
 >      > https://lists.sourceforge.net/lists/listinfo/check-users

Hi.
 In case someone run into the same problem I had. Here is what was
wrong in my setup. 
 I noticed that libtool had it's own aclocal files under .../share/.
But since I installed all my GNU tools in their own directory
structure, hence running "./configure --prefix=$HOME/GNU/". This have
the affect that the aclocal (m4) files for libtools are not found by
aclocal when it try to build the aclocal.m4 file. I guess when using
this setup you need to make sure that you add "-I " to your aclocal
call. 
 However, I just rebuilt the packages into the same directory
structure and it all worked "out of the box". In other words I did
".configure --prefix=$HOME/GNU/tools" for all packages so that
directory bin, share etc end up in the same "tools" folder. This will
make aclocal find the files it needs, libtool in this case.  
 The link problem I had still remain though. But the -ansi flag for
the compilation works now. But using --disable-shared make it build
the check lib. 
 --
 BR, Emil
 ----- Ursprungligt Meddelande -----
 Ämne: Re: [Check-users] check 0.9.6 on Solaris?
 Från:  Emil Hevald 
 Till: "Chris Pickett" 
 CC: "check-users@..." 
 Datum: 2009-01-23 8:14
 Hi Chris. 
 I did build the tools from source. I guess I need to try to
understand autoconf a bit more. :)
 Thanks for your help. 
 --
 BR, Emil
 ----- Ursprungligt Meddelande -----
 Ämne: Re: [Check-users] check 0.9.6 on Solaris?
 Från:  Chris Pickett 
 Till: "Emil Hevald" 
 CC: "check-users@..." 
 Datum: 2009-01-22 18:49
 Hi Emil,
 I guess I have one idea: if you try building the autoconf, automake,
and 
 libtool sources instead of using binary packages that you expand in
your 
 home directory, that might help.  Sometimes binaries are expected to
be 
 installed in standard locations, and have hardcoded paths, which is
why 
 they might be finding old versions.  It's really easy to build
autoconf, 
 automake, and libtool: just ./configure --prefix=$HOME/ && 
 gmake && gmake install.
 If that doesn't work, I think you need to contact
bug-autoconf@...
 Cheers,
 Chris
 Emil Hevald wrote:
 > Hi Chris.
 > 
 > I do not have access to svn (not installed), but I downloaded the
"GNU 
 > tarball" from 
 > http://check.svn.sourceforge.net/viewvc/check.tar.gz?view=tar. I
guess 
 > that is "latest" source as well?
 > 
 > I installed the latest version of automake, autoreconf and libtool
that 
 > I found, and tried on the source I downloaded. But there seem to
be a 
 > problem with my libtool installation.
 > 
 > ~/check/check/trunk > autoreconf --version
 > autoreconf (GNU Autoconf) 2.63
 > 
 > ~/check/check/trunk > autoreconf -vif -W all
 > autoreconf: Entering directory `.'
 > autoreconf: configure.ac: not using Gettext
 > autoreconf: running: aclocal --force -I m4
 > autoreconf: configure.ac: tracing
 > configure.ac:41: warning: The macro `AC_HELP_STRING' is obsolete.
 > configure.ac:41: You should run autoupdate.
 > ../../lib/autoconf/general.m4:209: AC_HELP_STRING is expanded
from...
 > .....
 > ..... A lot more of these kinds of warnings .
 > .....
 > configure.ac:84: error: possibly undefined macro: AC_PROG_LIBTOOL
 >       If this token and others are legitimate, please use
m4_pattern_allow.
 >       See the Autoconf documentation.
 > autoreconf: ~/GNU/autoconf/bin/autoconf failed with exit status: 1
 > 
 > After searching the web for an answers on this fault it seem that
people 
 > with similar faults hade old libtool installed. And I guess it
might 
 > find the old version that reside in the system here.
 > 
 > ~/check/check/trunk > libtool --version
 > ltmain.sh (GNU libtool) 2.2.6
 > 
 > But looking at this, it should find the correct one. The old
libtool 
 > should not even be in my PATH.
 > 
 > Any suggestions on what could be the problem?
 > 
 > Thanks in advance!
 > 
 > --
 > BR, Emil
 > 
 > 
 > 
 >     ----- Ursprungligt Meddelande -----
 >     *Ämne: *Re: [Check-users] check 0.9.6 on Solaris?
 >     *Från:  *Chris Pickett 
 >     *Till: *"Emil Hevald" 
 >     *CC: *"check-users@..."
 >     
 >     *Datum: *2009-01-22 2:36
 > 
 > 
 >     Hi Emil,
 > 
 >     Thanks for the bug report. check-users or check-devel is fine,
there
 >     isn't a lot of traffic on either.
 > 
 >     First of all, you could simply build the latest versions of
autoconf,
 >     automake, and libtool in your home directory. I do this often.
 > 
 >     Second, try updating to the latest SVN version of check:
 > 
 >     svn co https://check.svn.sourceforge.net/svnroot/check check
 > 
 >     There has been some work in the portability area specifically
since
 >     0.9.6 and your problem may have already been fixed.
 > 
 >     Third, by all means let us know if you still have a problem.
 > 
 >     Cheers,
 >     Chris
 > 
 >     Emil Hevald wrote:
 >      > Oh, found a test flag in the changelog. And running the
tests
 >     without
 >      > timeout tests will make the test suite compile, and run
without
 >     errors.
 >      > If I build the check lib as described below.
 >      >
 >      > --
 >      > Br, Emil
 >      >
 >      >
 >      > ----- Ursprungligt Meddelande -----
 >      > *Ämne: *[Check-users] check 0.9.6 on Solaris?
 >      > *Från: *Emil Hevald 
 >      > *Till: *"check-users@..."
 >      > 
 >      > *Datum: *2009-01-21 8:51
 >      >
 >      >
 >      > Hello folks.
 >      >
 >      > I am new to this list, and not sure if this rather belong
in
 >      > check-devel? I have been using check on Solaris before,
some years
 >      > ago (0.9.5). And is about to try it out again, but have
been unable
 >      > to build 0.9.6 on my Solaris system. Seem like there is
something in
 >      > the makefiles since 0.9.5 do build on my system, at least
the check
 >      > lib. The test code do not work since it uses [un]setenv
while
 >      > Solaris only support putenv.
 >      >
 >      > 
 >      > checking for putenv... yes
 >      > checking for setenv... no
 >      >
 >      > I guess this could be solved with a check in the test code
for
 >      > HAVE_SETENV. But that's not a big issue for me atm.
 >      >
 >      > Before going into details, I need to say that I do not have
the
 >      > correct versions of autoconf and automake. But I am not
sure if that
 >      > is the problem here? Since I use ./configure and gmake (GNU
make),
 >      > and can get it to produce a lib in the end. Anyway....
 >      >
 >      > When doing ./configure;gmake I get an error when trying to
build
 >      > check_run.c. The log below is just the error printed, not
the entire
 >      > printout.
 >      >
 >      > check_run.c:145: error: storage size of `old_action' isn't
known
 >      > check_run.c:146: error: storage size of `new_action' isn't
known
 >      >
 >      > [old/new]_action is declared as struct sigaction, that
should be in
 >      > signal.h. Looking in my signal.h file I can find the
sigaction
 >      > struct . But the compiler seem to miss them. I guess there
is some
 >      > #ifdef that break this for me.
 >      >
 >      > The gcc command that libtool create looks like this.
 >      >
 >      > gcc -DHAVE_CONFIG_H -I. -I.. -ansi -pedantic -g -O2 -Wall
 >      > -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings
-MT
 >      > check_run.lo -MD -MP -MF .deps/check_run.Tpo -c check_run.c
-fPIC
 >      > -DPIC -o .libs/check_run.o
 >      >
 >      > I removed -ansi and it compile as expected. But now it will
not link
 >      > the lib.
 >      >
 >      > gcc -shared -Wl,-M -Wl,.libs/libcheck.so.0.0.0.exp -Wl,-h
 >      > -Wl,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 -lc
 >      >
 >    
/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:
 >      > file format not recognized; treating as linker script
 >      >
 >    
/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:1:
 >      > parse error
 >      > collect2: ld returned 1 exit status
 >      >
 >      > I don't know enough about Makefiles to understand this. But
is seem
 >      > like .../bin/ld:.libs/.... is wrong? ld is the command and
one would
 >      > expect that you might want to change the ":" to a " "?
 >      >
 >      > Doing a ./configure --disable-share;gmake will build
 >      > the lib.
 >      >
 >      > creating libcheck.la
 >      >
 >      > But I have not tried it yet to see if its working. Tweaking
the test
 >      > code to make it build and running "gmake check" will make
quite a
 >      > few tcs fail. But I did not put that much time into fixing
the
 >      > testcases or looking at what they do.
 >      >
 >      > The question really is, did anyone manage to build, and use
the new
 >      > check lib on solaris? Will correct versions of automake and
autoconf
 >      > fix these issues? I can't update these myself, therefor I
have not
 >      > tried that yet. An my limited knowledge of make systems
might make
 >      > this an easy fix by adding a magic flag to configure or
something. :)
 >      >
 >      > --
 >      > BR, Emil
 >      >
 >    
------------------------------------------------------------------------------
 >      > This SF.net email is sponsored by:
 >      > SourcForge Community
 >      > SourceForge wants to tell your story.
 >      >
 >    
http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
 >      > Check-users mailing list
 >      > Check-users@...
 >      > https://lists.sourceforge.net/lists/listinfo/check-users
 >      >
 >      >
 >      >
 >    
------------------------------------------------------------------------
 >      >
 >      >
 >    
------------------------------------------------------------------------------
 >      > This SF.net email is sponsored by:
 >      > SourcForge Community
 >      > SourceForge wants to tell your story.
 >      > http://p.sf.net/sfu/sf-spreadtheword
 >      >
 >      >
 >      >
 >    
------------------------------------------------------------------------
 >      >
 >      > _______________________________________________
 >      > Check-users mailing list
 >      > Check-users@...
 >      > https://lists.sourceforge.net/lists/listinfo/check-users
   
------------------------------------------------------------------------------
 This SF.net email is sponsored by:
 SourcForge Community
 SourceForge wants to tell your story.

http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
 Check-users mailing list
 Check-users@...
 https://lists.sourceforge.net/lists/listinfo/check-users

I was too fast with that last email. I should have added that it do
compile with the lastest version from svn (downloaded from
sourceforge webpage). 0.9.6 do not compile on my Solaris system, and
the error is the same as in my first email. So I guess the fix that
was made in this area after 0.9.6 at least do the trick on Solaris. 
 Sorry for the spam. :)
 --
 BR, Emil
 ----- Ursprungligt Meddelande -----
 Ämne: Re: [Check-users] check 0.9.6 on Solaris?
 Från:  Emil Hevald 
 Till: "check-users@..." 
 Datum: 2009-01-23 9:50
 Hi.
 In case someone run into the same problem I had. Here is what was
wrong in my setup. 
 I noticed that libtool had it's own aclocal files under .../share/.
But since I installed all my GNU tools in their own directory
structure, hence running "./configure --prefix=$HOME/GNU/". This have
the affect that the aclocal (m4) files for libtools are not found by
aclocal when it try to build the aclocal.m4 file. I guess when using
this setup you need to make sure that you add "-I " to your aclocal
call. 
 However, I just rebuilt the packages into the same directory
structure and it all worked "out of the box". In other words I did
".configure --prefix=$HOME/GNU/tools" for all packages so that
directory bin, share etc end up in the same "tools" folder. This will
make aclocal find the files it needs, libtool in this case.  
 The link problem I had still remain though. But the -ansi flag for
the compilation works now. But using --disable-shared make it build
the check lib. 
 --
 BR, Emil
 ----- Ursprungligt Meddelande -----
 Ämne: Re: [Check-users] check 0.9.6 on Solaris?
 Från:  Emil Hevald 
 Till: "Chris Pickett" 
 CC: "check-users@..." 
 Datum: 2009-01-23 8:14
 Hi Chris. 
 I did build the tools from source. I guess I need to try to
understand autoconf a bit more. :)
 Thanks for your help. 
 --
 BR, Emil
 ----- Ursprungligt Meddelande -----
 Ämne: Re: [Check-users] check 0.9.6 on Solaris?
 Från:  Chris Pickett 
 Till: "Emil Hevald" 
 CC: "check-users@..." 
 Datum: 2009-01-22 18:49
 Hi Emil,
 I guess I have one idea: if you try building the autoconf, automake,
and 
 libtool sources instead of using binary packages that you expand in
your 
 home directory, that might help.  Sometimes binaries are expected to
be 
 installed in standard locations, and have hardcoded paths, which is
why 
 they might be finding old versions.  It's really easy to build
autoconf, 
 automake, and libtool: just ./configure --prefix=$HOME/ && 
 gmake && gmake install.
 If that doesn't work, I think you need to contact
bug-autoconf@...
 Cheers,
 Chris
 Emil Hevald wrote:
 > Hi Chris.
 > 
 > I do not have access to svn (not installed), but I downloaded the
"GNU 
 > tarball" from 
 > http://check.svn.sourceforge.net/viewvc/check.tar.gz?view=tar. I
guess 
 > that is "latest" source as well?
 > 
 > I installed the latest version of automake, autoreconf and libtool
that 
 > I found, and tried on the source I downloaded. But there seem to
be a 
 > problem with my libtool installation.
 > 
 > ~/check/check/trunk > autoreconf --version
 > autoreconf (GNU Autoconf) 2.63
 > 
 > ~/check/check/trunk > autoreconf -vif -W all
 > autoreconf: Entering directory `.'
 > autoreconf: configure.ac: not using Gettext
 > autoreconf: running: aclocal --force -I m4
 > autoreconf: configure.ac: tracing
 > configure.ac:41: warning: The macro `AC_HELP_STRING' is obsolete.
 > configure.ac:41: You should run autoupdate.
 > ../../lib/autoconf/general.m4:209: AC_HELP_STRING is expanded
from...
 > .....
 > ..... A lot more of these kinds of warnings .
 > .....
 > configure.ac:84: error: possibly undefined macro: AC_PROG_LIBTOOL
 >       If this token and others are legitimate, please use
m4_pattern_allow.
 >       See the Autoconf documentation.
 > autoreconf: ~/GNU/autoconf/bin/autoconf failed with exit status: 1
 > 
 > After searching the web for an answers on this fault it seem that
people 
 > with similar faults hade old libtool installed. And I guess it
might 
 > find the old version that reside in the system here.
 > 
 > ~/check/check/trunk > libtool --version
 > ltmain.sh (GNU libtool) 2.2.6
 > 
 > But looking at this, it should find the correct one. The old
libtool 
 > should not even be in my PATH.
 > 
 > Any suggestions on what could be the problem?
 > 
 > Thanks in advance!
 > 
 > --
 > BR, Emil
 > 
 > 
 > 
 >     ----- Ursprungligt Meddelande -----
 >     *Ämne: *Re: [Check-users] check 0.9.6 on Solaris?
 >     *Från:  *Chris Pickett 
 >     *Till: *"Emil Hevald" 
 >     *CC: *"check-users@..."
 >     
 >     *Datum: *2009-01-22 2:36
 > 
 > 
 >     Hi Emil,
 > 
 >     Thanks for the bug report. check-users or check-devel is fine,
there
 >     isn't a lot of traffic on either.
 > 
 >     First of all, you could simply build the latest versions of
autoconf,
 >     automake, and libtool in your home directory. I do this often.
 > 
 >     Second, try updating to the latest SVN version of check:
 > 
 >     svn co https://check.svn.sourceforge.net/svnroot/check check
 > 
 >     There has been some work in the portability area specifically
since
 >     0.9.6 and your problem may have already been fixed.
 > 
 >     Third, by all means let us know if you still have a problem.
 > 
 >     Cheers,
 >     Chris
 > 
 >     Emil Hevald wrote:
 >      > Oh, found a test flag in the changelog. And running the
tests
 >     without
 >      > timeout tests will make the test suite compile, and run
without
 >     errors.
 >      > If I build the check lib as described below.
 >      >
 >      > --
 >      > Br, Emil
 >      >
 >      >
 >      > ----- Ursprungligt Meddelande -----
 >      > *Ämne: *[Check-users] check 0.9.6 on Solaris?
 >      > *Från: *Emil Hevald 
 >      > *Till: *"check-users@..."
 >      > 
 >      > *Datum: *2009-01-21 8:51
 >      >
 >      >
 >      > Hello folks.
 >      >
 >      > I am new to this list, and not sure if this rather belong
in
 >      > check-devel? I have been using check on Solaris before,
some years
 >      > ago (0.9.5). And is about to try it out again, but have
been unable
 >      > to build 0.9.6 on my Solaris system. Seem like there is
something in
 >      > the makefiles since 0.9.5 do build on my system, at least
the check
 >      > lib. The test code do not work since it uses [un]setenv
while
 >      > Solaris only support putenv.
 >      >
 >      > 
 >      > checking for putenv... yes
 >      > checking for setenv... no
 >      >
 >      > I guess this could be solved with a check in the test code
for
 >      > HAVE_SETENV. But that's not a big issue for me atm.
 >      >
 >      > Before going into details, I need to say that I do not have
the
 >      > correct versions of autoconf and automake. But I am not
sure if that
 >      > is the problem here? Since I use ./configure and gmake (GNU
make),
 >      > and can get it to produce a lib in the end. Anyway....
 >      >
 >      > When doing ./configure;gmake I get an error when trying to
build
 >      > check_run.c. The log below is just the error printed, not
the entire
 >      > printout.
 >      >
 >      > check_run.c:145: error: storage size of `old_action' isn't
known
 >      > check_run.c:146: error: storage size of `new_action' isn't
known
 >      >
 >      > [old/new]_action is declared as struct sigaction, that
should be in
 >      > signal.h. Looking in my signal.h file I can find the
sigaction
 >      > struct . But the compiler seem to miss them. I guess there
is some
 >      > #ifdef that break this for me.
 >      >
 >      > The gcc command that libtool create looks like this.
 >      >
 >      > gcc -DHAVE_CONFIG_H -I. -I.. -ansi -pedantic -g -O2 -Wall
 >      > -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings
-MT
 >      > check_run.lo -MD -MP -MF .deps/check_run.Tpo -c check_run.c
-fPIC
 >      > -DPIC -o .libs/check_run.o
 >      >
 >      > I removed -ansi and it compile as expected. But now it will
not link
 >      > the lib.
 >      >
 >      > gcc -shared -Wl,-M -Wl,.libs/libcheck.so.0.0.0.exp -Wl,-h
 >      > -Wl,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 -lc
 >      >
 >    
/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:
 >      > file format not recognized; treating as linker script
 >      >
 >    
/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:1:
 >      > parse error
 >      > collect2: ld returned 1 exit status
 >      >
 >      > I don't know enough about Makefiles to understand this. But
is seem
 >      > like .../bin/ld:.libs/.... is wrong? ld is the command and
one would
 >      > expect that you might want to change the ":" to a " "?
 >      >
 >      > Doing a ./configure --disable-share;gmake will build
 >      > the lib.
 >      >
 >      > creating libcheck.la
 >      >
 >      > But I have not tried it yet to see if its working. Tweaking
the test
 >      > code to make it build and running "gmake check" will make
quite a
 >      > few tcs fail. But I did not put that much time into fixing
the
 >      > testcases or looking at what they do.
 >      >
 >      > The question really is, did anyone manage to build, and use
the new
 >      > check lib on solaris? Will correct versions of automake and
autoconf
 >      > fix these issues? I can't update these myself, therefor I
have not
 >      > tried that yet. An my limited knowledge of make systems
might make
 >      > this an easy fix by adding a magic flag to configure or
something. :)
 >      >
 >      > --
 >      > BR, Emil
 >      >
 >    
------------------------------------------------------------------------------
 >      > This SF.net email is sponsored by:
 >      > SourcForge Community
 >      > SourceForge wants to tell your story.
 >      >
 >    
http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
 >      > Check-users mailing list
 >      > Check-users@...
 >      > https://lists.sourceforge.net/lists/listinfo/check-users
 >      >
 >      >
 >      >
 >    
------------------------------------------------------------------------
 >      >
 >      >
 >    
------------------------------------------------------------------------------
 >      > This SF.net email is sponsored by:
 >      > SourcForge Community
 >      > SourceForge wants to tell your story.
 >      > http://p.sf.net/sfu/sf-spreadtheword
 >      >
 >      >
 >      >
 >    
------------------------------------------------------------------------
 >      >
 >      > _______________________________________________
 >      > Check-users mailing list
 >      > Check-users@...
 >      > https://lists.sourceforge.net/lists/listinfo/check-users
   
------------------------------------------------------------------------------
 This SF.net email is sponsored by:
 SourcForge Community
 SourceForge wants to tell your story.

http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
 Check-users mailing list
 Check-users@...
 https://lists.sourceforge.net/lists/listinfo/check-users
   
------------------------------------------------------------------------------
 This SF.net email is sponsored by:
 SourcForge Community
 SourceForge wants to tell your story.

http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
 Check-users mailing list
 Check-users@...
 https://lists.sourceforge.net/lists/listinfo/check-users

On Fri, 23 Jan 2009, Emil Hevald wrote:

> Hi Chris.
> I did build the tools from source. I guess I need to try to
> understand autoconf a bit more. :)

I can help if you want to modify check's configure.ac file for solaris

Vincent torri

To install newer autoconf, automake and libtool in otherdirectory than 
/usr or /usr/local, I suggest that:

1) I suppose that, for example, you want to install it in your home, in 
the subdirectory local/

2) export PATH="$HOME/loca:$PATH"

3) go into the directory of the autoconf that you want to install and 
type:

./configure --prefix=$HOME/local
make
make install

4) do the same for automake and libtool

5) Normally, everything should be fine, now. The m4 files of autoconf, 
automake, aclocal and libtool, which are respectively in:
$HOME/local/share/autoconf
$HOME/local/share/autoake
$HOME/local/share/aclocal
$HOME/local/share/libtool

are automatically used .


Now, you can install these tools in another directory than $HOME/local, 
BUT, you must always do the export call that I mentioned above to have all 
those tools working correctly. To do that automatically, export PATH in a 
shell system file, like .bashrc, .zshrc or any other shell you use

hope this helps

Vincent Torri

Hi Vincent. 
 Thanks, I managed to figure that out after some troubleshooting. But
thanks anyway. :)
 My problem now is that when building a shared check lib it failes. I
need to look at this some more, but it seem like my sed is not
compatible. Since it will generate an empty exported.sym file, but if
I manually copy the sed expression used and use gsed it will generate
a file containing symbols. Which I guess is correct. 
 But this is something I am looking into atm, so I basically have
come nowhere with this. :)
 --
 Br, Emil
 ----- Ursprungligt Meddelande -----
 Ämne: Re: [Check-users] check 0.9.6 on Solaris?
 Från:  Vincent Torri 
 Till: "Emil Hevald" 
 CC: "check-users@..." 
 Datum: 2009-01-23 11:05
 To install newer autoconf, automake and libtool in otherdirectory
than 
 /usr or /usr/local, I suggest that:
 1) I suppose that, for example, you want to install it in your home,
in 
 the subdirectory local/
 2) export PATH="$HOME/loca:$PATH"
 3) go into the directory of the autoconf that you want to install
and 
 type:
 ./configure --prefix=$HOME/local
 make
 make install
 4) do the same for automake and libtool
 5) Normally, everything should be fine, now. The m4 files of
autoconf, 
 automake, aclocal and libtool, which are respectively in:
 $HOME/local/share/autoconf
 $HOME/local/share/autoake
 $HOME/local/share/aclocal
 $HOME/local/share/libtool
 are automatically used .
 Now, you can install these tools in another directory than
$HOME/local, 
 BUT, you must always do the export call that I mentioned above to
have all 
 those tools working correctly. To do that automatically, export PATH
in a 
 shell system file, like .bashrc, .zshrc or any other shell you use
 hope this helps
 Vincent Torri

libtool: link:  gcc -shared -Wl,-z -Wl,text -Wl,-M
-Wl,.libs/libcheck.so.0.0.0.exp -Wl,-h -Wl,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  -Wl,-z -Wl,allextract ../lib/.libs/libcompat.a
-Wl,-z -Wl,defaultextract  -lc  -pthreads   -pthreads
 /../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp: file
format not recognized; treating as linker script
 /../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:1: parse
error
 collect2: ld returned 1 exit status
 My libscheck.se.0.0.0.exp looks empty, but I guess you could have an
"empty" .exp file?
 $> cat .libs/libcheck.so.0.0.0.exp 
 { global:
 local: *; };
 Even if I run the sed command manually and do get a file that
contain stuff, I still get the parse error. 
 $> cat .libs/libcheck.so.0.0.0.exp 
 { global:
 check_major_version;
 check_minor_version;
 check_micro_version;
 suite_create;
 suite_add_tcase;
 tcase_create;
 _tcase_add_test;
 tcase_add_unchecked_fixture;
 tcase_add_checked_fixture;
 tcase_set_timeout;
 tcase_fn_start;
 _fail_unless;
 _mark_point;
 tr_rtype;
 tr_ctx;
 tr_msg;
 tr_lno;
 tr_lfile;
 tr_tcname;
 srunner_create;
 srunner_add_suite;
 srunner_free;
 srunner_run_all;
 srunner_ntests_failed;
 srunner_ntests_run;
 srunner_failures;
 srunner_results;
 srunner_print;
 srunner_set_log;
 srunner_has_log;
 srunner_log_fname;
 srunner_set_xml;
 srunner_has_xml;
 srunner_xml_fname;
 srunner_fork_status;
 srunner_set_fork_status;
 check_fork;
 check_waitpid_and_exit;
 local: *; };
 Ideas? I have not had the time to troubleshoot this yet. So it might
very well be a basic thing. --disable-shared will build the lib. 
 --
 Br, Emil
 ----- Ursprungligt Meddelande -----
 Ämne: Re: [Check-users] check 0.9.6 on Solaris?
 Från:  Vincent Torri 
 Till: "Emil Hevald" 
 CC: "check-users@..." 
 Datum: 2009-01-23 12:33
 > My problem now is that when building a shared check lib it failes.
 what is the error message ?
 Vincent
 > I
 > need to look at this some more, but it seem like my sed is not
 > compatible. Since it will generate an empty exported.sym file, but
if
 > I manually copy the sed expression used and use gsed it will
generate
 > a file containing symbols. Which I guess is correct.
 > But this is something I am looking into atm, so I basically have
 > come nowhere with this. :)
 > --
 > Br, Emil
 > ----- Ursprungligt Meddelande -----
 > Ämne: Re: [Check-users] check 0.9.6 on Solaris?
 > Från:  Vincent Torri
 > Till: "Emil Hevald"
 > CC: "check-users@..."
 > Datum: 2009-01-23 11:05
 > To install newer autoconf, automake and libtool in otherdirectory
 > than
 > /usr or /usr/local, I suggest that:
 > 1) I suppose that, for example, you want to install it in your
home,
 > in
 > the subdirectory local/
 > 2) export PATH="$HOME/loca:$PATH"
 > 3) go into the directory of the autoconf that you want to install
 > and
 > type:
 > ./configure --prefix=$HOME/local
 > make
 > make install
 > 4) do the same for automake and libtool
 > 5) Normally, everything should be fine, now. The m4 files of
 > autoconf,
 > automake, aclocal and libtool, which are respectively in:
 > $HOME/local/share/autoconf
 > $HOME/local/share/autoake
 > $HOME/local/share/aclocal
 > $HOME/local/share/libtool
 > are automatically used .
 > Now, you can install these tools in another directory than
 > $HOME/local,
 > BUT, you must always do the export call that I mentioned above to
 > have all
 > those tools working correctly. To do that automatically, export
PATH
 > in a
 > shell system file, like .bashrc, .zshrc or any other shell you use
 > hope this helps
 > Vincent Torri
 >
 >
 >
 > -- 
 > Ce message a été vérifié par
MailScanner
 > pour des virus ou des polluriels et rien de
 > suspect n'a été trouvé.
 > Message délivré par le serveur de messagerie de
l'Université d'Evry.
 >
 >

> My problem now is that when building a shared check lib it failes.

what is the error message ?

Vincent

> I
> need to look at this some more, but it seem like my sed is not
> compatible. Since it will generate an empty exported.sym file, but if
> I manually copy the sed expression used and use gsed it will generate
> a file containing symbols. Which I guess is correct.
> But this is something I am looking into atm, so I basically have
> come nowhere with this. :)
> --
> Br, Emil
> ----- Ursprungligt Meddelande -----
> Ämne: Re: [Check-users] check 0.9.6 on Solaris?
> Från:  Vincent Torri
> Till: "Emil Hevald"
> CC: "check-users@..."
> Datum: 2009-01-23 11:05
> To install newer autoconf, automake and libtool in otherdirectory
> than
> /usr or /usr/local, I suggest that:
> 1) I suppose that, for example, you want to install it in your home,
> in
> the subdirectory local/
> 2) export PATH="$HOME/loca:$PATH"
> 3) go into the directory of the autoconf that you want to install
> and
> type:
> ./configure --prefix=$HOME/local
> make
> make install
> 4) do the same for automake and libtool
> 5) Normally, everything should be fine, now. The m4 files of
> autoconf,
> automake, aclocal and libtool, which are respectively in:
> $HOME/local/share/autoconf
> $HOME/local/share/autoake
> $HOME/local/share/aclocal
> $HOME/local/share/libtool
> are automatically used .
> Now, you can install these tools in another directory than
> $HOME/local,
> BUT, you must always do the export call that I mentioned above to
> have all
> those tools working correctly. To do that automatically, export PATH
> in a
> shell system file, like .bashrc, .zshrc or any other shell you use
> hope this helps
> Vincent Torri
>
>
>
> -- 
> Ce message a été vérifié par MailScanner
> pour des virus ou des polluriels et rien de
> suspect n'a été trouvé.
> Message délivré par le serveur de messagerie de l'Université d'Evry.
>
>

You should report that problem on the libtool ML, I guess. I have idea 
about how to solve the problem

Vincent Torri

On Fri, 23 Jan 2009, Emil Hevald wrote:

> libtool: link:  gcc -shared -Wl,-z -Wl,text -Wl,-M
> -Wl,.libs/libcheck.so.0.0.0.exp -Wl,-h -Wl,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  -Wl,-z -Wl,allextract ../lib/.libs/libcompat.a
> -Wl,-z -Wl,defaultextract  -lc  -pthreads   -pthreads
> /../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp: file
> format not recognized; treating as linker script
> /../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:1: parse
> error
> collect2: ld returned 1 exit status
> My libscheck.se.0.0.0.exp looks empty, but I guess you could have an
> "empty" .exp file?
> $> cat .libs/libcheck.so.0.0.0.exp
> { global:
> local: *; };
> Even if I run the sed command manually and do get a file that
> contain stuff, I still get the parse error.
> $> cat .libs/libcheck.so.0.0.0.exp
> { global:
> check_major_version;
> check_minor_version;
> check_micro_version;
> suite_create;
> suite_add_tcase;
> tcase_create;
> _tcase_add_test;
> tcase_add_unchecked_fixture;
> tcase_add_checked_fixture;
> tcase_set_timeout;
> tcase_fn_start;
> _fail_unless;
> _mark_point;
> tr_rtype;
> tr_ctx;
> tr_msg;
> tr_lno;
> tr_lfile;
> tr_tcname;
> srunner_create;
> srunner_add_suite;
> srunner_free;
> srunner_run_all;
> srunner_ntests_failed;
> srunner_ntests_run;
> srunner_failures;
> srunner_results;
> srunner_print;
> srunner_set_log;
> srunner_has_log;
> srunner_log_fname;
> srunner_set_xml;
> srunner_has_xml;
> srunner_xml_fname;
> srunner_fork_status;
> srunner_set_fork_status;
> check_fork;
> check_waitpid_and_exit;
> local: *; };
> Ideas? I have not had the time to troubleshoot this yet. So it might
> very well be a basic thing. --disable-shared will build the lib.
> --
> Br, Emil
> ----- Ursprungligt Meddelande -----
> Ämne: Re: [Check-users] check 0.9.6 on Solaris?
> Från:  Vincent Torri
> Till: "Emil Hevald"
> CC: "check-users@..."
> Datum: 2009-01-23 12:33
> > My problem now is that when building a shared check lib it failes.
> what is the error message ?
> Vincent
> > I
> > need to look at this some more, but it seem like my sed is not
> > compatible. Since it will generate an empty exported.sym file, but
> if
> > I manually copy the sed expression used and use gsed it will
> generate
> > a file containing symbols. Which I guess is correct.
> > But this is something I am looking into atm, so I basically have
> > come nowhere with this. :)
> > --
> > Br, Emil
> > ----- Ursprungligt Meddelande -----
> > Ämne: Re: [Check-users] check 0.9.6 on Solaris?
> > Från:  Vincent Torri
> > Till: "Emil Hevald"
> > CC: "check-users@..."
> > Datum: 2009-01-23 11:05
> > To install newer autoconf, automake and libtool in otherdirectory
> > than
> > /usr or /usr/local, I suggest that:
> > 1) I suppose that, for example, you want to install it in your
> home,
> > in
> > the subdirectory local/
> > 2) export PATH="$HOME/loca:$PATH"
> > 3) go into the directory of the autoconf that you want to install
> > and
> > type:
> > ./configure --prefix=$HOME/local
> > make
> > make install
> > 4) do the same for automake and libtool
> > 5) Normally, everything should be fine, now. The m4 files of
> > autoconf,
> > automake, aclocal and libtool, which are respectively in:
> > $HOME/local/share/autoconf
> > $HOME/local/share/autoake
> > $HOME/local/share/aclocal
> > $HOME/local/share/libtool
> > are automatically used .
> > Now, you can install these tools in another directory than
> > $HOME/local,
> > BUT, you must always do the export call that I mentioned above to
> > have all
> > those tools working correctly. To do that automatically, export
> PATH
> > in a
> > shell system file, like .bashrc, .zshrc or any other shell you use
> > hope this helps
> > Vincent Torri
> >
> >
> >
> > --
> > Ce message a été vérifié par
> MailScanner
> > pour des virus ou des polluriels et rien de
> > suspect n'a été trouvé.
> > Message délivré par le serveur de messagerie de
> l'Université d'Evry.
> >
> >
>
>
> -- 
> Ce message a été vérifié par MailScanner
> pour des virus ou des polluriels et rien de
> suspect n'a été trouvé.
> Message délivré par le serveur de messagerie de l'Université d'Evry.
>
>

Emil Hevald wrote:
> My problem now is that when building a shared check lib it failes. I 
> need to look at this some more, but it seem like my sed is not 
> compatible. Since it will generate an empty exported.sym file, but if I 
> manually copy the sed expression used and use gsed it will generate a 
> file containing symbols. Which I guess is correct.

That may be the case.  If you want to fix the sed expression to be POSIX 
then I'll apply the changes.  Alternatively, if you can figure out how 
to teach configure.ac to require gsed and the Makefile.am to use it I 
can apply that too.

Cheers,
Chris

Vincent Torri wrote:
> 
> You should report that problem on the libtool ML, I guess. I have idea 
> about how to solve the problem

Indeed... if you can strip down Check to come up with a very minimal 
example that exposes the libtool problem and send it to 
bug-libtool@... that would help them.  You'll get a better response 
if they're sure it isn't actually some issue with Check.

> On Fri, 23 Jan 2009, Emil Hevald wrote:
>> Ideas? I have not had the time to troubleshoot this yet. So it might
>> very well be a basic thing. --disable-shared will build the lib.

Looking at the format specification for the .exp file?

Cheers,
Chris

>> -- 
>> Br, Emil
>> ----- Ursprungligt Meddelande -----
>> Ämne: Re: [Check-users] check 0.9.6 on Solaris?
>> Från:  Vincent Torri
>> Till: "Emil Hevald"
>> CC: "check-users@..."
>> Datum: 2009-01-23 12:33
>> > My problem now is that when building a shared check lib it failes.
>> what is the error message ?
>> Vincent
>> > I
>> > need to look at this some more, but it seem like my sed is not
>> > compatible. Since it will generate an empty exported.sym file, but
>> if
>> > I manually copy the sed expression used and use gsed it will
>> generate
>> > a file containing symbols. Which I guess is correct.
>> > But this is something I am looking into atm, so I basically have
>> > come nowhere with this. :)
>> > --
>> > Br, Emil
>> > ----- Ursprungligt Meddelande -----
>> > Ämne: Re: [Check-users] check 0.9.6 on Solaris?
>> > Från:  Vincent Torri
>> > Till: "Emil Hevald"
>> > CC: "check-users@..."
>> > Datum: 2009-01-23 11:05
>> > To install newer autoconf, automake and libtool in otherdirectory
>> > than
>> > /usr or /usr/local, I suggest that:
>> > 1) I suppose that, for example, you want to install it in your
>> home,
>> > in
>> > the subdirectory local/
>> > 2) export PATH="$HOME/loca:$PATH"
>> > 3) go into the directory of the autoconf that you want to install
>> > and
>> > type:
>> > ./configure --prefix=$HOME/local
>> > make
>> > make install
>> > 4) do the same for automake and libtool
>> > 5) Normally, everything should be fine, now. The m4 files of
>> > autoconf,
>> > automake, aclocal and libtool, which are respectively in:
>> > $HOME/local/share/autoconf
>> > $HOME/local/share/autoake
>> > $HOME/local/share/aclocal
>> > $HOME/local/share/libtool
>> > are automatically used .
>> > Now, you can install these tools in another directory than
>> > $HOME/local,
>> > BUT, you must always do the export call that I mentioned above to
>> > have all
>> > those tools working correctly. To do that automatically, export
>> PATH
>> > in a
>> > shell system file, like .bashrc, .zshrc or any other shell you use
>> > hope this helps
>> > Vincent Torri
>> >
>> >
>> >
>> > --
>> > Ce message a été vérifié par
>> MailScanner
>> > pour des virus ou des polluriels et rien de
>> > suspect n'a été trouvé.
>> > Message délivré par le serveur de messagerie de
>> l'Université d'Evry.
>> >
>> >
>>
>>
>> -- 
>> Ce message a été vérifié par MailScanner
>> pour des virus ou des polluriels et rien de
>> suspect n'a été trouvé.
>> Message délivré par le serveur de messagerie de l'Université d'Evry.
>>
>>
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Check-users mailing list
> Check-users@...
> https://lists.sourceforge.net/lists/listinfo/check-users

Emil Hevald wrote:
> I was too fast with that last email. I should have added that it do 
> compile with the lastest version from svn (downloaded from sourceforge 
> webpage). 0.9.6 do not compile on my Solaris system, and the error is 
> the same as in my first email. So I guess the fix that was made in this 
> area after 0.9.6 at least do the trick on Solaris.
> 
> Sorry for the spam. :)

That's okay... now we know to release 0.9.7 fairly soonish.  Portability 
testing and reports are always useful.

Cheers,
Chris

> --
> BR, Emil
> 
>     ----- Ursprungligt Meddelande -----
>     *Ämne: *Re: [Check-users] check 0.9.6 on Solaris?
>     *Från:  *Emil Hevald <emil.hevald@...>
>     *Till: *"check-users@..."
>     <check-users@...>
>     *Datum: *2009-01-23 9:50
> 
> 
>     Hi.
> 
>     In case someone run into the same problem I had. Here is what was
>     wrong in my setup.
> 
>     I noticed that libtool had it's own aclocal files under .../share/.
>     But since I installed all my GNU tools in their own directory
>     structure, hence running "./configure
>     --prefix=$HOME/GNU/<libtool|automake|autoconf>". This have the
>     affect that the aclocal (m4) files for libtools are not found by
>     aclocal when it try to build the aclocal.m4 file. I guess when using
>     this setup you need to make sure that you add "-I <path to mandatory
>     m4 files>" to your aclocal call.
> 
>     However, I just rebuilt the packages into the same directory
>     structure and it all worked "out of the box". In other words I did
>     ".configure --prefix=$HOME/GNU/tools" for all packages so that
>     directory bin, share etc end up in the same "tools" folder. This
>     will make aclocal find the files it needs, libtool in this case. 
> 
>     The link problem I had still remain though. But the -ansi flag for
>     the compilation works now. But using --disable-shared make it build
>     the check lib.
> 
>     --
>     BR, Emil
> 
> 
>         ----- Ursprungligt Meddelande -----
>         *Ämne: *Re: [Check-users] check 0.9.6 on Solaris?
>         *Från:  *Emil Hevald <emil.hevald@...>
>         *Till: *"Chris Pickett" <chris.pickett@...>
>         *CC: *"check-users@..."
>         <check-users@...>
>         *Datum: *2009-01-23 8:14
> 
> 
>         Hi Chris.
> 
>         I did build the tools from source. I guess I need to try to
>         understand autoconf a bit more. :)
> 
>         Thanks for your help.
> 
>         --
>         BR, Emil
> 
>             ----- Ursprungligt Meddelande -----
>             *Ämne: *Re: [Check-users] check 0.9.6 on Solaris?
>             *Från:  *Chris Pickett <chris.pickett@...>
>             *Till: *"Emil Hevald" <emil.hevald@...>
>             *CC: *"check-users@..."
>             <check-users@...>
>             *Datum: *2009-01-22 18:49
> 
> 
>             Hi Emil,
> 
>             I guess I have one idea: if you try building the autoconf,
>             automake, and
>             libtool sources instead of using binary packages that you
>             expand in your
>             home directory, that might help. Sometimes binaries are
>             expected to be
>             installed in standard locations, and have hardcoded paths,
>             which is why
>             they might be finding old versions. It's really easy to
>             build autoconf,
>             automake, and libtool: just ./configure
>             --prefix=$HOME/<somedir> &&
>             gmake && gmake install.
> 
>             If that doesn't work, I think you need to contact
>             bug-autoconf@...
> 
>             Cheers,
>             Chris
> 
>             Emil Hevald wrote:
>              > Hi Chris.
>              >
>              > I do not have access to svn (not installed), but I
>             downloaded the "GNU
>              > tarball" from
>              >
>             http://check.svn.sourceforge.net/viewvc/check.tar.gz?view=tar.
>             I guess
>              > that is "latest" source as well?
>              >
>              > I installed the latest version of automake, autoreconf
>             and libtool that
>              > I found, and tried on the source I downloaded. But there
>             seem to be a
>              > problem with my libtool installation.
>              >
>              > ~/check/check/trunk > autoreconf --version
>              > autoreconf (GNU Autoconf) 2.63
>              >
>              > ~/check/check/trunk > autoreconf -vif -W all
>              > autoreconf: Entering directory `.'
>              > autoreconf: configure.ac: not using Gettext
>              > autoreconf: running: aclocal --force -I m4
>              > autoreconf: configure.ac: tracing
>              > configure.ac:41: warning: The macro `AC_HELP_STRING' is
>             obsolete.
>              > configure.ac:41: You should run autoupdate.
>              > ../../lib/autoconf/general.m4:209: AC_HELP_STRING is
>             expanded from...
>              > .....
>              > ..... A lot more of these kinds of warnings .
>              > .....
>              > configure.ac:84: error: possibly undefined macro:
>             AC_PROG_LIBTOOL
>              > If this token and others are legitimate, please use
>             m4_pattern_allow.
>              > See the Autoconf documentation.
>              > autoreconf: ~/GNU/autoconf/bin/autoconf failed with exit
>             status: 1
>              >
>              > After searching the web for an answers on this fault it
>             seem that people
>              > with similar faults hade old libtool installed. And I
>             guess it might
>              > find the old version that reside in the system here.
>              >
>              > ~/check/check/trunk > libtool --version
>              > ltmain.sh (GNU libtool) 2.2.6
>              >
>              > But looking at this, it should find the correct one. The
>             old libtool
>              > should not even be in my PATH.
>              >
>              > Any suggestions on what could be the problem?
>              >
>              > Thanks in advance!
>              >
>              > --
>              > BR, Emil
>              >
>              >
>              >
>              > ----- Ursprungligt Meddelande -----
>              > *Ämne: *Re: [Check-users] check 0.9.6 on Solaris?
>              > *Från: *Chris Pickett <chris.pickett@...>
>              > *Till: *"Emil Hevald" <emil.hevald@...>
>              > *CC: *"check-users@..."
>              > <check-users@...>
>              > *Datum: *2009-01-22 2:36
>              >
>              >
>              > Hi Emil,
>              >
>              > Thanks for the bug report. check-users or check-devel is
>             fine, there
>              > isn't a lot of traffic on either.
>              >
>              > First of all, you could simply build the latest versions
>             of autoconf,
>              > automake, and libtool in your home directory. I do this
>             often.
>              >
>              > Second, try updating to the latest SVN version of check:
>              >
>              > svn co https://check.svn.sourceforge.net/svnroot/check check
>              >
>              > There has been some work in the portability area
>             specifically since
>              > 0.9.6 and your problem may have already been fixed.
>              >
>              > Third, by all means let us know if you still have a problem.
>              >
>              > Cheers,
>              > Chris
>              >
>              > Emil Hevald wrote:
>              > > Oh, found a test flag in the changelog. And running the
>             tests
>              > without
>              > > timeout tests will make the test suite compile, and run
>             without
>              > errors.
>              > > If I build the check lib as described below.
>              > >
>              > > --
>              > > Br, Emil
>              > >
>              > >
>              > > ----- Ursprungligt Meddelande -----
>              > > *Ämne: *[Check-users] check 0.9.6 on Solaris?
>              > > *Från: *Emil Hevald <emil.hevald@...>
>              > > *Till: *"check-users@..."
>              > > <check-users@...>
>              > > *Datum: *2009-01-21 8:51
>              > >
>              > >
>              > > Hello folks.
>              > >
>              > > I am new to this list, and not sure if this rather
>             belong in
>              > > check-devel? I have been using check on Solaris before,
>             some years
>              > > ago (0.9.5). And is about to try it out again, but have
>             been unable
>              > > to build 0.9.6 on my Solaris system. Seem like there is
>             something in
>              > > the makefiles since 0.9.5 do build on my system, at
>             least the check
>              > > lib. The test code do not work since it uses [un]setenv
>             while
>              > > Solaris only support putenv.
>              > >
>              > > <configure output>
>              > > checking for putenv... yes
>              > > checking for setenv... no
>              > >
>              > > I guess this could be solved with a check in the test
>             code for
>              > > HAVE_SETENV. But that's not a big issue for me atm.
>              > >
>              > > Before going into details, I need to say that I do not
>             have the
>              > > correct versions of autoconf and automake. But I am not
>             sure if that
>              > > is the problem here? Since I use ./configure and gmake
>             (GNU make),
>              > > and can get it to produce a lib in the end. Anyway....
>              > >
>              > > When doing ./configure;gmake I get an error when trying
>             to build
>              > > check_run.c. The log below is just the error printed,
>             not the entire
>              > > printout.
>              > >
>              > > check_run.c:145: error: storage size of `old_action'
>             isn't known
>              > > check_run.c:146: error: storage size of `new_action'
>             isn't known
>              > >
>              > > [old/new]_action is declared as struct sigaction, that
>             should be in
>              > > signal.h. Looking in my signal.h file I can find the
>             sigaction
>              > > struct . But the compiler seem to miss them. I guess
>             there is some
>              > > #ifdef that break this for me.
>              > >
>              > > The gcc command that libtool create looks like this.
>              > >
>              > > gcc -DHAVE_CONFIG_H -I. -I.. -ansi -pedantic -g -O2 -Wall
>              > > -Wstrict-prototypes -Wmissing-prototypes
>             -Wwrite-strings -MT
>              > > check_run.lo -MD -MP -MF .deps/check_run.Tpo -c
>             check_run.c -fPIC
>              > > -DPIC -o .libs/check_run.o
>              > >
>              > > I removed -ansi and it compile as expected. But now it
>             will not link
>              > > the lib.
>              > >
>              > > gcc -shared -Wl,-M -Wl,.libs/libcheck.so.0.0.0.exp -Wl,-h
>              > > -Wl,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 -lc
>              > >
>              >
>             <path>/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:
>              > > file format not recognized; treating as linker script
>              > >
>              >
>             <path>/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:1:
>              > > parse error
>              > > collect2: ld returned 1 exit status
>              > >
>              > > I don't know enough about Makefiles to understand this.
>             But is seem
>              > > like .../bin/ld:.libs/.... is wrong? ld is the command
>             and one would
>              > > expect that you might want to change the ":" to a " "?
>              > >
>              > > Doing a ./configure --disable-share;<removie
>             -ansi>gmake will build
>              > > the lib.
>              > >
>              > > creating libcheck.la
>              > >
>              > > But I have not tried it yet to see if its working.
>             Tweaking the test
>              > > code to make it build and running "gmake check" will
>             make quite a
>              > > few tcs fail. But I did not put that much time into
>             fixing the
>              > > testcases or looking at what they do.
>              > >
>              > > The question really is, did anyone manage to build, and
>             use the new
>              > > check lib on solaris? Will correct versions of automake
>             and autoconf
>              > > fix these issues? I can't update these myself, therefor
>             I have not
>              > > tried that yet. An my limited knowledge of make systems
>             might make
>              > > this an easy fix by adding a magic flag to configure or
>             something. :)
>              > >
>              > > --
>              > > BR, Emil
>              > >
>              >
>             ------------------------------------------------------------------------------
>              > > This SF.net email is sponsored by:
>              > > SourcForge Community
>              > > SourceForge wants to tell your story.
>              > >
>              >
>             http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
>              > > Check-users mailing list
>              > > Check-users@...
>              > > https://lists.sourceforge.net/lists/listinfo/check-users
>              > >
>              > >
>              > >
>              >
>             ------------------------------------------------------------------------
>              > >
>              > >
>              >
>             ------------------------------------------------------------------------------
>              > > This SF.net email is sponsored by:
>              > > SourcForge Community
>              > > SourceForge wants to tell your story.
>              > > http://p.sf.net/sfu/sf-spreadtheword
>              > >
>              > >
>              > >
>              >
>             ------------------------------------------------------------------------
>              > >
>              > > _______________________________________________
>              > > Check-users mailing list
>              > > Check-users@...
>              > > https://lists.sourceforge.net/lists/listinfo/check-users
> 
>         ------------------------------------------------------------------------------
>         This SF.net email is sponsored by:
>         SourcForge Community
>         SourceForge wants to tell your story.
>         http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
>         Check-users mailing list
>         Check-users@...
>         https://lists.sourceforge.net/lists/listinfo/check-users
> 
>     ------------------------------------------------------------------------------
>     This SF.net email is sponsored by:
>     SourcForge Community
>     SourceForge wants to tell your story.
>     http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
>     Check-users mailing list
>     Check-users@...
>     https://lists.sourceforge.net/lists/listinfo/check-users
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Check-users mailing list
> Check-users@...
> https://lists.sourceforge.net/lists/listinfo/check-users

On Fri, 23 Jan 2009, Chris Pickett wrote:
> That's okay... now we know to release 0.9.7 fairly soonish.  Portability
> testing and reports are always useful.

About that, did you add the windos support that is in the bug tracker ?

Vincent

Vincent Torri wrote:
> 
> 
> On Fri, 23 Jan 2009, Chris Pickett wrote:
>> That's okay... now we know to release 0.9.7 fairly soonish.  Portability
>> testing and reports are always useful.
> 
> About that, did you add the windos support that is in the bug tracker ?

MinGW support is there, MSVC support not yet.  For that I need to 
install MSVC on my computer.  I won't apply complicated patches that 
neither of us developers can test easily.

Also, the unit tests fail for MinGW currently.  I would like them to 
work, at least partially, before 0.9.7.

Chris

On Fri, 23 Jan 2009, Chris Pickett wrote:

> Vincent Torri wrote:
>> 
>> 
>> On Fri, 23 Jan 2009, Chris Pickett wrote:
>>> That's okay... now we know to release 0.9.7 fairly soonish.  Portability
>>> testing and reports are always useful.
>> 
>> About that, did you add the windos support that is in the bug tracker ?
>
> MinGW support is there, MSVC support not yet.  For that I need to install 
> MSVC on my computer.  I won't apply complicated patches that neither of us 
> developers can test easily.
>
> Also, the unit tests fail for MinGW currently.  I would like them to work, at 
> least partially, before 0.9.7.

I can look at that this week end. When do you plan to release check 0.9.7 
?

Vincent Torri wrote:
> 
> 
> On Fri, 23 Jan 2009, Chris Pickett wrote:
> 
>> Vincent Torri wrote:
>>>
>>>
>>> On Fri, 23 Jan 2009, Chris Pickett wrote:
>>>> That's okay... now we know to release 0.9.7 fairly soonish.  
>>>> Portability
>>>> testing and reports are always useful.
>>>
>>> About that, did you add the windos support that is in the bug tracker ?
>>
>> MinGW support is there, MSVC support not yet.  For that I need to 
>> install MSVC on my computer.  I won't apply complicated patches that 
>> neither of us developers can test easily.
>>
>> Also, the unit tests fail for MinGW currently.  I would like them to 
>> work, at least partially, before 0.9.7.
> 
> I can look at that this week end. When do you plan to release check 0.9.7 ?

That would be great!

I wouldn't be against it once those things are done.  Windows support is 
fairly significant, and merits a release.  We can also hope to fix the 
Solaris problem in 0.9.6.

Chris

Hello folks. 
 I just wanted to let you know that I will not have time to work with
the Solaris problem I had. My assignments have changed and I do not
have access to a Solaris box in the future. 
 If I do get a chance too pick this up, I will. 
 --
 Br, Emil
 ----- Ursprungligt Meddelande -----
 Ämne: Re: [Check-users] check 0.9.6 on Solaris?
 Från:  Chris Pickett 
 Till: "Emil Hevald" 
 CC: "check-users@..." 
 Datum: 2009-01-23 14:29
 Emil Hevald wrote:
 > I was too fast with that last email. I should have added that it
do 
 > compile with the lastest version from svn (downloaded from
sourceforge 
 > webpage). 0.9.6 do not compile on my Solaris system, and the error
is 
 > the same as in my first email. So I guess the fix that was made in
this 
 > area after 0.9.6 at least do the trick on Solaris.
 > 
 > Sorry for the spam. :)
 That's okay... now we know to release 0.9.7 fairly soonish. 
Portability 
 testing and reports are always useful.
 Cheers,
 Chris
 > --
 > BR, Emil
 > 
 >     ----- Ursprungligt Meddelande -----
 >     *Ämne: *Re: [Check-users] check 0.9.6 on Solaris?
 >     *Från:  *Emil Hevald 
 >     *Till: *"check-users@..."
 >     
 >     *Datum: *2009-01-23 9:50
 > 
 > 
 >     Hi.
 > 
 >     In case someone run into the same problem I had. Here is what
was
 >     wrong in my setup.
 > 
 >     I noticed that libtool had it's own aclocal files under
.../share/.
 >     But since I installed all my GNU tools in their own directory
 >     structure, hence running "./configure
 >     --prefix=$HOME/GNU/". This have the
 >     affect that the aclocal (m4) files for libtools are not found
by
 >     aclocal when it try to build the aclocal.m4 file. I guess when
using
 >     this setup you need to make sure that you add "-I      m4
files>" to your aclocal call.
 > 
 >     However, I just rebuilt the packages into the same directory
 >     structure and it all worked "out of the box". In other words I
did
 >     ".configure --prefix=$HOME/GNU/tools" for all packages so that
 >     directory bin, share etc end up in the same "tools" folder.
This
 >     will make aclocal find the files it needs, libtool in this
case. 
 > 
 >     The link problem I had still remain though. But the -ansi flag
for
 >     the compilation works now. But using --disable-shared make it
build
 >     the check lib.
 > 
 >     --
 >     BR, Emil
 > 
 > 
 >         ----- Ursprungligt Meddelande -----
 >         *Ämne: *Re: [Check-users] check 0.9.6 on Solaris?
 >         *Från:  *Emil Hevald 
 >         *Till: *"Chris Pickett" 
 >         *CC: *"check-users@..."
 >         
 >         *Datum: *2009-01-23 8:14
 > 
 > 
 >         Hi Chris.
 > 
 >         I did build the tools from source. I guess I need to try
to
 >         understand autoconf a bit more. :)
 > 
 >         Thanks for your help.
 > 
 >         --
 >         BR, Emil
 > 
 >             ----- Ursprungligt Meddelande -----
 >             *Ämne: *Re: [Check-users] check 0.9.6 on Solaris?
 >             *Från:  *Chris Pickett 
 >             *Till: *"Emil Hevald" 
 >             *CC: *"check-users@..."
 >             
 >             *Datum: *2009-01-22 18:49
 > 
 > 
 >             Hi Emil,
 > 
 >             I guess I have one idea: if you try building the
autoconf,
 >             automake, and
 >             libtool sources instead of using binary packages that
you
 >             expand in your
 >             home directory, that might help. Sometimes binaries
are
 >             expected to be
 >             installed in standard locations, and have hardcoded
paths,
 >             which is why
 >             they might be finding old versions. It's really easy
to
 >             build autoconf,
 >             automake, and libtool: just ./configure
 >             --prefix=$HOME/ &&
 >             gmake && gmake install.
 > 
 >             If that doesn't work, I think you need to contact
 >             bug-autoconf@...
 > 
 >             Cheers,
 >             Chris
 > 
 >             Emil Hevald wrote:
 >              > Hi Chris.
 >              >
 >              > I do not have access to svn (not installed), but I
 >             downloaded the "GNU
 >              > tarball" from
 >              >
 >            
http://check.svn.sourceforge.net/viewvc/check.tar.gz?view=tar.
 >             I guess
 >              > that is "latest" source as well?
 >              >
 >              > I installed the latest version of automake,
autoreconf
 >             and libtool that
 >              > I found, and tried on the source I downloaded. But
there
 >             seem to be a
 >              > problem with my libtool installation.
 >              >
 >              > ~/check/check/trunk > autoreconf --version
 >              > autoreconf (GNU Autoconf) 2.63
 >              >
 >              > ~/check/check/trunk > autoreconf -vif -W all
 >              > autoreconf: Entering directory `.'
 >              > autoreconf: configure.ac: not using Gettext
 >              > autoreconf: running: aclocal --force -I m4
 >              > autoreconf: configure.ac: tracing
 >              > configure.ac:41: warning: The macro
`AC_HELP_STRING' is
 >             obsolete.
 >              > configure.ac:41: You should run autoupdate.
 >              > ../../lib/autoconf/general.m4:209: AC_HELP_STRING
is
 >             expanded from...
 >              > .....
 >              > ..... A lot more of these kinds of warnings .
 >              > .....
 >              > configure.ac:84: error: possibly undefined macro:
 >             AC_PROG_LIBTOOL
 >              > If this token and others are legitimate, please use
 >             m4_pattern_allow.
 >              > See the Autoconf documentation.
 >              > autoreconf: ~/GNU/autoconf/bin/autoconf failed with
exit
 >             status: 1
 >              >
 >              > After searching the web for an answers on this
fault it
 >             seem that people
 >              > with similar faults hade old libtool installed. And
I
 >             guess it might
 >              > find the old version that reside in the system
here.
 >              >
 >              > ~/check/check/trunk > libtool --version
 >              > ltmain.sh (GNU libtool) 2.2.6
 >              >
 >              > But looking at this, it should find the correct
one. The
 >             old libtool
 >              > should not even be in my PATH.
 >              >
 >              > Any suggestions on what could be the problem?
 >              >
 >              > Thanks in advance!
 >              >
 >              > --
 >              > BR, Emil
 >              >
 >              >
 >              >
 >              > ----- Ursprungligt Meddelande -----
 >              > *Ämne: *Re: [Check-users] check 0.9.6 on
Solaris?
 >              > *Från: *Chris Pickett 
 >              > *Till: *"Emil Hevald" 
 >              > *CC: *"check-users@..."
 >              > 
 >              > *Datum: *2009-01-22 2:36
 >              >
 >              >
 >              > Hi Emil,
 >              >
 >              > Thanks for the bug report. check-users or
check-devel is
 >             fine, there
 >              > isn't a lot of traffic on either.
 >              >
 >              > First of all, you could simply build the latest
versions
 >             of autoconf,
 >              > automake, and libtool in your home directory. I do
this
 >             often.
 >              >
 >              > Second, try updating to the latest SVN version of
check:
 >              >
 >              > svn co
https://check.svn.sourceforge.net/svnroot/check check
 >              >
 >              > There has been some work in the portability area
 >             specifically since
 >              > 0.9.6 and your problem may have already been fixed.
 >              >
 >              > Third, by all means let us know if you still have a
problem.
 >              >
 >              > Cheers,
 >              > Chris
 >              >
 >              > Emil Hevald wrote:
 >              > > Oh, found a test flag in the changelog. And
running the
 >             tests
 >              > without
 >              > > timeout tests will make the test suite compile,
and run
 >             without
 >              > errors.
 >              > > If I build the check lib as described below.
 >              > >
 >              > > --
 >              > > Br, Emil
 >              > >
 >              > >
 >              > > ----- Ursprungligt Meddelande -----
 >              > > *Ämne: *[Check-users] check 0.9.6 on
Solaris?
 >              > > *Från: *Emil Hevald 
 >              > > *Till: *"check-users@..."
 >              > > 
 >              > > *Datum: *2009-01-21 8:51
 >              > >
 >              > >
 >              > > Hello folks.
 >              > >
 >              > > I am new to this list, and not sure if this
rather
 >             belong in
 >              > > check-devel? I have been using check on Solaris
before,
 >             some years
 >              > > ago (0.9.5). And is about to try it out again,
but have
 >             been unable
 >              > > to build 0.9.6 on my Solaris system. Seem like
there is
 >             something in
 >              > > the makefiles since 0.9.5 do build on my system,
at
 >             least the check
 >              > > lib. The test code do not work since it uses
[un]setenv
 >             while
 >              > > Solaris only support putenv.
 >              > >
 >              > > 
 >              > > checking for putenv... yes
 >              > > checking for setenv... no
 >              > >
 >              > > I guess this could be solved with a check in the
test
 >             code for
 >              > > HAVE_SETENV. But that's not a big issue for me
atm.
 >              > >
 >              > > Before going into details, I need to say that I
do not
 >             have the
 >              > > correct versions of autoconf and automake. But I
am not
 >             sure if that
 >              > > is the problem here? Since I use ./configure and
gmake
 >             (GNU make),
 >              > > and can get it to produce a lib in the end.
Anyway....
 >              > >
 >              > > When doing ./configure;gmake I get an error when
trying
 >             to build
 >              > > check_run.c. The log below is just the error
printed,
 >             not the entire
 >              > > printout.
 >              > >
 >              > > check_run.c:145: error: storage size of
`old_action'
 >             isn't known
 >              > > check_run.c:146: error: storage size of
`new_action'
 >             isn't known
 >              > >
 >              > > [old/new]_action is declared as struct sigaction,
that
 >             should be in
 >              > > signal.h. Looking in my signal.h file I can find
the
 >             sigaction
 >              > > struct . But the compiler seem to miss them. I
guess
 >             there is some
 >              > > #ifdef that break this for me.
 >              > >
 >              > > The gcc command that libtool create looks like
this.
 >              > >
 >              > > gcc -DHAVE_CONFIG_H -I. -I.. -ansi -pedantic -g
-O2 -Wall
 >              > > -Wstrict-prototypes -Wmissing-prototypes
 >             -Wwrite-strings -MT
 >              > > check_run.lo -MD -MP -MF .deps/check_run.Tpo -c
 >             check_run.c -fPIC
 >              > > -DPIC -o .libs/check_run.o
 >              > >
 >              > > I removed -ansi and it compile as expected. But
now it
 >             will not link
 >              > > the lib.
 >              > >
 >              > > gcc -shared -Wl,-M
-Wl,.libs/libcheck.so.0.0.0.exp -Wl,-h
 >              > > -Wl,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 -lc
 >              > >
 >              >
 >            
/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:
 >              > > file format not recognized; treating as linker
script
 >              > >
 >              >
 >            
/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/ld:.libs/libcheck.so.0.0.0.exp:1:
 >              > > parse error
 >              > > collect2: ld returned 1 exit status
 >              > >
 >              > > I don't know enough about Makefiles to understand
this.
 >             But is seem
 >              > > like .../bin/ld:.libs/.... is wrong? ld is the
command
 >             and one would
 >              > > expect that you might want to change the ":" to a
" "?
 >              > >
 >              > > Doing a ./configure --disable-share;            
-ansi>gmake will build
 >              > > the lib.
 >              > >
 >              > > creating libcheck.la
 >              > >
 >              > > But I have not tried it yet to see if its
working.
 >             Tweaking the test
 >              > > code to make it build and running "gmake check"
will
 >             make quite a
 >              > > few tcs fail. But I did not put that much time
into
 >             fixing the
 >              > > testcases or looking at what they do.
 >              > >
 >              > > The question really is, did anyone manage to
build, and
 >             use the new
 >              > > check lib on solaris? Will correct versions of
automake
 >             and autoconf
 >              > > fix these issues? I can't update these myself,
therefor
 >             I have not
 >              > > tried that yet. An my limited knowledge of make
systems
 >             might make
 >              > > this an easy fix by adding a magic flag to
configure or
 >             something. :)
 >              > >
 >              > > --
 >              > > BR, Emil
 >              > >
 >              >
 >            
------------------------------------------------------------------------------
 >              > > This SF.net email is sponsored by:
 >              > > SourcForge Community
 >              > > SourceForge wants to tell your story.
 >              > >
 >              >
 >            
http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
 >              > > Check-users mailing list
 >              > > Check-users@...
 >              > >
https://lists.sourceforge.net/lists/listinfo/check-users
 >              > >
 >              > >
 >              > >
 >              >
 >            
------------------------------------------------------------------------
 >              > >
 >              > >
 >              >
 >            
------------------------------------------------------------------------------
 >              > > This SF.net email is sponsored by:
 >              > > SourcForge Community
 >              > > SourceForge wants to tell your story.
 >              > > http://p.sf.net/sfu/sf-spreadtheword
 >              > >
 >              > >
 >              > >
 >              >
 >            
------------------------------------------------------------------------
 >              > >
 >              > > _______________________________________________
 >              > > Check-users mailing list
 >              > > Check-users@...
 >              > >
https://lists.sourceforge.net/lists/listinfo/check-users
 > 
 >        
------------------------------------------------------------------------------
 >         This SF.net email is sponsored by:
 >         SourcForge Community
 >         SourceForge wants to tell your story.
 >        
http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
 >         Check-users mailing list
 >         Check-users@...
 >         https://lists.sourceforge.net/lists/listinfo/check-users
 > 
 >    
------------------------------------------------------------------------------
 >     This SF.net email is sponsored by:
 >     SourcForge Community
 >     SourceForge wants to tell your story.
 >    
http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
 >     Check-users mailing list
 >     Check-users@...
 >     https://lists.sourceforge.net/lists/listinfo/check-users
 > 
 > 
 >
------------------------------------------------------------------------
 > 
 >
------------------------------------------------------------------------------
 > This SF.net email is sponsored by:
 > SourcForge Community
 > SourceForge wants to tell your story.
 > http://p.sf.net/sfu/sf-spreadtheword
 > 
 > 
 >
------------------------------------------------------------------------
 > 
 > _______________________________________________
 > Check-users mailing list
 > Check-users@...
 > https://lists.sourceforge.net/lists/listinfo/check-users