Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
Subject: Re: Cygwin GCC linking Python extensions issue
References: <ullwxonvt DOT fsf AT boost-consulting DOT com>
	<20030527131009 DOT GA1624 AT tishler DOT net>
From: David Abrahams <dave AT boost-consulting DOT com>
Date: Tue, 27 May 2003 10:45:22 -0400
In-Reply-To: <20030527131009.GA1624@tishler.net> (Jason Tishler's message of
 "Tue, 27 May 2003 09:10:10 -0400")
Message-ID: <uhe7gxxbx.fsf@boost-consulting.com>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Jason Tishler <jason AT tishler DOT net> writes:

> Dave,
>
> On Fri, May 23, 2003 at 08:20:38AM -0400, David Abrahams wrote:
>> Recently I've begun to see the following link errors when building
>> some of the Boost.Python test suite extension modules using Cygwin gcc
>> (version 2 or 3, doesn't matter) and Python 2.2.2 release or Python
>> 2.3 debug.
>
> When did you begin to see this problem?  Specifically, what changed?
> The tools or the Boost code?

I'm afraid both changed before I noticed it.

>> Does anyone have an explanation/workaround for this?
>
> Not really, but I have some (possibly useless) comments below...
>
>> g++ -fmessage-length=0  -Wl, --export-all-symbols -Wl, --exclude-symbols, _bss_end__:
>>     _bss_start__:_data_end__:_data_start__ -Wl, --out-implib, c:\build\libs\python\test\bin\
>>     args_ext.pyd\gcc\debug-python\runtime-link-dynamic\args_ext.lib  -g -shared  -o "c:\build\
>>     libs\python\test\bin\args_ext.pyd\gcc\debug-python\runtime-link-dynamic\args_ext.dll" 
>
> Why are you using Win32 as opposed to Posix style pathnames?  Why are
> you using Win32 as opposed to Posix style extensions (e.g., ".lib" vs.
> ".a")?

It's an artifact of my multi-compiler/platform build system; the next
version of it uses paths and extensions appropriate for Cygwin even
when building from a Win32 shell, but I'm still using the old one for
production work.  I probably should stop that, but anyway, my users
still need it to work, and it always has worked for me.

>>     -L"/usr/local/pydebug/lib/python2.3/config" -L"c:/build/libs/python/build/bin/boost_python.
>>     dll/gcc/debug-python/runtime-link-dynamic"   "c:\build\libs\python\test\bin\args_ext.pyd\
>>     gcc\debug-python\runtime-link-dynamic\args.obj"  "c:\build\libs\python\build\bin\
>
> Ditto for ".obj".
>
> Does the above imply a mixing of Win32 and Cygwin Python?

Not one bit.

>>     boost_python.dll\gcc\debug-python\runtime-link-dynamic\boost_python.lib"  "c:\build\libs\
>>     python\build\bin\boost_python.dll\gcc\debug-python\runtime-link-dynamic\boost_python.lib"
>>     -lpython2.3.dll
>         ^^^^^^^^^^^^^
>
> Does the above imply direct linking against the DLL (i.e., python2.3.dll)
> instead of the import library (i.e., python2.3.dll.a)?  

No, when you write -lxxx, you link against libxxx.a, so I'm linking
against the import library: libpython2.3.dll.a

> If so, then try linking against the import library.
>
>>     -lboost_python
>         ^^^^^^^^^^^^
>
> Ditto for the above.

Likewise.  Or as they say in NYC, "ditto to you too, bub."

>> d000000.o(.idata$2+0x0): multiple definition of `__head_boost_python_dll'
>> c:\build\libs\python\build\bin\boost_python.dll\gcc\debug-python\runtime-link-dynamic\
>>     boost_python.lib(d000000.o)(.idata$2+0x0): first defined here
>> d000001.o(.idata$5+0x0): multiple definition of `__imp___ZN5boost6python5scope13current_scopeE'
>> c:\build\libs\python\build\bin\boost_python.dll\gcc\debug-python\runtime-link-dynamic\
>> [snip]
>> Info: resolving boost::python::scope::current_scope     by linking to
>>     __imp___ZN5boost6python5scope13current_scopeE (auto-import)
>
> Try providing the necessary __declspec(dllimport)/__declspec(dllexport)
> to eliminate the auto-import.

For one thing, I don't know which ones are "the neccessary" ones:
__head_boost_python_dll is not my symbol.

For another, a long time ago I stopped trying to use *any*
__declspec(dllxxx) with Cygwin builds because they always gave me
problems (the details of which I don't remember).  I have lots of
BOOST_PYTHON_EXPORT macro usages to provide the __declspecs only when
they're needed (e.g. not on Unix).  I'd hate to have to add a second
BOOST_PYTHON_CYGEXPORT macro which is __declspec(dllxxx) only on
Cygwin and used for particular symbols, but if it works out, I guess
that's what I'll do.

Thanks for your help.
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/