This is the mail archive of the
mailing list for the Cygwin project.
Re: Cygwin GCC linking Python extensions issue
Jason Tishler <firstname.lastname@example.org> writes:
> 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\
> 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.
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\
> 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.
> 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'
>> boost_python.lib(d000000.o)(.idata$2+0x0): first defined here
>> d000001.o(.idata$5+0x0): multiple definition of `__imp___ZN5boost6python5scope13current_scopeE'
>> 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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html