build dumps core (binutils 2.13/solaris)

[arkoenig]

BPO	596422
Nosy	@gvanrossum, @loewis
Files	test-dynload: shell script to check that dynamic linking works configure: patch to "configure" to work around the problem configure.in: patch to "configure.in" to work around the problem configure.in: patch to "configure.in" to work around the problem elflink.h: Patch to binutils 2.13.1

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/loewis'
closed_at = <Date 2003-01-03.17:26:21.000>
created_at = <Date 2002-08-17.13:44:32.000>
labels = ['build']
title = 'build dumps core (binutils 2.13/solaris)'
updated_at = <Date 2003-01-03.17:26:21.000>
user = 'https://bugs.python.org/arkoenig'

bugs.python.org fields:

activity = <Date 2003-01-03.17:26:21.000>
actor = 'nnorwitz'
assignee = 'loewis'
closed = True
closed_date = None
closer = None
components = ['Build']
creation = <Date 2002-08-17.13:44:32.000>
creator = 'arkoenig'
dependencies = []
files = ['588', '589', '590', '591', '592']
hgrepos = []
issue_num = 596422
keywords = []
message_count = 13.0
messages = ['12026', '12027', '12028', '12029', '12030', '12031', '12032', '12033', '12034', '12035', '12036', '12037', '12038']
nosy_count = 4.0
nosy_names = ['gvanrossum', 'loewis', 'nnorwitz', 'arkoenig']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue596422'
versions = []

[arkoenig]

Installing Python 2.2.1 on Solaris causes a core dump
during build (just after trying to load struct.so) if I
am using binutils 2.13. This happens with either gcc
3.1.1 or gcc 3.2, on either solaris 7 or solaris 8. I
suspect it happens on other combinations as well.

It works just fine with binutils 2.12.1, so the problem
appears to be in binutils, not Python per se. The
attached file, contributed by Zack Weinberg
(zack@codesourcery.com), tests for the presence of the
problem; if it executes to completion, the problem
isn't there.

Perhaps it might make sense to put a similar test into
the Python installation procedure?

[arkoenig]

Logged In: YES
user_id=418174

I have learned from Nick Clifton at Red Hat that the source
of the problem is a change in the default linker options
between 2.12 and 2.13. The specific option that causes the
trouble is -zcombreloc, which is the default in 2.13, and
which apparently produces a dll that doesn't work under
Solaris. Don't know whether this is a Solaris bug or not,
but a workaround is clearly indicated.

Attached are patch files that can be applied to configure
and configure.in (in the Python root directory) to work
around the problem.

[arkoenig]

Logged In: YES
user_id=418174

Here's the patch to configure.in

[gvanrossum]

Logged In: YES
user_id=6380

Looks harmless to me, but I can't test it. Only the
configure.in patch is really needed; we generate configure
using autoconf (and then check it in for the benefit of others).

Assigning to MvL.

Martin, can you test this on Solaris with the indicated GCC
release? Or should we just jump the gun??? (Hm, what about
older GCC releases -- it needs to be tested there too.)

I'd still like to understand what "combreloc" does...

[loewis]

Logged In: YES
user_id=21627

combreloc is not a compiler option, but a linker option. For
GNU binutils, it was first implemented in 2.12. The system
linker supports this option since Solaris 7. Older binutils
versions ignore -z options that they don't recognize, so
there is no need for a version check here.

The option arranges to combine multiple relocation sections,
sorting them by symbol so that multiple relocations for the
same symbol follow each other. The dynamic linker can cache
the most-recently looked-up symbol from relocation to
relocation, so that combreloc reduces the number of symbol
lookups.

I somehow doubt the validity of this patch, though: the
entire approach was pioneered by Sun for Solaris, so if it
causes problems with GNU binutils, it is likely a binutils bug.

Therefore, I'd postpone this patch until the issue has been
fully studied by binutils maintainers, and would advise
against using binutils 2.13 on Solaris for the moment.

[arkoenig]

Logged In: YES
user_id=418174

Binutils 2.13.1 is still not right. I am told that 2.13.2
will be out soon and will fix the problem.

[loewis]

Logged In: YES
user_id=21627

I will wait before making changes until the entire issue is
settled (or until the 2.3 release is getting near). Thanks
for the update.

[arkoenig]

Logged In: YES
user_id=418174

At this point, I do not believe that any changes to Python
are necessary. The main point is for people installing
Python on Solaris (and perhaps elsewhere) to realize that
they must not use binutils 2.13 or 2.13.1. The attached
patch will make binutils 2.13.1 work.

[arkoenig]

Logged In: YES
user_id=418174

Here is a patch (to binutils) that makes it possible to
build Python with binutils 2.13.1.

[loewis]

Logged In: YES
user_id=21627

I still have the plan of adding a comment to README pointing
out what binutils releases need to be avoided, but that can
be done when we know what binutils release to use.

[nnorwitz]

Logged In: YES
user_id=33168

Andrew reported (on python-dev) the problem is fixed.
Martin, is there anything you want to do for this bug
report? You mentioned writing something in the README.

[loewis]

Logged In: YES
user_id=21627

Skip just mentioned he would update the README; if that is
done, this can be closed.

[nnorwitz]

Logged In: YES
user_id=33168

Skip checked in the change, so I'm closing.