On Fri, Feb 07, 2003, Andrews, Martin wrote:
> I am trying to tweak the python package to get support for xml - it requires
> expat. I thought I had a clever (for my first openpkg patch) solution to
> pick up libraries from the openpkg installation but I think I am now butting
> my head against the static library policy - how do you get binary extensions
> to scripting languages without shared libraries? Any thoughts? This may be a
> show stopper for me. Here are the errors that occur while building python on
> solaris (7 and 9):
Extensions for scripting languages do usually not require
shared libraries, they just provide their extensions as shared
libraries/objects. The usual approach (which Perl and Python use)
are that an extension module foo.so is build by linking against an
externally available library libfoo.a (a so-called static library).
This step _includes_ the static library into the new shared library
foo.so which in turn is loaded on demand by the scripting language via
dlopen(3) and friends (like the GNU libtool wrapper around it).
For this to work, the static library libfoo.a in Unix theory just has to
be compiled with Position Independent Code (PIC), but is not required to
be linked into a shared library format itself. And because all modern
Unix platforms are smart enough to on-the-fly transform non-PIC into
PIC, in practice you can create a scripting language extension foo.so by
linking in an arbitrary static library libfoo.a.
But all this does not conflict with the OpenPKG policy of using static
_libraries_. Because our policy is about <prefix>/lib/libfoo.so files,
i.e., those files which are _implicitly_ loaded by the run-time link
editor RTLD (the Unix program loader). xxx.so files in other locations
and which are loaded _explicitly_ by an application (like a scripting
language as Perl and Python) are not affected by this policy at all.
> building 'pyexpat' extension
> /.d1/openpkg/RPM/TMP/Python-2.2.2/Modules/pyexpat.c: In function
> `get_version_string':
> /.d1/openpkg/RPM/TMP/Python-2.2.2/Modules/pyexpat.c:1556: warning: subscript
> has type `char'
> /opt/openpkg/bin/cc -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -fPIC
> -DHAVE_EXPAT_H=1 -I. -I/.d1/openpkg/RPM/TMP/Python-2.2.2/./Include
> -I/opt/openpkg/include -I/.d1/openpkg/RPM/TMP/Python-2.2.2/Include
> -I/.d1/openpkg/RPM/TMP/Python-2.2.2 -c
> /.d1/openpkg/RPM/TMP/Python-2.2.2/Modules/pyexpat.c -o
> build/temp.solaris-2.9-sun4u-2.2/pyexpat.o
> /opt/openpkg/bin/cc -shared build/temp.solaris-2.9-sun4u-2.2/pyexpat.o
> -L/opt/openpkg/lib -lexpat -o build/lib.solaris-2.9-sun4u-2.2/pyexpat.so
> WARNING: removing "pyexpat" since importing it failed
>
> Or without binutils:
>
> building 'pyexpat' extension
> /opt/openpkg/RPM/TMP/Python-2.2.2/Modules/pyexpat.c: In function
> `get_version_string':
> /opt/openpkg/RPM/TMP/Python-2.2.2/Modules/pyexpat.c:1556: warning: subscript
> has type `char'
> Text relocation remains referenced
> against symbol offset in file
> <unknown> 0x1f14
> /opt/openpkg/lib/libexpat.a(xmlparse.o)
> <unknown> 0x1f18
> /opt/openpkg/lib/libexpat.a(xmlparse.o)
Hmmm.... I've still not clue what the problem here is. I've to check
this myself on our platforms in depth first. I'll investigate if time
permits, although Python is not one of my favorite pieces of software ;_)
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
User Communication List [EMAIL PROTECTED]
