On Wed, 25 Jan 2017, Zack Weinberg wrote:
> > Interesting, as I recall seeing -D_FILE_OFFSET_BITS=64 on various
> > compiler command lines when working under GNU. (I normally work
> > under BSD at home, so I don’t know where exactly.)
>
> Is it possible that those programs were not using a config
On 01/25/2017 10:24 AM, Zack Weinberg wrote:
The ChangeLog entry for the addition says "Import AC_SYS_LARGEFILE
from largefile.m4 serial 12", so that sounds like there was an add-on
.m4 file with the same functionality floating around prior to that - I
don't know where to find copies of that file
On Wed, Jan 25, 2017 at 1:02 PM, Thorsten Glaser wrote:
> On Wed, 25 Jan 2017, Zack Weinberg wrote:
>
>> As far as I can tell from the Git history, AC_SYS_LARGEFILE has
>> *always* used AC_DEFINE_UNQUOTED to define the various preprocessor
>> macros that it can define (_FILE_OFFSET_BITS, _LARGE_FI
On Wed, 25 Jan 2017, Zack Weinberg wrote:
> As far as I can tell from the Git history, AC_SYS_LARGEFILE has
> *always* used AC_DEFINE_UNQUOTED to define the various preprocessor
> macros that it can define (_FILE_OFFSET_BITS, _LARGE_FILES, and
> _DARWIN_USE_64_BIT_INODE).
Interesting, as I recall
On Wed, Jan 25, 2017 at 12:21 PM, Thorsten Glaser wrote:
>
> Would you at least *consider* moving the definition back to some
> command line argument? (Changing severity to wishlist now; if not,
> we can likely close the bug, but I’d still like you to please at
> least consider doing the change.)
severity 852617 wishlist
tags 852617 = upstream
thanks
On Wed, 25 Jan 2017, Eric Blake wrote:
> If the real-world package is not including config.h first, then that is
> a bug in the real-world package that should be fixed there. Autoconf
OK, I’ve (separately) reported the bug to xrdp upstream.
system header before "config.h", the definition will be
>> ignored, because it comes too late.
>>
>> CPPFLAGS is r̲e̲a̲l̲l̲y̲ the correct place for this. Again.
>
> Let’s keep track of t̲h̲i̲s̲ bug here <852...@bugs.debian.org>.
> Again, please
sed.
>
> If AC_CONFIG_HEADERS is used, the definition is only written to
> its output file (config.h by default).
>
> This is even more unfortunate, because now, if any program includes
> a glibc system header before "config.h", the definition will be
> ignored, because it comes
On Wednesday 31 July 2013 11:16:27 Nate Bargmann wrote:
> * On 2013 31 Jul 08:03 -0500, LRN wrote:
> > On 31.07.2013 16:17, Daniel Pocock wrote:
> > > Should we be distributing a config script, e.g. bin/xxx-config that can
> > > emit CPPFLAGS?
> >
> > Either
efinition. The expansion of
> gl_ABSOLUTE_HEADER causes my function look for the header before I've
> modified CPPFLAGS. The, after I modify CPPFLAGS, the cached "no" result is
> being used.
>
> Recreate:
> 1. Snag absolute_header.m4 from the link above
> 2. Pick your favori
ADER causes my function look for the header before I've
modified CPPFLAGS. The, after I modify CPPFLAGS, the cached "no" result is
being used.
Recreate:
1. Snag absolute_header.m4 from the link above
2. Pick your favorite Makefile.am.
3. Use this configure.ac:
AC_INIT(recreate, 0.0.
* Rhys Ulerich wrote on Thu, Aug 14, 2008 at 06:30:50AM CEST:
>
> How many chickens must I sacrifice for AC_CHECK_HEADER to notice that I've
> modified CFLAGS/CPPFLAGS within my configure script?
Please show your full configure.ac script, or, even better, a reduced
one that stil
Me again,
How many chickens must I sacrifice for AC_CHECK_HEADER to notice that I've
modified CFLAGS/CPPFLAGS within my configure script?
Within an m4 macro and using autoconf version 2.62:
# Code to save LDFLAGS/CPPFLAGS/etc.
>
LDFLAGS="-L${trilinos_libdir} $LDFLAGS&qu
This is a messy area, but the usual workaround is to put the relevant
flags into CC and CXX, e.g., CC='xlc -DFOO' CXX='g++ -DBAR'.
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
If this is the wrong forum for this question, please let me know where
to send it. I am working on a project that mixes C and C++. The
problem that I have is that there is only one CPPFLAGS for both
compilers. Why is this the case? It would be nice if
automake/autoconf provided a CXXPPFLAGS
Alexandre Duret-Lutz wrote:
[Please reply to [EMAIL PROTECTED]
"Robert" == Robert Lowe <[EMAIL PROTECTED]> writes:
Robert> Hi!
Robert> I have a set of common headers files in includes/ and the following
Robert> line in configure.ac:
Robert> AC_SUBST(CPPFLAG
Bob Friesenhahn wrote:
CPPFLAGS="${srcdir}/includes"
AC_SUBST(CPPFLAGS)
Overridding the user CPPFLAGS is a bad idea. In your Makefile.am, use:
AM_CPPFLAGS = -I$(top_srcdir)/includes
___
Autoconf mailing list
[EMAIL PROTE
[Please reply to [EMAIL PROTECTED]
>>> "Robert" == Robert Lowe <[EMAIL PROTECTED]> writes:
Robert> Hi!
Robert> I have a set of common headers files in includes/ and the following
Robert> line in configure.ac:
Robert> AC_SUBST(CPPFLAGS,[-I../includes]
Daniel Reed wrote:
On 2004-12-04T21:11-0600, Robert Lowe wrote:
) > CPPFLAGS="${srcdir}/includes"
) > AC_SUBST(CPPFLAGS)
) No, that didn't quite do it, even with -I. It substitutes './includes',
) and caused the next AC_CHECK_LIB() to fail, which I
Bob Friesenhahn wrote:
> On Sat, 4 Dec 2004, Robert Lowe wrote:
>
>> Hi!
>>
>> I have a set of common headers files in includes/ and the following
>> line in configure.ac:
>>
>> AC_SUBST(CPPFLAGS,[-I../includes])
>>
>> ...since all source file
On Sat, 4 Dec 2004, Robert Lowe wrote:
Hi!
I have a set of common headers files in includes/ and the following
line in configure.ac:
AC_SUBST(CPPFLAGS,[-I../includes])
...since all source files are in parallel directories. This works
fine for everything but a distcheck. Is there a simple means
Hi!
I have a set of common headers files in includes/ and the following
line in configure.ac:
AC_SUBST(CPPFLAGS,[-I../includes])
...since all source files are in parallel directories. This works
fine for everything but a distcheck. Is there a simple means of
placing an absolute path there? I&#x
On Mon, 2004-06-14 at 17:28, Andreas Schwab wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> > On Fri, 2004-06-04 at 13:02, Patrick Welche wrote:
> >> automake by default pops
> >>
> >> CPPFLAGS = @CPPFLAGS@
> >>
> >> in Mak
Dan Kegel wrote:
Russell Shaw wrote:
One caveat, though: the manpage says
PKG_CONFIG_PATH
A colon-separated (on Windows, semicolon-separated) list
of directories to search for .pc files. Thedefault directory
will always be searched aftersearching the path;
the default is l
Russell Shaw wrote:
One caveat, though: the manpage says
PKG_CONFIG_PATH
A colon-separated (on Windows, semicolon-separated)
list of directories to search for .pc files. The
default directory will always be searched after
searching the path;
the default is lib-dir/pkgconfig
Dan Kegel wrote:
Russell Shaw wrote:
Dan Kegel wrote:
Paul Jarc wrote:
Dan Kegel <[EMAIL PROTECTED]> wrote:
The right thing to do is use
/opt/arm-linux/usr/lib/pkgconfig/audiofile.pc,
which will point to the right library.
Right. So set PKG_CONFIG_PATH=/opt/arm-linux/lib/pkgconfig.
I certainly
Russell Shaw wrote:
Dan Kegel wrote:
Paul Jarc wrote:
Dan Kegel <[EMAIL PROTECTED]> wrote:
The right thing to do is use
/opt/arm-linux/usr/lib/pkgconfig/audiofile.pc,
which will point to the right library.
Right. So set PKG_CONFIG_PATH=/opt/arm-linux/lib/pkgconfig.
I certainly agree that'd do i
Dan Kegel wrote:
Paul Jarc wrote:
Dan Kegel <[EMAIL PROTECTED]> wrote:
The right thing to do is use
/opt/arm-linux/usr/lib/pkgconfig/audiofile.pc,
which will point to the right library.
Right. So set PKG_CONFIG_PATH=/opt/arm-linux/lib/pkgconfig.
I certainly agree that'd do it. Not sure that Russ
Paul Jarc wrote:
Dan Kegel <[EMAIL PROTECTED]> wrote:
The right thing to do is use /opt/arm-linux/usr/lib/pkgconfig/audiofile.pc,
which will point to the right library.
Right. So set PKG_CONFIG_PATH=/opt/arm-linux/lib/pkgconfig.
I certainly agree that'd do it. Not sure that Russell does yet, thou
I wrote:
> Dan Kegel <[EMAIL PROTECTED]> wrote:
>> The right thing to do is use /opt/arm-linux/usr/lib/pkgconfig/audiofile.pc,
>> which will point to the right library.
>
> Right. So set PKG_CONFIG_PATH=/opt/arm-linux/lib/pkgconfig.
Er, s:lib:usr/lib:, of course.
paul
Dan Kegel <[EMAIL PROTECTED]> wrote:
> The right thing to do is use /opt/arm-linux/usr/lib/pkgconfig/audiofile.pc,
> which will point to the right library.
Right. So set PKG_CONFIG_PATH=/opt/arm-linux/lib/pkgconfig.
> If you still think only one copy of, say, audiofile.pc is needed
> on the enti
Russell Shaw wrote:
::
audiofile.pc
::
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
includedir=/usr/include
The only way pkg-config can work is if you have a separate
copy of pkg-config and its data files for each copy of the userland
libraries.
This makes perfect sense: fo
Dan Kegel wrote:
Murray Cumming wrote:
I think one needs a separate copy of pkg-config for each toolchain
you want to build things with. (Or at least its data files)...
No, that makes no sense.
Nevertheless, even after reviewing "man pkg-config", I think it's true.
Take a look at the output of "st
Murray Cumming wrote:
I think one needs a separate copy of pkg-config for each toolchain
you want to build things with. (Or at least its data files)...
No, that makes no sense.
Nevertheless, even after reviewing "man pkg-config", I think it's true.
Take a look at the output of "strings /usr/bin/p
On Mon, 2004-06-14 at 08:31 -0700, Dan Kegel wrote:
> Russell Shaw wrote:
> > Hal Snyder wrote:
> >
> >> Ralf Corsepius <[EMAIL PROTECTED]> writes:
> >>
> >>> BTW: Having to pass "/usr/local" almost always indicates a massively
> >>> mis-configured toolchain or configure script.
> >>
> >>
> >> Sor
Dan Kegel wrote:
Russell Shaw wrote:
Hal Snyder wrote:
Ralf Corsepius <[EMAIL PROTECTED]> writes:
BTW: Having to pass "/usr/local" almost always indicates a massively
mis-configured toolchain or configure script.
Sorry if this is an F.A.Q. I see various ways of doing it but wonder,
what is best pra
Russell Shaw wrote:
Hal Snyder wrote:
Ralf Corsepius <[EMAIL PROTECTED]> writes:
BTW: Having to pass "/usr/local" almost always indicates a massively
mis-configured toolchain or configure script.
Sorry if this is an F.A.Q. I see various ways of doing it but wonder,
what is best practice?
What are
Ralf Corsepius <[EMAIL PROTECTED]> writes:
> On Fri, 2004-06-04 at 13:02, Patrick Welche wrote:
>> automake by default pops
>>
>> CPPFLAGS = @CPPFLAGS@
>>
>> in Makefile.in
>>
>> If I configure with:
>>
>> ./configure LDFLAGS=&q
Hal Snyder wrote:
Ralf Corsepius <[EMAIL PROTECTED]> writes:
BTW: Having to pass "/usr/local" almost always indicates a massively
mis-configured toolchain or configure script.
Sorry if this is an F.A.Q. I see various ways of doing it but wonder,
what is best practice?
What are the recommended autom
Ralf Corsepius <[EMAIL PROTECTED]> writes:
> BTW: Having to pass "/usr/local" almost always indicates a massively
> mis-configured toolchain or configure script.
Sorry if this is an F.A.Q. I see various ways of doing it but wonder,
what is best practice?
What are the recommended automake and aut
On Fri, Jun 04, 2004 at 03:30:06PM +0200, Ralf Corsepius wrote:
> Unless the configure script is broken and playing tricks with quoting,
Thanks for the reassurance that in principle it should work.. Just tracked
this down in xine-lib:
saved_CPPFLAGS="$CPPFLAGS"
...
CPPFLAGS=&
On Fri, 2004-06-04 at 13:02, Patrick Welche wrote:
> automake by default pops
>
> CPPFLAGS = @CPPFLAGS@
>
> in Makefile.in
>
> If I configure with:
>
> ./configure LDFLAGS="-L/usr/local/lib -Wl,-R/usr/local/lib"
> CPPFLAGS=-I/usr/local/include
>
&
automake by default pops
CPPFLAGS = @CPPFLAGS@
in Makefile.in
If I configure with:
./configure LDFLAGS="-L/usr/local/lib -Wl,-R/usr/local/lib"
CPPFLAGS=-I/usr/local/include
Isn't it reasonable to expect for CPPFLAGS to be set in the Makefile?
It appears blank in my cas
>some automake contraption? Should I just add it to CPPFLAGS? Please
> >>tell me.
> >
> >
> > The Autoconf manual tells the tale:
> >
> >A corollary is that you should not use these variables except in
> > Makefiles. For instance, i
Peter Eisentraut writes:
> Fredrik Tolf writes:
>
> > How do I get the sysconfdir into a cpp macro if I use automake as
> > well? Should I do it through a config header, or should I do it via
> > some automake contraption? Should I just add it to CPPFLAGS? Please
Peter Eisentraut wrote:
Fredrik Tolf writes:
How do I get the sysconfdir into a cpp macro if I use automake as
well? Should I do it through a config header, or should I do it via
some automake contraption? Should I just add it to CPPFLAGS? Please
tell me.
The Autoconf manual tells the tale
Fredrik Tolf writes:
> How do I get the sysconfdir into a cpp macro if I use automake as
> well? Should I do it through a config header, or should I do it via
> some automake contraption? Should I just add it to CPPFLAGS? Please
> tell me.
The Autoconf manual tells the tale:
A
it to CPPFLAGS? Please
tell me.
Fredrik Tolf
Jose Roman Bilbao <[EMAIL PROTECTED]> writes:
> configure:9331: checking vtkImageFFT.h usability
> configure:9344: gcc -c -g -O2 -I/usr/local/include/vtk conftest.c >&5
> In file included from /usr/local/include/vtk/vtkIndent.h:52,
> from /usr/local/include/vtk/vtkObject.h:67,
>
Hi Again,
Here you are a part of the "config.log" file code. This is the beginning
of the "test for vtkImageFFT.h file:
configure:9331: checking vtkImageFFT.h usability
configure:9344: gcc -c -g -O2 -I/usr/local/include/vtk conftest.c >&5
In file included from /usr/local/include/vtk/vtkIndent.h:
Jose Roman Bilbao <[EMAIL PROTECTED]> writes:
> I can not show you now the output but I can tell you that configure
> finished saying "NO" to all the tests performed to that library, I mean,
> usability, compiler and presence.
config.log probably has more hints as to why this happened.
> I tried
> the vtk include directory],
> > [CPPFLAGS="${CPPFLAGS} -I${withval}"])
>
> [...]
>
> > AC_CHECK_HEADER([vtkImageFFT.h],,
> > [AC_MSG_ERROR([VTK headers not found; Check your installation or try
> > ./configure --with-vtk-incdir=/libdir/for/vtkhe
Jose Roman Bilbao <[EMAIL PROTECTED]> writes:
> AC_ARG_WITH(vtk-incdir,[ --with-vtk-incdir=DIR location of
> the vtk include directory],
> [CPPFLAGS="${CPPFLAGS} -I${withval}"])
[...]
> AC_CHECK_HEADER([vtkImageFFT.h],,
> [AC_MSG_ERROR([VT
LIBFOO_LDFLAGS = "-Lfoo/lib"
> LIB_FOO_LIBS= "-lfoo"
>
> The problem is then in Makefile.in I do something like
>
> libs = @LIBS@ @LIB_FOO_LIBS@ @LIB_OTHERLIB_LIBS@ ...
>
> Is there any reason not to do this in configure.in:
>
> CPPFLAGS =
in Makefile.in I do something like
libs = @LIBS@ @LIB_FOO_LIBS@ @LIB_OTHERLIB_LIBS@ ...
Is there any reason not to do this in configure.in:
CPPFLAGS = "${CPPFLAGS} -Ifoo/include"
LDFLAGS = "${LDFLAGS} -Lfoo/lib"
LIBS = "${LIBS} -lfoo"
and then in Makefile
>>> "John" == John D Burger <[EMAIL PROTECTED]> writes:
[...]
John> Here's what I've come up with:
John> eval test -d $includedir && CPPFLAGS="-I$includedir $CPPFLAGS"
John> eval jb_expanded_libdir=$libdir
John> jb_expanded
Alexandre Duret-Lutz wrote:
> John> I've tried:
> John> AC_INIT(libspec, 1.0, [EMAIL PROTECTED])
> John> CPPFLAGS="-I$includedir $CPPFLAGS"
> John> LDFLAGS="-L$libdir $LDFLAGS"
> John> ...
> John> but this doesn't
>>> "John" == John D Burger <[EMAIL PROTECTED]> writes:
[...]
John> I've tried:
John> AC_INIT(libspec, 1.0, [EMAIL PROTECTED])
John> CPPFLAGS="-I$includedir $CPPFLAGS"
John> LDFLAGS="-L$libdir $LDFLAGS"
John> ...
Asi
/strange/place
Configuring and installing successive packages would ordinarily require:
configure --prefix=/some/strange/place \
CPPFLAGS=-I/some/strange/place/include \
LDFLAGS=-L/some/strange/place/lib
What I would like to do is have my generated configure scripts give
default values to
>>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Ralf> Wouldn't AC_REQUIRE-ing a macro containing AC_SUBST(CPPFLAGS)
Ralf> from AC_PROG_CC and AC_PROG_CPP remedy this issue?
Akim> Yep, that's a means to implement the factoring thing
>>>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
>> I _know_ that CPPFLAGS is used both by AC_PROG_CPP and AC_PROG_CC,
>> so it seems natural to document it in both or find a means to
>> factor it for both.
Ralf> Wouldn't AC_REQ
| ..
| # make
| gcc -DHAVE_CONFIG_H -I. -I. -I. @CPPFLAGS@ -g -O2 -c hello.c
| gcc: @CPPFLAGS@: Datei oder Verzeichnis nicht gefunden
| make: *** [hello.o] Error 1
|
| The return of a "N'aucun ficher ou repertoire" / "No such file or
| directory" bug :)
Actually you m
-DHAVE_CONFIG_H -I. -I. -I. @CPPFLAGS@ -g -O2 -c hello.c
gcc: @CPPFLAGS@: Datei oder Verzeichnis nicht gefunden
make: *** [hello.o] Error 1
The return of a "N'aucun ficher ou repertoire" / "No such file or
directory" bug :)
Ralf.
--
Ralf Corsepius
Forschungsinstitut f
63 matches
Mail list logo
