From: joshturner1967 on
Hello I apologize if I have this in the wrong group again but I tried
the moderated comp lang moderated C group and in microsoft.­public.­
dotnet.­languages.­vc they both suggested I try another group. The
last group sugested this group. I know it's not an exact match but I
was wondering if you guys could
help me out. Please know that it's not my intention to overpost this
issue but rather to try and resolve it

I have several projects written C that interacts with a third party
api. This third
party has a library that compiles and links in VS 2005 lets call it
pnznmapi55.lib. However when I take the same code swap out the
includes
and the libs for an upgraded version of 58 and of course using
pnznmapi58.lib
then it will compile but will not link.


I have my additional link lib directory set to the path of the lib
and
I also have the actual lib mentioned in the addtional dependencies.
This is standard for what we did for the old lib and also standard
for
what we did for the old lib in Vs 2003 as well. I am confused as to
what the problem might be. The third party is trying to say that
it's
because I don't have my environmental variables setup properly for
2005 but if that is the case then why would it work for 55 but not 58
of the lib. The link messages that I am getting is the standard
lnk2001 here is an example


pnznmapi.lib(tdebug.obj) : error LNK2001: unresolved external symbol
_pnz_errfrm_unmark_API


As you can see it all comes back to the pnznmapi.lib which is the lib
I am specifically linking too in my link sentings - I have no
control
over _pnz_ type symbols since they are internal third party code.


Anybody have any ideas? I am stumped


Thanks
Josh


From: Carl Daniel [VC++ MVP] on
joshturner1967 wrote:
> As you can see it all comes back to the pnznmapi.lib which is the lib
> I am specifically linking too in my link sentings - I have no
> control
> over _pnz_ type symbols since they are internal third party code.
>
>
> Anybody have any ideas? I am stumped

Add the /verbose switch to the linker command line arguments. This will
show you the full path to every module and library that the linker loads -
you may find your problem right there.

If that doesn't turn up anything useful, then add /showIncludes to the
compiler command line options and do a full rebuild. This will show you the
full path to every file that the compiler includes.

If that doesn't help, try building the smallest program that you can using
the 3rd party library and see if that works - build up from there until you
find the problem.

You're either somehow building with a mismatched header/library set, or it's
a bug in the 3rd party library that you're using.

-cd


From: joshturner1967 on
On May 7, 12:14 pm, "Carl Daniel [VC++ MVP]"
<cpdaniel_remove_this_and_nos...(a)mvps.org.nospam> wrote:
> joshturner1967 wrote:
> > As you can see it all comes back to the pnznmapi.lib which is the lib
> > I am specifically linking too in my link sentings  - I have no
> > control
> > over _pnz_ type symbols since they are internal third party code.
>
> > Anybody have any ideas?  I am stumped
>
> Add the /verbose switch to the linker command line arguments.  This will
> show you the full path to every module and library that the linker loads -
> you may find your problem right there.
>
> If that doesn't turn up anything useful, then add /showIncludes to the
> compiler command line options and do a full rebuild.  This will show you the
> full path to every file that the compiler includes.
>
> If that doesn't help, try building the smallest program that you can using
> the 3rd party library and see if that works - build up from there until you
> find the problem.
>
> You're either somehow building with a mismatched header/library set, or it's
> a bug in the 3rd party library that you're using.
>
> -cd

Thanks for the suggestions on the settings. With those being set they
clearly show that VS 2005 is pulling the the files from the new
directories for the new version.

I sent the output off to the third party to show them the results and
I am awaiting their response.

Just out of curiousity and to rule it out could it be anything to do
with any of my system and or user environmental variables for my
computer? Given that the fact that the correct paths seems to be
found for the new version of the api as well as finding the proper VS
2005 directories.

Thanks
Josh