round this, is there?
Even if there was a way to expand shell variables in the --help text,
you wouldn't be able to easily use $host_cpu because this requires
running actual configure tests to determine (via AC_CANONICAL_HOST).
None of this is performed for ./configure --help which exits configu
First of all, thanks for your help.
M4 macros are fine but as documented, AS_HELP_STRING does not expand its
second argument, so you need to be careful about quoting when you use it.
[...]
If the defaults can be determined by m4 then you can use m4 to generate
the help string.
[...]
All the
lt is $someDefault)])
>
> The trouble is, when I run "./configure --help", the $someDefault
> variable appears as a literal, that is, it is not being substituted. I
> tried with an M4 macro instead of a shell variable, to no avail.
M4 macros are fine but as documented, A
[blah blah (default is $someDefault)])
The trouble is, when I run "./configure --help", the $someDefault variable
appears as a literal, that is, it is not being substituted. I tried with an M4 macro
instead of a shell variable, to no avail.
After a while struggling with this weird Autoconf
On 11/17/22 13:35, Bruno Haible wrote:
Clang will surely not acquire knowledge about "every library", right,
only about the C library according to relevant standards (ISO C, POSIX)?
I don't know the Clang developers' plans. But if I wanted Clang to be
picky then yes, I'd have it know about ev
Paul Eggert wrote:
> > AC_CHECK_FUNC *should not* just probe for linkability of a symbol
>
> ... Autoconf cannot
> be expected to know every signature of every function in every library.
Clang will surely not acquire knowledge about "every library", right,
only about the C library according to
On 2022-11-16 10:59, Zack Weinberg wrote:
I'm generally in agreement with Rich Felker's argument
(inhttps://ewontfix.com/13/) that AC_CHECK_FUNC*should not* just probe for
linkability of a symbol
So am I. I'm not saying Autoconf should never change here, only that the
change would not be tr
tps://lists.gnu.org/r/autoconf/2022-11/msg00118.html>
It would help if Clang developers could cooperate to address this
potential problem with stricter compilation defaults. It's a real
problem. And it shouldn't require much work on the Clang side to address it.
On Sat, Nov 12, 2022 at 7:44 PM Paul Eggert wrote:
> On 2022-11-11 07:11, Aaron Ballman wrote:
> > Clang doesn't require such a linker (we work with various system
> linkers).
>
> As long as the system linkers continue to work as they have
> traditionally worked, we're fine.
>
> > the frontend pe
Hello,
On Wed, 16 Nov 2022, Paul Eggert wrote:
> On 2022-11-16 06:26, Michael Matz wrote:
> > char foobar(void);
> > int main(void) {
> >return &foobar != 0;
> > }
>
> That still has undefined behavior according to draft C23,
This is correct (and also holds for the actually working variant
On Wed, Nov 16, 2022, at 1:17 PM, Paul Eggert wrote:
...
> If Clang's threatened pickiness were of some real use elsewhere, it
> might be justifiable for default Clang to break Autoconf. But so far we
> haven't seen real-world uses that would justify this pickiness for
> Autoconf's use of 'char
On Wed, Nov 16, 2022 at 1:18 PM Paul Eggert wrote:
> ...
> If Clang's threatened pickiness were of some real use elsewhere, it
> might be justifiable for default Clang to break Autoconf. But so far we
> haven't seen real-world uses that would justify this pickiness for
> Autoconf's use of 'char me
On 2022-11-16 06:26, Michael Matz wrote:
char foobar(void);
int main(void) {
return &foobar != 0;
}
That still has undefined behavior according to draft C23, which says
behavior is undefined when foobar is (say) 'memset_explicit' because the
declaration 'char memset_explicit(void);' disagr
On Wed, 16 Nov 2022 at 16:34, Michael Matz wrote:
>
> Hello,
>
> On Wed, 16 Nov 2022, Jonathan Wakely wrote:
>
> > > > Unrelated but I was a bit tempted to ask for throwing in
> > > > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > > > it, but I suppose we don't want th
Hello,
On Wed, 16 Nov 2022, Jonathan Wakely wrote:
> > > Unrelated but I was a bit tempted to ask for throwing in
> > > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > > it, but I suppose we don't want the world to burn too much,
> >
> > :-) It's IMHO a bug in the sta
On Wed, 16 Nov 2022 at 15:59, Michael Matz wrote:
>
> Hello,
>
> On Wed, 16 Nov 2022, Sam James wrote:
>
> > Unrelated but I was a bit tempted to ask for throwing in
> > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > it, but I suppose we don't want the world to burn to
Hello,
On Wed, 16 Nov 2022, Sam James wrote:
> Unrelated but I was a bit tempted to ask for throwing in
> -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> it, but I suppose we don't want the world to burn too much,
:-) It's IMHO a bug in the standard that it misses "i
-O0,
>>> and thus no symbol reference remains in the resulting assembly.
>>
>> Err, right, *head-->table*.
>> Playing with volatile should help:
>>
>> char foobar(void);
>> char (* volatile ptr)(void);
>> int main(void) {
>>ptr = foob
historic?) reasons why it
> > > couldn't be used are gone now?
> >
> > Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
> > and thus no symbol reference remains in the resulting assembly.
>
> Err, right, *head--
ronically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
> and thus no symbol reference remains in the resulting assembly.
Err, right, *head-->table*.
Playing with volatile should help:
char foobar(void);
char (* volatile ptr)(void);
int main(void) {
ptr = foobar;
return ptr != 0;
}
Ciao,
Michael.
On Wed, 16 Nov 2022, Michael Matz via Gcc wrote:
> I sympathize, and I would think a compiler emitting an error (not a
> warning) in the situation at hand (in absence of -Werror) is overly
> pedantic. But, could autoconf perhaps avoid the problem? AFAICS the
> ac_fn_c_check_func really does
Hi,
On Tue, 15 Nov 2022, Paul Eggert wrote:
> On 2022-11-15 11:27, Jonathan Wakely wrote:
> > Another perspective is that autoconf shouldn't get in the way of
> > making the C and C++ toolchain more secure by default.
>
> Can you cite any examples of a real-world security flaw what would be
> f
On Tue, Nov 15, 2022 at 15:09:19 -0800, Paul Eggert wrote:
> This may be a hack, but it's a *good* hack. It's likely to fix
> real-world bugs that would be caused if Clang becomes overly pedantic by
> default here. And the probability of introducing real-world bugs is
> essentially zero.
FWIW,
I've seen a few instances of folks adding it themselves very
early in their configure scripts (which is a pain for distros
anyway) which then ends up affecting the rest.
Autoconf can help with this issue due to GCC and some other compilers
providing extensions (usually a pragma) to control w
Can you cite any examples of a real-world security flaw what would be
found by Clang erroring out because 'char foo(void);' is the wrong
prototype? Is it plausible that any such security flaw exists?
CVE-2006-1174 is a possibly reasonable example.
CVE-2006-1174 is not an example, because no p
On Tue, Nov 15, 2022 at 3:27 PM Paul Eggert wrote:
>
> On 2022-11-15 11:27, Jonathan Wakely wrote:
> > Another perspective is that autoconf shouldn't get in the way of
> > making the C and C++ toolchain more secure by default.
>
> Can you cite any examples of a real-world security flaw what would
On Tue, Nov 15, 2022 at 2:08 PM Paul Eggert wrote:
>
> On 2022-11-15 06:50, Jonathan Wakely wrote:
> > Could you clarify what you mean, with a concrete example? Surely as
> > long as errors are reported on stderr and the compiler exits with
> > non-zero status, that's an acceptable way to report e
On 2022-11-15 11:27, Jonathan Wakely wrote:
Another perspective is that autoconf shouldn't get in the way of
making the C and C++ toolchain more secure by default.
Can you cite any examples of a real-world security flaw what would be
found by Clang erroring out because 'char foo(void);' is the
On Tue, 15 Nov 2022 at 19:08, Paul Eggert wrote:
>
> On 2022-11-15 06:50, Jonathan Wakely wrote:
> > Could you clarify what you mean, with a concrete example? Surely as
> > long as errors are reported on stderr and the compiler exits with
> > non-zero status, that's an acceptable way to report err
On 2022-11-15 06:50, Jonathan Wakely wrote:
Could you clarify what you mean, with a concrete example? Surely as
long as errors are reported on stderr and the compiler exits with
non-zero status, that's an acceptable way to report errors?
Not if the "error" is harmless as far as Autoconf is conc
On Mon, 14 Nov 2022 at 18:15, Paul Eggert wrote:
>
> On 2022-11-14 04:41, Aaron Ballman wrote:
> > it's generally a problem when autoconf relies on invalid
> > language constructs
>
> Autoconf *must* rely on invalid language constructs, if only to test
> whether the language constructs work. And C
> On 15 Nov 2022, at 13:30, Zack Weinberg wrote:
>
> On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote:
>>> On 13 Nov 2022, at 00:43, Paul Eggert wrote:
>>>
>>> Although there will be problems with people who run "./configure
>>> CFLAGS='-Werror'", that sort of usage has always been problem
On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote:
>> On 13 Nov 2022, at 00:43, Paul Eggert wrote:
>>
>> Although there will be problems with people who run "./configure
>> CFLAGS='-Werror'", that sort of usage has always been problematic and
>> unsupported by Autoconf, so we can simply contin
> On 13 Nov 2022, at 00:43, Paul Eggert wrote:
>
> On 2022-11-11 07:11, Aaron Ballman wrote:
>> We believe the runtime behavior is sufficiently dangerous to
>> warrant a conservative view that any call to a function will be a call
>> that gets executed at runtime, hence a definitive signature m
On Sat, Nov 12, 2022 at 7:43 PM Paul Eggert wrote:
>
> On 2022-11-11 07:11, Aaron Ballman wrote:
> > We believe the runtime behavior is sufficiently dangerous to
> > warrant a conservative view that any call to a function will be a call
> > that gets executed at runtime, hence a definitive signatu
* Paul Eggert:
> On 2022-11-14 04:41, Aaron Ballman wrote:
>> it's generally a problem when autoconf relies on invalid
>> language constructs
>
> Autoconf *must* rely on invalid language constructs, if only to test
> whether the language constructs work. And Clang therefore must be
> careful abou
On 2022-11-14 04:41, Aaron Ballman wrote:
it's generally a problem when autoconf relies on invalid
language constructs
Autoconf *must* rely on invalid language constructs, if only to test
whether the language constructs work. And Clang therefore must be
careful about how it diagnoses invalid
On Mon, Nov 14, 2022 at 1:14 PM Paul Eggert wrote:
>
> On 2022-11-14 04:41, Aaron Ballman wrote:
> > it's generally a problem when autoconf relies on invalid
> > language constructs
>
> Autoconf *must* rely on invalid language constructs, if only to test
> whether the language constructs work. And
On 2022-11-11 07:11, Aaron Ballman wrote:
We believe the runtime behavior is sufficiently dangerous to
warrant a conservative view that any call to a function will be a call
that gets executed at runtime, hence a definitive signature mismatch
is something we feel comfortable diagnosing (in some f
On 2022-11-11 07:11, Aaron Ballman wrote:
Clang doesn't require such a linker (we work with various system linkers).
As long as the system linkers continue to work as they have
traditionally worked, we're fine.
the frontend perspective, we can't tell the difference between
"trust me this is
On 2022-11-11 19:45, Zack Weinberg wrote:
For anything specified by either ISO C or POSIX/XSI, I think Autoconf
probably*can* bake in an expected function prototype.
Unfortunately that won't work in general. strerror_r comes to mind
(GNU's signature disagrees with POSIX). And it's not uncommo
On 2022-11-12 06:09, Zack Weinberg wrote:
- and ‘false’ work anyway. This is for compatibility with C 2023 and
+ and ‘false’ work anyway. This is for compatibility with C23 and
Why are you changing four-digit years to two-digit years?
Formerly the Autoconf documentation was inconsistent. I
. This
>> means that as an autoconf maintainer, you unfortunately won't be able to
>> help us much.
>
> We changed the default in debian to re-autoconf on build a few years
> ago precisely so that changes in the tools (particularly new arch
> support) were picked
ts regenerated using autoconf for a decade or more. This
> means that as an autoconf maintainer, you unfortunately won't be able to
> help us much.
We changed the default in debian to re-autoconf on build a few years
ago precisely so that changes in the tools (particularly new arch
su
Demi Marie Obenour writes:
> On 11/10/22 15:19, Paul Eggert wrote:
>> Here's the main Autoconf issue issue with bool. Traditionally, Autoconf
>> supported K&R C, C89, C99, etc. At some point (I'm not sure when),
>> Autoconf started requiring C89 or later. Is it now OK for Autoconf to
>> requi
the newer compilers (and
>> also newer Perl and Bash and M4) is a thing that could happen.
>
> I didn't want to ask you to do this because I felt fortunate enough
> you were volunteering to handle 2.72, but this would indeed be a help,
> because then I won't have to try persuade
Paul Eggert writes:
> On 2022-11-10 19:33, Zack Weinberg wrote:
>
>> It would be relatively easy for me to take a couple hours this
>> weekend and put out a 2.72 release with everything that's already in
>> trunk and nothing else. Anyone have reasons I _shouldn't_ do that?
>
> I don't have anyth
grade Gnulib
> and in the meantime the other packages released since July would still have
> the changes whatever we do with Gnulib and/or Autoconf.
>
> Since distros need to deal with the issue anyway, regardless of what Autoconf
> and/or Gnulib does, I don't see why backing the ch
Bob Friesenhahn writes:
> On Thu, 10 Nov 2022, Zack Weinberg wrote:
>> The biggest remaining (potential) problem, that I’m aware of, is that
>> AC_CHECK_FUNC unconditionally declares the function we’re probing for
>> as ‘char NAME (void)’
>
> This does seem like the biggest problem since it would
On Fri, 11 Nov 2022, Zack Weinberg via Gcc wrote:
> These are also a trip hazard for novices, and the only way to turn them
> off is with -std=cXX, which also turns another trip hazard (trigraphs)
> *on*… so yeah, anything you can do to help speed up their removal, I
> think it’d b
for a decade or more. This
>> means that as an autoconf maintainer, you unfortunately won't be able to
>> help us much.
>
> I’m sadly not surprised.
>
> This is definitely more work than I can see myself doing on a volunteer
> basis, but a 2.69.1 patch release — not
nfortunately won't be able to
> help us much.
I’m sadly not surprised.
This is definitely more work than I can see myself doing on a volunteer
basis, but a 2.69.1 patch release — nothing that’s not already on trunk,
cherry pick the changes needed to support the newer compilers (and
also newer
Rich Felker writes:
> On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote:
>> The biggest remaining (potential) problem, that I’m aware of, is that
>> AC_CHECK_FUNC unconditionally declares the function we’re probing for
>> as ‘char NAME (void)’, and asks the compiler to call it with no
Nick Bowler writes:
> My gut feeling is that Autoconf should just determine the necessary
> options to get compatible behaviour out of these modern compilers, at
> least for the purpose of running configure tests. For example, Autoconf
> should probably build the AC_CHECK_FUNC programs using gcc'
On 11/10/22 15:19, Paul Eggert wrote:
> On 2022-11-10 09:16, Zack Weinberg wrote:
>> Changes to handle C23 built-in ‘bool’ better are under development but
>> the design has not yet been finalized.
>
> [I'm cc'ing this to bug-gnulib too.]
>
> To my mind this is the biggest outstanding issue in Au
ince distros need to deal with the issue anyway, regardless of what
Autoconf and/or Gnulib does, I don't see why backing the changes out of
Autoconf will help all that much.
It should pretty easy for a distro to say "hold on, I don't want 64-bit
time_t yet" without changing eithe
> On 11 Nov 2022, at 03:33, Zack Weinberg wrote:
>
> On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote:
>>> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote:
>>> While everyone else is discussing big ideas, it would be helpful for me
>>> personally if autoconf just made a release with the lat
On Thu, Nov 10, 2022 at 4:05 PM Paul Eggert wrote:
>
> On 2022-11-10 10:19, Aaron Ballman wrote:
> > In terms of the Clang side of things, I don't think we've formed any
> > sort of official stance on how to handle that yet. It's UB (you can
> > declare the C standard library interface without UB
> On 10 Nov 2022, at 17:16, Zack Weinberg wrote:
>
> I’m the closest thing Autoconf has to a lead maintainer at present.
>
> It’s come to my attention (via https://lwn.net/Articles/913505/ and
> https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> Clang both plan to disable
> On 11 Nov 2022, at 03:33, Zack Weinberg wrote:
>
> On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote:
>>> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote:
>>> While everyone else is discussing big ideas, it would be helpful for me
>>> personally if autoconf just made a release with the lat
On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote:
>> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote:
>> While everyone else is discussing big ideas, it would be helpful for me
>> personally if autoconf just made a release with the latest bugfixes.
>
> Before I dive into the rest of this thread
> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote:
>
> On Thu, 2022-11-10 at 12:16 -0500, Zack Weinberg wrote:
>>
>> Nobody has a whole lot of time to work on Autoconf at present, but I
>> would like to ask, anyway, what Autoconf could potentially do to make
>> this transition easier.
>
> Wh
* Rich Felker:
> I've been writing/complaining about autoconf doing this wrong for
> decades, with the best writeup around 9 years ago at
> https://ewontfix.com/13/. Part of the reason is that this has bitten
> musl libc users over and over again due to configure finding symbols
> that were intend
On Thu, 2022-11-10 at 12:16 -0500, Zack Weinberg wrote:
>
> Nobody has a whole lot of time to work on Autoconf at present, but I
> would like to ask, anyway, what Autoconf could potentially do to make
> this transition easier.
While everyone else is discussing big ideas, it would be helpful for m
On 2022-11-10 10:19, Aaron Ballman wrote:
In terms of the Clang side of things, I don't think we've formed any
sort of official stance on how to handle that yet. It's UB (you can
declare the C standard library interface without UB but calling any
function with a mismatched signature is UB)
The
On 2022-11-10 09:16, Zack Weinberg wrote:
Changes to handle C23 built-in ‘bool’ better are under development but
the design has not yet been finalized.
[I'm cc'ing this to bug-gnulib too.]
To my mind this is the biggest outstanding issue in Autoconf as far as
C23 goes, as the upgrade path for
On Thu, Nov 10, 2022 at 12:16 PM Zack Weinberg via cfe-commits
wrote:
>
> I’m the closest thing Autoconf has to a lead maintainer at present.
>
> It’s come to my attention (via https://lwn.net/Articles/913505/ and
> https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> Clang both
On Thu, 10 Nov 2022 at 17:58, Jonathan Wakely wrote:
>
> On Thu, 10 Nov 2022 at 17:52, Nick Bowler wrote:
> > It saddens me to see so much breakage happening in "modern C", a
> > language that has (until now) a long history of new language features
> > being carefully introduced to avoid these sort
On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote:
> I’m the closest thing Autoconf has to a lead maintainer at present.
>
> It’s come to my attention (via https://lwn.net/Articles/913505/ and
> https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> Clang both plan to
On Thu, Nov 10, 2022 at 1:12 PM Jonathan Wakely via cfe-commits
wrote:
>
> On Thu, 10 Nov 2022 at 17:58, Jonathan Wakely wrote:
> >
> > On Thu, 10 Nov 2022 at 17:52, Nick Bowler wrote:
> > > It saddens me to see so much breakage happening in "modern C", a
> > > language that has (until now) a long
On Thu, 10 Nov 2022 at 17:52, Nick Bowler wrote:
> It saddens me to see so much breakage happening in "modern C", a
> language that has (until now) a long history of new language features
> being carefully introduced to avoid these sort of problems.
The features were introduced in 1999. Compilers
On Thu, 10 Nov 2022, Zack Weinberg wrote:
The biggest remaining (potential) problem, that I’m aware of, is that
AC_CHECK_FUNC unconditionally declares the function we’re probing for
as ‘char NAME (void)’, and asks the compiler to call it with no
arguments, regardless of what its prototype actual
hat LWN article caught me a bit off guard.
Anyway, based on a limited attempt to get this fixed about three years
ago, I expect that many of the problematic packages have not had their
configure scripts regenerated using autoconf for a decade or more. This
means that as an autoconf maintainer, you unf
On 2022-11-10, Zack Weinberg wrote:
> The biggest remaining (potential) problem, that I’m aware of, is that
> AC_CHECK_FUNC unconditionally declares the function we’re probing for
> as ‘char NAME (void)’, and asks the compiler to call it with no
> arguments, regardless of what its prototype actual
I’m the closest thing Autoconf has to a lead maintainer at present.
It’s come to my attention (via https://lwn.net/Articles/913505/ and
https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
Clang both plan to disable several “legacy” C language features by
default in a near-future
It’s been two weeks since the release of autoconf 2.69d.
I’m not going to be able to work on autoconf at all from the beginning
of December until mid-January, so I’d really like to make the final
release of 2.70 by the end of November, to avoid losing momentum. For
this to happen, I need help
The wording all looks clear, except:
On 7/12/20 8:37 AM, Zack Weinberg wrote:
The only macros that are guaranteed *not* to
use AC_REQUIRE are the macros for acting on the results of a
test: AC_DEFINE, AC_SUBST, AC_MSG_*, AC_CACHE_CHECK, etc.
This sentence is too broad. It app
I've been going through the outstanding Savannah bugs in preparation
for a 2.70 beta. I've found a situation where 2.70 may break existing
configure scripts, that we can't address in our code, and is worth
warning people about in the NEWS, but I'm having trouble with the
wording.
The problem in a
On Thu, 14 Jun 2018, Anmol Mishra wrote:
I was thinking if I can check for both which version of Python is currently
available like 2 or 3, installation proceed with that.
PYTHON= python2.6, does this mean that it will be installed with Python 3
as well?
Python may be installed several times o
> > have moved forward to provide our package dual compatibility in Python 2
> > and Python 3, whole code is ready but I seek help for How to make the
> > suitable changes that my changes in makefile gets adapted in such a way
> > that my package will be installed in py
provide our package dual compatibility in Python 2
and Python 3, whole code is ready but I seek help for How to make the
suitable changes that my changes in makefile gets adapted in such a way
that my package will be installed in python 2 or python 3 directory
depending on the version available on
Python 2
and Python 3, whole code is ready but I seek help for How to make the
suitable changes that my changes in makefile gets adapted in such a way
that my package will be installed in python 2 or python 3 directory
depending on the version available on system. Your precious help and
guidance will
On 2017-09-21 03:40, suzuki toshiya wrote:
Dear Anton,
I'm afraid there is no standard mechanism to control the
execution of cross compiled binary. Yet I've not detected
which autoconf macro defines it, but I can find many
attempts trying to execute "./conftest" directly, in
generated configure
they are needed.
I think, Christian's idea to insert "cross_compiling=yes"
to your skeleton could make the first issue passed.
Anyway, it sounds that autotools will give me more
headache than help.
Maybe I made you misunderstood, I'm quite sorry.
Regards,
mpsuzuki
ables are run on the same platform,
it's just the invocation of the
executable is not simply ./a.out,
but "mpirun -np ./a.out", or
"cafrun -np ./a.out".
Anyway, it sounds that autotools will give me more
headache than help.
Thanks!
Anton
__
Oops, sorry for my poor English.
> The proprietary
> toolchain for HPC systems might be something what the original
> designers of autotool expected.
I meant "might be something *different from* what the original
designers of autotool expected".
Regards,
mpsuzuki
suzuki toshiya wrote:
> Dear An
Dear Anton,
I'm afraid there is no standard mechanism to control the
execution of cross compiled binary. Yet I've not detected
which autoconf macro defines it, but I can find many
attempts trying to execute "./conftest" directly, in
generated configure script - no variable to insert the
intermedia
Hi, I'm new to this list.
I develop a Fortran 2008 coarrays project
targeting HPC systems.
I'd like to simplify my build process with autotools.
The immediate problem is that the executable is
run in different ways on different platforms.
For example, OpenCoarrays compiler is "caf", but
the exec
Hi:
I am looking for someone to help me finish off an autoconf setup for the
OO-Browser: http://savannah.nongnu.org/projects/oo-browser/ which will be
released publicly soon after we finish this part off.
It is mostly an Emacs Lisp package but uses as a subprocess, an X Windows
program that
I’ve looked at it further this morning. A possible solution I can see on my
own is dropping in the the AC_*FLAGS_WARN_ALL as replacing the old
AC_PROG_* macros, and renaming the old macros to AC_PROG_*_OLD/CLASSIC. The
AC_PROG_* macros each have their own sets of parameters (enabling
specification
-Original Message-
From: "Dale Visser"
Sent: 12/23/2013 2:02 PM
To: "autoconf@gnu.org"
Subject: Help needed on how to resolve a circular dependency.
I'm attempting to modify AC_PROG_CC to include another macro that I'm
adding as well. The problem I&#
I'm attempting to modify AC_PROG_CC to include another macro that I'm
adding as well. The problem I'm hitting is that the new macro invokes
AC_COMPILE_IF_ELSE, which ends up doing an AC_REQUIRE([AC_PROG_CC}). Of
course, then autoconf is unhappy since AC_PROG_CC is effectively calling
AC_REQUIRE on
Interesting;
So in Oren's m4 file this is the target referenced for DX_CONFIG
# .PHONY: doxygen-run doxygen-doc $(DX_PS_GOAL) $(DX_PDF_GOAL)
#
# .INTERMEDIATE: doxygen-run $(DX_PS_GOAL) $(DX_PDF_GOAL)
#
# doxygen-run: @DX_DOCDIR@/@PACKAGE@.tag
#
# doxygen-doc: doxygen-run $(DX_PS
Hi Dave,
On 11/16/2013 02:35 PM, dave wrote:
But when i switch to a fresh build directory and then try to configure
outside the sourcedir it fails with :
[dave@localhost build-hello]$ make doxygen-run
make: *** No rule to make target `../helloworld_cc-0.5/doxygen.cfg',
needed by `doxygen-doc
[adding the list, so others can learn from this...]
On 08/20/2013 12:24 PM, dmitry...@gmail.com wrote:
> You were right. I was defining the environment variable as the path to M4.
> After I changed it to point to the executable itself, everything worked.
> Thanks very much.
Is there any particula
On 08/19/2013 06:02 PM, dmitry...@gmail.com wrote:
> Hi,
>
> I am trying to build autoconf 2.69, needed for another package.
> Configure works OK. In the make stage I get an error:
>
> autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg'
> ../bin/autom4te -B '..'/lib -B '..'/lib
s version 1.4.
Typing autom4te --version gives the following:
autom4te: need GNU m4 1.4 or later:
/global/homes/d/dmitryp/m4-1.4.16/install/bin
I am at a loss. Would appreciate some help on this.
Thanks very much,
D.P.
___
Autoconf mailing list
Autoc
On Mon, 2013-06-03 at 17:06 -0400, Paul Smith wrote:
> I can't think of any reason why adding those flags would cause this to
> happen. Indeed, I can't think of any reason why ld-linux.so would NOT
> be linked with your application before these flags were added. I would
> have thought that any ex
On Mon, 2013-06-03 at 13:37 -0700, Kip Warner wrote:
> Another thing, I see the the libstdc++.so.6 and libgcc_s.so.1 removed
> from its dependencies according to objdump, but I did note the addition
> of a new one, ld-linux-x86-64.so.2. Do you think that will be a problem?
I can't think of any rea
On Sun, 2013-06-02 at 10:45 -0400, Paul Smith wrote:
> I'm removing automake from this thread as I'm getting two copies of
> every mail. Hope no one minds.
No problem. I'll try to remember to do the same.
> This is because GCC has some of its internal functionality implemented
> in libraries, wh
1 - 100 of 500 matches
Mail list logo
