New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow building python as shared library #36219
Comments
This patch allows building python as a shared library.
|
Logged In: YES Could you submit the thread.o double inclusion patch I like the idea of building Python as a shared lib, but I'm I need more reviewers. Maybe the submitter can get some P.S. it would be better if you used the current CVS or at |
Logged In: YES As the first issue, I'd like to clarify ownership of this The same comments that I made to bpo-497102 apply to this patch |
Logged In: YES IMHO this patch has a couple of problems. The main one is that GNU configure has standard options for enabling shared library support, --enable/disable-shared/static. They should be used! The other is that it's Linux-only. Shared library support tends to work well, for varying definitions of "well" anyway, on lots of platforms, but you really need to use libtool for it. That would also get rid of the LD_PRELOAD, since that'd be encapsulated by libtool. It's a rather bigger job to convert something like Python to libtool properly instead of hacking the Makefile a bit, and the build will definitely get somewhat slower as a result, BUT if we agree that a shared Python library is a good idea (i think it is!), the work is definitely worth doing. |
Logged In: YES Sorry, I've been inspired by the former patch and I have |
Logged In: YES While I agree on the "not Linux only" and "use standard |
Logged In: YES libtool sucks. Case closed. |
Logged In: YES Ok, so no libtool. Did I get correctly, that you want:
|
Logged In: YES Yes, that is all right. The approach, in general, is also Also, I still like to get a clarification as to who is the |
Logged In: YES This ain't gonna happen on the 2.2.x branch, so changing group. |
Logged In: YES As far as I can see, the problems are: I'm the author of the patch (ppython.diff). I'm not the |
Logged In: YES The patch looks quite good. There are a number of remaining
|
Logged In: YES A SOVERSION of 0.0 makes perfect sense for the CVS head. Release versions should probably use 1.0. I don't quite know, though, if builds from CVS should keep a fixed SOVERSION -- after all, the API can change. One idea would be to use the tip version number of Doc/api/api.tex, i.e. libpython2.3.so.0.154 or libpython2.3.154.so.0.0. |
Logged In: YES The CVS version will usually use a completely different |
Logged In: YES This is exactly the problem -- if today's libpython23.so replaces last week's libpython23.so, then everything I built during the last week is going to break if the ABI changes. That's why I think that incorporating the version number from api.tex is a good idea -- call me an optimmist, but I think that any change will be documented. ;-) This kind of problem is NOT pretty. I went through it a few years ago when the GNU libc transitioned to versioned linking. It managed to cause a LOT of almost-intractable incompatibilities during that time, and I don't care at all to repeat that experience with Python. :-( |
Logged In: YES The API version is maintained in modsupport.h:API_VERSION. I'm personally not concerned about breakage of API during |
Logged In: YES I have rebuilt the patch against CVS
|
Logged In: YES I think the remaining issues are shallow only: Few users |
Logged In: YES Thanks for the patch, committed as Makefile.pre.in 1.78 I hope you'll stay around to deal with the bug reports for |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: