Title: frozen.c should #include instead of "importlib.h"
Type: Stage:
Components: Interpreter Core Versions: Python 3.4
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: brett.cannon Nosy List: brett.cannon, eric.snow, jbeck, ncoghlan, swalker
Priority: normal Keywords: patch

Created on 2014-08-05 20:32 by jbeck, last changed 2014-08-12 14:16 by brett.cannon. This issue is now closed.

File name Uploaded Description Edit
frozen-path.patch jbeck, 2014-08-05 20:32
Messages (4)
msg224885 - (view) Author: John Beck (jbeck) Date: 2014-08-05 20:32
Background: on Solaris, we build Python and various modules 64-bit. To
make this work with our general 64-bit changes, we use foo/64 as the path
for our shared objects (.so files) rather than foo, for various values
of foo (e.g., "/usr/lib", "/usr/lib/python3.4", etc.).  We had to tweak
Lib/importlib/ to implement this.  In so doing, we learned
that Python/frozen.o does not pick up this change.  The reason is that
Python/frozen.c has a #include of "importlib.h".  But because of the
quotes, it looks in the same directory for importlib.h .  But when we
rebuild importlib.h (via _freeze_importlib), the rebuilt importlib.h is
placed into our build dir, not $srcdir.  But '#include "importlib.h"'
looks first for $srcdir/Python/importlib.h, finds the old one, then
uses it without finding the rebuilt one over in the build dir.

Although the description of the problem is rather convoluted, the fix is
fortunately extremely simple: change "importlib.h" to <importlib.h>, i.e.,
change the quotes to angle-brackets, per the attached patch.
msg225077 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2014-08-08 16:04
Unfortunately switching to angle brackets breaks on other platforms, e.g. OS X using Clang:

Python/frozen.c:5:10: error: 'importlib.h' file not found with <angled> include; use "quotes" instead
#include <importlib.h>
1 error generated.
make: *** [Python/frozen.o] Error 1

Is there a change you want to propose in our configure or Makefile instead?
msg225200 - (view) Author: John Beck (jbeck) Date: 2014-08-11 18:46
Hm, that is strange.  My reading of the semantics of <foo.h> vs
"foo.h" was that they are almost the same, except that "foo.h" has
the additional semantic of searching the local directory (wherever
the .c file is that is #include'ing it) first.  So if other platforms
require that, and we require the opposite of that, then it seems
neither Makefile nor configure tweaking would help, and the needs
of the many outweigh the needs of the few (or the one), and we will
just patch this privately in our internal repo.  Thanks for your
msg225230 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2014-08-12 14:16
The key point here is that importlib.h isn't installed with the other header files; it's purely for compilation since it doesn't expose any API. I'm not sure how you tweaked your build environment to break that assumption, but since importlib.h is not expected to be used outside of the build I don't want to make it a header that gets installed with the other headers Python provides for expressing APIs.
Date User Action Args
2014-08-12 14:16:48brett.cannonsetstatus: open -> closed
resolution: not a bug
messages: + msg225230
2014-08-11 18:46:53jbecksetstatus: pending -> open

messages: + msg225200
2014-08-08 16:04:59brett.cannonsetstatus: open -> pending

messages: + msg225077
2014-08-06 13:42:57brett.cannonsetassignee: brett.cannon
2014-08-05 22:45:33pitrousetnosy: + brett.cannon, ncoghlan, eric.snow
2014-08-05 22:06:21swalkersetnosy: + swalker
2014-08-05 20:32:50jbeckcreate