Add FreeBSD to the same class as Linux, GNU, and NetBSD
so that the shared library will be built and installed
on FreeBSD systems when --enabled-shared is specified.

I didn't regenerate the configure script as I wasn't
sure what version of autoconf would be desired. I'll
leave that up to the committer, if accepted.

Logged In: YES 
user_id=21627

Looks good to me.

Logged In: YES 
user_id=595483

Adding a patch that fixes configure (and configure.in). Used 
autoconf2.59 as is specified in previous configure script.

Patch is at 
http://seojiwon.dnip.net:8000/~jiwon/configure.patch

Logged In: YES 
user_id=55188

FreeBSD port (their packaging system) already has
a scheme for shared library.

http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/patch-configure?rev=1.10&content-type=text/x-cvsweb-markup

It would be good if Python's setting become simliar
to FreeBSD port's.

Logged In: YES 
user_id=595483

http://seojiwon.dnip.net:8000/~jiwon/configure.patch2 

Here's a patch conforming to FreeBSD port scheme. (I think)
However, for "ac_cv_pthread_system_supported" problem, I
think it's better patched in port system, isn't it?

Logged In: YES 
user_id=1044177

This might be a question for the port maintainer, but what's
the point of cutting the .0 off the SOVERSION? Having it
there hasn't caused any trouble for my CVS build(yet?)..

Logged In: YES 
user_id=55188

For jiwon's patch:

You don't need to post a patch to configure, only
configure.in is enough.  For line 1347,1354, I think we
don't need to keep using not $CC but 'cc' as linker on
OpenBSD.  AFAIK, OpenBSD uses gcc as their compiler set and
there're no alternatives available.  So, it'll not need to
have a special case for OpenBSD.

And, ac_cv_pthread_system_supported stuff is to fix Python's
pthread scope behavior that is not appropriate on FreeBSD.
(In FreeBSD, system scope threads are very expensive than
process scope threads and the former has lots of limitations
on resource usages.)  I think it can go into Python src as a
ifdef'ed block, I will post a patch in a new bug item soon.

To jwpye:

FreeBSD's runtime linker system can't handle so versions
with dot(s).  You can link againt shared objects with dotted
so versions if you explicitly specified rpath on linking. 
But -lpython2.3.1.0 may not be found by ldconfig(1) nor ld
-shared.
Hence, it tends to make KDE and/or GNOME applications using
python difficult to compile.

Logged In: YES 
user_id=595483

Okay. 
Here's the patch reflection  your suggestion.

http://seojiwon.dnip.net:8000/~jiwon/configure.in

Logged In: YES 
user_id=21627

perky, I fail to understand your comment on versioning. It
appears to suggest that the patch attached to this report
does not work. However, if it doesn't work, I'm surprised
that jwpye suggested it in the first place.

Anyway, assigning the entire issue to you for resolution.

Logged In: YES 
user_id=1044177

I understand now:

flaw@void:~ % sudo ldconfig /usr/lib /usr/local/lib
/usr/X11R6/lib /usr/dev/lib
flaw@void:~ % ldconfig -r | grep 'python'
        342:-lpython2.3.1 => /usr/local/lib/libpython2.3.so.1

/usr/dev/lib has libpython2.4.so and libpython2.4.so.1.0

flaw@void:~ % cd /usr/dev/lib
flaw@void:/usr/dev/lib % sudo ln -s libpython2.4.so.1.0
libpython2.4.so.1
flaw@void:/usr/dev/lib % sudo ln -sf libpython2.4.so.1
libpython2.4.so
flaw@void:/usr/dev/lib % l libpython2.4.so
lrwxr-xr-x  1 root  wheel  - 17B Oct 21 18:01
libpython2.4.so -> libpython2.4.so.1
flaw@void:/usr/dev/lib % l libpython2.4.so.1
lrwxr-xr-x  1 root  wheel  - 19B Oct 21 18:01
libpython2.4.so.1 -> libpython2.4.so.1.0
flaw@void:/usr/dev/lib % sudo ldconfig /usr/lib
/usr/local/lib /usr/X11R6/lib /usr/dev/lib
flaw@void:/usr/dev/lib % ldconfig -r | grep 'python'
        342:-lpython2.3.1 => /usr/local/lib/libpython2.3.so.1
        625:-lpython2.4.1 => /usr/dev/lib/libpython2.4.so.1

Although, it doesn't appear to be "fatal". A ld
-L/usr/dev/lib -lpython2.4 will work fine, either way.

Logged In: YES 
user_id=55188

Sorry for late reply, jwpye.

Whether ldconfig(1) can catch a shared library or not can be
not so important if all applications detect by trying
linkings with explicit path or -L option.  But, even FreeBSD
ports uses ldconfig(1) to track dependency and ports
prohibits installing shared libraries with dotted versions.
(you can define NO_FILTER_SHLIBS=yes to avoid the rule.)

In fact, FreeBSD developers are discussing internally about
allowing lib*.so.major.minor versions for base shared
libraries like libc. But Python tends to keep perfect ABI
compatibility within branches and shared library major
versions are virtually useless for Python. So, I think we
can use just ".1" in FreeBSD anyways.

Logged In: YES 
user_id=1044177

Okay. Thanks for handling and explaining this, perky, as it
is a rather important aspect that I had obviously missed.

Logged In: YES 
user_id=55188

Thanks!

Just checked it in:
configure.in 1.473
configure 1.460
Misc/NEWS 1.1178