[issue6081] str.format_from_mapping()
Changes by Evan Behar : -- nosy: +ebehar ___ Python tracker <http://bugs.python.org/issue6081> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Evan Behar added the comment:
I think I've found the problem.
In configure:
13830 if test "${ac_cv_lib_intl_textdomain+set}" = set; then
13831 echo $ECHO_N "(cached) $ECHO_C" >&6
13832 else
13833 ac_check_lib_save_LIBS=$LIBS
13834 LIBS="-lintl $LIBS"
but then
13883 rm -f core conftest.err conftest.$ac_objext
conftest_ipa8_conftest.oo \
13884 conftest$ac_exeext conftest.$ac_ext
13885 LIBS=$ac_check_lib_save_LIBS
ac_check_lib_save_LIBS is assigned before -lintl is added to LIBS, and
then LIBS is unconditionally re-assigned to ac_check_lib_save_LIBS a
little bit further down, which then doesn't have -lintl in it.
I've included a patch that changes this to be:
...
13880 ac_cv_lib_intl_textdomain=no
13881 LIBS=$ac_check_lib_save_LIBS
13882 fi
13883
13884 rm -f core conftest.err conftest.$ac_objext
conftest_ipa8_conftest.oo \
13885 conftest$ac_exeext conftest.$ac_ext
13886 fi
So that LIBS is only restored to the saved state if the check fails.
I'm not sure if mucking with the configure file directly is a great
idea, but this was the simplest thing I could think of that would work.
--
nosy: +ebehar
Added file: http://bugs.python.org/file14160/configure_lintl.patch
___
Python tracker
<http://bugs.python.org/issue6154>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Evan Behar added the comment: I applied Benjamin's new patch to the original files, but I receive the same error, and the LIBS in the Makefile still only has -ldl and not -lintl. -- ___ Python tracker <http://bugs.python.org/issue6154> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Evan Behar added the comment: It works fine for my framework build on 10.4.11 -- ___ Python tracker <http://bugs.python.org/issue6154> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Evan Behar added the comment:
Nevermind, my bad. With Brett's patch, the build does not work with
--enable-framework
It appears that configure.in makes no assignment to FRAMEWORKLINK or
AC_SUBST call with it, and so it is deposited in the final Makefile
verbatim as @FRAMEWORKLINK@
If --enable-framework is defined, then this compiler command in
Makefile.pre:461 gets executed:
$(CC) -o $(LDLIBRARY) -dynamiclib \
-isysroot "${UNIVERSALSDK}" \
-all_load $(LIBRARY) -Wl,-single_module \
-install_name
$(DESTDIR)$(PYTHONFRAMEWORKINSTALLDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)
\
-compatibility_version $(VERSION) \
-current_version $(VERSION) \
$(FRAMEWORKLINK);
Which expands $(FRAMEWORKLINK) to @FRAMEWORKLINK@ because of this.
This makes no use of LIBS or any other environment variable that might
contain -lintl or -framework CoreFoundation, and the build will fail
with linker errors citing undefined intl and CFString symbols.
Attached is a patch that fixes this issue; it combines brett's lintl
patch with the fix for --enable-framework.
--
Added file: http://bugs.python.org/file14174/darwin_lintl_framework.patch
___
Python tracker
<http://bugs.python.org/issue6154>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Evan Behar added the comment: Curiously, if I define --with-pydebug I get ld: Undefined symbols: ___eprintf If I don't define --with-pydebug but I do use --enable-universalsdk I get a whole different problem: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -c ./Modules/_localemodule.c -o Modules/_localemodule.o ./Modules/_localemodule.c:28:21: error: libintl.h: No such file or directory This leads to whole bunch of other crap. libintl.h is used in other forms of the build, so I'm not sure why this is cropping up. I also have no idea what ___eprintf is. -- ___ Python tracker <http://bugs.python.org/issue6154> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Evan Behar added the comment: I haven't got any library issues using --enable-universalsdk, it won't get to the linking stage becaue it doesn't find libintl.h And with --with-pydebug still doesn't build because it won't find ___eprintf, whatever that is. The only version of libintl on my system is universal, so I don't think that's related. -- ___ Python tracker <http://bugs.python.org/issue6154> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
