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

[David Abrahams]

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

> Hail, thanks for the quick response.

You're welcome. It would be easier to read your replies if you'd leave
a blank line after quoted text.

> David Abrahams <dave at boost-consulting.com> wrote:
> 
> > On the other hand, MSVC6 is reknowned for its many bugs, so you might
> > just be running into a problem with your tools.
> Indeed, and I was using it only because I wanted to compile boost with
> stlport, and there's no toolset to compile intel+stlport.

Huh? What's wrong with
http://www.boost.org/tools/build/intel-win32-stlport-tools.jam?

> > 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 rebuild Boost.Python with Intel 6, because I wanted to
> build it using STLport.

In theory, Intel is supposed to produce code that's link-compatible
with that produced by msvc6. However in general that's not true of C++
compilers and I wouldn't be at all surprised to find out that it fails
in corner cases for msvc6 and Intel C++.

> > That's awfully strange. Does Intel give any more-detailed information
> > about which source files (or preferably functions) are asking for
> > these symbols?
>
> Unfortunetely, no. But here it is the complete error for one of the functions:
> rgba.obj : error LNK2001: unresolved external symbol "__declspec(dllimport)
> void __cdecl boost::python::objects::register_dynamic_id_aux(struct
> boost::python::type_info,struct _STL::pair<void *,struct
> boost::python::type_info> (__cdecl*)(void *))" (
> __imp_?register_dynamic_id_aux at objects@python at boost@@YAXUtype_info at 23@P6A?AU?$
> pair at PAXUtype_info@python at boost@@@_STL@@PAX at Z@Z)

Oh, that's very different: your previous message seemed to indicate
that 3 symbols were missing. This is just one symbol. Unfortunately,
it doesn't change my response.

> > I suggest that you start with a small example using Boost.Build.
>
> Thanks, I will do just that.
> 
> One thing that I noticed after analyzing the command line generated by
> Boost.Build is that I was not specifying the path to my stlport instalation
> correctly! I corrected this, but now the msvc compiler gives internal errors
> while parsing one of the stlport's headers, _complex.h. 8(
> So, the previous unresolved externals where the result of the mixing of
> STLport and the msvc stl implementation, because like I said previously, if I
> compiled without STLport everything worked.

Yeah, that seems plausible. In particular, it was the confusion about
std::pair vs _STL::pair.

> I then compiled everything with Intel 32, without STLport, and Alas!,
> everything works nicely.

Why "alas"? Do you lament the fact that it's working?

>  (except one detail: like I said before, to embed the code in one
> executable, I compiled the static lib with BOOST_PYTHON_STATIC_LIB,
> which was giving me one unresolved external. After I removed this
> define, it compiled and linked without any error or warning).

Is there a reason you need static linking? Dynamically linking to the
boost_python dll should still work for embedding.

> After all this, another question then: How can I compile Boost.Python using
> the Intel compiler and STLport? Unfortunetely, using the native msvc stl
> libraries is not an option for me.

Use the supplied toolset?

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