This is actually a problem in AC_F77_LIBRARY_LDFLAGS, and may represent
the first general failure of the library detection scheme that we use.
Sigh..
If I correctly understand what you wrote, then your Fortran compiler
compiler passes the library paths to the "real" compiler by setting the
LPATH
> From: Matt Watson <[EMAIL PROTECTED]>
> Date: Mon, 25 Jun 2001 14:55:26 -0700
>
> My vote too. How often does configure come across a system which doesn't
> have a macro defining the byte order?
Fairly often. Solaris 8 has two macros (_BIG_ENDIAN and
_LITTLE_ENDIAN), but autoconf 2.50 doesn'
On Mon, 25 Jun 2001, Peter Eisentraut wrote:
> Mike Castle writes:
>
> > On Sun, Jun 24, 2001 at 01:51:27PM -0700, Matt Watson wrote:
> > > I'm trying to figure out the best way to fix this. Is the
> >
> > Fix the code so it doesn't require knowledge of the endianess of the
> > machine.
> >
> >
AC_C_INLINE loops through "inline", "__inline__", and "__inline" to
determine the proper keyword for inline support. These are used in the
following code fragment to test for inline support:
static $inline int static_foo () {return 0; }
$inline int foo () {return 0; }
The IRIX C compiler has
Paul Eggert wrote:
> [...]
> does OpenSSH 2.9p1. So AC_C_BIGENDIAN works only for native compiles.
> [...]
> Also, if you want to throw in cross-compiles for Solaris 8 while
> you're at it, append "|| defined _BIG_ENDIAN".
>
The topic of cross-compiling with ac_c_bigendian has been on the list
Mike Castle writes:
> On Sun, Jun 24, 2001 at 01:51:27PM -0700, Matt Watson wrote:
> > I'm trying to figure out the best way to fix this. Is the
>
> Fix the code so it doesn't require knowledge of the endianess of the
> machine.
>
> Personally, I'd vote for getting rid of AC_C_BIGENDIAN. No need
