classification
Title: Python doesn't compile anymore on our Solaris buildbot: undefined libintl_* symbols
Type: Stage:
Components: Build Versions: Python 3.2, Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, jcea, loewis, palm.kevin, pitrou, skrah, thoratsandip, trent, vstinner
Priority: normal Keywords:

Created on 2012-01-23 21:32 by vstinner, last changed 2013-06-07 07:50 by vstinner. This issue is now closed.

Messages (9)
msg151848 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2012-01-23 21:32
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
msg151849 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2012-01-23 21:34
The issue doesn't occur on Python 2.7.
msg151854 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-01-23 21:58
The buildbot is Martin's.
msg152648 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-02-04 23:44
Martin, do you have any idea? There doesn't seem to be any recent commits that could have caused this problem.
msg152670 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2012-02-05 10:04
See also #6617 (which I marked as a duplicate).
msg152680 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2012-02-05 11:47
> 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 ...".
msg173238 - (view) Author: Trent Nelson (trent) * (Python committer) Date: 2012-10-18 08:15
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.
msg190736 - (view) Author: Palm Kevin (palm.kevin) Date: 2013-06-07 07:45
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)
msg190737 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-06-07 07:50
> 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>
> _______________________________________
History
Date User Action Args
2013-06-07 07:50:11vstinnersetmessages: + msg190737
2013-06-07 07:45:20palm.kevinsetnosy: + palm.kevin
messages: + msg190736
2012-10-18 08:15:27trentsetstatus: open -> closed

nosy: + trent
messages: + msg173238

resolution: fixed
2012-02-05 11:47:58vstinnersetmessages: + msg152680
2012-02-05 10:04:53skrahsetnosy: + skrah, amaury.forgeotdarc, thoratsandip
messages: + msg152670
2012-02-05 10:04:46skrahlinkissue6617 superseder
2012-02-04 23:44:26pitrousetmessages: + msg152648
2012-01-25 17:26:06jceasetnosy: + jcea
2012-01-23 21:58:57pitrousetnosy: + loewis
messages: + msg151854
2012-01-23 21:34:27vstinnersetmessages: + msg151849
versions: + Python 3.2
2012-01-23 21:32:14vstinnercreate