W3C home > Mailing lists > Public > xmlschema-dev@w3.org > October 2000

Re: problems with Linking and loading extensions to Python

From: Michael Burns <Michael.Burns@sas.com>
Date: Wed, 25 Oct 2000 13:43:08 -0500
Message-Id: <200010251843.OAA31817@tux.w3.org>
Cc: python-list@python.org, macosx-dev@omnigroup.com, xmlschema-dev@w3.org
To: "Steven D. Majewski" <sdm7g@virginia.edu>
Thanks a whole bunch!  
The '-bundle -undefined warning' did the trick.
Now it no longer complains about the filetype, just one problem
remaining (so far) and that is an unresolved reference to
either dyld_stub_binding_helper
or __mh_dylib_header

If I remove dylib1.o from my ld command the undefined for __mh_dylib_header
goes away and I get the undefined for dyld_stub_binding_helper.
The dyld_stub_binding_helper references is coming from a .o file
compiled this way:
% cc -O2 -DXML_ERRORS -DFOR_LT  -I/usr/local/include/python2.0 -I. -I/usr/local/include/ltxml12   -c NSLintermodule.c -o NSLintermodule8.o
% nm NSLintermodule8.o | grep dyld_stub_binding_helper
         U dyld_stub_binding_helper

There is no mention of this symbol in the .c source or even in the .i file.
I cannot figure out where this reference is coming from or how it is supposed
to be satisfied.  I cannot find mention of it in the man pages for ld, cc, libtool,
dyld.  

otool says there are 75 references to this symbol:
Relocation information (__DATA,__la_symbol_ptr) 75 entries
address  pcrel length extern type    scattered symbolnum/value
00000128 False long   True   VANILLA False     dyld_stub_binding_helper
00000124 False long   True   VANILLA False     dyld_stub_binding_helper
...

My experience with dynamic loading is on AIX, and it does not help much
here.

Any help you can add would be much appreciated. 




Here is my command:

 /usr/bin/ld \
-bundle -undefined warning \
   -arch ppc -o XMLintermodule8.so -L/usr/local/lib \
   NSLintermodule8.o alloc.o block_alloc.o hash.o \
   -lltapi12 -lltstd12 \
   -framework System


On Tuesday, October 24, 2000, at 11:49 PM, Steven D. Majewski wrote:

>  
> On Tue, 24 Oct 2000, Michael Burns wrote: 
>  
> > What is the right combinations of ld options to use? > > Anybody have 
> any examples that work for them? > > > Background: > > I am trying to get 
> an extension to Python to link and load on Mac OS X public beta. > > > I 
> have tried many combinations of ld options like -dyld, -bundle, -dylinker, 
> -fvmlib, > > -preload > > > Some of them give me unresolved references or 
> other ld complaints.  
>  
> Are you using Python 2.0 ?  
>  
> Take a look at the switches the python2.0/Modules/Makefile uses for 
> building shared libraries: "-bundle -undefined suppress"  
>  
> I used the following command to link the python gtk module: 
>  
> cc -bundle -undefined warning gtkmodule.o  -L/usr/local/lib  
> -L/usr/X11R6/lib -lgtk -lgdk -lgmodule -lgthread -lglib -lXext  -lX11     
> .libs/lib_gtkmodule.a   -o _gtkmodule.so 
>  
>  
> ---|  Steven D. Majewski   (804-982-0831)  <sdm7g@Virginia.EDU>  |--- 
> ---|  Department of Molecular Physiology and Biological Physics  |--- 
> ---|  University of Virginia             Health Sciences Center  |--- 
> ---|  P.O. Box 10011            Charlottesville, VA  22906-0011  |--- 
> 		"All operating systems want to be unix,  
> 		 All programming languages want to be lisp."  
>  
>  
> --  
> http://www.python.org/mailman/listinfo/python-list 
>  
>  

------------------------------------------------------------------------
Michael Burns                        email: Michael.Burns@sas.com
Principal Systems Developer           home: mburns@bga.com 
Metadata Integration Technology      voice: (512)258-5171x3264
SAS Institute, Inc.                    fax: (512)258-3906
11920 Wilson Parke Ave.                www: http://www.realtime.net/~mburns
Austin, TX 78726-4052                  sww: http://sww.sas.com/~sasmkb
"choose for yourselves today whom you will serve;...
 but as for me and my house, we will serve the Lord." Joshua 24:15
Received on Wednesday, 25 October 2000 14:43:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:14:47 UTC