[Python-bugs-list] [ python-Bugs-794140 ] cygwin builds do not embed

Thu Sep 4 05:51:20 EDT 2003

Bugs item #794140, was opened at 2003-08-24 07:18
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794140&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alejandro Lopez-Valencia (dradul)
Assigned to: Jason Tishler (jlt63)
Summary: cygwin builds do not embed

Initial Comment:
As an example case, try to build a copy of vim with an 

embeded python interpreter:

"""

indow.o   objects/if_python.o objects/py_config.o     

objects/netbeans.o  object

s/version.o       -lncurses   -liconv -lintl   -

L/usr/lib/python2.3/config -lpyt

hon2.3 -lutil -lm

objects/py_config.o(.data+0x4):config.c: referencia a 

`_initthread' sin definir

objects/py_config.o(.data+0xc):config.c: referencia a 

`_initsignal' sin definir

objects/py_config.o(.data+0x14):config.c: referencia a 

`_initposix' sin definir

objects/py_config.o(.data+0x1c):config.c: referencia a 

`_initerrno' sin definir

objects/py_config.o(.data+0x24):config.c: referencia a 

`_init_sre' sin definir

objects/py_config.o(.data+0x2c):config.c: referencia a 

`_init_codecs' sin defini

r

"""

As you can see, it doesn't embed. 

I have tracked down the failure to a problem in the 

LDSHARED defaults provided by configure.in. The default 

supplied is:

LDSHARED="gcc -shared -Wl,--enable-auto-image-

base";;

but this *does not* work. As per Cygwin documentation 

on the creation of DLLs, this works (already tested 

compiling vim under the same conditions):

LDSHARED="gcc -shared -Wl,--enable-auto-image-base -

Wl,--export-all-symbols -Wl,--enable-auto-import";;

As a side note, please notice that this problem, proper 

user of GNU ld flags under win32, has a direct impact on 

the possible success of a true Mingw32 port (which I 

expect eagerly).

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

>Comment By: Jason Tishler (jlt63)
Date: 2003-09-04 03:51

Message:
Logged In: YES 
user_id=86216

I should have mentioned that the patch assumes Python's

builtin modules are only written in C (not C++). If this

assumption is incorrect, then I will add the standard

__cplusplus/extern "C" idiom.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-09-04 03:37

Message:
Logged In: YES 
user_id=86216

Combined the original two patches into one and refreshed

against current CVS.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-09-02 12:11

Message:
Logged In: YES 
user_id=86216

Please try again with the second patch applied too.  The

combination of them seem to work for me.

> I have tested it against the release23-maint CVS branch,

>and unfortunately it doesn't work.. 

BTW, it would have been helpful it you indicated that the

first patch eliminated all but 3 link errors.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-27 07:31

Message:
Logged In: YES 
user_id=86216

What do you get when you execute the following?

$ objdump -p libpython2.3.dll | fgrep '] init'

Are you building vim against the newly built Python?

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-27 07:13

Message:
Logged In: YES 
user_id=659006

I have tested it against the release23-maint CVS branch, and

unfortunately it doesn't work.. 

*Sigh* I mentioned the autotools because I didn't see the

patch at first (the wonders of top posting, who designed

this bug-tracker?). But now... I think we need an export

symbols definition file... :-(

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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-27 06:12

Message:
Logged In: YES 
user_id=86216

> Yes, I am willing to test it.

Thanks. Are you willing to build against Python CVS? Or,

do you need me to provide you with replacements for

libpython2.3.dll.a and libpython2.3.dll?

> Yet... Don't you think you are complicating the issue, the

> autotool files and your life, too much?

I don't think so. Note that my approach does not affect

any autotools files.

> There are no obvious security issues involved and...

IIRC, exporting all symbols under Win32 can cause

multiple definition link errors.

> Anyway, it's your ballgame, it's your call.

I appreciate your willingness to acquiesce.

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-27 05:06

Message:
Logged In: YES 
user_id=659006

Yes, I am willing to test it.

Yet... Don't you think you are complicating the issue, the

autotool files and your life, too much? There are no obvious

security issues involved and the procedure only adds extra

text to the DATA segment in the DLLs, there are no changes

in the actual object code; it won't become a hybrid

DLL/implib such as cygwin1.dll! Take any Unix shared library

(Linux, Solaris, BSD, whatever), and it is already exporting

*all symbols*, how else would you be able to link to them?

There are no import libs, that's a Windows/MacOS Classic

abomination as far as I am concerned :-)

