On 04/09/2012 08:27 AM, Kabi wrote:
I am using AM_CFLAGS to include directories where make should look for
headers, but only headers surrounded by when included is overridden. make
is still looking for headers surrounded by in the directory with the
projects source .c files.
Searching for
On 03/07/2012 02:26 AM, Paul Eggert wrote:
On 03/06/2012 11:54 PM, Martin Dunja Zaun wrote:
The failures should be easily reproducible on a vanilla Solaris 11/x86_64.
Thanks, I guess someone with easy access to an installation of
that OS will have to dive in a bit more.
noexec seems to
On 12/07/2011 12:08 PM, Werner LEMBERG wrote:
#if defined UINT64_MAX || defined uint64_t
typedef uint64_t TA_ULongLong;
#else
# error No unsigned 64bit wide data type found.
#endif
stdint.h will not define UINT64_MAX if __cplusplus is defined unless
__STDC_LIMIT_MACROS
On 12/07/2011 01:04 PM, Werner LEMBERG wrote:
It's nothing to do with autoconf really, configure correctly finds
uint64_t, your C program then checks for UINT64_MAX or a uint64_t
macro instead of #includeconfig.h and checking for HAVE_UINT64_T.
HAVE_UINT64_T is *not* defined in
On 02/22/2011 04:04 PM, Eric Blake wrote:
[adding bug-m4]
On 02/22/2011 01:38 PM, Mike Stump wrote:
On Feb 22, 2011, at 11:00 AM, Eric Blake wrote:
Hmm, can you point to a URL of the web archive of that thread, to see if
I can glean anything from that discussion?
On 02/09/2011 09:39 PM, Lyre wrote:
PHPINC=`php-config --includes`
PHPCDIR=`php-config --configure-options | sed -n
's|.*--with-config-file-scan-dir=\([^ ]*\).*|\1|p'`
Probably the [] in your sed expression need extra quoting.
e.g.
\([[^ ]]*\)
You can verify by looking at the generated
On 01/26/2011 01:15 PM, tom fogal wrote:
Sergio Belkinseb...@gmail.com writes:
Hi,
Is there a way to check is a library function is global?
AC_TRY_COMPILE(...,
[extern rettype funcname(args);],
[funcname(...);]
)
This would need to be AC_TRY_LINK, but it's possible to just
though we consistently set CC,
CFLAGS and so on at build time, we sometimes get libraries with __xpg
symbols dependent on whether the configure.ac has one of those two
macros.
We patch our autoconf to not add -xc99=all to avoid the issue.
Peter
--
Peter O'Gorman
po...@thewrittenword.com
On 12/20/2010 10:54 AM, Bruce Korb wrote:
If the default build is 64 bit, why does it make sense that the
default library directory is the 32 bit library?
Because the user may not be building for multiple architectures, in
which case a default of $prefix/lib for libdir makes perfect sense
On 08/16/2010 07:37 AM, Paolo Bonzini wrote:
On 08/16/2010 12:54 AM, David Fang wrote:
Actually, 'pogma' pointed out that this comes from the autoconf macros
in libtool.m4, near AC_MSG_CHECKING([how to print strings]).
I'm using libtool-2.2.10 right now.
I don't understand, is it breaking in
On 06/30/2010 03:55 AM, Wesley Smith wrote:
I don't disagree, but let's consider this an academic exercise at this
point. I'd actually like to know how to do this regardless of whether
it violates anyones code sensibilities.
Before we answer your question, I'd like a clarification: what would
, does anyone happen to know what exactly libc does differently
with __xpg4=1 (the __xpg6 settings are documented in
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/inc/xpg6.h)
Peter
--
Peter O'Gorman
po...@thewrittenword.com
eval libltdl_cv_shlibext=$shrext_cmds
Or similarly but setting 'module=no' first.
Peter
--
Peter O'Gorman
http://pogma.com
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
? Usually this
file is read before the user ever runs ./configure, and contains package
specific information.
Peter
--
Peter O'Gorman
http://pogma.com
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
.
Aren't these warnings because of including config.h after string.h?
I think that they'll go away if you ensure that config.h is the first
thing included in every source file.
Peter
--
Peter O'Gorman
http://pogma.com
from him, and obviously that involves trying to keep my
requests trivially simple for him.
Where does -D_FORTIFY_SOURCE come from, without this
/usr/include/secure/_string.h would not be included.
Peter
--
Peter O'Gorman
http://pogma.com
/include -L/Users/aaragon/Lib/lib conftest.cpp
-lcpputils 5
Undefined symbols:
_flip, referenced from:
I'm guessing that the cpputils library does not define _flip. Does nm
-g libcpputils.a | grep _flip show it with a capital letter?
Peter
--
Peter O'Gorman
http://pogma.com
Tim Post wrote:
Hi Eric,
On Thu, 2008-11-27 at 20:53 -0700, Eric Blake wrote:
AC_CHECK_MEMBERS does what you want.
Thank you. I'm not sure how I could have missed that. Autoconf is
probably one of the best documented projects available .. the manual is
so massive that sometimes its
://paste.lisp.org/display/66595
Peter
--
Peter O'Gorman
http://pogma.com
manual.
Has it been reported? Seems like the kind of thing that could be fixed
before Solaris 11 is released.
http://defect.opensolaris.org/
Peter
--
Peter O'Gorman
http://pogma.com
Jim Meyering wrote:
Peter O'Gorman [EMAIL PROTECTED] wrote:
Eric Blake wrote:
According to Jim Meyering on 9/16/2008 3:58 AM:
Jim Meyering [EMAIL PROTECTED] wrote:
I discovered that Solaris 11's /bin/sh exhibits the following
surprising behavior:
$ /bin/sh -c 'umask 22; (umask 0
in the future.
Josef noted that he did not want this to change. I'm inclined to agree
with him, people who are cross-compiling may not have all of the `tools'
available as triplet-prefixed-name, but are likely to have their PATH
set correctly to point at the cross-tools.
Peter
--
Peter O'Gorman
few of the lists that I am subscribed to
set the Reply-To header.
Peter
--
Peter O'Gorman
http://pogma.com
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
is not enabled. At least that is how the manual documents
this.
Please commit with above changes, or tell me to do so for you, if you
agree with things.
If you could commit for me with those changes that would be great. I
don't have write access to autoconf.
Peter
--
Peter O'Gorman
[EMAIL PROTECTED]
you will harm the portability of your
software, those with different systems will be unable to send you
patches, only bug reports (and they may not even bother with bug
reports, personally, I would just give up and delete it).
Peter
--
Peter O'Gorman
http://pogma.com
not sure
it is best to put this in the INSTALL document without any warnings or
caveats.
Apple recommends building once per architecture (on a machine that can
do so natively) and using lipo to create a universal binary. That way
most of the problems are avoided.
Peter
--
Peter O'Gorman
http
Bruno Haible wrote:
Peter O'Gorman wrote:
+On MacOS X systems, you can create libraries and executables that work
For 10.4.x ppc you had to install an SDK and add -isysroot flags.
ok, please change to doc patch to say On MacOS X systems, version 10.5
or newer.
For automake using projects
Ralf mentioned that he was going to do some testing (I have tested
powerpc-aix and i386-darwin, not got to linux yet), I am happy to wait
until his testing is done and ask him to push it when he's satisfied
(assuming that is ok with Ralf).
Peter
--
Peter O'Gorman
[EMAIL PROTECTED]
WORDS_BIGENDIAN */
# endif
when building on an x86-darwin machine. That is, of course, wrong.
Peter
--
Peter O'Gorman
[EMAIL PROTECTED]
On Wed, Aug 13, 2008 at 08:19:03PM -0600, Eric Blake wrote:
According to Peter O'Gorman on 8/13/2008 12:13 PM:
| Hi,
|
| checking whether byte ordering is bigendian... universal is not the
| correct answer on powerpc-ibm-aix. The question is not really correct
| either (yes/no question
On Thu, Aug 14, 2008 at 09:39:32AM -0500, Peter O'Gorman wrote:
On Wed, Aug 13, 2008 at 08:19:03PM -0600, Eric Blake wrote:
According to Peter O'Gorman on 8/13/2008 12:13 PM:
| Hi,
|
| checking whether byte ordering is bigendian... universal is not the
| correct answer on powerpc-ibm
is occuring.
universal)
+ AC_DEFINE([AC_APPLE_UNIVERSAL_BUILD],1,[Define if building universal])
s/universal/ (internal helper macro)/ ???
Good idea.
Peter
--
Peter O'Gorman
[EMAIL PROTECTED]
builds it will have the __BIG_ENDIAN__ macro defined and set to 1,
regardless of the build machines endianness.
Peter
--
Peter O'Gorman
[EMAIL PROTECTED]
On Wed, Aug 13, 2008 at 08:19:03PM -0600, Eric Blake wrote:
According to Peter O'Gorman on 8/13/2008 12:13 PM:
| Hi,
|
| checking whether byte ordering is bigendian... universal is not the
| correct answer on powerpc-ibm-aix. The question is not really correct
| either (yes/no question
On Thu, Aug 14, 2008 at 09:39:32AM -0500, Peter O'Gorman wrote:
On Wed, Aug 13, 2008 at 08:19:03PM -0600, Eric Blake wrote:
According to Peter O'Gorman on 8/13/2008 12:13 PM:
| Hi,
|
| checking whether byte ordering is bigendian... universal is not the
| correct answer on powerpc-ibm
with universal binary issues, it came as a
bit of a surprise on aix though.
Peter
--
Peter O'Gorman
[EMAIL PROTECTED]
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
are
bootstrapping on, or it is not in your path, things will fail like this.
You can work around it by doing 'echo 2.62a .tarball-version' before
you bootstrap.
Peter
--
Peter O'Gorman
http://pogma.com
___
Autoconf mailing list
Autoconf@gnu.org
http
Peter O'Gorman wrote:
[cross-posting, if emails from mailman about awaiting moderator approval
bother you, feel free to drop xquartz-dev]
Hi,
Martin Costabel reported on Apple's xquartz-dev mailing list that
AC_PATH_X fails to work on the latest release candidate of X11 for Mac
OS X
the test take
longer, of course. There is also the possibility that autoconf use
pkgconfig to check for the X11 .pc files.
We are hoping to persuade Jeremy to add xmkmf and imake back before the
next release as a workaround, but this is really an autoconf problem.
Thanks,
Peter
--
Peter O'Gorman
http
Peter O'Gorman wrote:
[cross-posting, if emails from mailman about awaiting moderator approval
bother you, feel free to drop xquartz-dev]
Hi,
Martin Costabel reported on Apple's xquartz-dev mailing list that
AC_PATH_X fails to work on the latest release candidate of X11 for Mac
OS X
vars LIBRARY_PATH and CPATH.
Does this answer your question?
Peter
--
Peter O'Gorman
http://pogma.com
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
://git.savannah.gnu.org/gitweb/?p=m4.git;a=commitdiff;h=c1841dc6d2e95ebe4f4c705a36254447957152c2
Peter
--
Peter O'Gorman
http://pogma.com
the gnome
package intltool).
Why are you trying to generate these files? They should have been
included in the tarball that you downloaded. If they were not, then
complain to the package author.
Peter
--
Peter O'Gorman
http://pogma.com
___
Autoconf mailing
own macros in acinclude.m4. The aclocal program
will m4_include acinclude.m4 at the end of the generated aclocal.m4.
autoconf itself knows nothing about acinclude.m4.
Peter
--
Peter O'Gorman
http://pogma.com
___
Autoconf mailing list
Autoconf@gnu.org
does not mention this file, only aclocal.m4 and acsite.m4.
Tim
No, see the automake manual
http://www.gnu.org/software/automake/manual/automake.html#Examples
Peter
--
Peter O'Gorman
http://pogma.com
___
Autoconf mailing list
Autoconf@gnu.org
http
have to give
details of what is failing (including the error message) if it fails for
you.
Peter
--
Peter O'Gorman
http://pogma.com
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
./configure; make; make check; make distcheck
Should work around the problem also (untested though).
Peter
--
Peter O'Gorman
http://pogma.com
be a public method to turn it
on and off for individual tests without resorting to changing the value
of ac_c_werror_flag (it is set to yes or no).
Peter
--
Peter O'Gorman
http://pogma.com
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org
Paul Eggert wrote:
Peter O'Gorman [EMAIL PROTECTED] writes:
After macro expansion that line turns into:
{ do { *yy_cp = yy_hold_char; yy_c_buf_p = yy_cp = yy_bp + input () !=
0 - 0; yytext = yy_bp; yyleng = (int) (yy_cp - yy_bp); yy_hold_char =
*yy_cp; *yy_cp = '\0'; yy_c_buf_p = yy_cp
Paul Eggert wrote:
Peter O'Gorman [EMAIL PROTECTED] writes:
I see no reason why autoconf should not work with flex-2.5.4 though.
I suppose it depends on what one means by work. My own suggestion
would be for Autoconf to reject a lex implementation that does not
implement yyless correctly
Peter O'Gorman wrote:
Now, looking at the expanded version, I am unsure if my patch is
correct, is the test supposed to be that input() != 0 or that (yy_bp +
input ()) != 0 ? At the moment, due to operator precedence, it is
testing that yy_bp + input () is non-zero, is that intentional
Paul Eggert wrote:
Peter O'Gorman [EMAIL PROTECTED] writes:
-e { yyless (input () != 0); }
+e { yyless ((input () != 0)); }
Why is this patch necessary? yyless is supposed to take an int
parameter, and another set of parentheses shouldn't affect the
parameter's type or value.
After
move the header checks to just after the compiler
check, rerun autoconf, and configure again, you should have better
results.
Thanks,
Peter
--
Peter O'Gorman
http://pogma.com
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org
On 12-Nov-07, at 1:39 PM, Ralf Wildenhues wrote:
make check TESTSUITEFLAGS='-v -x -k libtool'
I don't see any dSYM.
Thanks!
Peter
Ralf Wildenhues wrote:
* Peter O'Gorman wrote on Mon, Nov 12, 2007 at 06:44:36AM CET:
On 11-Nov-07, at 8:41 AM, Ralf Wildenhues wrote:
OK? Could somebody with Leopard access please test this by running
make all check TESTSUITEFLAGS='-v -x'
Looks like one or two spots were missed.
Here
On 12-Nov-07, at 1:39 PM, Ralf Wildenhues wrote:
make check TESTSUITEFLAGS='-v -x -k libtool'
I don't see any dSYM.
Thanks!
Peter
Ralf Wildenhues wrote:
[ http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/5811/focus=5817
]
AFAICS Automake needs no changes.
Proposed patches for Libtool HEAD and branch-1-5. OK?
It is okay with me. You sure that you want to proceed this way, rather
than changing
rm conftest*
On 11-Nov-07, at 8:41 AM, Ralf Wildenhues wrote:
Proposed patch for Autoconf (adding Jeff to THANKS not shown).
We can thank Apple for needing one more fork per link test now. :-/
FWIW, I do think that, of the fortran.m4 changes, all but the first
hunk
are not necessary, rather, the `rm
Jeff Squyres wrote:
Ralf -- thanks for reporting this; I had a hectic week and could not get
to this issue before now. We noticed this issue in the context of the
Open MPI project (my laptop is a MacBook, just recently upgraded to
Leopard). Note that I am *not* an OS X expert!
Here's the
Peter O'Gorman wrote:
Jeff Squyres wrote:
Ralf -- thanks for reporting this; I had a hectic week and could not get
to this issue before now. We noticed this issue in the context of the
Open MPI project (my laptop is a MacBook, just recently upgraded to
Leopard). Note that I am *not* an OS X
Ralf Wildenhues wrote:
Hello Peter, Jeff,
Thanks for your additional information; and thanks, Peter, for trying to
work against this, umm, a bit ugly situation.
* Peter O'Gorman wrote on Sat, Nov 10, 2007 at 04:01:09PM CET:
Peter O'Gorman wrote:
When you do cc -o foo foo.c,
Of course, I
On Jun 10, 2007, at 4:35 AM, Ralf Wildenhues wrote:
Hello Peter, all,
* Peter O'Gorman wrote on Sun, Jun 03, 2007 at 07:37:39AM CEST:
2007-06-03 Peter O'Gorman [EMAIL PROTECTED]
[...]
+AT_SETUP([static library contains static library])
[...]
+archive_contents=`ar -t libbar.a
On Thu, 2007-05-24 at 09:56 +1000, Bill Northcott wrote:
On 24/05/2007, at 2:00 AM, Martin-Gilles Lavoie wrote:
To resume the problem, I need to build a Universal Binary (aka, PPC +
i386) library of BerkeleyDB. Now, normally, this is a simple task but
it seems Autoconfig is working against
On Thu, 2007-05-24 at 14:16 -0400, Martin-Gilles Lavoie wrote:
On 23 mai 2007, at 10:03, Martin-Gilles Lavoie wrote:
This is just an update on the status of my problem for you guys to be
curious at. At this moment, I'm waiting for some info from the
BerkeleyDB guys (their autoconf
On Wed, 2007-05-23 at 10:03 -0400, Martin-Gilles Lavoie wrote:
Greetings
First, I'd like to apologize upfront for the sheer autoconf noob-ness
this post might impose on vets possibly on this list. But as luck
would have it, I seem to be stuck with the job of dealing with an
On Mar 6, 2007, at 9:50 AM, Paul Eggert wrote:
Peter O'Gorman [EMAIL PROTECTED] writes:
What if the package does not use AC_CONFIG_HEADERS? This patch will
fail. What about AC_CHECK_SIZEOF which will report incorrect results
if -arch i386 -arch x86_64 are specified for example?
Those
On Mar 6, 2007, at 9:50 AM, Paul Eggert wrote:
Peter O'Gorman [EMAIL PROTECTED] writes:
What if the package does not use AC_CONFIG_HEADERS? This patch will
fail. What about AC_CHECK_SIZEOF which will report incorrect results
if -arch i386 -arch x86_64 are specified for example?
Those
On Feb 28, 2007, at 12:47 PM, Elias Pipping wrote:
Hello,
autoconf fails for me with
177: AC_C_BIGENDIAN FAILED (semantics.at:478)
I am not sure it is worth the effort to get autoconf clean for
Apple's universal builds. The whole autoconf philosophy is about
checking
On Mar 1, 2007, at 8:34 AM, Elias Pipping wrote:
On Mar 1, 2007, at 12:18 AM, Peter O'Gorman wrote:
Apple suggests using their lipo tool to create universal binaries
from multiple single architecture runs of configure and make.
Where do they do that? I was following
http
On Mar 1, 2007, at 9:20 AM, Paul Eggert wrote:
Elias Pipping [EMAIL PROTECTED] writes:
autoconf fails for me with
177: AC_C_BIGENDIAN FAILED (semantics.at:478)
Thanks for testing this. I have installed the following additional
patch, which I hope fixes your problem. It also fixes
On Feb 28, 2007, at 12:47 PM, Elias Pipping wrote:
Hello,
autoconf fails for me with
177: AC_C_BIGENDIAN FAILED (semantics.at:478)
I am not sure it is worth the effort to get autoconf clean for
Apple's universal builds. The whole autoconf philosophy is about
checking
On Dec 13, 2006, at 9:48 PM, Ralf Wildenhues wrote:
Hi Peter,
Hi Ralf,
* Peter O'Gorman wrote on Tue, Dec 12, 2006 at 01:26:42PM CET:
There is a test to check the stack direction when building the
replacement alloca. This test returns bad results with optimizations:
[...]
exit
Hi,
Really I discovered this issue when building mysql, but they swiped a
test from autoconf to check the stack direction, so I'll ask here.
There is a test to check the stack direction when building the
replacement alloca. This test returns bad results with optimizations:
Solaris 10/x86
% cat
On Dec 11, 2006, at 3:21 AM, Bruce Korb wrote:
Hi Ralf,
This is far too putrid to expect people to spin off of the
top of their heads. I think it is Darwin's fault that it
is so hard, but autoconf should include this macro so that
folks-other-than-gurus can successfully cope with wint_t.
On Aug 28, 2006, at 1:03 AM, Ralf Wildenhues wrote:
Hello Peter,
* Peter O'Gorman wrote on Sat, Aug 26, 2006 at 04:16:19PM CEST:
I don't believe that there is a case in libtool where darwin uses -
nostdlib. If there is such a case that I missed please let me know
and I will fix
On Aug 25, 2006, at 3:54 PM, Ralf Wildenhues wrote:
Hi Ralf,
Well, on some systems (also Darwin in some cases), Libtool uses
-nostdlib in shared library creation. Wouldn't omitting gcc_s in this
case cause missing symbols, at least if the output file is a module
(say, it uses Fortran) and
On Aug 24, 2006, at 9:34 PM, Bill Northcott wrote:
Following my last post I have done some digging on AC_FC_DUMMY_MAIN.
Using gcc4 and gfortran FLIBS include '-lgfortranbegin -
lgfortran'. libgfortranbegin defines _main and needs _MAIN__
Since the test program also defines _main it will
On Aug 24, 2006, at 5:06 PM, Ralf Wildenhues wrote:
Hello Bill,
* Bill Northcott wrote on Thu, Aug 24, 2006 at 09:59:40AM CEST:
In lib/autoconf/fortran.m4 (v2.60 and cvs) there is a macro
_AC_FC_LIBRARY_LDFLAGS which defines FLIBS for linking Fortran code.
Darwin/MacOS X also include
On Mon, 2006-07-17 at 14:41 -0700, Paul Eggert wrote:
Patrick Welche [EMAIL PROTECTED] writes:
so the -R made it, and all is well :-)
I can't check the opposite though: do systems that don't want rpath get
one now?
Yes, they probably do. Perhaps the libtool guys can chime in on
On Thu, 2006-07-20 at 08:55 -0700, Paul Eggert wrote:
Peter O'Gorman [EMAIL PROTECTED] writes:
This patch will now add -R to X_LIBS for all systems.
It's not supposed to. It's supposed to try -R, and add it only if it
worked.
I tried just
now on Mac OS X to see the result: powerpc
On Thu, 2006-07-20 at 15:39 -0700, Paul Eggert wrote:
Peter O'Gorman [EMAIL PROTECTED] writes:
see http://pogma.com/misc/autoscrewup.txt for the transcript.
Thanks for checking this. Please bear with me, as I can't easily
test this directly. How about the following further patch, which
On Mon, 2006-07-17 at 14:41 -0700, Paul Eggert wrote:
Patrick Welche [EMAIL PROTECTED] writes:
so the -R made it, and all is well :-)
I can't check the opposite though: do systems that don't want rpath get
one now?
Yes, they probably do. Perhaps the libtool guys can chime in on
On Thu, 2006-07-20 at 08:44 -0600, Ed Hartnett wrote:
Howdy all!
I use autoconf to build my library.
When attempting to do a mingw cross-compile, the configure script
checks for a whole bunch of extra compilers. What's up with that?
If I do this:
bash-3.1$ ./configure
On Thu, 2006-07-20 at 08:55 -0700, Paul Eggert wrote:
Peter O'Gorman [EMAIL PROTECTED] writes:
This patch will now add -R to X_LIBS for all systems.
It's not supposed to. It's supposed to try -R, and add it only if it
worked.
I tried just
now on Mac OS X to see the result: powerpc
is not set. I am saying that even
without this flag libtool can and should look for static libraries in favor
of shared ones if -static is on the command line.
Peter
--
Peter O'Gorman - http://www.pogma.com
___
Autoconf mailing list
[EMAIL PROTECTED]
http
, feel free :-).
Peter
--
Peter O'Gorman - http://www.pogma.com
___
Autoconf mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/autoconf
to the libtool branch-1-5
configure.ac, sorry. Won't take but a minute.
But yes, it is very annoying that g++ is returned when no valid c++ compiler
is found. Is there any valid reason for this?
Peter
--
Peter O'Gorman - http://www.pogma.com
___
Autoconf
87 matches
Mail list logo
