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.

Author mark.dickinson
Recipients benjamin.peterson, brett.cannon, erickt, mark.dickinson, rpetrov, tarek
Date 2009-05-31.20:39:11
SpamBayes Score 0.0
Marked as misclassified No
Message-id <1243802353.92.0.743930943611.issue6154@psf.upfronthosting.co.za>
In-reply-to
Content
I don't see Brett's failure with a straight './configure && make' issued 
from the top directory of a clean svn py3k checkout (r73082), but I do 
see it with:

CC="gcc -I/opt/local/include -L/opt/local/lib" ./configure && make

I'm on OS X 10.5.7, and have a MacPorts version of libintl installed as 
/opt/local/lib/libintl.dylib.  The configure script correctly defines 
HAVE_LIBINTL_H to 1, and later detects that libintl *is* needed, and 
consequently defines WITH_LIBINTL, but then as far as I can tell does 
nothing further with that define.

In the patch (locale_fix.patch), I don't understand this bit:

+                if test $have_intl
+                then
+		   LINKFORSHARED="$extra_undefs -lintl"
+                else
+                   LINKFORSHARED="$extra_undefs -framework 
CoreFoundation"
+                fi

Why is the "-framework CoreFoundation" bit not included if $have_intl is 
set?  When I apply your patch and rebuild as above I get a different 
failure:

gcc -I/opt/local/include -L/opt/local/lib  -lintl -o python.exe \
			Modules/python.o \
			libpython3.1.a -ldl      
Undefined symbols:
  "_CFStringConvertEncodingToIANACharSetName", referenced from:
      _PyLocale_getdefaultlocale in libpython3.1.a(_localemodule.o)
  "_CFStringGetSystemEncoding", referenced from:
      _PyLocale_getdefaultlocale in libpython3.1.a(_localemodule.o)
  "_CFStringGetCStringPtr", referenced from:
      _PyLocale_getdefaultlocale in libpython3.1.a(_localemodule.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [python.exe] Error 1

But if I apply your patch and also add the "-framework CoreFoundation" 
bit back in, then the build succeeds.

Also note that there's already a check for whether libintl is needed
in configure.in, at around line 1820:

# check if we need libintl for locale functions
AC_CHECK_LIB(intl, textdomain,
	AC_DEFINE(WITH_LIBINTL, 1,
	[Define to 1 if libintl is needed for locale functions.]))

Probably we don't need both checks.

And a nitpick:  it looks as though the tabbing in your patch isn't 
consistent with the surrounding configure code.
History
Date User Action Args
2009-05-31 20:39:14mark.dickinsonsetrecipients: + mark.dickinson, brett.cannon, benjamin.peterson, erickt, tarek, rpetrov
2009-05-31 20:39:13mark.dickinsonsetmessageid: <1243802353.92.0.743930943611.issue6154@psf.upfronthosting.co.za>
2009-05-31 20:39:12mark.dickinsonlinkissue6154 messages
2009-05-31 20:39:11mark.dickinsoncreate