Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Date:	Tue, 27 May 2003 09:10:10 -0400
From:	Jason Tishler <jason AT tishler DOT net>
Subject:	Re: Cygwin GCC linking Python extensions issue
In-reply-to:	<ullwxonvt.fsf@boost-consulting.com>
To:	David Abrahams <dave AT boost-consulting DOT com>
Cc:	cygwin AT cygwin DOT com
Mail-followup-to:	David Abrahams <dave AT boost-consulting DOT com>, cygwin AT cygwin DOT com
Message-id:	<20030527131009.GA1624@tishler.net>
MIME-version:	1.0
User-Agent:	Mutt/1.4i
References:	<ullwxonvt DOT fsf AT boost-consulting DOT com>

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?

> 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")?

>     -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?

>     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)?  If so, then try
linking against the import library.

>     -lboost_python
        ^^^^^^^^^^^^

Ditto for the above.

> 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.

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
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/

- Raw text -