classification
Title: Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Type: behavior Stage: resolved
Components: Build Versions: Python 3.1
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: benjamin.peterson Nosy List: benjamin.peterson, brett.cannon, brodie, ebehar, erickt, mark.dickinson, ronaldoussoren, rpetrov, tarek, ygale
Priority: release blocker Keywords: patch

Created on 2009-05-31 07:34 by brett.cannon, last changed 2009-06-30 14:06 by ygale. This issue is now closed.

Files
File name Uploaded Description Edit
locale_fix.patch benjamin.peterson, 2009-05-31 14:35
locale_fix.patch benjamin.peterson, 2009-06-02 22:42
configure_lintl.patch ebehar, 2009-06-02 22:46 patch to fix missing -lintl under OS X
locale_fix2.patch benjamin.peterson, 2009-06-03 00:17
add_lintl.patch brett.cannon, 2009-06-03 01:21 Add "-lintl" if intl turns out to be acceptable
darwin_lintl_framework.patch ebehar, 2009-06-03 20:42 brett's patch + --enable-framework fix
lintl_for_frameworks.patch brett.cannon, 2009-06-03 22:10 Still fails for --enable-universalsdk
libintl-framework-ronald.patch ronaldoussoren, 2009-06-07 15:39
Messages (36)
msg88594 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-05-31 07:34
I believe r72863 broke building on OS X. If you uncomment the ``-lintl``
part for _localemodule.c in Modules/Setup then Python 3.1 builds. Below
is the linkage error that Tarek and I both independently ran into.

gcc -L/Users/brett/usr/lib -L/Users/brett/.local/lib -L/unix/lib
-L/unix/macports/lib -L/Developer/usr/lib -framework CoreFoundation -o
python.exe \
			Modules/python.o \
			libpython3.1.a -ldl      
