, AC_PACKAGE_VERSION, AC_PACKAGE_BUGREPORT, and so
on?..
Or I'm not required to define these macros in the package.m4 indeed,
and, possible, to generate package.m4 at all? My tryings show that
required, but may be I missed something...
--
Andrew W. No
has Autoconf/Automake support.
--
Andrew W. Nosenko
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
is check variable $GCC for value 'yes':
if test x$GCC = xyes
then
# ...
else
# ...
fi
See autoconf documentation, node 'C Compiler Characteristics', macro AC_PROG_CC.
--
Andrew W. Nosenko
___
Autoconf m
as simple silently ignored on my FreeBSD-7.0 +
gcc-4.3 + Gnu ld 2.15 (all compilation stages were passed just as if
non-existent option would not be passed).
--
Andrew W. Nosenko
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
On Fri, Aug 7, 2009 at 16:18, Andrew W.
Nosenko wrote:
> On Fri, Aug 7, 2009 at 13:39, Dr. David Kirkby wrote:
>> I'm trying to write a test, but find the documentation extremely sparse on
>> this.
>>
>> I wish to compile the following C program:
>>
>&g
depends on
compiler) instead of linking around libpthread directly. Sometime the
true name of thread library may be different. Sometime systems have
more than one thread library.
2. IIRC, on Mac OS X you don't need any special library or flag at
all. All pthread
On Mon, Aug 10, 2009 at 12:07, Philip
Herron wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Andrew W. Nosenko wrote:
>> On Mon, Aug 10, 2009 at 03:44, Philip
>> Herron wrote:
>>> Hey guys
>>>
>>> I have a project i am using GNU M
On Mon, Aug 10, 2009 at 12:45, Philip
Herron wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Andrew W. Nosenko wrote:
>> On Mon, Aug 10, 2009 at 12:07, Philip
>> Herron wrote:
>>> -BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>&g
ty with upstream)
And please, don't say about "Linux has interlibrary dependency for
shared libraries". First at all, not all libraries are shared (even
under Linux). Second, Linux is not only one flavor of Unix. Third,
sometime developers are forced to use OS'es different
return retval;
> }
> #fi
>
> Is it as simple as that, or am I missing something? How would that be
> improved - I somewhat doubt my method is optimal.
>
What about
AC_CHECK_FUNC (atoll, [], [AC_LIBOBJ(atoll)])
and place your atoll() implementation into atoll.c ?
Also you w
oconf. It's incredibly helpful to get some much good
> info. Sorry if my questions seem vague. I'm only just starting to
> get a hold of the issues involved in writing a portable build system.
>
Excuse me, but why just don't
#include
and use in
ning testsuite at the "make distcheck" is not a problem but
intended goal. If you want just build tarball but don't want to run a
tests for some reason, then use "make dist" instead (pay attention on
"dist" instead of "distcheck").
--
Andrew
x27;t compile actually these examples, but hope you
get the idea.
--
Andrew W. Nosenko
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
On Tue, Sep 28, 2010 at 17:52, Andrew W. Nosenko
wrote:
> On Tue, Sep 28, 2010 at 06:13, Sergio Belkin wrote:
>> Hi,
>>
>> I am autoconfiscating a project that has a header file with a line:
>>
>> #include
>>
>> configure.ac has:
>>
>>
On Tue, Sep 28, 2010 at 18:01, Ralf Corsepius wrote:
> On 09/28/2010 04:52 PM, Andrew W. Nosenko wrote:
>>
>> On Tue, Sep 28, 2010 at 06:13, Sergio Belkin wrote:
>>>
>>> Hi,
>>>
>>> I am autoconfiscating a project that has a header file wit
So this method is useless.
>
> How is one supposed to test these things with autoconf?
>
> It seems to me that the only truly workable option is to fall back to
> deciding the flags and features of a given compiler from combination of
> platform, compi
2010/10/16 Andrew W. Nosenko :
> 2010/10/15 Václav Haisman :
>> Hi.
>>
>> I am having difficulty testing for compiler features like
>> __declspec(dllimport) and switches like -Wall or -Werror.
>>
>> The problem has started like this. I wanted to test com
ses all
> file descriptors before starting the daemon.
Excuse me, but why you didn't close all FDs inside your daemon before
daemonizing at all?
Properly written daemon shoud to do it anyway for preventing opened
FDs to be "leaked" forever (ok, not fo
y
int i = -1 >> 1; if (i == -1) {}
may be evaluated at the compile time and therefore may check the
compiler itselt, not the code generated by compiler (which also
important).
volatile int i = -1; i = i >> 1; if (i == -1) {}
force bypass the
On Fri, Dec 10, 2010 at 17:38, Paul Eggert wrote:
> On 12/10/2010 03:54 AM, Andrew W. Nosenko wrote:
>>> > Doesn't this suffice, without dragging Autoconf into it?
>>> >
>>> > #if -1 >> 1 == -1
>> No. It won't work. Your preprocess
ically better to avoid the
> preprocessor.
>
> On 12/10/10 09:17, Andrew W. Nosenko wrote:
>
>> Why do you think that preprocessor should match the
>> behavior of compiler???
>
> Because in practice, when they don't, Bad Things Happen,
> this being one of
On Sat, Dec 11, 2010 at 05:39, Bob Friesenhahn
wrote:
> On Fri, 10 Dec 2010, Andrew W. Nosenko wrote:
>>
>> Excuse me? Why do you think that preprocessor should match the
>> behavior of compiler???
>
> Excuse me? Why do you think that the behavior of the comp
On Sat, Dec 11, 2010 at 22:09, Paul Eggert wrote:
> On 12/11/2010 06:16 AM, Andrew W. Nosenko wrote:
>> You mismatch the preprocessor function (find the LONG_MAX macro and
>> replace it by it's definition found somewhere in header) with the
>> function of compiler (in
On Sun, Dec 12, 2010 at 03:05, Andrew W. Nosenko
wrote:
> On Sat, Dec 11, 2010 at 22:09, Paul Eggert wrote:
>> On 12/11/2010 06:16 AM, Andrew W. Nosenko wrote:
>>> You mismatch the preprocessor function (find the LONG_MAX macro and
>>> replace it by it's defi
d long, for portability). Of course this means
> the test needs to include AC_INCLUDES_DEFAULT in the test header, for
> stdio.h. The latter means you can then drop including sys/types another
> time.
IMHO, better would to be just disable a compiler to do optimization
dances a
n be required?
>
exec() may fail. And you need to exit somehow. Calling of exit() in
such situation is a bad thing because it call atexit handlers. Thus
you need _exit().
--
Andrew W. Nosenko
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
On Mon, Jun 20, 2011 at 11:25, Andrew W. Nosenko
wrote:
> On Sun, Jun 19, 2011 at 22:03, Andy Wingo wrote:
>> Hi,
>>
>> On Sat 18 Jun 2011 22:25, "Andrew W. Nosenko"
>> writes:
>>
>>> On Fri, Jun 17, 2011 at 13:21, Andy Wingo
his in
> INSTALL. Maybe there would be way too many false positives, I don't know — I
> have no idea how many configurers use extended charsets in their directory
> names.
>
1. Excuse me, but what is the reason to have LC_ALL=C? If need to
parse so
ithout.
If compiler doesn't support it, then pragma GCC visibility will be
skipped with #if (because undefined HAVE_PRAGMA_VISIBILITY) or without
(just because unknown pragmas are ignored per standard).
--
Andrew W. Nosenko
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
ain-dameged defines like
__STDC_VERSION__. After all, Autoconf is all about the actual
features of compilation environment, not about "branding labels" on
that environment.
--
Andrew W. Nosenko
le with C++11 code compiled
with different GCC versions and with C++98/C++03 code compiled
with any version.
--
Andrew W. Nosenko
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
On Sat, Nov 3, 2012 at 6:42 PM, Florian Weimer wrote:
> * Florian Weimer:
>
>> * Andrew W. Nosenko:
>>
>>> ABI break by gcc-4.7.0 and 4.7.1 in c++11 mode was a bug (or
>>> misfeature, call it as you want). Fixed in gcc-4.7.2.
>>> From http://gcc.g
On Sat, Nov 3, 2012 at 8:08 PM, Florian Weimer wrote:
> * Andrew W. Nosenko:
>
>>> I've since checked, and it was was with 4.7.1.
>>>
>>> Linking C++98 and C++11 code together is still officially unsupported,
>>> even if it is supposed to work if you
files?
>>
>>
> The user is required to get those sources and then point my code to them
> using a configure parameter. I know it is not nice to do it this way but
> because of licensing issues with the third-party code (who allows using
> their code but not distribution of it
(AC_PROG_CC_C99 vs. new AC_PROG_CC) have different semantics.
AC_PROG_CC_C99 — select best/prefered compiler that supports particular
standard (c99), while
new AC_PROG_CC — select best/most recent standard supported by particular
compiler.
So deprecating one in favour of another is quite like dep
On Wed, Feb 5, 2020 at 5:56 PM Nick Bowler wrote:
> On 2020-02-01, Andrew W. Nosenko wrote:
> > On Fri, Jan 24, 2020 at 9:48 PM Nick Bowler wrote:
> > > AC_PROG_CC now tries to select the highest language revision supported
> > > by the compiler.
> >
> &g
ftware. If configure can select the fastest shell which
> works reliably, then Autoconf's reputation will improve.
>
> Bob
> --
> Bob Friesenhahn
> bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
> Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
>
>
--
Andrew W. Nosenko
37 matches
Mail list logo