[ python-Bugs-1530448 ] ctypes build fails on Solaris 10

Tue Aug 1 22:02:29 CEST 2006

Bugs item #1530448, was opened at 2006-07-28 17:04
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Thomas Heller (theller)
Summary: ctypes build fails on Solaris 10

Initial Comment:
Thomas,

I tried to build Python from cvs (svn rev 50905) on
Solaris 10 today.
Compiler was gcc 3.4.  I got a text relocation error
when linking
ctypes.so:

/opt/app/g++lib6/gcc-3.4/bin/gcc -shared
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o
-L/usr/local/lib -o
build/lib.solaris-2.10-i86pc-2.5/_ctypes.so
Text relocation remains                         referenced
    against symbol                  offset      in file
ffi_closure_SYSV_inner              0x8e       
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o
ld: fatal: relocations remain against allocatable but
non-writable sections
collect2: ld returned 1 exit status

I tried configuring both with and without the
--with-system-ffi flag.
The error was the same in both cases.

If you need more information, let me know.

Skip

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-08-01 22:02

Message:
Logged In: YES 
user_id=11105

I didn't know there are any systems that depend on the order
of object files on the linker command line any more ;-).

IIUC, the objects list is derived by distutils from the
sources list, so the attached patch (for
Modules/_ctypes/libffi/fficonfig.py.in) *could* do the
trick.  Please make sure that fficonfig.py is recreated (by
doing make clean before building or whatever).
Thanks for looking into this.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-08-01 18:16

Message:
Logged In: YES 
user_id=44345

    Thomas> Skip, do you have *any* idea what might be
    Thomas> wrong, or could you even come up with a patch?

    Skip> I've no idea so far.  I'll try to find some time
    Skip> to take a look at it later today.

Thomas,

Sorry for the delay.  I think I have it figured out and it
was fairly straightforward.  Looking at the files in order
on the _ctypes.so link line we see that the definition of
ffi_closure_SYSV_inner is defined before it's referenced:

    for obj in
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o
 ; do echo $obj; nm -p $obj | egrep ffi_closure_SYSV_inner; done

build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o

build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o

build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o

build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o

build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o

build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o

build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o

build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o

build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o

build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o
    0000000456 T ffi_closure_SYSV_inner

build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o
    0000000000 U ffi_closure_SYSV_inner

Since we're linking from object files, it's a one-pass link
algorithm.  At the time ffo.o is examined, sysv.o hasn't
been seen.  Consequently, ffi_closure_SYSV_inner is not yet
known and its definition isn't picked up from ffi.o.

I couldn't quickly figure out where the link command is
generated, but I'm sure you'll know where it resides.
Either swap ffi.o and sysv.o on the link line, or add ffi.o
a second time to resolve the new reference.

Skip

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-31 12:54

Message:
Logged In: YES 
user_id=11105

Skip, do you have *any* idea what might be wrong, or could
you even come up with a patch?

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-07-29 00:03

Message:
Logged In: YES 
user_id=44345

Yeah, you'd definitely need -fPIC on any brand of Solaris.  That test might be 
changed to

    plat = get_platform()
    if plat in (... buncha platforms ...) or "solaris" in plat:
        os.environ["CFLAGS"] = "-fPIC"

That doesn't seem to be what's happening in this case though.  I rm'd the .o 
files in .../Modules/_ctypes and tried again.  The compile commands *do* 
have -fPIC on them.  I don't think it's required on the link line.

S

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-07-28 18:19

Message:
Logged In: YES 
user_id=11105

Skip,

This looks *somewhat* like the problems reported in bugs
1529269 and 1528620 (although they have a sparc, and you
seem to have x86 solaris).

Hm, in the standalone ctypes setup script, I find this code
snippet:

if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]:
    os.environ["CFLAGS"] = "-fPIC"

Can it be that -fPIC must be used, but is not specified?

It is also funny that the solaris buildbot does NOT seem to
have a problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470