Undefined symbols:
  "_libintl_textdomain", referenced from:
      _PyIntl_textdomain in libpython3.1.a(_localemodule.o)
  "_libintl_dgettext", referenced from:
      _PyIntl_dgettext in libpython3.1.a(_localemodule.o)
  "_libintl_dcgettext", referenced from:
      _PyIntl_dcgettext in libpython3.1.a(_localemodule.o)
  "_libintl_bindtextdomain", referenced from:
      _PyIntl_bindtextdomain in libpython3.1.a(_localemodule.o)
  "_libintl_gettext", referenced from:
      _PyIntl_gettext in libpython3.1.a(_localemodule.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [python.exe] Error 1
msg88597 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-05-31 14:35
Sorry to be pulling you into this, but would you see if this patch fixes
your woes?
msg88598 - (view) Author: Roumen Petrov (rpetrov) * Date: 2009-05-31 15:10
Benjamin, configure script check for function textdomain in libintl.
msg88603 - (view) Author: Erick Tryzelaar (erickt) Date: 2009-05-31 19:04
Benjamin, I just applied that patch but I still got the same error:

		/usr/bin/libtool -o Python.framework/Versions/3.1/Python 
-dynamic  libpython3.1.a \
			 -lSystem -lSystemStubs -arch_only i386 -
install_name 
/opt/local/Library/Frameworks/Python.framework/Versions/3.1/Python -
compatibility_version 3.1 -current_version 3.1 -framework 
CoreFoundation;\
	fi
Undefined symbols:
  "_libintl_textdomain", referenced from:
      _PyIntl_textdomain in libpython3.1.a(_localemodule.o)
  "_libintl_dgettext", referenced from:
      _PyIntl_dgettext in libpython3.1.a(_localemodule.o)
  "_libintl_dcgettext", referenced from:
      _PyIntl_dcgettext in libpython3.1.a(_localemodule.o)
  "_libintl_bindtextdomain", referenced from:
      _PyIntl_bindtextdomain in libpython3.1.a(_localemodule.o)
  "_libintl_gettext", referenced from:
      _PyIntl_gettext in libpython3.1.a(_localemodule.o)
ld: symbol(s) not found
/usr/bin/libtool: internal link edit command failed
msg88604 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-05-31 19:36
Still fails because you are now no longer compiling against
CoreFoundation. Probably need both CoreFoundation and intl:

gcc -L/Users/brett/usr/lib -L/Users/brett/.local/lib -L/unix/lib
-L/unix/macports/lib -L/Developer/usr/lib -lintl -o python.exe \
			Modules/python.o \
			libpython3.1.a -ldl      
Undefined symbols:
  "_CFStringConvertEncodingToIANACharSetName", referenced from:
      _mac_getscript in libpython3.1.a(_localemodule.o)
  "_CFStringGetSystemEncoding", referenced from:
      _mac_getscript in libpython3.1.a(_localemodule.o)
  "_CFStringGetCStringPtr", referenced from:
      _mac_getscript in libpython3.1.a(_localemodule.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
msg88608 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-05-31 20:39
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.
msg88615 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-05-31 22:08
I do have intl installed through MacPorts so I am sure Mark's right that
having intl installed as well as running on OS X is triggering this.
msg88769 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-06-02 22:42
Here's another patch.
msg88771 - (view) Author: Evan Behar (ebehar) Date: 2009-06-02 22:46
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.
msg88773 - (view) Author: Evan Behar (ebehar) Date: 2009-06-02 22:50
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.
msg88780 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-06-03 00:59
@Evan -- You need to edit configure.in and use autoconf to regenerate
configure.

@Benjamin -- your second patch leads to an infinite recursion or
something with 'y\n' being printed out constantly.
msg88781 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-06-03 01:04
What about the third?
msg88782 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-06-03 01:21
I meant locale_fix2.patch causes the infinite output.

Regardless, I now have my own patch that solves the problem. I simply
make sure that if the check for intl passes it also added "-lintl" to
$LIBS. You will need to run autoconf/autoheader yourself as when I ran
it svn diff complained about different line endings on configure.
msg88783 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-06-03 01:25
Does that fix framework builds, too?
msg88790 - (view) Author: Evan Behar (ebehar) Date: 2009-06-03 03:14
It works fine for my framework build on 10.4.11
msg88797 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-06-03 06:58
Didn't work when I turned on --enable-framework, but I have no clue how
the framework build works so I am of no help with that.
msg88825 - (view) Author: Evan Behar (ebehar) Date: 2009-06-03 20:42
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.
msg88833 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-06-03 22:10
So Evan's patch didn't work for me. But I did take Evan's point that
LIBS was not being used in the framework build step and simply added
$(LIBS) to Makefile.pre.in where the linking for the Python executable
happens (attached a new patch with that in it). That got
``--with-pydebug --enable-framework`` working, but the build still fails
under ``--with-pydebug --enable-framework --enable-universalsdk``. Why
does it fail? Well because ``-lintl`` ends up not being set in $(LIBS),
that's why! =)

I have burned way too much time on this to finish debugging this
autoconf crap. This is getting hairy enough that either a) get more help
from python-dev, b) revert the static linking of _locale, c) get Ronald
involved.
msg88835 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-06-03 22:24
I take it the build problem is because intl isn't a universal library?
In that case, I think the best solution is to not define WITH_INTL if
--enable-universalsdk is passed. Ronald, do you have an opinion?
msg88837 - (view) Author: Evan Behar (ebehar) Date: 2009-06-03 22:37
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.
msg88839 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-06-03 22:45
Do you have a copy of libintl in /usr/local or ~brett//local/lib? If so, 
could you run 'file' on that library to check if it is a universal 
library?

All system libraries on OSX are universal binaries and work just fine 
with a universal build of Python, that's why I believe you have a non-
universal copy of some libraries on your systems and those won't work 
when you try to do a universal build.

Removing -lintl for a universal build would not be a valid solution, 
unless -lintl is completely unnecessary on OSX.

And for the record: I cannot reproduce this on my system, the end of 
build with --enable-universalsdk:

Python build finished, but the necessary bits to build these modules 
were not found:
_gdbm              ossaudiodev        readline        
spwd                                                  
To find the necessary bits, look in setup.py in detect_modules() for the 
module's name.


Failed to build these modules:
_gestalt           _tkinter                           


And the output of file:

file python.exe
python.exe: Mach-O universal binary with 2 architectures
python.exe (for architecture ppc):	Mach-O executable ppc
python.exe (for architecture i386):	Mach-O executable i386

Al of this is with a fresh checkout (r73188) of the py3k branch.


