LINKCC incorrectly set

[cardou]

BPO	569668
Nosy	@akuchling

^{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/akuchling'
closed_at = <Date 2002-12-03.14:01:16.000>
created_at = <Date 2002-06-16.15:12:32.000>
labels = ['build']
title = 'LINKCC incorrectly set'
updated_at = <Date 2002-12-03.14:01:16.000>
user = 'https://bugs.python.org/cardou'

bugs.python.org fields:

activity = <Date 2002-12-03.14:01:16.000>
actor = 'akuchling'
assignee = 'akuchling'
closed = True
closed_date = None
closer = None
components = ['Build']
creation = <Date 2002-06-16.15:12:32.000>
creator = 'cardou'
dependencies = []
files = []
hgrepos = []
issue_num = 569668
keywords = []
message_count = 3.0
messages = ['11213', '11214', '11215']
nosy_count = 3.0
nosy_names = ['akuchling', 'nnorwitz', 'cardou']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue569668'
versions = ['Python 2.2']

[cardou]

I was building Python 2.2.1 on Debian/GNU Linux 3.0
(testing pre-release) with gcc and g++ of version 3.0.4,
using --with-cxx=g++ configure option. Then linking of the
"python" executable fails due to an unresolved symbol
(__gxx_personality_v0) in Modules/ccpython.o, because
linking is still done with gcc: LINKCC is set to gcc ($CC)
by configure, rather than to g++ ($CXX).

The configure script attempts to determine the value of
LINKCC and sets it to $CC if the latter can
successfully link
the simplest program "int main(){return 0;}" which was
compiled with $CXX. In this case, linking apparently
succeeds, setting LINKCC to $CC. Yet linking of
Modules/ccpython.o with $CC fails, probably because
Modules/ccpython.c is slightly more complex than the
above configuration test, hence an extra unresolved
symbol generated by g++.

I am not sure how the correct value of LINKCC can be
determined at config time without unnecessarily using
$CXX all the time when it is available. Maybe the
makefile should be modified so it always starts from
$CC and falls through to $CXX if the former fails?

Sincerely,
Dr. Leonid Timochouk
Computing Laboratory
University of Kent at Canterbury
England

[nnorwitz]

Logged In: YES
user_id=33168

I believe there were some changes made which should fix this
problem. Can you try the latest CVS for the 2.2 branch or
2.3?

cvs update -r release22-maint
will get the 2.2.1+ version (what will become 2.2.2).

Thanks.

[akuchling]

Logged In: YES
user_id=11375

As Neal suggested, this problem seems to be fixed in Python 2.2.2 and 2.3CVS. Marking as closed.