y
not just:
AC_CHECK_FUNC(connect, ,
AC_CHECK_LIB(socket, connect, X_EXTRA_LIBS="-lsocket $X_EXTRA_LIBS", ,
$X_EXTRA_LIBS))
--
albert chin ([EMAIL PROTECTED])
link, you get an unresolved
reference to the symbol open? Using AC_SYS_LARGEFILE should be
transparent to your program.
--
albert chin ([EMAIL PROTECTED])
Is there a reason autoconf doesn't use AC_PROG_SED internally to
select a more-appropriate sed command to use in config.status?
Could we just AC_REQUIRE(AC_PROG_SED) in _AC_OUTPUT_CONFIG_STATUS and
then use $SED throughout generation of config.status?
--
albert chin ([EMAIL PROT
On Wed, Dec 29, 2004 at 04:55:48PM +0100, Stepan Kasal wrote:
> On Wed, Dec 29, 2004 at 09:39:18AM -0600, Albert Chin wrote:
> > Is there a reason autoconf doesn't use AC_PROG_SED internally to
> > select a more-appropriate sed command to use in config.status?
> >
&g
On Wed, Dec 29, 2004 at 05:40:53PM +0100, Stepan Kasal wrote:
> On Wed, Dec 29, 2004 at 10:21:09AM -0600, Albert Chin wrote:
> > > Have you encountered any problem on a particular platform?
> >
> > Yes. When building kdevelop from kde-3.3.2 on Solaris 2.6, 7,
> > sub
on (i.e.
default behaviour is not what a typical Solaris user might expect).
> And now for something completely different:
>
> > Yep. I cannot AC_REQUIRE([AC_PROG_SED]) in a m4_define'd macro.
>
> If your approach wins,
On Wed, Dec 29, 2004 at 05:04:35PM -0600, Albert Chin wrote:
> On Wed, Dec 29, 2004 at 11:11:17PM +0100, Stepan Kasal wrote:
> > And now for something completely different:
> >
> > > Yep. I cannot AC_REQUIRE([AC_PROG_SED]) in a m4_define'd macro.
> >
>
If a program has;
1. Makefile.in's in each directory
2. AC_CONFIG_LIBOBJ_DIR(lib) in the top-level configure.ac
then how do subdirectory Makefile.in's make use of @[EMAIL PROTECTED] @LIBOBJ@
contains relative paths, rather than something looking like
$(top_builddir)/lib/func.o.
On Sat, Jan 08, 2005 at 01:01:30AM +0100, Alexandre Duret-Lutz wrote:
> >>> "Albert" == Albert Chin <[EMAIL PROTECTED]> writes:
>
> Albert> If a program has;
> Albert> 1. Makefile.in's in each directory
> Albert> 2. AC_CONFIG_LIBOBJ_DIR(lib
orks just about everywhere, as long as you have Perl.
You can find the source at:
ftp://ftp.gnu.org/gnu/autoconf
--
albert chin ([EMAIL PROTECTED])
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
On Mon, Feb 07, 2005 at 03:55:49PM -0500, Dan Manthey wrote:
> I instead just ask `test ${#ac_delim} -gt 1000', which gives six
> iterations with the current set up.
${#} isn't portable. I think this is:
_len=`expr "${ac_delim}" : ".*"
file so that autoconf doesn't croak?
If you know your compiler works, why not just delete the
AC_TRY_COMPILER line? Failing that, just AC_DEFUN it to nothing.
--
albert chin ([EMAIL PROTECTED])
___
Autoconf mailing list
Autoconf@gnu.org
htt
set_errcall_accept_dbe=no)])
> if test "$ac_cv_dbe_set_errcall_accept_dbe" = "yes"; then
> AC_DEFINE(HAVE_DBE_SET_ERRCALL_ACCEPT_DBE,1,
> [Define to 1 if DB_ENV->set_errcall() accepts DBE])
> fi
How about testing if conftest.err is non-empt
kse")
>
> which "seems to work". Can you or anybody else with more experience
> than me see any problems with it?
Depends. Won't work on Tru64 because pthread_create is a #define. Some
platforms have stub functions in libc so you don't need to -lpthread.
Getting pth
rtable to most unices)?
See m4/socklen.m4 from the gnulib project.
--
albert chin ([EMAIL PROTECTED])
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
f restrict.
Should AC_C_RESTRICT be updated to include a function call with
restrict in the parameter list to catch the above?
--
albert chin ([EMAIL PROTECTED])
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
On Fri, Mar 31, 2006 at 02:25:51PM -0600, Albert Chin wrote:
> Autoconf 2.59 chooses __restrict on HP-UX 11.x. Indeed, the following
> works:
> $ cat a.c
> void
> foo (int var) {
> float * __restrict x;
> }
>
> However, this fails:
> $ cat a.c
> void
>
On Mon, Apr 03, 2006 at 06:55:30PM +0200, Ralf Wildenhues wrote:
> Hi Albert,
>
> * Albert Chin wrote on Fri, Mar 31, 2006 at 10:40:14PM CEST:
> > On Fri, Mar 31, 2006 at 02:25:51PM -0600, Albert Chin wrote:
> > > Autoconf 2.59 chooses __restrict on HP-UX 11.x.
>
> >
> > The /bin/sh that comes with SunOS 4.1.4, when it processes a "."
> > command,
>
> SunOS 4 is the one before SunOS 5 which was Solaris 2.5.
No:
http://www.science.uva.nl/pub/solaris/solaris2.html
--
albert chin ([EMAIL PROTECTED])
__
r/X11R6/lib though?
--
albert chin ([EMAIL PROTECTED])
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
the latter, we have a problem.
>
> I used autoconf head with a simple configure.ac and Makefile.am, that I
> wrote just for this test. It failed. The -R flag was added on a machine
> that does not support -R.
Can you post a tarball of this? I need to test on some more systems.
--
albert chin ([EMAIL PROTECTED])
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
directory of the
test. Why not create a shell script that wraps the compiler executable
that removes these temporary files? Then, rebuild with:
./configure CC= ...
--
albert chin ([EMAIL PROTECTED])
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
test$ac_exeext m4_ifval([$1], [conftest.$ac_ext])[]dnl
> ])# _AC_LINK_IFELSE
What's the 8 in ipa8 for? Compiler version? Maybe ipa? instead?
--
albert chin ([EMAIL PROTECTED])
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
efine my_debug_macro(...) some_debug_function(__FILE__, __LINE__,
> __VA_ARGS__)
glib has this in configure.in:
# check for flavours of varargs macros
AC_MSG_CHECKING(for ISO C99 varargs macros in C)
...
--
albert chin ([EMAIL PROTECTED])
__
efine my_debug_macro(...) some_debug_function(__FILE__, __LINE__,
> __VA_ARGS__)
What nasty-gram are you getting. Seems to work fine with v7.0.0.6 of
the compiler.
--
albert chin ([EMAIL PROTECTED])
___
Autoconf mailing list
Autoconf@gnu.org
http:
ther everyone...I figured it out:
You can do what you want from within gcc. Just modify gcc so that when
it links a program, it automatically adds the runtime path to the
libstdc++.so library:
http://gcc.gnu.org/ml/gcc/2006-06/msg00820.html
--
albert chin ([EMAIL PROTECTED])
__
On Mon, Feb 19, 2007 at 11:08:40PM -0800, David Byron wrote:
> On Monday, February 19, 2007 @ 8:31p, Albert Chin wrote:
>
> > On Fri, Feb 16, 2007 at 06:37:58PM -0800, David Byron wrote:
> > > On Friday, February 16, 2007 @ 3:35p, David Byron wrote:
> > &g
iler I know of that
> needs a flag to grok ANSI code at all is HP-UX's.
With HP-UX 11.00 and above, -Aa (dunnot about -Ae) is the default.
--
albert chin ([EMAIL PROTECTED])
aying "Use libtool". I have other linker errors if I don't do a
> export LD=CC.
You should be using the HEAD branch of libtool, what will become 1.5.
It contains support for C++ and sets LD=CC.
--
albert chin ([EMAIL PROTECTED])
/tmp/xlcW0Xytrya
unlink: /tmp/xlcW1Xytryb
unlink: /tmp/xlcW2Xytryc
So, can we go back to 2.54 behaviour?
--
albert chin ([EMAIL PROTECTED])
On Sat, Nov 30, 2002 at 05:01:20PM +, Lars Hecking wrote:
> Albert Chin writes:
> > There seem to be problems with AC_CHECK_FUNCS on AIX with the IBM C
> > compiler (5.0.2.6). With autoconf 2.54, AC_CHECK_FUNCS(chflags)
> > outputs (b.c):
> [...]
> > The problem
Inconsistent for "gettimeofday".
This error also occurs on HP-UX 11.00 and 11i.
--
albert chin ([EMAIL PROTECTED])
On Mon, Dec 23, 2002 at 12:06:26AM -0800, Paul Eggert wrote:
> > Date: Sun, 22 Dec 2002 22:21:20 -0600
> > From: Albert Chin <[EMAIL PROTECTED]>
> >
> > Under, HP-UX 10.20, #include brings in which
> > defines a prototype for gettimeofday().
>
> H
ly.
There is a libtool mailing list:
http://www.gnu.org/software/libtool/
--
albert chin ([EMAIL PROTECTED])
a couple of years). Ostensibly to provide
> > > a prototype for exit(), it actually is used to allow
> > > glibc to tack a "throws" onto the exit() prototype.
> >
> > Thank you.
> >
> > Would it be reasonable to if/else it for gcc only?
>
&g
be undeclared or ambiguous.
...
Any way to change the #define to:
#ifndef __cplusplus
#define inline __inline
#endif
--
albert chin ([EMAIL PROTECTED])
've
> has some joy from th following (and no description are in the AC_DEFINEs).
>
> AH_VERBATIM(inline,
> [/* Define as `__inline' if that's what the C compiler calls it, or to nothing
>if it is not supported. */
> #ifndef __cplusplus
> #undef inline
> #end
On Tue, Jul 01, 2003 at 09:56:59AM -0700, Paul Eggert wrote:
> Albert Chin <[EMAIL PROTECTED]> writes:
>
> > How about the patch below.
>
> That patch (archived in
> <http://mail.gnu.org/archive/html/autoconf/2003-06/msg00099.html>)
> assumes that 'inl
On Tue, Jul 01, 2003 at 09:31:24AM -0700, Paul Eggert wrote:
> Albert Chin <[EMAIL PROTECTED]> writes:
>
> > How's this. I don't ifdef __GNUC__ as you mention glibc above
>
> > --- lib/autoconf/c.m4.orig Sun Dec 22 22:10:46 2002
> > +++ lib/a
oconf 2.59.
The solution is libtool. I'm sure the libtool list would be interested
in any problems you find.
--
albert chin ([EMAIL PROTECTED])
about -R. However, you might find this useful:
http://mail.gnu.org/archive/html/autoconf/2002-05/msg00124.html
It was mentioned recently on this list.
--
albert chin ([EMAIL PROTECTED])
ibution.
>
> How about moving these macros into Autoconf now?
I think libtool is the proper solution. If it's broken somehow, then
it should be fixed.
--
albert chin ([EMAIL PROTECTED])
nt
> to use this for the next release of NTP.
The proposed macro will fail on Tru64 UNIX, AIX, and HP-UX. This is
due to the limits discussed at the end of Bruno's email. Do we want a
macro that fails on these systems?
--
albert chin ([EMAIL PROTECTED])
On Thu, Jan 15, 2004 at 12:27:16AM +0100, Alexandre Duret-Lutz wrote:
> >>> "Dalibor" == Dalibor Topic <[EMAIL PROTECTED]> writes:
>
> IOW, config.rpath is not something that automake installs.
It's from gettext.
--
albert chin ([EMAIL PROTECTED])
ROG_LIBTOOL to expand before the macro. Since there is
> > none, it should expand within.
>
> If we're talking about libtool 1.5, then notice the first thing
> AC_PROG_LIBTOOL does is an AC_REQUIRE of _AC_PROG_LIBTOOL. :-(
So the fac that AC_PROG_LIBTOOL AC_REQUIRE's some
e
> whether LD_RUN_PATH/rpath is the right way to go, or if static linking
> will be required or whatever.
That doesn't help during the ./configure run. Bruno Haible (gettext
maintainer) has a solution for what you want:
http://mail.gnu.org/archive/html/autoconf/2002-05/msg00124.html
--
albert chin ([EMAIL PROTECTED])
However, the 'break 2' in
_AC_FEATURE_CHECK_LENGTH seems rather brittle. Looks like we need to
get out of the loop without 'break', to avoid an assumption about how
deeply nested we are.
What should I do? Set a variable to exit the loop?
--
albert chin ([EMAIL PROTECTED])
READ) is not proving useful due to not working on common
> platforms (e.g. Solaris).
Take a look at how OpenLDAP 2.0 does it (ftp.openldap.org). It should
be an improvement to how things were done in the 1.2 release.
--
albert chin ([EMAIL PROTECTED])
___
A
48 matches
Mail list logo
