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

Sorry to be pulling you into this, but would you see if this patch fixes
your woes?

Benjamin, configure script check for function textdomain in libintl.

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

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

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.

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.

Here's another patch.

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.

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.

@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.

What about the third?

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.

Does that fix framework builds, too?

It works fine for my framework build on 10.4.11

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.

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.

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.

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?

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.

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.

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.

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.

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)

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.

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.

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

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

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

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

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.

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.

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.

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.

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.

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.