P.S. I'd love to know a clean way to exclude /usr/local/{include,lib} 
from the search paths of GCC, I've had a number of bugreports for other 
projects where the compiler picked up a non-universal library in 
/usr/local that the user didn't even know they had installed and didn't 
want to use.
msg88840 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-06-03 22:47
I have two procedural questions:

1) Who should I contact to get e-mail for all bugs that get tagged with 
the Macintosh component?

2) Please tag all mac-related bugs with the 'Macintosh' component, that's 
the one I most often check for new issues.
msg88842 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-06-03 22:51
2009/6/3 Ronald Oussoren <report@bugs.python.org>:
>
> Ronald Oussoren <ronaldoussoren@mac.com> added the comment:
>
> I have two procedural questions:
>
> 1) Who should I contact to get e-mail for all bugs that get tagged with
> the Macintosh component?

Create an issue on the meta tracker:
http://psf.upfronthosting.co.za/roundup/meta
>
> 2) Please tag all mac-related bugs with the 'Macintosh' component, that's
> the one I most often check for new issues.

I will tell the bug triage people that.
msg88843 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-06-03 22:56
I just noticed the update of the title.

I propose to close this issue if this is caused by a non-universal version 
of libintl that's installed by macports.

Macports can install universal binaries of its packages (the +universal 
variant), use that if you want to link a universal build of python with 
macports libraries (and if you don't want to link with macports you 
shouldn't add the macports $prefix to the search path of the compiler)
msg88844 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-06-03 22:58
2009/6/3 Ronald Oussoren <report@bugs.python.org>:
>
> Ronald Oussoren <ronaldoussoren@mac.com> added the comment:
>
> I just noticed the update of the title.
>
> I propose to close this issue if this is caused by a non-universal version
> of libintl that's installed by macports.

Actually, it can happen with regular builds, but the attached patches
fix that issue.

>
> Macports can install universal binaries of its packages (the +universal
> variant), use that if you want to link a universal build of python with
> macports libraries (and if you don't want to link with macports you
> shouldn't add the macports $prefix to the search path of the compiler)

That sounds reasonable.
msg88846 - (view) Author: Evan Behar (ebehar) Date: 2009-06-03 22:59
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.
msg88847 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-06-03 23:20
On 4 Jun, 2009, at 0:59, Evan Behar wrote:

>
> Evan Behar <behare@gmail.com> 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.

The --with-pydebug issue is unrelated to this one, and IIRC there is  
already a tracker item for that, at least when you're running OSX  
10.4.  I don't have problems with --with-pydebug on 10.5
msg88848 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-06-03 23:20
On 4 Jun, 2009, at 0:59, Benjamin Peterson wrote:

>
> Benjamin Peterson <benjamin@python.org> added the comment:
>
> 2009/6/3 Ronald Oussoren <report@bugs.python.org>:
>>
>> Ronald Oussoren <ronaldoussoren@mac.com> added the comment:
>>
>> I just noticed the update of the title.
>>
>> I propose to close this issue if this is caused by a non-universal  
>> version
>> of libintl that's installed by macports.
>
> Actually, it can happen with regular builds, but the attached patches
> fix that issue.

How can it happen with regular builds?  This can only happen if there  
is a non-universal copy of used libraries on the compiler search-path,  
or rather if there are libraries with incompatible architectures on  
the search-path. This would also happen with readline, or if you have  
a ppc-only library on an intel machine.

Not having the right archtectures of libraries is IMHO in "don't do  
that then" territory.

Ronald
msg88849 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-06-03 23:20
On 4 Jun, 2009, at 0:59, Benjamin Peterson wrote:

>
> Benjamin Peterson <benjamin@python.org> added the comment:
>
> 2009/6/3 Ronald Oussoren <report@bugs.python.org>:
>>
>> Ronald Oussoren <ronaldoussoren@mac.com> added the comment:
>>
>> I just noticed the update of the title.
>>
>> I propose to close this issue if this is caused by a non-universal  
>> version
>> of libintl that's installed by macports.
>
> Actually, it can happen with regular builds, but the attached patches
> fix that issue.

How can it happen with regular builds?  This can only happen if there  
is a non-universal copy of used libraries on the compiler search-path,  
or rather if there are libraries with incompatible architectures on  
the search-path. This would also happen with readline, or if you have  
a ppc-only library on an intel machine.

Not having the right archtectures of libraries is IMHO in "don't do  
that then" territory.

Ronald
msg88851 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-06-03 23:37
On 4 Jun, 2009, at 0:59, Evan Behar wrote:

>
> Evan Behar <behare@gmail.com> 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.

The --with-pydebug issue is unrelated to this one, and IIRC there is  
already a tracker item for that, at least when you're running OSX  
10.4.  I don't have problems with --with-pydebug on 10.5
msg88854 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-06-03 23:44
There's a broader issue than just the non-universal intl problem. If
intl.h is defined, then configure causes _localemodule.c to use
functions from it, but it wasn't being linked to.
msg88857 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-06-04 00:24
As Benjamin said, this was failing on non-universal framework builds and
just a regular build because '-lintl' was not getting added to LIBS in
configure.in and LIBS was not being passed into the framework compile
rule (for both universal and non-universal).

As for my copy of libintl.dylib, 'file' says::

  /unix/macports/lib/libintl.dylib: Mach-O dynamically linked shared
library i386

From my reading of that it means gettext was not built as a universal
library (which I will go fix and so for other libraries I have through
MacPorts).

Ronald, can you look at the changes I proposed on Makefile.pre.in to
make sure LIBS from configure get used in the framework builds? If you
do then that change with the configure.in change I suggested should
solve all of this.
msg88866 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-06-04 07:39
On 4 Jun, 2009, at 2:24, Brett Cannon wrote:
>
>
> Ronald, can you look at the changes I proposed on Makefile.pre.in to
> make sure LIBS from configure get used in the framework builds? If you
> do then that change with the configure.in change I suggested should
> solve all of this.

The basic idea looks fine, I will have a more serious look later  
today. I'm not entirely sure of adding LIBS to the link line is 100%  
correct, or if it would be better to have a separate FRAMEWORKLIBS  
definition that only contains the files that must be linked into the  
framework.
msg88905 - (view) Author: Roumen Petrov (rpetrov) * Date: 2009-06-04 21:40
The current check for *gettext/*textdomain* functions is not so correct.
It mix(!?!) checks for headers with check for functions.

GNU libc include them and on linux we will see in pyconfig.h (trunk):
-----------
/* #undef WITH_LIBINTL */
#define HAVE_LIBINTL_H 1
#define HAVE_BIND_TEXTDOMAIN_CODESET 1
-----------

If system "C" library don't include them then configure check(search) in
 additional libraries (-lintl) but in this case
"bind_textdomain_codeset" is not detected.

As the current check is "AC_CHECK_LIB(intl, textdomain, [ACTION], ..."
the library is not added to LIBS (see autoconf texinfo pages as reference).

Another file is setup.py . Trunk version add library "intl" if
WITH_LIBINTL is defined and on darwin adds '-framework',
'CoreFoundation' to link flags.

It seems to me that patch is not so simple.
May i propose following changes:
- remove current check for function "bind_textdomain_codeset";
- remove current check for header "libintl.h"
- replace "AC_CHECK_LIB(intl, textdomain, ..." with 
AC_SEARCH_LIBS(bindtextdomain, intl, 
 #ACTION-IF-FOUND
   check for header "libintl.h"
   check for function "bind_textdomain_codeset"
- adjust use of defines in locale module
- adjust setup.py if necessary (I don't know p3k branch)


In a more advanced check I won't add library "intl" to $LIBS.
The check will be similar to the check for readline + restore of LIBS
after check and I will move line for locale module from Setup.dist into
Setup.config.in as example:
_locale _localemodule.c @LOCALE_LIBS@ #
where LOCALE_LIBS is substituted by configure script.
msg89044 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-06-07 15:39
The attached file libintl-framework-ronald.patch should do the trick.

Could someone who is affected by this issue test this patch (and feel free 
to commit it if it works). I don't have libintl on my system and hence 
cannot test right now.
msg89052 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-06-07 20:11
OK, committed by configure.in patch along with Ronald's Makefile.pre.in
patch in r73274. Thanks to everyone who helped out with this. Building
sucks and autoconf doesn't always help.
History
Date User Action Args
2009-06-30 14:06:31ygalesetnosy: + ygale
2009-06-07 20:11:32brett.cannonsetstatus: open -> closed
2009-06-07 20:11:19brett.cannonsetresolution: fixed
messages: + msg89052
stage: needs patch -> resolved
2009-06-07 15:39:10ronaldoussorensetfiles: + libintl-framework-ronald.patch

messages: + msg89044
2009-06-04 21:40:18rpetrovsetmessages: + msg88905
2009-06-04 18:34:50brett.cannonsettitle: Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl -> Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
2009-06-04 17:17:06loewissetfiles: - smime.p7s
2009-06-04 17:17:02loewissetfiles: - smime.p7s
2009-06-04 17:16:58loewissetfiles: - smime.p7s
2009-06-04 17:16:53loewissetfiles: - smime.p7s
2009-06-04 07:39:58ronaldoussorensetmessages: + msg88866
title: Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl -> Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
2009-06-04 00:24:16brett.cannonsetmessages: + msg88857
2009-06-03 23:44:30benjamin.petersonsetmessages: + msg88854
2009-06-03 23:37:13ronaldoussorensetfiles: + smime.p7s

messages: + msg88851
2009-06-03 23:20:48ronaldoussorensetfiles: + smime.p7s

messages: + msg88849
2009-06-03 23:20:45ronaldoussorensetfiles: + smime.p7s

messages: + msg88848
2009-06-03 23:20:31ronaldoussorensetfiles: + smime.p7s

messages: + msg88847
title: Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl -> Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
2009-06-03 22:59:46ebeharsetmessages: + msg88846
2009-06-03 22:58:58benjamin.petersonsetmessages: + msg88844
2009-06-03 22:56:08ronaldoussorensetmessages: + msg88843
2009-06-03 22:51:40benjamin.petersonsetmessages: + msg88842
2009-06-03 22:47:50ronaldoussorensetmessages: + msg88840
2009-06-03 22:45:18ronaldoussorensetmessages: + msg88839
2009-06-03 22:37:10ebeharsetmessages: + msg88837
2009-06-03 22:25:00benjamin.petersonsettitle: Python 3.1 rc1 will not build on OS X 10.5.7 -> Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
2009-06-03 22:24:02benjamin.petersonsetnosy: + ronaldoussoren
messages: + msg88835
2009-06-03 22:10:04brett.cannonsetfiles: + lintl_for_frameworks.patch

messages: + msg88833
2009-06-03 20:42:25ebeharsetfiles: + darwin_lintl_framework.patch

messages: + msg88825
2009-06-03 06:58:53brett.cannonsetmessages: + msg88797
2009-06-03 03:14:19ebeharsetmessages: + msg88790
2009-06-03 01:25:08benjamin.petersonsetmessages: + msg88783
2009-06-03 01:21:09brett.cannonsetfiles: + add_lintl.patch

messages: + msg88782
2009-06-03 01:04:03benjamin.petersonsetmessages: + msg88781
2009-06-03 00:59:01brett.cannonsetmessages: + msg88780
2009-06-03 00:17:22benjamin.petersonsetfiles: + locale_fix2.patch
2009-06-02 22:50:26ebeharsetmessages: + msg88773
2009-06-02 22:46:12ebeharsetfiles: + configure_lintl.patch
nosy: + ebehar
messages: + msg88771

2009-06-02 22:42:16benjamin.petersonsetfiles: + locale_fix.patch

messages: + msg88769
2009-06-02 20:59:57brett.cannonsetstage: needs patch
2009-06-01 12:09:16brodiesetnosy: + brodie
2009-05-31 22:08:03brett.cannonsetmessages: + msg88615
2009-05-31 20:39:12mark.dickinsonsetnosy: + mark.dickinson
messages: + msg88608
2009-05-31 19:36:24brett.cannonsetmessages: + msg88604
2009-05-31 19:04:19ericktsetnosy: + erickt
messages: + msg88603
2009-05-31 15:10:41rpetrovsetnosy: + rpetrov
messages: + msg88598
2009-05-31 14:35:25benjamin.petersonsetfiles: + locale_fix.patch
keywords: + patch
messages: + msg88597
2009-05-31 07:34:18brett.cannoncreate