Re: [PATCH] posix-shell.m4: reject Solaris 11's /bin/sh (due to umask)

; (umask 0); umask' >>> > > We should also document this in the autoconf 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

Re: [PATCH] posix-shell.m4: reject Solaris 11's /bin/sh (due to umask)

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 Sola

Re: Detailed structure checks

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 sometime

Re: library search test fails, please help

-g -O2 > -I/Users/aaragon/Lib/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

Re: Redefinition of _FILE_OFFSET_BITS triggers an unusual amount of warnings in Solaris.

de-fixed/sys included by > string.h. > 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

Re: autoconf does not process README.in

README file? 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

Re: getting the file extension of a shared object

ib, you can do like ltdl: module=yes 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

Re: AC_LTDL_SHLIBEXT setting LT_MODULE_EXT with wrong extension on mac os x

_shlibext=$shrext_cmds or similar, then you will get the correct result. Peter -- Peter O'Gorman http://pogma.com ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: checking Mac OS X headers

On 11/14/2009 01:20 PM, Vincent Torri wrote: do you have an idea of how to do that ? I'd be inclined to just AC_CHECK_HEADERS([Cocoa/Cocoa.h]) Framework style includes like that should work with all Mac OS X compilers. Peter -- Peter O'Gorman http:/

-xc99=all and libraries on Solaris 10

d, perhaps it should be? Also, 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&#

Re: determining 32 v. 64 bit compilatio

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

Re: How does one specify linking to 64 bit libraries when there is a choice?

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 an

Re: -xc99=all and libraries on Solaris 10

CC_C99/AC_PROG_CC_STDC, it does, however add -xc99=all on solaris, so even 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 -

Re: Check for global symbol

On 01/26/2011 01:15 PM, tom fogal wrote: Sergio Belkin 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 use AC_CHECK_LI

Re: Use pipe and sed in configure.ac

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 config

Re: uint64_t fails with C++

On 12/07/2011 03:17 AM, 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 is de

Re: uint64_t fails with C++

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

Re: uint64_t fails with C++

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 #include and checking for HAVE_UINT64_T. HAVE_UINT64_T is *not* defined in my... Sorry, my bad

Re: How to force location of headers

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. Searchi

Re: libtool--release--2.0 test results

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 __

Re: Building all static

ey are available in the linker path. There should be no need for any lists of system shared objects. Peter -- Peter O'Gorman - http://www.pogma.com ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf

Re: Building all static

_static 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

Re: Building all static

you want to file a bug at http://bugreporter.apple.com, feel free :-). Peter -- Peter O'Gorman - http://www.pogma.com ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf

Re: nonstandard library directories

On Thu, 2006-06-29 at 21:38 -0600, Bob Proulx wrote: > So probably what you want is something similar to this: > > ./configure CPPFLAGS="-I /sw" LDFLAGS="-L /sw" Probably like this instead: ./configure CPPFLAGS="-I/sw/include" LDFLAGS="-L/sw/lib" Peter signature.asc Description: This is a d

Re: AC_PATH_XTRA and -rpath

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 chi

Re: why does autoconf check for all these extra compilers?

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 --host

Re: AC_PATH_XTRA and -rpath

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

Re: AC_PATH_XTRA and -rpath

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

Re: AC_FC_DUMMY_MAIN broken with gcc4/gfortran

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 n

Re: Autoconf fix Darwin/MacOS X Fortran

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 ele

Re: Autoconf fix Darwin/MacOS X Fortran

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 li

Re: Autoconf fix Darwin/MacOS X Fortran

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 w

Re: Mac OS X.4.8 build problem -- new macro for Autoconf

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. Tha

Stack direction check fails with optimizations

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

Re: Stack direction check fails with optimizations

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: [...]

Re: Darwin universal binaries and LDFLAGS conundrum

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 > autoc

Re: Darwin universal binaries and LDFLAGS conundrum

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 ag

Re: Darwin universal binaries and LDFLAGS conundrum

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 envi

Re: Mac OS X Leopard and conftest.dSYM directories

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

Re: Mac OS X Leopard and conftest.dSYM directories

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 >>

Re: Mac OS X Leopard and conftest.dSYM directories

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 wrot

Re: Mac OS X Leopard and conftest.dSYM directories

Ralf Wildenhues wrote: > [ > ] > > 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 con

Re: Mac OS X Leopard and conftest.dSYM directories

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 -f

Re: Mac OS X Leopard and conftest.dSYM directories

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'

Re: XCode 3.0 sys/types.h breaks AC_CACHE_CHECK for ac_cv_have_intxx_t

u 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/m

Re: Problems with AC_LANG_WERROR

to fix them, then consider removing AC_LANG_WERROR. That being said, I agree that there should 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

Re: Building Fat libraries with autoconf-based build systems

packages, you would 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

Re: aclocal or acinclude?

mbination with automake or not. If you use automake, or use its aclocal to generate aclocal.m4, then you can put your 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

Re: aclocal or acinclude?

hen you can put your 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. >> > > So then is it fair to say that acinclude.m4 is not

Re: just one of a million reasons why autoconf is a worthless piece of shit

les for this package because you do not have the correct tools installed (missing at least 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 co

Re: header check, cross compiling and compiler version?

etting CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib at configure time is sufficient. It is also possible to do this with gcc env 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

Re: failed build from git repo

n the system that you 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 ___ Auto

AC_C_BIGENDIAN answers "universal" on powerpc-aix

pect to have to deal 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

Re: AC_C_BIGENDIAN answers "universal" on powerpc-aix

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 rea

Re: AC_C_BIGENDIAN answers "universal" on powerpc-aix

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... uni

Re: document how to create universal binaries

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://pogma.com ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: document how to create universal binaries

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

Re: configure.ac, Makefile.am question

nly to be foiled by the lack of configure.ac and Makefile.am. By not distributing those files 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 ju

Re: mailing list behavior

ts that do things differently then they are they > unusual ones. I have to agree, only a very 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

Re: Noooooooooo!

ling 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 http://pogma.com ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf