I get a number of "cannot find -lpython2.5" error when building Python
2.5.2 on FreeBSD 2.5.2 with gcc 2.95.4.
This problem is only occured when I build it with "--enable-shared"
configure option.

This is how you can reproduce this problem.

cd Python-2.5.2
configure --enable-shared
make

and you will get

gcc -shared
build/temp.freebsd-4.11-RELEASE-i386-2.5/usr/home/build/dev/Python-2.5.2/Modules/_struct.o
-L/usr/local/lib -lpython2.5 -o build/lib.freebsd-4.11-RELEASE-i386-2.5/_
struct.so
/usr/libexec/elf/ld: cannot find -lpython2.5
...
/home/build/dev/Python-2.5.2/Modules/_ctypes/libffi/src/x86/sysv.o
-L/usr/local/lib -lpython2.5 -o
build/lib.freebsd-4.11-RELEASE-i386-2.5/_ctypes.so
/usr/libexec/elf/ld: cannot find -lpython2.5
...
gcc -shared
build/temp.freebsd-4.11-RELEASE-i386-2.5/usr/home/build/dev/Python-2.5.2/Modules/_ctypes/_ctypes_test.o
-L/usr/local/lib -lpython2.5 -o build/lib.freebsd-4.11-RELEA
SE-i386-2.5/_ctypes_test.so
/usr/libexec/elf/ld: cannot find -lpython2.5 
...
gcc -shared
build/temp.freebsd-4.11-RELEASE-i386-2.5/usr/home/build/dev/Python-2.5.2/Modules/_weakref.o
-L/usr/local/lib -lpython2.5 -o build/lib.freebsd-4.11-RELEASE-i386-2.5/
_weakref.so
/usr/libexec/elf/ld: cannot find -lpython2.5
...
gcc -shared
build/temp.freebsd-4.11-RELEASE-i386-2.5/usr/home/build/dev/Python-2.5.2/Modules/arraymodule.o
-L/usr/local/lib -lpython2.5 -o build/lib.freebsd-4.11-RELEASE-i386-2
.5/array.so
/usr/libexec/elf/ld: cannot find -lpython2.5
......


You can workaround this by running  ./configure LDFLAGS="-L."
--enable-shared.

Please try this patch with a clean source tree. It adds the current
directory to the library search path.

Index: setup.py
===================================================================
--- setup.py    (revision 67295)
+++ setup.py    (working copy)
@@ -245,6 +245,7 @@
     def detect_modules(self):
         # Ensure that /usr/local is always used
         add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
+        add_dir_to_list(self.compiler.library_dirs, '.')
         add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')

         # Add paths specified in the environment variables LDFLAGS and

Christian's patch fixed this problem!
(tested on 4.11-RELEASE)

I'm not sure why the other platforms don't suffer this problem.

Since r53691, and issue 1600860, "." is added to library_dirs on Linux
and GNU systems. This probably should be extended to FreeBSD, and other
systems.

The critical point to notice is that the -L option is not only while
building Python itself, but also for extension modules (assuming Python
is installed into a non-standard location).

Now, the question is how to extend this approach to FreeBSD. For 2.5 and
2.6, I think it is safest to explicitly add freebsd to the list of
systems tested for.

For the trunk, and probably 3.0, I would try to add the library whenever
Py_ENABLE_SHARED is defined, and os.name is posix.

Changing the title because this is not 2.5.x specific.

Changing the title again because this problem is not FreeBSD 4 specific.
Build on recent FreeBSD also has the same problem.
(I tested this on 6.3, too)

2.5.3 is out of scope for this issue (and thus, the whole of 2.5). There
is no workable patch, yet, and 2.5.3 is just two weeks ahead.

Martin,
Two questions:

1. Isn't Christian's patch enough for this?
2. How about Python 3.0 and 2.6.1? Are they also out of scope for this?

> 1. Isn't Christian's patch enough for this?

No. It should be dealt with in the same way as on Linux (or the Linux
way should be changed).

> 2. How about Python 3.0 and 2.6.1? Are they also out of scope for this?

Not yet, no. However, they are soon to be released, so chances are low
that a patch arrives in time.

A more appropriate patch should be (for 2.7 trunk - I'm grabbing a checkout of 3.2 trunk now):

Index: build_ext.py
===================================================================
--- build_ext.py	(revision 77388)
+++ build_ext.py	(working copy)
@@ -280,7 +280,7 @@
         # Python's library directory must be appended to library_dirs
         sysconfig.get_config_var('Py_ENABLE_SHARED')
         if ((sys.platform.startswith('linux') or sys.platform.startswith('gnu')
-             or sys.platform.startswith('sunos'))
+             or sys.platform.startswith('sunos') or sys.platform.startswith('freebsd'))
             and sysconfig.get_config_var('Py_ENABLE_SHARED')):
             if sys.executable.startswith(os.path.join(sys.exec_prefix, "bin")):
                 # building third party extensions


I'm hoping someone will weigh in on whether this should be done on all versions of FreeBSD (I don't see why not, but perhaps there is some magic that I don't understand in newer versions).

configure.in has the same action for NetBSD*|FreeBSD*|DragonFly*, so I think distutils should parallel that. Not sure what sys.platform would be on the other BSDs, though.

NetBSD is netbsd* and DragonFly is dragonfly* (currently dragonfly2, although I suspect in this way dragonfly1 was identical, if it ever existed).