[Python-Dev] use cases for "python-config" versus "pkg-config python"
Hello! Stumbling over problems on AIX (Modules/python.exp not found) building libxml2 as python module let me wonder about the intended use-cases for 'python-config' and 'pkg-config python'. FWIW, I can see these distinct use cases here, and I'm kindly asking if I got them right: * Build an application containing a python interpreter (like python$EXE itself): + link against libpython.so + re-export symbols from libpython.so for python-modules (platform-specific) + This is similar to build against any other library, thus = 'python.pc' is installed (for 'pkg-config python'). * Build a python-module (like build/lib.-/*.so): + no need to link against libpython.so, instead + expect symbols from libpython.so to be available at runtime, platform-specific either as + undefined symbols at build-time (Linux, others), or + a list of symbols to import from "the main executable" (AIX) + This is specific to python-modules, thus = 'python-config' is installed. Thank you! /haubi/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] use cases for "python-config" versus "pkg-config python"
Hi,
following up myself with a patch proposal:
On 05/28/2014 04:51 PM, Michael Haubenwallner wrote:
> Stumbling over problems on AIX (Modules/python.exp not found) building
> libxml2 as python module
> let me wonder about the intended use-cases for 'python-config' and
> 'pkg-config python'.
>
> FWIW, I can see these distinct use cases here, and I'm kindly asking if I got
> them right:
>
> * Build an application containing a python interpreter (like python$EXE
> itself):
> + link against libpython.so
> + re-export symbols from libpython.so for python-modules (platform-specific)
> + This is similar to build against any other library, thus
> = 'python.pc' is installed (for 'pkg-config python').
>
> * Build a python-module (like build/lib.-/*.so):
> + no need to link against libpython.so, instead
> + expect symbols from libpython.so to be available at runtime,
> platform-specific either as
> + undefined symbols at build-time (Linux, others), or
> + a list of symbols to import from "the main executable" (AIX)
> + This is specific to python-modules, thus
> = 'python-config' is installed.
>
Based on these use-cases, I'm on a trip towards a patch improving AIX support
here,
where the attached one is a draft against python-tip (next step is to have
python-config
not print $LIBS, but $LINKFORMODULE only).
Thoughts?
Thank you!
/haubi/
diff -r dc3afbee4ad1 Makefile.pre.in
--- a/Makefile.pre.in Mon Jun 02 01:32:23 2014 -0700
+++ b/Makefile.pre.in Mon Jun 02 19:57:54 2014 +0200
@@ -87,6 +87,9 @@
SGI_ABI= @SGI_ABI@
CCSHARED= @CCSHARED@
LINKFORSHARED= @LINKFORSHARED@
+BLINKFORSHARED=@BLINKFORSHARED@
+LINKFORMODULE= @LINKFORMODULE@
+BLINKFORMODULE=@BLINKFORMODULE@
ARFLAGS= @ARFLAGS@
# Extra C flags added for building the interpreter object files.
CFLAGSFORSHARED=@CFLAGSFORSHARED@
@@ -540,7 +543,7 @@
# Build the interpreter
$(BUILDPYTHON):Modules/python.o $(LIBRARY) $(LDLIBRARY) $(PY3LIBRARY)
- $(LINKCC) $(PY_LDFLAGS) $(LINKFORSHARED) -o $@ Modules/python.o
$(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)
+ $(LINKCC) $(PY_LDFLAGS) $(BLINKFORSHARED) -o $@ Modules/python.o
$(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)
platform: $(BUILDPYTHON) pybuilddir.txt
$(RUNSHARED) $(PYTHON_FOR_BUILD) -c 'import sys ; from sysconfig import
get_platform ; print(get_platform()+"-"+sys.version[0:3])' >platform
@@ -666,7 +669,7 @@
fi
Modules/_testembed: Modules/_testembed.o $(LIBRARY) $(LDLIBRARY) $(PY3LIBRARY)
- $(LINKCC) $(PY_LDFLAGS) $(LINKFORSHARED) -o $@ Modules/_testembed.o
$(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)
+ $(LINKCC) $(PY_LDFLAGS) $(BLINKFORSHARED) -o $@ Modules/_testembed.o
$(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)
# Importlib
@@ -1310,7 +1313,7 @@
# pkgconfig directory
LIBPC= $(LIBDIR)/pkgconfig
-libainstall: all python-config
+libainstalldirs:
@for i in $(LIBDIR) $(LIBPL) $(LIBPC); \
do \
if test ! -d $(DESTDIR)$$i; then \
@@ -1319,6 +1322,16 @@
elsetrue; \
fi; \
done
+
+# resolve Makefile variables eventually found in configured python.pc values
+$(DESTDIR)$(LIBPC)/python-$(VERSION).pc: Misc/python.pc Makefile
libainstalldirs
+ @echo "Resolving more values for $(LIBPC)/python-$(VERSION).pc"; \
+ if test set = "$${PYTHON_PC_CONTENT:+set}"; \
+ then echo '$(PYTHON_PC_CONTENT)' | tr '@' '\n' > $@; \
+ else PYTHON_PC_CONTENT="`awk -v ORS='@' '{print $0}' < Misc/python.pc`"
$(MAKE) $@ `grep = Misc/python.pc`; \
+ fi
+
+libainstall: all python-config libainstalldirs
$(DESTDIR)$(LIBPC)/python-$(VERSION).pc
@if test -d $(LIBRARY); then :; else \
if test "$(PYTHONFRAMEWORKDIR)" = no-framework; then \
if test "$(SHLIB_SUFFIX)" = .dll; then \
@@ -1338,7 +1351,6 @@
$(INSTALL_DATA) Modules/Setup $(DESTDIR)$(LIBPL)/Setup
$(INSTALL_DATA) Modules/Setup.local $(DESTDIR)$(LIBPL)/Setup.local
$(INSTALL_DATA) Modules/Setup.config $(DESTDIR)$(LIBPL)/Setup.config
- $(INSTALL_DATA) Misc/python.pc $(DESTDIR)$(LIBPC)/python-$(VERSION).pc
$(INSTALL_SCRIPT) $(srcdir)/Modules/makesetup
$(DESTDIR)$(LIBPL)/makesetup
$(INSTALL_SCRIPT) $(srcdir)/install-sh $(DESTDIR)$(LIBPL)/install-sh
$(INSTALL_SCRIPT) python-config.py $(DESTDIR)$(LIBPL)/python-config.py
@@ -1540,6 +1552,7 @@
-rm -rf build platform
-rm -rf $(PYTHONFRAMEWORKDIR)
-rm -f python-config.py python-config
+ -rm -f M
Re: [Python-Dev] AIX to stable, what does that take?
Hi Michael,
being on a similar road with Gentoo Prefix, I really do appreciate
your AIX related work!
However, for two (not so minor) topics I've got a little different
experience, which I think should be mentioned here for completion:
On 10/04/2018 11:13 AM, Michael Felt wrote:
> On 10/4/2018 10:30 AM, INADA Naoki wrote:
>> Hello,
>>
>> First of all, congratulations on passing all test on AIX.
>> As a one of core developer, I don't know anything about AIX.
>> If my change breaks AIX build, I can't investigate what's happened.
>>
>> So I think we need following in devguide:
>>
>> * Brief description about AIX, from developer's point of view.
> This I might be able to do. Bullet form:
> ... I build everything myself, using xlc
> (gcc introduces the need for a GNU RTE, e.g., glibc).
Using gcc does *not* require to use glibc or even GNU binutils at all.
Except for gcc's own runtime libraries, there's no need for a GNU RTE.
In fact, in Gentoo Prefix I do use gcc as the compiler, configured to
use AIX provided binutils (as, ld, nm, ...), with AIX libc as RTE.
> * finally, a bit deeper: while the AIX linker loader supports svr4
> shared libraries (it is the data, not the file name) it also supports
> having multiple shared libraries in a classic archive. So, rather that
> .../lib/libxxx.so and .../lib64/libxxx.so AIX prefers .../lib/libxxx.a
> with two so-called members, with same or different names. The one found
> is not it's name, but the symbol name and size of the ABI (32-bit or 64-bit)
While this all is true, having multiple *versions* of one shared library in
one single file is a PITA for package managers - both human or software.
But fortunately, the AIX linker does support so called "Import Files",
allowing for *filename based* shared library versioning like on Linux,
while still allowing for both ABIs in a single library archive file.
For example, libtool provides the --with-aix-soname={aix|svr4|both}
configure flag since libtool-2.4.4. Although the default will stay
at 'aix' here, in Gentoo Prefix I do use 'svr4' only. This actually
is a package manager's decision, ideally for all depending packages.
As gcc does use libtool, for more information please refer to
https://gcc.gnu.org/install/configure.html#WithAixSoname
But note that "Import Files" should work with xlc as well.
Thanks!
/haubi/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
