Bug 169276 - Current lang/python27 fails to build 'pyexpat' and '_elementtree' modules
Summary: Current lang/python27 fails to build 'pyexpat' and '_elementtree' modules
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Many People
Assignee: Marcus von Appen
Depends on:
Reported: 2012-06-20 22:20 UTC by freebsd
Modified: 2014-08-03 08:02 UTC (History)
4 users (show)

See Also:

make log (596.63 KB, text/plain)
2014-07-03 06:52 UTC, randy
no flags Details
Experimental patch to remove our local hacks (4.74 KB, patch)
2014-07-11 22:30 UTC, Jung-uk Kim
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description freebsd 2012-06-20 22:20:09 UTC
Latest lang/python27 does not build completely:

	Python build finished, but the necessary bits to build these modules were not found:
	dl                 imageop            linuxaudiodev
	spwd               sunaudiodev

	To find the necessary bits, look in setup.py in detect_modules() for the module's name.

	Failed to build these modules:
	_elementtree       pyexpat

First set of modules is fine, but second set should build, and are
required for other ports, eg: devel/libnotify.


Workaround: revert to ports tree as of 2012.05.13.
How-To-Repeat: Build lang/python27 with current ports tree.
Comment 1 Edwin Groothuis freebsd_committer 2012-06-20 22:20:22 UTC
Responsible Changed
From-To: freebsd-ports-bugs->freebsd-python

Over to maintainer (via the GNATS Auto Assign Tool)
Comment 2 dfilter service freebsd_committer 2012-06-20 23:35:30 UTC
mva         2012-06-20 22:35:15 UTC

  FreeBSD ports repository

  Modified files:
    lang/python24        Makefile 
    lang/python25        Makefile 
    lang/python26        Makefile 
    lang/python27        Makefile 
    lang/python31        Makefile 
    lang/python32        Makefile 
  - Fix builds, if the NLS option switch is set. In some cases
    expat-related modules are not built correctly.
  PR:             ports/169276
  Submitted by:   Greg Byshenk <freebsd@byshenk.net>
  Revision  Changes    Path
  1.179     +3 -2      ports/lang/python24/Makefile
  1.171     +3 -2      ports/lang/python25/Makefile
  1.187     +3 -2      ports/lang/python26/Makefile
  1.192     +3 -2      ports/lang/python27/Makefile
  1.184     +3 -2      ports/lang/python31/Makefile
  1.188     +3 -2      ports/lang/python32/Makefile
cvs-all@freebsd.org mailing list
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 3 Marcus von Appen freebsd_committer freebsd_triage 2012-06-20 23:36:13 UTC
State Changed
From-To: open->closed

A fix was supplied. Thanks for noticing!
Comment 4 randy 2014-07-03 06:52:00 UTC
Created attachment 144366 [details]
make log
Comment 5 randy 2014-07-03 06:52:57 UTC
this has reappeared in

FreeBSD bgpmon0.attn.jp 10.0-RELEASE-p4 FreeBSD 10.0-RELEASE-p4 #0: Tue Jun  3 12:52:18 UTC 2014     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2014-07-03 06:56:39 UTC
Thank you Randy, can you revert the changes in:


And let us know whether that allows those modules to be built again please
Comment 7 randy 2014-07-03 08:16:41 UTC
user error.  cflags in make.conf  <blush>
Comment 8 Kubilay Kocak freebsd_committer freebsd_triage 2014-07-03 08:20:24 UTC
Not your fault Randy, the Python build system *should* honour user-supplied *CFLAGS correctly, but doesn't.

For our future selves, reference that Randy's /etc/make.conf contained the following entry:


I will be putting the comment back in that was removed in r357486 that mentions that we use CPPFLAGS not CFLAGS specifically for this reason (Include ordering issues)
Comment 9 Marcus von Appen freebsd_committer freebsd_triage 2014-07-03 13:44:11 UTC
(In reply to Kubilay Kocak from comment #8)
> Not your fault Randy, the Python build system *should* honour user-supplied
> *CFLAGS correctly, but doesn't.
> For our future selves, reference that Randy's /etc/make.conf contained the
> following entry:

Care to add that as a TODO|Thing To Watch(tm) on the wiki (Policy -> Section Python builds maybe)? :-)
Comment 10 Jung-uk Kim freebsd_committer 2014-07-11 22:24:29 UTC
I had many problems with python-config previously, e.g., '--libs' output includes '-L/usr/local/lib' when NLS is enabled.  Ubuntu manual page (http://manpages.ubuntu.com/manpages/precise/man1/python2.7-config.1.html) says:

              print the flags that should be passed to the linker.

              similar to --ldflags but only with -l options (used libraries).

In other words, we may add '-L/usr/local/lib' to '--ldflags' output but not to '--libs' output.

Also, I believe LDFLAGS environment variable should not affect '--ldflags' output.  Now you even want to let CFLAGS environment variable affect '--cflags' output.  I don't think that's a good idea.  With these local hacks, it is really hard to control library/header search precedence.
Comment 11 Jung-uk Kim freebsd_committer 2014-07-11 22:30:16 UTC
Created attachment 144604 [details]
Experimental patch to remove our local hacks

This patch also removes PTH option.  Please see Bug 191744.
Comment 12 Jung-uk Kim freebsd_committer 2014-07-11 22:34:17 UTC
FYI, I get this with default options after applying my patch.

% python-config --ldflags
-L/usr/local/lib/python2.7/config -L/usr/local/lib -pthread -lintl -lutil -lm -lpython2.7 -Wl,--export-dynamic
% python-config --libs
-lintl -lutil -lm -lpython2.7
Comment 13 Marcus von Appen freebsd_committer freebsd_triage 2014-08-03 08:02:16 UTC
The lang/python27 port has been reworked heavily. Also, the -L flags are added explicitly to Python's LIBS environment via http://svnweb.freebsd.org/ports?view=revision&revision=357486, causing python-config to add -L/usr/local/lib to the --libs flags.

It's to be said, that -L indeed should not be added to LIBS by default. If this is a critical issue, we should discuss the changes of r357486 and bug #190592 once more.

Ubuntu's manpage regarding python-config is not something provided by upstream, so this won't be considered as reference, we have to stick to, for now.

If the behaviour is still considered wrong, please open another issue.
I'm closing the issue for now.