GNU bug report logs - #10313
24.0.92; configure fails to find include path on openbsd

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10313 in the body.
You can then email your comments to 10313 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.92; configure fails to find include path on openbsd
Date: Fri, 16 Dec 2011 11:51:24 +0100

On OpenBSD, running ./configure fails to find some libraries (libjpeg,
libpng,...) that are correctly installed (via package system). The
following patch fixes this bug but I don't know if it is the right place
to do it.

--- configure.in.orig	Fri Dec 16 11:30:34 2011
+++ configure.in	Fri Dec 16 11:24:36 2011
@@ -478,6 +478,7 @@
       sparc*)    machine=sparc ;;
       vax-*)     machine=vax ;;
     esac
+    CPPFLAGS="-I/usr/local/include"
   ;;
 
   ## Apple Darwin / Mac OS X



In GNU Emacs 24.0.92.1 (i386-unknown-openbsd5.0, GTK+ Version 2.24.8)
 of 2011-12-16 on K
Windowing system distributor `The X.Org Foundation', version 11.0.11102000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: fr_FR.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: nil
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

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

Recent input:
e <backspace> M-x c u s t <tab> a <tab> <backspace> 
i <tab> - p a <backspace> <backspace> a p <tab> <return> 
s m t p m a i l <return> M-x M-p <return> s m t p <return> 
<down-mouse-2> <mouse-2> <return> C-p C-e C-x C-e C-a 
C-f C-f C-f C-f C-f C-f C-x o C-p C-n C-n C-e ( t e 
<backspace> <backspace> s e t q SPC u s e r - m a i 
l - a d d r e s s SPC $ <backspace> " m a n u e l @ 
l u <backspace> e d u - g i r a a <backspace> u d . 
f r " ) C-e C-x C-e M-x C-g <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<menu-bar> <help-menu> <send-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
customize-apropos: No customizable items matching (smtpmail)
customize-apropos: No customizable items matching (smtp)
Mark set
"localhost"
"manuel <at> ledu-giraud.fr"
Quit

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug apropos cus-edit easymenu cus-start cus-load wid-edit time-date
tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image fringe lisp-mode register page menu-bar rfn-eshadow
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

-- 
Manuel Giraud

Message #8 received at 10313 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 10313 <at> debbugs.gnu.org
Subject: Re: configure fails to find include path on openbsd
Date: Fri, 16 Dec 2011 17:23:24 -0800

Thanks for the bug report.  I worry that that fix,
though it works for you, may cause problmes on other
OpenBSD installations.  So I have some questions.

First, Is this use of /usr/local standardized by OpenBSD?
Is there documentation for this somewhere?

Second, gcc looks at /usr/local/include by default.  Why doesn't
that work for you?  What's the output of the following shell script
for you?  If you're not using gcc, which compiler are you using, and
can you do a similar test for it?

echo 'int main (void) { return 0; }' >t.c
gcc -v t.c

Third, why is this problem limited to /usr/local/include?
Why doesn't it also happen for /usr/local/lib?

Thanks for any further info you can provide.

Message #11 received at 10313 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 10313 <at> debbugs.gnu.org, Manuel Giraud <manuel <at> ledu-giraud.fr>
Subject: Re: bug#10313: configure fails to find include path on openbsd
Date: Fri, 16 Dec 2011 22:07:40 -0500

Paul Eggert wrote:

> Third, why is this problem limited to /usr/local/include?
> Why doesn't it also happen for /usr/local/lib?

There's a comment in configure.in (for freebsd though) that sounds related:

   ## Let `ld' find image libs and similar things in /usr/local/lib.
   ## The system compiler, GCC, has apparently been modified to not
   ## look there, contrary to what a stock GCC would do.
   LD_SWITCH_SYSTEM=-L/usr/local/lib

This dates from at least Emacs 21 (was in src/s/freebsd.h there).

Message #14 received at 10313 <at> debbugs.gnu.org (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 10313 <at> debbugs.gnu.org, Manuel Giraud <manuel <at> ledu-giraud.fr>,
	Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#10313: configure fails to find include path on openbsd
Date: Sat, 24 Dec 2011 03:40:28 +0000

On 17/12/11 01:23, Paul Eggert wrote:
> Thanks for the bug report.  I worry that that fix,
> though it works for you, may cause problmes on other
> OpenBSD installations.  So I have some questions.
>
> First, Is this use of /usr/local standardized by OpenBSD?
> Is there documentation for this somewhere?


