From xemacs-m  Thu Jun  5 14:58:40 1997
Received: from iria.mines.u-nancy.fr (galibert@iria.mines.u-nancy.fr [193.49.140.100])
	by xemacs.org (8.8.5/8.8.5) with SMTP id OAA17430
	for <xemacs-beta@xemacs.org>; Thu, 5 Jun 1997 14:58:39 -0500 (CDT)
Received: (from galibert@localhost) by iria.mines.u-nancy.fr (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA21077; Thu, 5 Jun 1997 21:57:29 +0200
Message-ID: <19970605215728.38901@iria.mines.u-nancy.fr>
Date: Thu, 5 Jun 1997 21:57:28 +0200
From: Olivier Galibert <Olivier.Galibert@mines.u-nancy.fr>
To: Martin Buchholz <mrb@Eng.Sun.COM>
Cc: xemacs-beta@xemacs.org
Subject: Re: Why is XpmFree being erroneously checked as a function?
References: <m2910pbeb3.fsf@altair.xemacs.org> <199706051143.EAA09882@xemacs.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.74
In-Reply-To: <199706051143.EAA09882@xemacs.eng.sun.com>; from Martin Buchholz on Thu, Jun 05, 1997 at 04:43:06AM -0700

On Thu, Jun 05, 1997 at 04:43:06AM -0700, Martin Buchholz wrote:
> My Linux system I use for testing has no problems.  Ideally we would
> test for a symbol introduced in the *oldest* Xpm library that works.
Hmmm...tricky.

Actually, the SGI-provided libXpm may work were the corresponding
xpm.h provided. But it's not the case. The main problem on SGIs
is that there exists multiple "kinds" of librairies (old 32,
new 32, 64) within different directories (/usr/lib, /usr/lib32 and
/usr/lib64 respectively) but with common includes (/usr/include of
course). In my case, having installed a recent libXpm in n32 mode,
I had a false autodetection in o32...

Tricky...

We probably need a test program that looks like :

#include "X11/xpm.h"

int main()
{
  XpmFree(0);
  XpmReadFileToData(0, 0);
  return 0;
}

to phase out both old libs with new header and old header alone (since
the old header #defines XpmFree to free).

  OG.

