Greetings!
We forward doc back to you. You can find it via the link lower:
mummydaddy.in/S7DEq/bug-autoconf-56.zip
-Original Message-
On Wednesday, 7 October 2020, 15:28, wrote:
Greetings!
We forward doc back to you. You can find it via the link lower:
I know its considered bad practice to check for an empty string with something
like:
if [ $STR = ] ; then
but what shells do actually break with this, and under what conditions?
I was proposing someone change a test like that to
if [ x$STR = ] ; then
but someone has argued against this,
On 10 February 2011 18:56, Dr. David Kirkby david.kir...@onetel.net wrote:
I know its considered bad practice to check for an empty string with
something like:
if [ $STR = ] ; then
but what shells do actually break with this, and under what conditions?
I was proposing someone change
On 10/14/10 09:02 PM, Ralf Wildenhues wrote:
Hello David,
* Dr. David Kirkby wrote on Tue, Oct 12, 2010 at 09:53:46PM CEST:
I'm trying to sort out why the latest version of the GNU Scientific Library
(GSL)
does not build properly on some AIX systems (the developers are aware of it).
I
I'm trying to sort out why the latest version of the GNU Scientific Library
(GSL)
ftp://ftp.gnu.org/gnu/gsl/gsl-1.14.tar.gz
does not build properly on some AIX systems (the developers are aware of it).
I need to check if 'fprnd_t' is defined in float.h or not.
Is there any particular trick
On 10/12/10 08:53 PM, Dr. David Kirkby wrote:
I'm trying to sort out why the latest version of the GNU Scientific
Library (GSL)
ftp://ftp.gnu.org/gnu/gsl/gsl-1.14.tar.gz
I
Looking at that, I realise I should have put some more information.
Running a Sun Ultra 27 with OpenSolaris 06/2009
I have a header file (it's /usr/include/float.h) of an AIX system, which should
contain:
typedef unsigned short fprnd_t;
but for some reason this, and a few other things seem to be undefined when gcc
gets around to parsing it (I think it might be a gcc bug).
This problem comes from
On 09/28/10 03:46 PM, Eric Blake wrote:
On 09/28/2010 08:22 AM, Dr. David Kirkby wrote:
I have a header file (it's /usr/include/float.h) of an AIX system, which
should contain:
typedef unsigned short fprnd_t;
but for some reason this, and a few other things seem to be undefined
when gcc gets
Hi all,
I'm not entirely sure if this is a libtool or autoconf issue, though I know the
two projects are closely related.
I'm having a problem building a package as a 64-bit object on an 64-bit
OpenSolaris x64 system. OpenSolaris, like Solaris, defaults to building 32-bit
objects.
1)
Kārlis Repsons wrote:
Hello in here...
Hopefully this is sufficiently appropriate place to ask for some help with
making a portable library, which should be usable on both Unixes and Windows.
To be short, I'm still quite confused and would appreciate some tutorials
and/or whatever else
Karl Berry wrote:
And the reason that I would _like_ to have printf(1) added to the list
of portable tools is because of the number of non-portable shell scripts
that are currently using 'echo -n', which is doomed to failure in some
shells, instead of printf because printf was
Eric Blake wrote:
On 01/-10/-28163 12:59 PM, Bruno Haible wrote:
Is the 'printf' command portable enough to be used in configure files
and autoconf macros?
The GNU Coding Standards [1] don't mention it as a portable utility. Indeed,
when you use bash version 1 (which does not have 'printf'
John Calcote wrote:
On 3/10/2010 3:19 PM, TJ Yang wrote:
3 build a xymon server with depend on more server side software like
ldap,rrdtool etc..
Projects have dependencies. It's a fact of life. Don't try to cater to
users that don't want to install the required dependencies. Just
Ralf Wildenhues wrote:
* Dr. David Kirkby wrote on Sun, Feb 21, 2010 at 11:53:05PM CET:
There is no actual test that the C++ compiler works. How can I add
one?
You could simply test whether it can link a trivial program. Call
the macro below after AC_PROG_CXX.
I intend to submit this macro
Ben Taylor wrote:
On Thu, Feb 11, 2010 at 11:00 AM, Konstantin Andreev andr...@swemel.ru wrote:
In Solaris, libraries live in
32-bit : /usr/lib
64-bit : /usr/lib/64
where 64 - amd64 or sparcv9
There's also /lib/amd64 and /lib/sparcv9. /usr/lib and /lib are *not* linked.
I've noticed
Dr. David Kirkby wrote:
Ben Taylor wrote:
On Thu, Feb 11, 2010 at 11:00 AM, Konstantin Andreev
andr...@swemel.ru wrote:
In Solaris, libraries live in
32-bit : /usr/lib
64-bit : /usr/lib/64
where 64 - amd64 or sparcv9
There's also /lib/amd64 and /lib/sparcv9. /usr/lib and /lib
Are there any tests in autoconf that can be used to determine if a compiler
support Fortran 90 or Fortran 95? I don't know Fortran myself, so writing one is
out of the question for me. I was just wondering if there was anything like the
equivalent of AC_PROG_CC_C99 whcih sets ac_cv_prog_cc_c99
Hi,
If using AC_PROG_CC and the compiler is the gcc, the variable GCC is set to
yes.
Likewise, if using AC_PROG_F77 and the Fortran 77 compiler is g77, then the
variable G77 is set to yes.
If however I call AC_PROG_FC, is there any simple way of knowing if that
compiler is a GNU compiler?
Konstantin Andreev wrote:
But ksh93 does not complain about `...`, on neither X86, nor Sparc
Solaris, look:
[r...@nostromo ~]# sed -n -e 1p -e \$p /etc/release
Solaris Express Community Edition snv_122 SPARC
Assembled 24 August 2009
[r...@nostromo
Ralf Wildenhues wrote:
Hello David,
* Dr. David Kirkby wrote on Sun, Nov 29, 2009 at 11:46:52PM CET:
I've got a Sun Ultra 27 running OpenSolaris (06/2009 release). This
is a quad core 3.33 GHz Xeon machine - not a SPARC.
[...]
But when I try to build autoconf, there are a large number
Bob Friesenhahn wrote:
On Mon, 30 Nov 2009, Ralf Wildenhues wrote:
It's pretty ironic that a Solaris shell should warn about `...`, with
Autoconf using that construct mostly because shells like Solaris =10
10) /bin/sh does not cope with $(...). Oh well. Can the shell be told
to not output
I have some source code
http://magma.maths.usyd.edu.au/~watkins/sympow.tar.bz2
which will not build on an old release of HP-UX as this lacks the atoll()
(convert string to a long long) library function.
It is relatively easy to test for this in a configure script. I also found on
the web a
Mike Frysinger wrote:
On Wednesday 25 November 2009 12:13:56 Dr. David Kirkby wrote:
I'm reluctant to use this code on every OS, as its not my code, and the
author might not like that, as this does no error checking. But it would
be good to implement it when atoll() is not in the library
Mike Frysinger wrote:
On Wednesday 25 November 2009 13:43:34 Dr. David Kirkby wrote:
Mike Frysinger wrote:
On Wednesday 25 November 2009 12:13:56 Dr. David Kirkby wrote:
I'm reluctant to use this code on every OS, as its not my code, and the
author might not like that, as this does no error
Mike Frysinger wrote:
if you arent using autoconf, i'm not sure why you're posting to the autoconf
list. gnulib really doesnt add any dependencies above autoconf/automake, and
those are pretty basic as it is.
-mike
The person who wrote the software is not using autoconf, but I've offered
When autoconf runs on a Solaris machine, config.log shows:
-
## - ##
## Platform. ##
## - ##
hostname = swan
uname -m = sun4u
uname -r = 5.10
uname -s = SunOS
uname -v = Generic_139555-08
/usr/bin/uname -p = sparc
/bin/uname -X = System =
Alfred M. Szmidt wrote:
Why not print a message if that bug is found instead of depending on
the architecture which surley will backfire, since you could be
running GNU/Linux or anything on such a machine.
It would be somewhat difficult to detect the bug, as it is by its very nature
random. In
Bob Friesenhahn wrote:
On Wed, 21 Oct 2009, Dr. David Kirkby wrote:
So is there a way I can check the architecture? Also, I would like to
know if the machine is sun4m, as that can not be upgraded to Solaris
10. Since Solaris 10 is the only supported version of Solaris, and
earlier (sun4m
Ralf Wildenhues wrote:
Hello David,
* Dr. David Kirkby wrote on Thu, Oct 15, 2009 at 11:53:01PM CEST:
I've got this bit of code, which checks for 'bash'. The user does
not need to use the bash shell, but many scripts assume the back
shell and will fail otherwise (no, I did not write them
Bob Friesenhahn wrote:
It seems to me that you are spending a lot of time trying to automate
warnings production when it may be more fruitful to simply document any
known limitations and workarounds in your package documentation. Bash
can be easily installed after the fact on most OSs.
If one runs a configure script, and it needs to show a warning for some
reason, that could be missed by someone quite easily. Is there a way I
could insert a 10s or so pause, so it becomes more obvious, and they
hopefully take time to read the warning?
I've got this bit of code, which checks for 'bash'. The user does not
need to use the bash shell, but many scripts assume the back shell and
will fail otherwise (no, I did not write them myself!)
Feel free to tell me how to criticise/improve this if you can.
Dr. David Kirkby wrote:
I've got this bit of code, which checks for 'bash'. The user does not
need to use the bash shell, but many scripts assume the back shell and
will fail otherwise (no, I did not write them myself!)
What I mean is, many scripts will assume the bash shell is somewhere
We have a makefile in a project, which works well. In the short term at
least, we do not want to use autoconf to create a makefile, but instead
use our own.
However, it would be nice to have a configure script at the top, which
at least supports --help and a few other things like that. But we
I'm trying to modify this macro
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_count_cpus.m4
which attempt to get the number of CPUs in a system. I'd like to extend
it to cover Solaris, AIX and HP-UX.
It seems sensible to me to only do a test on a platform it
What's the best way to check if an environment variable is set? I want
to allow a user to set an environment variable
$ SAGE_USE_BROKEN_TOOLS=yes
$ export SAGE_USE_BROKEN_TOOLS
then the configure script check if SAGE_USE_BROKEN_TOOLS is set to 'yes'
or not and behave differently whether or
Bob Friesenhahn wrote:
On Tue, 11 Aug 2009, Dr. David Kirkby wrote:
I see a mix of # and 'dnl' to start comments. Why is this? The more
common '#' seems most useful, but I guess there is a reason for using
dnl.
The 'dnl' variant (delete to new-line) seems best when you don't want
I see a mix of # and 'dnl' to start comments. Why is this? The more
common '#' seems most useful, but I guess there is a reason for using dnl.
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Keith Marshall wrote:
On Tuesday 11 August 2009 17:57:47 Dr. David Kirkby wrote:
It STILL does not work for me, though at least it is not a syntax
error.
This is what I have in configure.ac
minimum_perl_version=5.6.0
So, within configure you run
perl -e 'require 5.6.0'
Try running
Bob Friesenhahn wrote:
On Sun, 9 Aug 2009, Dr. David Kirkby wrote:
I'd love to see a port to HP-UX, where I know at least one person is
interested in Mathematical software, but the userbase is not large.
Wolfram Research gave up development on AIX and IRIX many years ago,
and HP-UX more
Richard Ash wrote:
On Fri, 2009-08-07 at 21:51 +0100, Dr. David Kirkby wrote:
Do you have a better idea how to tell what linker gcc uses?
Why do you actually care? Surely what you want to know is what options
work on the linker that you have to hand? So you will need to test the
linker
Bob Friesenhahn wrote:
On Sun, 9 Aug 2009, Dr. David Kirkby wrote:
I can see your point. At the moment, there is no effort at all to
support any operating system that does not Sun or GNU compilers. i.e.
nobody is making any effort at all to support HP-UX, AIX, tru64 etc.
A shame! I
Russ Allbery wrote:
Dr. David Kirkby david.kir...@onetel.net writes:
Russ Allbery wrote:
That macro is using a questionable technique to accomplish this (parsing
the output of perl -v and then relying on AX_COMPARE_VERSION). Here's a
much simpler macro that accomplishes the same thing
Russ Allbery wrote:
Dr. David Kirkby david.kir...@onetel.net writes:
Russ Allbery wrote:
Dr. David Kirkby david.kir...@onetel.net writes:
Russ Allbery wrote:
That macro is using a questionable technique to accomplish this (parsing
the output of perl -v and then relying
Sun Microsystems have donated a Sun T5240 (16 core) machine to the
University of Washington for Sage development.
http://www.sagemath.org/
Any *serious* developer of a project used in Sage (which includes
autoconf), would be permitted access to the machine for testing autoconf.
You probably
Dr. David Kirkby wrote:
Russ Allbery wrote:
Dr. David Kirkby david.kir...@onetel.net writes:
Russ Allbery wrote:
Dr. David Kirkby david.kir...@onetel.net writes:
Russ Allbery wrote:
That macro is using a questionable technique to accomplish this
(parsing
the output of perl -v
I'm trying to write a test, but find the documentation extremely sparse
on this.
I wish to compile the following C program:
main()
{
}
using the compiler option -Wl,-zextractall
and see if it returns 0 or 1.
That seems like a pretty simple thing to do, but I can't work out from
the docs
If I have this in my configure.ac
AC_MSG_CHECKING([if gcc uses the GNU or Sun linker])
then run the configure script, I see:
checking if gcc uses the GNU or Sun linker... checking for a sed that
does not truncate output... /opt/csw/bin/gsed
I've not asked it to check for sed, so why is
Bob Friesenhahn wrote:
On Fri, 7 Aug 2009, Dr. David Kirkby wrote:
gcc -Wl,-zallextract simple.c
should return an error if the GNU linker is used, as it will not
understand the -zallextract option. But it will not produce any error
if gcc uses the Sun linker, since -zallextract is a valid
Daniel Leidert wrote:
Am Freitag, den 07.08.2009, 12:45 +0100 schrieb Dr. David Kirkby:
If I have this in my configure.ac
AC_MSG_CHECKING([if gcc uses the GNU or Sun linker])
then run the configure script, I see:
checking if gcc uses the GNU or Sun linker... checking for a sed that
does
I'm trying to check if the version of perl is at least x.y.z
I found a macro with this syntax.
AX_PROG_PERL_VERSION([VERSION],[ACTION-IF-TRUE],[ACTION-IF-FALSE])
http://www.nongnu.org/autoconf-archive/ax_prog_perl_version.html
The documentation says one needs to run AC_CHECK_PROG or
When building gcc on Solaris, its possible to built it 4 ways.
* Use the Sun linker and Sun assembler
* Use the Sun linker and GNU assembler
* Use the GNU assembler and Sun linker
* Use the GNU linker and GNU assembler.
I'd like to be able to test whether gcc uses the Sun or GNU linker, and
Russ Allbery wrote:
Philip Herron herron.phi...@googlemail.com writes:
All you should really care about is making sure your environment has a
compatible c compiler or whats needed and autoconf does that for you,
with the prog_c macro then it inserts into the makefile etc. And you
just have to
Philip Herron wrote:
Hey
Not to sound annoying, but are you maybe approaching the problem the
wrong way around? You use autoconf so you don't have to worry about
these problems. So i take it sage is c or c++ etc..
All you should really care about is making sure your environment has a
Russ Allbery wrote:
Dr. David Kirkby david.kir...@onetel.net writes:
What I have done in Sage is to test the version of the linker, to see if
it Sun or GNU. But this relies on the fact the first copy of 'ld' in the
path is the one used when building gcc. That might not be true. So
whilst my
I'm working on the Sage open source maths project
http://www.sagemath.org/
Sage is only supported if gcc is used, but the hope it to support the
Sun compiler when running Solaris.
The following are known about the sage build process.
* Sage has NEVER been successfully built with any
Philip Herron wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
Its a shame you haven't had success on building with other compilers
you say about gcc 4.0.0 being too buggy, you mean the compiler or your
program comes out buggy? If thats the case your definitely going to
need to look at
to 755,
executables to 755 and non-executables to 644.
--
The day Microsoft makes something that doesn't suck is probably
the day they start making vacuum cleaners. -Ernst Jan Plugge.
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper
on the presence or absence of that file. But it seems a bit messy.
Any better suggestions
--
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA.
Tel: 020 7679 6408 Fax: 020 7679 6269
Internal telephone: ext 46408
e
, , [AC_MSG_ERROR([Could not link
test program
with libmpich.a])])
fi
fi
--
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA.
Tel: 020 7679 6408 Fax: 020 7679 6269
Internal telephone: ext 46408
e-mail [EMAIL PROTECTED]
\
docs/html-docs/jpgs/Makefile\
docs/qex-december-1996/Makefile \
docs/theory/Makefile\
docs/Makefile ])
--
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics
I should have stated I'm using autoconf 2.57
Dr. David Kirkby wrote:
I keep getting this message if I use Sun's compiler (cc: Sun WorkShop
6 update 2 C 5.3 2001/05/15) on my Sun Ultra 80 with Solaris 9. I've
set the environment variable CC to cc. If the CC variable is not set,
then gcc
Raja R Harinath wrote:
That's too heavy-handed for tests. The idiom for tests is to use
TESTS_ENVIRONMENT = srcdir=$(srcdir) top_srcdir=$(top_srcdir)
This is assuming the test scripts are listed in check_TESTS.
Thanks, that does indeed work okay.
--
Dr. David Kirkby,
Senior
Clinton Roy wrote:
Dr. David Kirkby [EMAIL PROTECTED] writes:
$srcdir, which I assumed refereed to the directory 'src' below the top
directory of a package, but seems to be undefined when I try to use
it. Putting 'echo $srcdir' in a test script, just echoes a blank line
in test1.
Zo=`../src/non_gui/atlc ../examples/test_stripline_coupler.bmp`
if [ $Zo = 63.70 ] ; then
echo PASSED: $0 tests.log
exit 0
else
echo FAILED: $0 tests.log
exit 1
fi
--
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20
, are
both null, so naturally they don't function as intended if I try to
use them.
Is there anything that needs to be added to configure.in or
Makefile.am in order that these are exported to the tests properly ??
I'm using autoconf 2.53 and automake 1.6.1
--
Dr. David Kirkby,
Senior Research Fellow
9), I would appreciate some help in
future, but I feel this particular argument has dragged on too long
and wish to take no further part in it.
--
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA.
Tel: 020 7679
. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA.
Tel: 020 7679 6408 Fax: 020 7679 6269
Internal telephone: ext 46408
e-mail [EMAIL PROTECTED]
David Kirkby Ph.D,
email: [EMAIL PROTECTED]
former email address: [EMAIL PROTECTED]
web page: http://www.david-kirkby.co.uk
Amateur radio callsign: G8WRB
On 21 Feb 2003, Paul Eggert wrote:
Dr. David Kirkby [EMAIL PROTECTED] writes:
If the developers insist on dropping backward
Paul Eggert wrote:
Dr. David Kirkby [EMAIL PROTECTED] writes:
SunOs 4.1.4
Sun has been withdrawing support for that OS. Since September 2000
Sun has not issued patches for new bugs in that operating system. On
September 30, Sun will further transition SunOS 4.1.4 to custom
quote
Mike Castle wrote:
In article [EMAIL PROTECTED],
Dr. David Kirkby [EMAIL PROTECTED] wrote:
/conftest: error while loading shared libraries: libgsl.so.0: cannot
open shared object file: No such file or directory
configure:4834: $? = 127
configure: program exited with status 127
configure
code,
that is portable according to POSIX 1003.2-1992 (a 10-year-old
standard), which SunOS 4.x happens to break on, and for which there is
no simple workaround.
Okay, if there's no simple workaround, I can see the point.
--
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical
])
--
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA.
Tel: 020 7679 6408 Fax: 020 7679 6269
Internal telephone: ext 46408
e-mail [EMAIL PROTECTED]
Bruce Korb wrote:
Dr. David Kirkby wrote:
Hi,
I've found in the past bugs in software are often found on one
platform that don't seem to get noticed on another. For this reason I
just tried to build gcc-2.0 on an old Sun SPARCstation 20 running
SunOs 4.1.4 (ie hardware
Russ Allbery wrote:
David Kirkby [EMAIL PROTECTED] writes:
Recently I was looking to put another operating system on a Sun for
testing and someone suggested using SunOs 4.1.4, since it is still used
a fair amount.
I think you've been somewhat misinformed there. Even
Eric Siegerman wrote:
On Fri, Feb 14, 2003 at 02:11:37AM +, Dr. David Kirkby wrote:
test: ==: unexpected operator on a Sun running NetBSD 1.6
== is indeed unexpected :-) Bourne shell doesn't support it; I
don't believe ksh does either. It looks like a bash extension,
in which shell
John Burger wrote:
From: Dr. David Kirkby [EMAIL PROTECTED]
[Much elided]
dnl something here generates an error:
dnl test: ==: unexpected operator on a Sun running NetBSD 1.6
if test $gsl_inc_count == 0 test $gsl_lib_count == 0; then
gsl_not_installed=1
elif test
\
docs/qex-december-1996/Makefile \
docs/theory/Makefile\
docs/Makefile ])
--
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA
(HAVE_GSL)
fi
--
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA.
Tel: 020 7679 6408 Fax: 020 7679 6269
Internal telephone: ext 46408
e-mail [EMAIL PROTECTED]
/local/atlc-version/html-docs and
/usr/local/atlc-version/html-docs/jpgs by default, with the /usr/local being
changed if someone alters the program-prefix?
--
Dr. David Kirkby PhD,
email: [EMAIL PROTECTED]
web page: http://www.david-kirkby.co.uk
Amateur radio callsign: G8WRB
to configure.
--
Dr. David Kirkby PhD,
email: [EMAIL PROTECTED]
web page: http://www.david-kirkby.co.uk
Amateur radio callsign: G8WRB
++, it uses
the CFLAGS, not the CPPFLAGS. So no matter what I put in CPPFLAGS, it never
propagates to the makefile.
Am I supposed to do anything special in the Makefile.am? I just have this:
bin_PROGRAMS = checksum
checksum_SOURCES = checksum.cpp
EXTRA_DIST = README
--
Dr. David Kirkby PhD,
email: [EMAIL
the configure.in.
--
Dr. David Kirkby PhD,
email: [EMAIL PROTECTED]
web page: http://www.david-kirkby.co.uk
Amateur radio callsign: G8WRB
dnl Process this file with autoconf to produce a configure script.
dns This macro is copied from the wxWindows distribution.
dnl
for the same source
will change, so it makes sense to compile a benchmark with only one compiler.
Any suggestions how to implement this?
--
Dr. David Kirkby PhD,
email: [EMAIL PROTECTED]
former email address: [EMAIL PROTECTED]
web page: http://www.david-kirkby.co.uk/
Amateur radio callsign: G8WRB
AC_HAVE_HEADERS(gsl/gsl_sf_expint.h)
dnl Check for st_blksize in struct stat
AC_ST_BLKSIZE
AC_OUTPUT([Makefile src/Makefile man/Makefile])
--
Dr. David Kirkby Ph.D,
email: [EMAIL PROTECTED]
former email address: [EMAIL PROTECTED]
web page: http://www.david-kirkby.co.uk/
Amateur radio callsign: G8WRB
want is being picked up.
Any suggestions ?
--
Dr. David Kirkby Ph.D,
email: [EMAIL PROTECTED]
former email address: [EMAIL PROTECTED]
web page: http://www.david-kirkby.co.uk
Amateur radio callsign: G8WRB
)
AC_DEFINE(_REENTRANT)
AC_DEFINE(_THREAD_SAFE)
AC_CHECK_LIB(thread, pthread_create)
AC_CHECK_LIB(pthread, pthread_create)
AC_CHECK_LIB(pthreads, pthread_create)
AC_CHECK_LIB(thread, thr_setconcurrency,
[AC_DEFINE(HAVE_THR_SETCONCURRENCY)])
fi
--
Dr. David Kirkby Ph.D,
email: [EMAIL PROTECTED
87 matches
Mail list logo