I for one welcome our OpenBSD over... I mean, I suspect Emacs upstream 
(i.e. "us") hardcoding an extra /usr/local search path would _not_ be 
welcomed by the GNU Emacs OpenBSD port&package maintainers - though I 
don't actually speak for them, maybe one Manuel Giraud already knows 
them [0]?

Why? Well...

***

OpenBSD local modifications to gcc seem comprehensively documented in 
their gcc-local manpage: policy is to explicitly modify the system gcc 
to stop it looking in /usr/local [1]:

"""
gcc does not search under /usr/local for include files nor for
libraries: as a system compiler, it only searches the system paths
by default.
"""

***

BUT: /usr/local is where OpenBSD packages and ports install to, it's not 
quite the playground it is on some systems. The OpenBSD system is fairly 
simple [2]:

"""
Packages install to /usr/local
"""

***

So, um how does that work, you may ask?  Well, AFAICS the Done Thing is 
to always explicitly specify the extra paths required on the command 
line in the package/port build wrapper scripts [3]:

"""
CONFIGURE_ENV =		CPPFLAGS="-I${LOCALBASE}/include \
				  -I${LOCALBASE}/include/libpng" \
			LDFLAGS="-L${LOCALBASE}/lib"
"""


***

But note $LOCALBASE variable, it is NOT just a hardcoded /usr/local !
In bsd.port.mk, we find [4]:

"""
LOCALBASE     where other ports have already been installed.  Default:
                   /usr/local.
"""

***

So, in conclusion, a hardcoded /usr/local is IMO The Wrong Thing for 
upstream Emacs on OpenBSD, especially seeing as advanced folk may be 
futzing with $LOCALBASE.

Now, the OpenBSD ports&package maintainers can of course just patch  out 
anything that upstream Emacs adds that they don't like, but IMO no point 
putting them to that hassle, and IMO users building from upstream source 
on OpenBSD outside the garden of the ports&packages system are advanced 
and therefore might be expected to be prepared for little OpenBSD quirks 
like having to add the extra paths themselves.

***

[0] http://www.openbsd.org/cgi-bin/cvsweb/ports/editors/emacs23/distinfo
[1] http://www.openbsd.org/cgi-bin/man.cgi?query=gcc-local&sektion=1
[2] http://www.openbsd.org/cgi-bin/man.cgi?query=packages&sektion=7
[3] http://www.openbsd.org/cgi-bin/cvsweb/ports/editors/emacs23/Makefile
[4] http://www.openbsd.org/cgi-bin/man.cgi?query=bsd.port.mk&sektion=5

Message #17 received at 10313 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: David De La Harpe Golden <david <at> harpegolden.net>
Cc: 10313 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
	Manuel Giraud <manuel <at> ledu-giraud.fr>
Subject: Re: bug#10313: configure fails to find include path on openbsd
Date: Mon, 02 Jan 2012 13:42:35 -0500

I agree that the Emacs build process should not add /usr/local back to
the include etc paths if the BSDs have decided to remove it.
(I assume this is true for all of them, not just OpenBSD?)

So rather than adding this patch, I suggest doing nothing for Emacs
24.1, but after that actually removing the existing configure.in piece
that sets LD_SWITCH_SYSTEM to /usr/local/lib for freebsd.

Does the same apply to /usr/pkg for netbsd (see configure.in)?


Though it seems odd to me to have a system where gcc does not look in
/usr/local, yet that is where packages get installed. If I were using
such a system, I'd just end up putting /usr/local in CPPFLAGS and
LDFLAGS all the time. Are things in /usr/local found at run-time, or do
they also have to set LD_LIBRARY_PATH, or use -rpath as well during
compilation (the netbsd entry in configure.in uses the latter)?

Message #20 received at 10313 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 10313 <at> debbugs.gnu.org, Manuel Giraud <manuel <at> ledu-giraud.fr>,
	David De La Harpe Golden <david <at> harpegolden.net>
Subject: Re: bug#10313: configure fails to find include path on openbsd
Date: Mon, 02 Jan 2012 10:51:53 -0800

On 01/02/12 10:42, Glenn Morris wrote:
> If I were using > such a system, I'd just end up putting /usr/local
> in CPPFLAGS and LDFLAGS all the time.

Likewise.

> Are things in /usr/local found at run-time, or do
> they also have to set LD_LIBRARY_PATH, or use -rpath as well during
> compilation (the netbsd entry in configure.in uses the latter)?

I expect the latter.  It's a bit of a hassle -- they're essentially
making it harder to install source off the net, and they're expecting
installers to know that one must specify "-L/usr/local/lib -R/usr/local/lib
-I/usr/local/include" or whatever the magic incantation happens to be.

