[C++-sig] Linking problems with msvc+stlport

David Abrahams dave at boost-consulting.com
Sat Oct 26 14:55:40 CEST 2002


"Nicodemus" <nicodemus at globalite.com.br> writes:

> Hail!
> 
> I've been trying to use boost python with the msvc 6.0 compiler and
> STLport-4.5.3 for two weeks now, without success.
> 
> I've read the tutorial, and created a short snippet to export a simple class
> that represents color information. I compiled boost without problems (using
> the "msvc-stlport" toolset), and I'm using Python 2.2 (ActiveState's
> distribution).
> I'm using a msvc project to build a DLL, and during the linking stage it
> complains about the following unresolved externals:

Did you try using Boost.Build to create your DLL? Usually when people
have trouble building or linking their Boost.Python projects it's
because they don't set up their build environment to do what
Boost.Build would do; they get the build instructions wrong...

If you invoke Boost.Build with the "-n -a" options it will just dump
all the build commands it runs so you can inspect the command-line
options.

On the other hand, MSVC6 is reknowned for its many bugs, so you might
just be running into a problem with your tools.

> void boost::python::objects::register_dynamic_id_aux(...)
> class boost::python::api::object __cdecl
> boost::python::objects::function_object

These are exported from libs/python/src/object/inheritance.cpp and
libs/python/src/object/function.cpp, respectively.

> Plus, it gives some warnings about:
>  "non dll-interface class 'boost::noncopyable' used as base for dll-interface
> struct 'boost::python::instance_holder'"

You can ignore that warning.

> I've also done the same tests using the Intel 6.0 compiler, and it
> gives the same unresolved externals, but no warnings. 

Did you rebuild the Boost.Python library with Intel 6.0, or are you
trying to use the same one you built with MSVC6?

> I didn't compile boost with Intel and STLport support because I
> couldn't find in the documentation a tool to do it, but would like
> to do it, since I don't plan to use the msvc compiler, which was
> used just for the sake of this tests.

An advantage of Intel + STLPort is that you can turn off the
"microsoft bug emulation mode" in the Intel compiler to get a very
high degree of standard conformance.

> I plan also to create a static library for embedding purposes, so
> that I can link this library with a program, and use the objects
> exported by it. To do this, I compile the lib with the flag
> BOOST_PYTHON_STATIC_LIB, and it gives 2 warnings (about int being
> cast to bool), and in the main() of the program I call the function
> initmymodule() (there's a better way to do this?). When I try to
> compile my application thought, it gives the same unresolved
> externals above.

That's awfully strange. Does Intel give any more-detailed information
about which source files (or preferably functions) are asking for
these symbols?

> On the other hand, If I don't use STLport (including compiling boost
> with the "msvc" toolset), everything works as expected, both the DLL
> and the embeded application.
> 
> What can I do to successfuly compile both the application and the DLL? Any
> pointer will be great!

I suggest that you start with a small example using Boost.Build.

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com





More information about the Cplusplus-sig mailing list