Hi.
Is it possible to reuse whatever AC_LANG_PROGRAM() produces?
I would like to define a test-case for __thread/__declspec(thread) but I
want to be able to use the same test-case for both AC_LINK_IFELSE() and
AC_RUN_IFELSE(), and I do not want to repeat the source code of the
test-case twice. T
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 compiler for
__declspec(dllimport) (for Windows) and if that fails for
__attribute__((visibility("default"))) (for *nix/GCC).
Andrew W. Nosenko wrote, On 16.10.2010 2:50:
> 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.
>&g
On 15 March 2016 at 17:35, Paul Eggert wrote:
> On 10/04/2012 12:41 AM, Václav Zeman wrote:
>>
>> Does attached patch work for you?
>
>
> Following up on this old thread, I applied the attached. In practice I
> expect this doesn't matter much, as people configure with CC=clang when they
> want cla
On 16 March 2016 at 16:30, Earnie wrote:
> (...)
> Rather than adding to this list of tools how about a configure.ac macro.
> Something named AC_REQUIRE_TOOL sounds correct and then AC_CHECK_TOOLS
> also checks (or maybe an option to only check) the required tool.
>
> The problem I find with the
On 31 March 2016 at 04:30, Ruben Safir wrote:
> On 03/16/2016 11:30 AM, Earnie wrote:
>> On 3/16/2016 4:02 AM, Václav Haisman wrote:
>>> On 15 March 2016 at 17:35, Paul Eggert wrote:
>>>> On 10/04/2012 12:41 AM, Václav Zeman wrote:
>>>&g
On 31.3.2016 18:46, Ruben Safir wrote:
> On 03/31/2016 12:31 PM, Jeffrey Walton wrote:
>> viable compiler
>
> It will be viable when they release it under the GPL3.
In that case, I am waiting for you to present and get through patches
that remove aCC, cl.exe, FCC, KCC, RCC, xlC_r, and xlC as well
On 1 August 2016 at 23:58, Jeffrey Walton wrote:
> I'm trying to build a package from its release tarball. config.guess
> appears to be misidentifying the platform, so I'd like to update it to
> the latest version.
>
> How do I update config.guess?
The upstream Git repository is there:
http://git
Hi.
I have a test that I would like to run during configure time which
basically involves compiling two files and linking a shared object/DLL
out of them. I think I would like to be using automake/libtool to
compile and link the configure test itself. Is there a good practice
or good example on ho
On 19 December 2016 at 15:03, Eric Blake wrote:
> On 12/18/2016 09:22 PM, Andrei Borzenkov wrote:
>> We got report that GRUB build fails under glibc 2.25 due to issue fixed
>> in commit e17a30e9 (warnings about using major() etc from sys/types.h
>> with -Werror). It was confirmed that this commit
On 30.7.2018 22:38, Mauricio Ramirez wrote:
> I have a project with about 30 modules. We've been using the following as
> our Makefile.am
>
> ACLOCAL_FLAGS = -I buildtools # To find out custom macros (for aclocal)
>
> SUBDIRS = \
> mylibrary\
> prog1 prog2 prog3 prog4 prog5 prog6 prog7 prog8 \
>
On Sun, 5 Aug 2018 at 00:17, Jeffrey Walton wrote:
> I'm testing different configurations of a C++ library. When I test on
> AIX with XLC I am catching an error:
>
> -bash-4.4$ OBJECT_MODE=64 CXX=xlC ./configure
> checking for a BSD-compatible install... ./install-sh -c
> checking whether build e
Hi,
I have this library, it includes autoconf generated config.h in its public
headers. Now, config.h defines PACKAGE_* set of symbols. The problem is that
if user programme or another library also uses autoconf and config.h, the
PACKAGE_* (and also other) symbols are now being #defined twice,
Hi,
how can I stop reconfiguration (automatic running of aclocal, automake and
autoconf)? I have sources including Makefile.in and configure and other
generated files in Subversion repository. I thought that if I touch each
foo.in file and the configure script, it will not try to re-run autoreconf.
There is a macro in the archive for this:
https://www.gnu.org/software/autoconf-archive/ax_check_define.html
On Sun, Mar 14, 2021 at 11:57 PM Dan Mahoney wrote:
>
> All,
>
> One of OpenDMARC’s users has commented that on the musl c library, the
> defines NETDB_SUCCESS and NETDB_INTERNAL are abse
On 27. 03. 23 17:38, Jim Meyering wrote:
We're overdue for a new release, so here's a snapshot in preparation
for that, which I want to call 2.73 (skipping 2.72). There has never
been an autoconf-2.72 release, yet `git describe` now prints 2.72c and
has been printing strings like v2.72a-92-g8db0
16 matches
Mail list logo
