Making AIX happy using dynamic linking

Galen Swint hcsgss at texlife.com
Tue Jul 24 16:01:28 EDT 2001


This outlines how to:
  - build python as a shared lib on AIX
  - build dyanmic modules that use shared libs on AIX

I posted a couple of weeks ago asking about problems with Python, shared
libraries and AIX. Basically what we wanted to do was this: have Python
load a C extension module which was a shared lib, which in turn relied
upon another shared lib which also needed embedded Python. It looks
like this:
Python -> imdpdfmodule -> libimagedoc.so -> embedded python
Naturally, we wanted the embedded python to be the same code as the
top-level interpreter, so that meant libimagedoc.so had to link back
up to the the Python level. It took a long time to get it all right
because neither one of us working on the project has much experience with
shared libs, and AIX doesn't make things easy. Here are the build
statements we ended up using (the .o files are built with plain old
gcc -c -g).
###
libimagedoc.so: libimagedoc.o xmtframe_backend.o
	rm -f libimagedoc.so
	/usr/local/Python-2.1/Modules/makexp_aix libimagedoc.exp
"libimagedoc.so" libimagedoc.o xmtframe_backend.o
$(IMAGEMAGICKHOME)/magick/.libs/libMagick.a $(PCLOBJS) /usr/local/lib/libt1.a
	$(CC) -shared -Wl,-G -Wl,-bE:libimagedoc.exp
-Wl,-bloadmap:libimagedoc.map -Wl,-H512 -Wl,-T512 -o libimagedoc.so
libimagedoc.o xmtframe_backend.o $(PCLOBJS)
$(IMAGEMAGICKHOME)/magick/.libs/libMagick.a /usr/local/lib/libt1.a -ljbig
-ljpeg -lmpeg -ltiff -lpng -lz -lXm -lXt -lX11 -lXext -lm

imdpdfmodule.so: imdpdfmodule.o libimagedoc.so libimagedocpdf.o
pcl_pdf_render.o
	rm -f imdpdfmodule.so
	./ld_so_aix gcc -Wl,-brtl -o imdpdfmodule.so -einitimdpdf
imdpdfmodule.o libimagedocpdf.o pcl_pdf_render.o -L/usr1/hcsgss/libimagedoc
-limagedoc -L$(PDFLIBHOME)/lib -lpdf

###
Notice that we ended up wrapping some of our static libraries (really just
libt1 and libMagick) in libimagedoc.so and exporting them so that other
shared libs (like imdpdfmodule.so) could use them. Also, we linked with
the -G flag. This left all unresovled symbols at link time to be resolved
by the run-time linker.
Some explanations of some flags we used:
 -Wl,-brtl --- this places the linker in 'dynamic' mode so that it also
           --- recognizes .so libraries
 -Wl,-G --- leaves symbols unresolved at link time to be resolved at
        --- load time

Once we had done this, we ended up with a error message that __eprintf
could not be resolved.  I (admittedly rather hackishly), dodged this
problem by re-making the python executable to export __eprintf.
__eprintf is in libgcc and is normally added to executables, but for some
reason python is not built with it. It must be exported before libimagedoc
could use it, also. I created the export file by hacking python's makefile
to do the following upon building the interpreter:
###
# Build the interpreter
$(PYTHON):	Modules/$(MAINOBJ) $(LDLIBRARY)
		cp Modules/python.exp pythoneprintf.exp; echo "__eprintf" >>
pythoneprintf.exp;
		$(LINKCC) $(LDFLAGS) $(PYLINKFORSHARED) -o $@ \
			Modules/$(MAINOBJ) \
			$(LDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)
###
This allows the run-time loader (rtl) find __eprintf in the interpreter.

Python as a shared lib:

Since we weren't always using libimagedoc with a python interpreter, and
since it relied upon embedded python, we also wanted a copy of python to
be dynamically linked to it. We again hacked python's Makefile and added
the following to the 'libpython$(VERSION).so' rule:
###
	aix*) \
	    $(CC) -shared -Wl,-T512 -Wl,-H512 -Wl,-bE:Modules/python.exp -o $@
$(LIBRARY_OBJS) -lpthread -lm   -lgcc \
      ;; \
###
We then copied this to our (prefix)/lib/config directory and were able to
easily use it by using the standard -Wl,-brtl, -L, and -l flags.

One final note, we always had duplicate symbol errors for some functions
included by -lm when we were using ld_so_aix, I did a little hack on this
so that -lm was included as part of CCARGS instead of CCOPT in lines
171 and 170 respectively.

I don't know if this was the *best* way to do this, but dang it, it works
so we're gonna use it!
:-)
Galen Swint




More information about the Python-list mailing list