bug#2280: 23.0.90; incorrect configuration

bug#2280: 23.0.90; incorrect configuration

[Peter Dyballa]

Hello!

When I try to configure GNU Emacs to use the X11R7.4 installation  
from MacPorts, installed under /opt, the configure script commands:

	checking whether it is safe to define __EXTENSIONS__... yes
	checking whether gcc understands -Wno-pointer-sign... yes
	checking whether ln -s works... yes
	checking how to run the C preprocessor... cc -E -no-cpp-precomp -I/ 
sw/include -L/sw/lib
	checking for a BSD-compatible install... /usr/bin/install -c
	checking for ranlib... ranlib

i.e., it uses a completely not competent installation (that of Fink).  
The product that gets built with this settings is unusable:

	Connection lost to X server `:0.0'

To become able to compile an usable GNU Emacs I have rename /sw to  
something different, which brings some other problems, because a few  
of the GNU utilities (ls, du) are used by GNU Emacs – and also pkg- 
config (OK, I found that this Perl script works incorrectly, so I  
need to use the MacPorts substitute).

This /sw preferential treatment also happens when I invoke as compile  
command:

	./configure --without-sound --without-pop --with-dbus --with-libotf  
--enable-locallisppath=/Library/Application\ Support/Emacs/ 
calendar23:/Library/Application\ Support/Emacs PKG_CONFIG_PATH=/opt/ 
local/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig  
CFLAGS="-Wno-pointer-sign -H -pipe -fPIC -mcpu=7450 -mtune=7450 -fast  
-mpim-altivec -ftree-vectorize -foptimize-register-move -freorder- 
blocks -freorder-blocks-and-partition -fthread-jumps -fpeephole -fno- 
crossjumping" CXXFLAGS="-no-cpp-precomp -I/opt/local/include"  
CPPFLAGS="-no-cpp-precomp -I/opt/local/include -idirafter -I/usr/ 
X11R6/include" LDFLAGS="-dead_strip -multiply_defined suppress -L/opt/ 
local/lib" PKG_CONFIG=/opt/local/bin/pkg-config

(exec-path and shell's PATH both start with /opt/local/bin) or a  
variation like this:

	env CXXFLAGS="-no-cpp-precomp -I/opt/local/include" CPPFLAGS="-no- 
cpp-precomp -I/opt/local/include -idirafter -I/usr/X11R6/include"  
LDFLAGS="-dead_strip -multiply_defined suppress -L/opt/local/lib"  
PKG_CONFIG=/opt/local/bin/pkg-config ./configure --without-sound -- 
without-pop --with-dbus --with-libotf --enable-locallisppath=/Library/ 
Application\ Support/Emacs/calendar23:/Library/Application\ Support/ 
Emacs PKG_CONFIG_PATH=/opt/local/lib/pkgconfig:/usr/local/lib/ 
pkgconfig:/usr/lib/pkgconfig CFLAGS="-Wno-pointer-sign -H -pipe -fPIC  
-mcpu=7450 -mtune=7450 -fast -mpim-altivec -ftree-vectorize - 
foptimize-register-move -freorder-blocks -freorder-blocks-and- 
partition -fthread-jumps -fpeephole -fno-crossjumping"

In this successful configuration the configure script simply reports:

	checking whether it is safe to define __EXTENSIONS__... yes
	checking whether gcc understands -Wno-pointer-sign... yes
	checking whether ln -s works... yes
	checking how to run the C preprocessor... cc -E -no-cpp-precomp
	checking for a BSD-compatible install... /usr/bin/install -c
	checking for ranlib... ranlib



In GNU Emacs 23.0.90.1 (powerpc-apple-darwin8.11.0, GTK+ Version 2.14.7)
  of 2009-02-11 on localhost
Windowing system distributor `The X.Org Foundation', version  
11.0.10402000
configured using `configure  '--without-sound' '--without-pop' '-- 
with-dbus' '--with-libotf' '--enable-locallisppath=/Library/ 
Application Support/Emacs/calendar23:/Library/Application Support/ 
Emacs' 'PKG_CONFIG_PATH=/opt/local/lib/pkgconfig:/usr/local/lib/ 
pkgconfig:/usr/lib/pkgconfig' 'CFLAGS=-Wno-pointer-sign -H -pipe - 
fPIC -mcpu=7450 -mtune=7450 -fast -mpim-altivec -ftree-vectorize - 
foptimize-register-move -freorder-blocks -freorder-blocks-and- 
partition -fthread-jumps -fpeephole -fno-crossjumping' 'CXXFLAGS=-no- 
cpp-precomp -I/opt/local/include' 'CPPFLAGS=-no-cpp-precomp -I/opt/ 
local/include' 'LDFLAGS=-dead_strip -multiply_defined suppress -L/opt/ 
local/lib' 'PKG_CONFIG=/opt/local/bin/pkg-config''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: de_DE.UTF-8
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: de_DE.UTF-8
   value of $XMODIFIERS: nil
   locale-coding-system: utf-8-unix
   default-enable-multibyte-characters: t

Major mode: Man

Minor modes in effect:
   show-paren-mode: t
   display-time-mode: t
   tooltip-mode: t
   tool-bar-mode: t
   mouse-wheel-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   global-auto-composition-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   column-number-mode: t
   line-number-mode: t
   transient-mark-mode: t

--
Greetings

   Pete

We have to expect it, otherwise we would be surprised.

bug#2280: 23.0.90; incorrect configuration

[Peter Dyballa]

Hello!

The situation seems to be even worse than I described before! Passing  
to configure "--x-includes=/opt/local/include --x-libraries=/opt/ 
local/lib" I see now twice the inappropriate /sw containing lines  
(CVS update in-between):

checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... cc -E -no-cpp-precomp -I/sw/ 
include -L/sw/lib
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for AIX... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether gcc understands -Wno-pointer-sign... yes
checking whether ln -s works... yes
checking how to run the C preprocessor... cc -E -no-cpp-precomp -I/sw/ 
include -L/sw/lib
checking for a BSD-compatible install... /usr/bin/install -c
checking for ranlib... ranlib

and in the end configure reports:

   What compiler should emacs be built with?               gcc -I/sw/ 
include -L/sw/lib -Wno-pointer-sign -H -pipe -fPIC -mcpu=7450 - 
mtune=7450 -fast -mpim-altivec -ftree-vectorize -foptimize-register- 
move -freorder-blocks -freorder-blocks-and-partition -fthread-jumps - 
fpeephole -fno-crossjumping


Let's see how this builds!

--
Greetings

   Pete

If you don't find it in the index, look very carefully through the  
entire catalogue.
	–  Sears, Roebuck, and Co., Consumer's Guide, 1897

bug#2280: 23.0.90; incorrect configuration

[Chong Yidong]

Hi Peter,

Going back to this bug report from Feb, did you manage to solve the
problem?


> When I try to configure GNU Emacs to use the X11R7.4 installation from
> MacPorts, installed under /opt, the configure script commands:

> 	checking whether it is safe to define __EXTENSIONS__... yes
> 	checking whether gcc understands -Wno-pointer-sign... yes
> 	checking whether ln -s works... yes
> 	checking how to run the C preprocessor... cc -E -no-cpp-precomp -I/sw/include -L/sw/lib
> 	checking for a BSD-compatible install... /usr/bin/install -c
> 	checking for ranlib... ranlib

> i.e., it uses a completely not competent installation (that of Fink).

bug#2280: 23.0.90; incorrect configuration

[Peter Dyballa]

Am 02.01.2010 um 22:32 schrieb Chong Yidong:

> Going back to this bug report from Feb, did you manage to solve the
> problem?


I "patch" the "patched" configure script to either use the default /sw  
setting (for Fink) or I comment this block and uncomment my block  
which adds in paths to /opt/local (MacPorts). I just have to think of  
it before I start to configure.

The /sw related paths to libraries and C header files are put in front  
so that they override everything sensible.

--
Greetings

   Pete

With Capitalism man exploits man. With communism it's the exact  
opposite.

bug#2280: 23.0.90; incorrect configuration

[Chong Yidong]

> > Going back to this bug report from Feb, did you manage to solve the
> > problem?
>
> I "patch" the "patched" configure script to either use the default /sw
> setting (for Fink) or I comment this block and uncomment my block
> which adds in paths to /opt/local (MacPorts). I just have to think of
> it before I start to configure.

Does the following patch solve the problem for you?

*** emacs/configure~	2009-12-30 20:38:31.000000000 -0500
--- emacs/configure	2010-01-09 19:09:55.000000000 -0500
***************
*** 2742,2747 ****
--- 2742,2752 ----
        GCC_TEST_OPTIONS="-I/sw/include -L/sw/lib"
        CPP="${CPP} ${GCC_TEST_OPTIONS}"
        NON_GCC_TEST_OPTIONS=${GCC_TEST_OPTIONS}
+     # Or use MacPorts packages if available.
+     elif test -d /opt/local/include && test -d /opt/local/lib; then
+       GCC_TEST_OPTIONS="-I/opt/local/include -L/opt/local/lib"
+       CPP="${CPP} ${GCC_TEST_OPTIONS}"
+       NON_GCC_TEST_OPTIONS=${GCC_TEST_OPTIONS}
      fi
    ;;
  
*** emacs/configure.in~	2010-01-04 05:35:18 +0000
--- emacs/configure.in	2010-01-10 00:09:03 +0000
***************
*** 475,480 ****
--- 475,485 ----
        GCC_TEST_OPTIONS="-I/sw/include -L/sw/lib"
        CPP="${CPP} ${GCC_TEST_OPTIONS}"
        NON_GCC_TEST_OPTIONS=${GCC_TEST_OPTIONS}
+     # Or use MacPorts packages if available.
+     elif test -d /opt/local/include && test -d /opt/local/lib; then
+       GCC_TEST_OPTIONS="-I/opt/local/include -L/opt/local/lib"
+       CPP="${CPP} ${GCC_TEST_OPTIONS}"
+       NON_GCC_TEST_OPTIONS=${GCC_TEST_OPTIONS}
      fi
    ;;

bug#2280: 23.0.90; incorrect configuration

[Peter Dyballa]

Am 10.01.2010 um 01:11 schrieb Chong Yidong:

> Does the following patch solve the problem for you?


No. What will happen when both package managers are installed? (And I  
think there are two more for Mac OS X which I haven't tested yet.)  
Removal of this block is another option – what led to its inclusion?  
CPPFLAGS, LDFLAGS etc. allow to use this or that software. Or another  
command line option...

--
Greetings

   Pete

Clovis' Consideration of an Atmospheric Anomaly:
         The perversity of nature is nowhere better demonstrated than  
by the fact that, when exposed to the same atmosphere, bread becomes  
hard while crackers become soft

bug#2280: 23.0.90; incorrect configuration

[Glenn Morris]

I agree with the suggestion to just remove this bit from configure.in:

    # Use fink packages if available.
    if test -d /sw/include && test -d /sw/lib; then
      GCC_TEST_OPTIONS="-I/sw/include -L/sw/lib"
      CPP_TEST_OPTIONS=${GCC_TEST_OPTIONS}
      NON_GCC_TEST_OPTIONS=${GCC_TEST_OPTIONS}
    fi

It's not Emacs's business to make this kind of decision.

bug#2280: 23.0.90; incorrect configuration

[Stefan Monnier]

> I agree with the suggestion to just remove this bit from configure.in:
>     # Use fink packages if available.
>     if test -d /sw/include && test -d /sw/lib; then
>       GCC_TEST_OPTIONS="-I/sw/include -L/sw/lib"
>       CPP_TEST_OPTIONS=${GCC_TEST_OPTIONS}
>       NON_GCC_TEST_OPTIONS=${GCC_TEST_OPTIONS}
>     fi
> It's not Emacs's business to make this kind of decision.

My motivation was to make it easy for Mac OS X users who like their Mac
to be more GNU-like (and hence install the typical GNU packages via
Fink).

I think this motivation is still valid and makes sense for a GNU package
like Emacs, so I'd rather not flat-out remove it.  It might need to be
revised/refined/improved, tho.
E.g. Chong's patch to add support for MacPorts makes sense.

Of course, there's the issue of which one to choose if both MacPorts and
Fink are found, as well as the issue of finding an old left-over Fink or
MacPorts installation.

One reason to add these lines was that stock Mac OS X was missing some
of the libraries we used commonly back then (e.g. Xaw3d).  So maybe one
way forward is to look more carefully at which libs we normally want to
get from Fink/MacPorts (because they're missing from Mac OS X) and then
check which ones of these are installed where.


        Stefan


PS: We should probably also contact the Fink and MacPorts team to see if
they could fix their respective home page to not only mention "open
source" but also "free software".

bug#2280: 23.0.90; incorrect configuration

[Glenn Morris]

Stefan Monnier wrote:

> Of course, there's the issue of which one to choose if both MacPorts and
> Fink are found, as well as the issue of finding an old left-over Fink or
> MacPorts installation.

As reported in bugs #5252, #5921, #6819, ...

> So maybe one way forward is to look more carefully at which libs we
> normally want to get from Fink/MacPorts (because they're missing from
> Mac OS X) and then check which ones of these are installed where.

I disagree about the usefulness of this. I think it is straightforward
to add in those search paths if you want them (users of those package
systems may well be used to doing so), but not so easy to override
configure if it makes the decision for you (and without really telling
you about it).

If we really must have this, then the suggestion of --with-fink,
--with-macports ... from bug#6819 seems the only clean way to get it.
But it seems ugly to me, and then obviously you need to keep adding such
options for every new Mac package system that comes along.

bug#2280: 23.0.90; incorrect configuration

[Stefan Monnier]

>> Of course, there's the issue of which one to choose if both MacPorts and
>> Fink are found, as well as the issue of finding an old left-over Fink or
>> MacPorts installation.
> As reported in bugs #5252, #5921, #6819, ...

If we're more selective (by looking for particular libraries), and if we
give it lower-precedence, we should be able to eliminate most of
those problems.

>> So maybe one way forward is to look more carefully at which libs we
>> normally want to get from Fink/MacPorts (because they're missing from
>> Mac OS X) and then check which ones of these are installed where.
> I disagree about the usefulness of this.  I think it is straightforward
> to add in those search paths if you want them (users of those package
> systems may well be used to doing so),

Back when I used a Mac OS X machine with Fink, I found it easier to
write the patch we now use than to figure out how to pass the proper
option to configure.

> If we really must have this, then the suggestion of --with-fink,
> --with-macports ... from bug#6819 seems the only clean way to get it.
> But it seems ugly to me, and then obviously you need to keep adding such
> options for every new Mac package system that comes along.

I think the main issue is that to make it work right, someone needs to
improve the configure code for it.  Until then, you're probably right that
we should comment it out.


        Stefan

bug#2280: 23.0.90; incorrect configuration

[Glenn Morris]

Version: 24.2

Stefan Monnier wrote:

> I think the main issue is that to make it work right, someone needs to
> improve the configure code for it.  Until then, you're probably right that
> we should comment it out.

I have commented out this code, opened a new bug about finding a
way to bring in back in some improved form, and am closing this report.

bug#2280: 23.0.90; incorrect configuration

[Glenn Morris]

Stefan Monnier wrote:

> Back when I used a Mac OS X machine with Fink, I found it easier to
> write the patch we now use than to figure out how to pass the proper
> option to configure.

I meant to say; isn't it just

CPPFLAGS=-I/sw/include LDFLAGS=-L/sw/lib ./configure [...] 

as documented in INSTALL?
(These days, you probably want PKG_CONFIG_PATH as well.)