I'm under the impression that this is issue is known about, however I couldn't find an existing bug, so I'm creating a new one for the following test failure:


test_distutils
/usr/lib/gcc/i686-pc-linux-gnu/4.4.4/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lpython2.6
collect2: ld returned 1 exit status
test test_distutils failed -- Traceback (most recent call last):
  File "/var/tmp/paludis/build/dev-lang-python-2.6.4-r1/work/Python-2.6.4/Lib/distutils/tests/test_build_ext.py", line 258, in test_get_outputs
    cmd.run()
  File "/var/tmp/paludis/build/dev-lang-python-2.6.4-r1/work/Python-2.6.4/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/var/tmp/paludis/build/dev-lang-python-2.6.4-r1/work/Python-2.6.4/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self.build_extension(ext)
  File "/var/tmp/paludis/build/dev-lang-python-2.6.4-r1/work/Python-2.6.4/Lib/distutils/command/build_ext.py", line 531, in build_extension
    target_lang=language)
  File "/var/tmp/paludis/build/dev-lang-python-2.6.4-r1/work/Python-2.6.4/Lib/distutils/ccompiler.py", line 848, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/var/tmp/paludis/build/dev-lang-python-2.6.4-r1/work/Python-2.6.4/Lib/distutils/unixccompiler.py", line 265, in link
    raise LinkError, msg
LinkError: command 'i686-pc-linux-gnu-gcc' failed with exit status 1


Perhaps I'm missing something here, but surely trying to link against the system (i.e. already installed, pre-existing) libpython2.6 defeats the purpose of having a testsuite, if you're not actually going to be testing what you're actually installing?

Any enlightenment here would be appreciated.

Thanks for the report. Can you reproduce with a more recent 2.6, or even the current stable version 2.7?

Thanks for the speedy response! I'm fairly certain that this affects 2.6.5 as well. I'll test and report back when I'm in front of my development machine (sometime tomorrow).

Valeo, can you reproduce the bug? Final version of 2.6 will come out on Monday.

this affects 2.7 as well. the problem was introduced by r78136 which skips out of the directory containing newly built libpython2.7, so the linking command cannot find it in -L. and fails (unless a systemwide libpython is already present)

the tests should probably specify that they want to link to a specific file, instead of relying on -lpython
however, i have no idea how to do that in general, let alone within distutils :/

see also issue8335

Hello,
on an up-to-date 2.7 I can't replicate this bug:

$ ./python Lib/test/regrtest.py test_distutils
test_distutils
1 test OK.

Is it just me or is been fixed already?

If it still exists in 2.6, I don’t think it could be fixed, that version being in security mode now.  (Barry is the release manager, he’ll chime in if I’m wrong.)

Valeo, can you reproduces the bug on 2.7?  Distutils code has been reverted to a prior version recently, which may be the explanation for the apparent fix, but the bug could still exist with distutils2.  Can you clone http://hg.python.org/distutils2/ and run the test suite on your machine?

Jan, do you think we should close this as a duplicate of #8335?  I’ve just read that one and it looks like the same bug.

I'm afraid this can't be fixed in 2.6.

i was able to reproduce this in clean 2.7
Sandro, this is only reproducible on systems without python - so by definition, you can hit this only during installation

as for issue8335, yes, i think that it's a duplicate

distutils2 is irrelevant here, because you can only install it on top of existing python. The problem here is that stdlib's distutils must use the newly built libpython, *not* the systemwide one - a problem that distutils2 don't need to solve until they become part of stdlib.

> i was able to reproduce this in clean 2.7
> as for issue8335, yes, i think that it's a duplicate

Ok, then please add your failure messages on the other bug.

> Sandro, this is only reproducible on systems without python
>- so by definition, you can hit this only during installation

Hm, Sandro didn’t say whether he had a system Python or not.

> distutils2 is irrelevant here

This is internal bookkeeping, you can ignore it.  When we fix something in distutils, it’s forward-ported to distutils2.  I don’t want to wait until the end to synchronize bug fixes.

On Mon, Oct 18, 2010 at 15:29, Éric Araujo <report@bugs.python.org> wrote:
> Éric Araujo <merwok@netwok.org> added the comment:
>> Sandro, this is only reproducible on systems without python
>>- so by definition, you can hit this only during installation
>
> Hm, Sandro didn’t say whether he had a system Python or not.

yes I have :) I can try on an isolated chroot to replicate the
problem, but it will probably take me some day to have the time to do
that,

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Even though this one's older, I'm going to mark it as a duplicate of issue 10126, which is tracking the backport of the fix I made in Python 3.2 to 3.1 and 2.7.

The key issues here are that Python was built with --enabled-shared and the test *only* fails when running 'make test'.  Running ./python as Sandro did does not trigger the bug - at least it didn't in 3.2.

Seems like roundup hates me.  Just go to issue 10126.