That is fixed in autoconf-2.63. The m4 macro you are referring to is
AC_X_PATH.
If you see a port failing this, first check if it is REALLY failing.
Some ports do AC_X_PATH followed by some PKG_CONFIG checks for X11
(IMO, this itself is a bug since the PKG_CONFIG results are far
superior to the AC_X_PATH results)... but none the less, make sure the
port is actually failing to find X. If it is misbehaving, you
probably need to:
depends_build port:autoconf # and probably port:automake and
port:libtool too
use_autoreconf yes
If that fails, you may need to do some autoreconf.env setting like:
autoreconf.env ACLOCAL="aclocal -I <some path the tarball stores m4
macros>"
See the x11/lesstif port. That one was particularly annoying.
Setting '--x-include=${x11prefix}/include --x-lib=${x11prefix}/lib' is
not the best way to address that.
--Jeremy
On Dec 14, 2008, at 16:34, Fred Dushin wrote:
I've found a few ports that have had issues checking for X11
libraries and headers during configuration. Hacking my way through
the configure scripts, I've found lines in the checking of X11 libs
like:
for ac_extension in a so sl; do
which of course works fine on Solaris, Linux, BSD, and HP/UX.
Changing this to:
for ac_extension in a so sl dylib; do
fixes the configure phase, and the package then installs properly.
I found this lately with the start-notification package, and I'm
wonder if I am doing something fundamentally wrong. There have been
others like this in the past, but I didn't take record of them.
Model Name: MacBook
Model Identifier: MacBook2,1
System Version: Mac OS X 10.5.5 (9F33)
> port version
Version: 1.700
XQuartz 2.3.1
I also installed the X11SDK from the Leopard install disk, just to
make sure.
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
