This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: standard include paths on command line
Type: Stage:
Components: Build Versions: Python 2.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: skip.montanaro Nosy List: doko, loewis, mwh, nnorwitz, skip.montanaro
Priority: normal Keywords:

Created on 2002-08-01 00:13 by doko, last changed 2022-04-10 16:05 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
setup-py.diff mwh, 2002-08-02 12:54 simple fix
prot.gz doko, 2002-08-03 15:56 build log
Messages (21)
msg11778 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2002-08-01 00:13
when compiling shared modules (using gcc-3.1.1), 
standard include paths are included (by setup.py?) in 
the include path, which can change the search order. 
gcc-3.1 warns about:

building 'xreadlines' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/home/packages/pyt
hon2.3/python2.3-2.2.90/./Include -I/usr/include -
I/usr/local/include -I/home/pa
ckages/python2.3/python2.3-2.2.90/Include -
I/home/packages/python2.3/python2.3-2
.2.90/build-static -
c /home/packages/python2.3/python2.3-
2.2.90/Modules/xreadlin
esmodule.c -o build/temp.linux-i686-
2.3/xreadlinesmodule.o
gcc -shared build/temp.linux-i686-
2.3/xreadlinesmodule.o -L/usr/lib -L/usr/local
/lib -o build/lib.linux-i686-2.3/xreadlines.so
building 'array' extension
gcc-3.1 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I. -I/hocc1: warning: c
hanging search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/include"
cc1: warning:   as it has already been specified as a non-
system directory
cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

In this case, /usr/include and /usr/local/include should 
not be included on the command line.
msg11779 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2002-08-01 09:08
Logged In: YES 
user_id=6656

This has been deemed a bug in gcc, see this thread:

http://mail.python.org/pipermail/python-dev/2002-June/025990.html
msg11780 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2002-08-01 20:23
Logged In: YES 
user_id=60903

I disagree. The discussion is on /usr/local/include. We are 
talking about /usr/include, which is a system include dir on 
almost all systems.

See the thread "gcc 3.2's cpp breaks configure scripts" at 
http://gcc.gnu.org/ml/gcc/2002-07/, i.e.:

http://gcc.gnu.org/ml/gcc/2002-07/msg01527.html

Inclusion of /usr/include can lead to errors, as explained in:
http://gcc.gnu.org/ml/gcc/2002-07/msg01541.html
msg11781 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2002-08-02 08:53
Logged In: YES 
user_id=6656

Ah, sorry!

Hmm.  Now I don't see the problem, i.e. for me
-I/usr/include is not part of the command line passed to the
compiler.

Are you building from up-to-date CVS?  Though I don't recall
any recent changes in this area.  Ahh, you're running
".../configure --prefix=/usr", right?

I'll dig.
msg11782 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2002-08-02 12:54
Logged In: YES 
user_id=6656

OK, can you try the attached patch?

Martin, does this look OK to you?
msg11783 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-08-02 13:49
Logged In: YES 
user_id=21627

The patch looks fine to me, please apply it.

I still think that the bogus warning should be removed from
gcc entirely.
msg11784 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2002-08-02 13:56
Logged In: YES 
user_id=6656

OK, done, in

setup.py revision 1.100

I don't see us removing /usr/local/include from the command
line.
msg11785 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-08-02 14:05
Logged In: YES 
user_id=21627

And indeed, we should not remove /usr/local/include, since
the system compiler may not be gcc.
msg11786 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2002-08-02 21:48
Logged In: YES 
user_id=60903

Thanks for the fix, however when building shared modules,
-I/usr/include and -L/usr/lib are still passed to the compiler.
msg11787 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2002-08-03 15:12
Logged In: YES 
user_id=6656

Really?  Nuts.  They're not on my machine.

What arguments are you passing to configure?
msg11788 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2002-08-03 15:56
Logged In: YES 
user_id=60903

build log attached. please tell me if you need an account on
a Debian machine (doko   debian org).
configure \
        --with-gcc=gcc-3.1 \
        --with-cxx=g++-3.1 \
        --prefix=/usr \
        --with-fpectl \
        --enable-ipv6
msg11789 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2002-08-03 16:19
Logged In: YES 
user_id=6656

