Re: using py_cpp

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-16 02:55:43

----- Original Message -----
From: "Anton Gluck" <gluc_at_[hidden]>

> Dave,
>
> I won't be able to participate in the py_cpp review on the level that I
> have seen here, but hopefully the kinds of problems I am struggling with
> are helpful in some way or another.

Every little bit helps. Thanks for participating.

> I have installed the version of py_cpp posted October 11, and your test
> and example work fine.

Wouldn't hurt to download the latest. I think there were some bugs in the
10/11 version. That probably has nothing to do with your problem, though.

> I am also able to build the DLL I am supposed to
> wrap up for py. However, when I put the two together, I get into
> trouble. In particular, it's the linker that's complaining. In order to
> get started, I began with a single class and single project from the
> whole DLL workspace. I can compile a static library with this
> segment, so I think I got all the necessary parts. Once I add the py_cpp
> code, two warnings come up:
>
> LINK : warning LNK4075: ignoring /EDITANDCONTINUE due to /INCREMENTAL:NO
> specification
>
> and
>
> LINK : warning LNK4098: defaultlib "LIBCD" conflicts with use of other
> libs; use /NODEFAULTLIB:library
>
> The first one is probably not so important, but I'm not sure about the
> second one. Do you have any suggestions?

I don't know if it's important or not. To be honest, I've never built the
source files into a DLL, so they may not be set up optimally for that job.
The only way I've ever tried this is by statically linking the source files
into my extension module. On the other hand, I think these warning messages
are failrly self-explanatory. The MSDN help for the 2nd one is quite
extensive. Just hit F1 from MSVC and type "LNK4098" into the index tab.

> After that I get a bunch of unresolved external symbol errors. The problem
> here might be that even the single class that I am using (which I even
> reduced to the no-argument constructor) might already be too linked up
> with other parts of the code. It would already help me if you could
> confirm that this is the likely cause.

Usually an unresolved symbol error means that you have too few things linked
in, not too many. But this sounds like a generic MSVC/DLL issue (an area in
which I'm not an expert) that has nothing in particular to do with py_cpp.

> Related to this, how would you suggest to go about wrapping a large
> DLL? Is the piece-meal approach not feasible? Is writing wrapper code an
> all-or-nothing adventure?

I'm sorry; could you be more explicit? What do you mean by "piece-meal"?

> A last remark: For the release version of vc6_proj you have both /Ot and
> /Os as compiler options, but it can only be one or the other.

Thanks. That's probably just left over from some stage of experimentation.

-Dave