homepage

gcc -o python Modules/python.o libpython3.3dm.a -lsocket -lnsl -lintl -lrt -ldl -lsendfile -lm 
Undefined first referenced
 symbol in file
libintl_bind_textdomain_codeset libpython3.3dm.a(_localemodule.o)
libintl_gettext libpython3.3dm.a(_localemodule.o)
libintl_textdomain libpython3.3dm.a(_localemodule.o)
libintl_dcgettext libpython3.3dm.a(_localemodule.o)
libintl_bindtextdomain libpython3.3dm.a(_localemodule.o)
libintl_dgettext libpython3.3dm.a(_localemodule.o)
ld: fatal: Symbol referencing errors. No output written to python
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `python'
program finished with exit code 1
http://www.python.org/dev/buildbot/all/builders/sparc%20solaris10%20gcc%203.x/builds/4131/steps/compile/logs/stdio 

The issue doesn't occur on Python 2.7.

The buildbot is Martin's.

Martin, do you have any idea? There doesn't seem to be any recent commits that could have caused this problem.

See also #6617 (which I marked as a duplicate).

> See also #6617 (which I marked as a duplicate).
This issue contains an interesting message (msg91758):
"I dont know Solaris, but googling for "libintl_textdomain solaris" shows 
that many other projects have the same issue.
The solution seems to set LDFLAGS=-lintl"
But I don't think that it would fix the issue because the failing command is "gcc -o python Modules/python.o libpython3.3dm.a -lintl ...".

I ran into this yesterday on my Solaris 10 box (nitrogen/s10), seemingly out of nowhere.
The problem is caused when a GNU libintl.h gets picked up via `#include <libintl.h>` instead of the system one in /usr/include.
In my case, this was happening because I had set CPPFLAGS to "-I/opt/csw/include -I/opt/csw/include/ncurses -I/usr/include".
The fix is to order the includes as follows: "-I/opt/csw/include/ncurses -I/usr/include -I/opt/csw/include".
The order is important: you want the /opt/csw/include/ncurses to come first, otherwise _curses won't build from the curses.h in /usr/include. However, for libintl.h, you want the /usr/include version, not the /opt/csw/include version.
(Side note: I briefly looked at the GNU libintl.h in /opt/csw/include. The `libintl_` function prefix is driven by some #ifdef logic, so, presumably, if you really wanted to build with the GNU libintl, you could do some #define tweaking to disable the `libintl_` prefix. The libintl shipped with Solaris 10 seems to work fine, so I didn't bother with this.)
Closing as fixed.

The `-lintl` fix did not work in my case.
But I succeeded to compile Python using the CC compiler (/usr/bin/cc) instead of GCC compiler.
(cc: Sun C 5.12 SunOS_sparc 2011年11月16日)

> But I succeeded to compile Python using the CC compiler (/usr/bin/cc) instead of GCC compiler.
I may be interesting to check if CC searchs header files in the same
directories than GCC. Same question for libraries. Using GCC, it can
be seen in the command line: -I and -L options. But GCC has also a
builtin list of directories, I don't know how to get this list.
2013年6月7日 Palm Kevin <report@bugs.python.org>:
>
> Palm Kevin added the comment:
>
> The `-lintl` fix did not work in my case.
> But I succeeded to compile Python using the CC compiler (/usr/bin/cc) instead of GCC compiler.
>
> (cc: Sun C 5.12 SunOS_sparc 2011年11月16日)
>
> ----------
> nosy: +palm.kevin
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue13843>
> _______________________________________