Message #23 received at 10313 <at> debbugs.gnu.org (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 10313 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
	Manuel Giraud <manuel <at> ledu-giraud.fr>
Subject: Re: bug#10313: configure fails to find include path on openbsd
Date: Mon, 02 Jan 2012 20:54:41 +0000

On 02/01/12 18:42, Glenn Morris wrote:
> Though it seems odd to me to have a system where gcc does not look in
> /usr/local, yet that is where packages get installed.

Well, the meaning of "package" is maybe also a bit different: OpenBSD's 
much-vaunted security claims only apply [1] to its monolithic "system" 
(though note that includes a whole bunch of things that would be 
packages on a lot of other OSes, AFAIUI [2][3]) and _not_ the OpenBSD 
ports&packages. The latter are strictly add-ons that have not been 
subjected to the same security auditing, it's not like the debian 
situation, say, where the whole "system" is pretty much /made of/ 
packages (like the base-files .deb with the filesystem hierarchy itself...)

So I guess the idea is to exclude them by default and require an active 
choice to use them, since once you start using the ports&packages system 
at all (never mind installing stuff direct from upstream sources...), 
you're choosing to break that assumption you're only running fully 
openbsd project audited code.

[1] http://www.openbsd.org/faq/faq15.html#Intro
"""
The packages and ports collection does NOT go through the same thorough 
security audit that is performed on the OpenBSD base system. Although we 
strive to keep the quality of the packages collection high, we just do 
not have enough human resources to ensure the same level of robustness 
and security.
"""

[2] http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/
[3] http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/

Message #26 received at 10313 <at> debbugs.gnu.org (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 10313 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
	Manuel Giraud <manuel <at> ledu-giraud.fr>
Subject: Re: bug#10313: configure fails to find include path on openbsd
Date: Mon, 02 Jan 2012 21:51:53 +0000

On 02/01/12 18:42, Glenn Morris wrote:
> Are things in /usr/local found at run-time, or do
> they also have to set LD_LIBRARY_PATH,

The OpenBSD case: Once a /usr/local/lib exists, /etc/rc (i.e. startup) 
will just add it in to be searched [1].  Simple, but presumably works 
adequately for their needs, avoids having to tell new users a mouthful 
something like "add a /usr/local/lib to shlib_dirs in your 
/etc/rc.conf.local to use the shared libraries installed by packages/ports"


[1] 
http://www.openbsd.org/cgi-bin/cvsweb/src/etc/rc?rev=1.397;content-type=text%2Fx-cvsweb-markup

"""
...
	if [ -d /usr/local/lib ]; then
		shlib_dirs="/usr/local/lib $shlib_dirs"
	fi
	if [ -d /usr/X11R6/lib ]; then
		shlib_dirs="/usr/X11R6/lib $shlib_dirs"
	fi
	ldconfig $shlib_dirs
...
"""

Message #29 received at 10313 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: David De La Harpe Golden <david <at> harpegolden.net>
Cc: 10313 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
	Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#10313: configure fails to find include path on openbsd
Date: Tue, 03 Jan 2012 15:10:39 +0100

David De La Harpe Golden <david <at> harpegolden.net> writes:

> So, in conclusion, a hardcoded /usr/local is IMO The Wrong Thing for
> upstream Emacs on OpenBSD, especially seeing as advanced folk may be
> futzing with $LOCALBASE.

Hum, you're right. I missed it (and made a fool of myself). I'll try to
build emacs 24 *inside* the ports framework and report back.
-- 
Manuel Giraud

Message #32 received at 10313 <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: David De La Harpe Golden <david <at> harpegolden.net>
Cc: 10313 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
	Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#10313: configure fails to find include path on openbsd
Date: Mon, 09 Jan 2012 17:43:22 +0100

Ok, so within the openbsd's ports framework (where CPPFLAGS is correctly
set inside the port Makefile) this issue doesn't stand. So this bug
report can safely be closed.

Best regards,
-- 
Manuel Giraud

Message #37 received at 10313-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: Glenn Morris <rgm <at> gnu.org>, 10313-done <at> debbugs.gnu.org,
	David De La Harpe Golden <david <at> harpegolden.net>
Subject: Re: bug#10313: configure fails to find include path on openbsd
Date: Mon, 09 Jan 2012 09:12:57 -0800

On 01/09/12 08:43, Manuel Giraud wrote:
> this bug report can safely be closed.

Thanks, I'm closing it now.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10313

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.