Latest lang/python27 does not build completely:
Python build finished, but the necessary bits to build these modules were not found:
dl imageop linuxaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
Failed to build these modules:
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.
Over to maintainer (via the GNATS Auto Assign Tool)
mva 2012-06-20 22:35:15 UTC
FreeBSD ports repository
- Fix builds, if the NLS option switch is set. In some cases
expat-related modules are not built correctly.
Submitted by: Greg Byshenk <email@example.com>
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
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"
A fix was supplied. Thanks for noticing!
Created attachment 144366 [details]
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 firstname.lastname@example.org:/usr/obj/usr/src/sys/GENERIC i386
Thank you Randy, can you revert the changes in:
And let us know whether that allows those modules to be built again please
user error. cflags in make.conf <blush>
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)
(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)? :-)
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.
Created attachment 144604 [details]
Experimental patch to remove our local hacks
This patch also removes PTH option. Please see Bug 191744.
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
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.