Anyway, it's your ballgame, it's your call.

Cheers

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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-26 05:46

Message:
Logged In: YES 
user_id=86216

I would prefer to just export the missing symbols than

all of them which is unnecessary and possibly problematic.

The attached patch (against Python CVS) exports the

following additionally symbols:

$ objdump -p libpython2.3.dll | fgrep '] init'

        [ 794] init_codecs

        [ 795] init_sre

        [ 796] init_symtable

        [ 797] initerrno

        [ 798] initposix

        [ 799] initsignal

        [ 800] initthread

        [ 801] initxxsubtype

        [ 802] initzipimport

Does the above meet your needs? Are you willing to test

your vim build against it?

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 03:05

Message:
Logged In: YES 
user_id=659006

Opps!

Sorry, my link fell down in the middle of submitting the form. 

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 03:00

Message:
Logged In: YES 
user_id=659006

Ramifications to changing LDSHARED? I don't perceive any 

besides having slightly bigger dlls, and the possibility to 

extract symbol definitions and create import libraries out of 

plugins, perhaps even linking extensoins directly (as in writing 

derivative extensions from, say, Numeric).

Adding -Wl,--enable-auto-import doesn't modify the defaults 

but hushes the linker, less perturbing line noise in stderr.

On giving you an example, I only use python under cygwin 

and having just managed to build my first embedded vim, I'm 

starting to experiment. There are some reasonable examples 

in vim's documentation (see ':h if_pyth.txt'). This works for 

me:

1. Type a line of text. Leave cursor on line.

2. Enter command mode and type:

    python import vim; vim.current.line = vim.current.line.upper

()

And about your "Huh?", this is the python bug tracker last 

time I checked. The issue is a GNU ld/Win32 issue, not 

necessarily exclusive to Cygwin. I am leaving a hint for future 

developers.

Cheers.

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

Comment By: Alejandro Lopez-Valencia (dradul)
Date: 2003-08-26 02:57

Message:
Logged In: YES 
user_id=659006

Ramifications to changing LDSHARED? I don't perceive any 

besides having slightly bigger dlls, and the possibility to 

extract symbol definitions and create import libraries out of 

plugins, perhaps even linking extensoins directly (as in writing 

derivative extensions from, say, Numeric).

Adding -Wl,--enable-auto-import doesn't modify the defaults 

but hushes the linker, less perturbing line noise in stderr.

On giving you an example, I only use python under cygwin 

and having just managed to build my first embedded vim, I'm 

starting to experiment. There are some reasonable examples 

in vim's documentation (see ':h if_pyth.txt'). This works for 

me:

1. Type a line of text. Leave cursor on line.

2. Enter command mode and type:

    python import vim; vim.current.line = vim.current.line.upper

()

And about your "Huh?", this is the python bug tracker last 

time I checked. The issue is a GNU ld/Win32 issue, not 

necessarily exclusive to Cygwin. I am leaving a hint for future 

developers.

Cheers.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-08-25 10:32

Message:
Logged In: YES 
user_id=86216

AFAICT, changing LDSHARED will affect building extensions

too. So, I am very hesitant to change its definition without

fully understanding the ramifications. Note that Cygwin

Python extensions have been working for almost three

years now. Additionally, I WAG that there are many more

people building extensions than embedding.

> LDSHARED="gcc -shared -Wl,--enable-auto-image-base

> -Wl,--export-all-symbols -Wl,--enable-auto-import";;

I can understand why adding "-Wl,--export-all-symbols"

fixes the above link errors. However, I don't understand

why "-Wl,--enable-auto-import" would help. IIRC, it

defaults to enabled anyway. Does vim with an 

embeded python interpreter build without this option?

Can you provide me a small embedded example so I

can do some testing? Using vim seems a bit unwieldy.

> As a side note, please notice that this problem, proper 

> user of GNU ld flags under win32, has a direct impact on 

> the possible success of a true Mingw32 port (which I 

> expect eagerly).

Huh? How is this related to the report Cygwin problem?

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

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