It's only the _ssl module, right?  I've fixed that.

The -R/usr/lib and -L/usr/lib's come from various database
modules, the configuration of which is under review anyway.
 I hope those doing the reviewing have seen this bug traffic...
msg11790 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2002-08-03 16:30
Logged In: YES 
user_id=60903

No. It's:

 - bsddb
 - dbm
 - _tkinter

all modules, which are installed in /usr at least on Debian
GNU/Linux (but maybe on other distros as well).
msg11791 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-08-04 12:47
Logged In: YES 
user_id=21627

I can't reproduce this. With the current CVS, on Debian,
with --prefix=/usr, I get

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC
-DWITH_APPINIT=1 -I/usr/include/tcl8.3 -I/usr/X11R6/include
-I. -I/vol/marvin-vol8/loewis/python/dist/src/./Include
-I/usr/local/include
-I/vol/marvin-vol8/loewis/python/dist/src/Include
-I/vol/marvin-vol8/loewis/python/dist/src -c
/vol/marvin-vol8/loewis/python/dist/src/Modules/_tkinter.c
-o build/temp.linux-i686-2.3/_tkinter.o

So it won't add -I/usr/include to the command line options.
msg11792 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2002-08-05 14:51
Logged In: YES 
user_id=6656

Skip, are you still working on the bsddb related bits of
setup.py?  Can you look into how /usr/include is getting
onto the commandline?
msg11793 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2002-08-05 15:25
Logged In: YES 
user_id=44345

Sorry guys, I'm coming in on this late.  

I'm done with the bsddb trickery.  In any case /usr/include is not added 
as a -I argument under any circumstances in the bsddb build section of 
setup.py.  Various Linux vendors allow you to install multiple versions of 
Berkeley DB simultaneously.  The only way you can guarantee that a 
particular version is compiled against and linked with is to add the 
appropriate -I and -L flags to the command line.  On RedHat-derived 
systems the include files are in /usr/include/db{1,2,3,4} if installed as part 
of a system install, while if you install from Sleepycat source I believe it's 
/usr/local/BerkeleyDB<version>/include.   I can't really get rid of the 
RH-related include directories. 

Wait a minute.  I take some of that back.  *If* you are foolish enough to 
uncomment the section of code which enables compilation and linkage 
with Berkeley DB 1.85, you might wind up with -I/usr/include on the 
command line to build the bsddb module.  I will correct that (make it so 
/usr/include isn't added to the -I flag) and also reorder the directory 
search so system include directories are scanned after non-system 
directories.

How's this going to help the OP?  I thought the problem he saw was 
more pervasive (xreadlines, _ssl, etc).

msg11794 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2002-08-14 02:29
Logged In: YES 
user_id=44345

Doko, are you still having problems?  I really have nothing to go on here.  I 
don't see /usr/include turning up on the command line and don't have a 
Debian system to try things out on. (Does the SF compile farm?)

Skip
msg11795 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2002-08-20 21:32
Logged In: YES 
user_id=60903

Two more problems:

On Debian, the db headers are installed in /usr/include.

- This directory is not searched and bsddb not built.

- Adding '/usr/include' to setup.py in the db setup,
   the header is found, but /usr/include added to
   the command line.

One unrelated thing is that the bsddb setup adds
-R/usr/lib, which is not support on Linux by gcc-3.2.
msg11796 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2003-02-07 22:18
Logged In: YES 
user_id=33168

Matthias, I seem to recall that the warnings were due to a
change in gcc or a bug.  I think I heard that it would be
fixed in gcc 3.2.2.  Do you still have any problems?
msg11797 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2003-02-22 11:21
Logged In: YES 
user_id=60903

Neil,

the /usr/include problems are solved now (in 2.3a2). I
didn't check for the /usr/local/include problems again,
because for the Debian build, I know that /usr/local/include
is the locale include dir anyway and commented out the two
lines in setup.py.

I think, the report can be closed.

     Matthias
msg11798 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2003-02-22 15:41
Logged In: YES 
user_id=33168

Thanks, Matthias.  Closing.
History
Date User Action Args
2022-04-10 16:05:32adminsetgithub: 36963
2002-08-01 00:13:24dokocreate