8 hrs invested, 1 unresolved external symbol to go...

Hi Dan,

> Still trying to get p4perl to install, keeping things
as plain-vanilla as I
> can:
>
> - Windows XP
> - ActiveState Perl v5.8.8 (latest, I believe)
> - M$ Visual C++ Express
> - P4-3.5708
> - API 2004.2.83213

It's worth noting that P4Perl 3.5708 was built with the
2006.1 API. While it 
should work with an older version (such as the 2004.2
version you're using), 
it almost certainly won't work with a newer one. 

> Any help at all would be greatly appreciated...

See below.

> libsupp.lib(fileiont.obj) : error LNK2001: unresolved
external symbol __iob
> libsupp.lib(diffsp.obj) : error LNK2001: unresolved
external symbol __iob
> libclient.lib(clientuser.obj) : error LNK2019:
unresolved external symbol
> __iob referenced in function "public: virtual
> void __thiscall ClientUser::OutputError(char *)"
(?OutputErrorClientUser
> UAEXPADZ)
> libsupp.lib(debug.obj) : error LNK2001: unresolved
external symbol __iob
> libsupp.lib(echoctl.obj) : error LNK2001: unresolved
external symbol __iob
> libsupp.lib(errorlog.obj) : error LNK2001: unresolved
external symbol __iob
> blibarchautoP4P4.dll : fatal error LNK1120: 1
unresolved externals
> NMAKE : fatal error U1077: '"C:Program
FilesMicrosoft Visual Studio
> 8VCBINlink.EXE"' : return code '0x460'

__iob is part of the stdio library. I can't imagine why your
linker can't find 
that - unless your Visual Studio environment is messed up? I
assume LIB, 
INCLUDE and all the other required VS environment variables
are set 
correctly? Usually there's a vcvars32.bat file you can run
to set them up 
before using the compilers from the command line.

Can you check that and let us know if it helps?

Thanks,

Tony
_______________________________________________
p4perl mailing list
p4perlperforce.com

http://maillist.perforce.com/mailman/listinfo/p4perl

On Tuesday 24 July 2007 17:16, Dan Lindy wrote:
> I found this:
>
> http://forums.microsoft.com/MSDN/ShowPo
st.aspx?PostID=327790&SiteID=1
>
> LNK2001s/LNK2019s are usually a result of mixing debug
libs with release
> libs (or libs compiled with another version of Visual
Studio). It can also
> be caused by static libraries not using the same
runtime library (project
> properties -> c/c++ -> code generation ->
runtime library -> should be /MDd
> for debug and /MD for release).
>
> Seems it may not be possible to use VS 2005 unless
Perforce provide a
> compatible set of libs.

OK, I've reproduced this, and I can't get P4Perl to build
with ActivePerl 
5.8.8 and VS 2005 either. Using the Perforce API at:

http://filehost.perforce.com/perforce/r06.2/b
in.ntx86/dyn/p4api.tar

resolves the build errors, but then you hit runtime loading
errors which, I 
think, have to do with incompatibilities between the version
of Visual Studio 
used to compile Perl and the version used for P4Perl.
Microsoft's C Runtime 
problems basically.

Do you need to build it yourself Dan, or can you just use
the pre-built 
installer? The precompiled installer for the development
build is compatible 
with ActivePerl 5.8.8 (it's compiled with Visual Studio
2003). If you want to 
compile it yourself, I suspect you'll need to use VS 2003.

Tony
_______________________________________________
p4perl mailing list
p4perlperforce.com

http://maillist.perforce.com/mailman/listinfo/p4perl

Hi Dan,

> Thanks for the follow-up. I was actually unaware that
the Windows installer
> included a pre-built version of the binary. I was under
the impression,
> from the documentation, that the binary had to be built
locally. Now that I
> look at the page again it seems obvious, but it wasn't
when I was reading
> through your instructions as there is no mention of
using the bre-built
> binary in step #2.

Thanks for the feedback, I'll take a look at improving the
page.

> Because of the plethora of version compatibility
issues, I am uneasy at
> this point about using an API which may break during a
future upgrade, 

I'm not sure I agree with that - once it's installed, it
works with all 
versions of Perforce, so you only need to upgrade if you
want to (and you can 
test that before you do it). 

> so I 
> am electing to go with basic scripting (using system
calls to p4 commands).
> This is less than ideal, as I am interested in
listening to audit events,
> but seems a simpler and more stable approach, at least
for now.

I'm sorry you had a hard time getting P4Perl to build, but I
hope it hasn't 
given you the wrong impression. P4Perl really is very stable
and is widely 
used.

The issue we hit is discussed online at: 
http://www.p
erlmonks.org/?node_id=621976 (amongst others), and it
seems that 
ActiveState are still using VS 6.0 to compile ActivePerl.
Small wonder then 
that modules compiled with VS 2005 aren't instantly
compatible with it! I 
think ActiveState have been lucky to get away with it for so
long. 

> If I had lots of time on my hands to get the API
working and play around
> with it, I'd likely go that route. For now, I'm out of
time and need to
> move on.
>
> Thanks for your help, though. P4Perl looks like a
worthwhile project and I
> hope to get a chance to use it in the future.

Good luck Dan.

Tony
_______________________________________________
p4perl mailing list
p4perlperforce.com

http://maillist.perforce.com/mailman/listinfo/p4perl

> Seems it may not be possible to use VS 2005 unless
Perforce provide a
> compatible set of libs.

Note that until very recently, Perl on Windows couldn't be
compiled by
VS2005 - and that meant that modules couldn't be compiled
with it
either.  I think only with the latest ActiveState build
(820) did
building with VS2005 become possible.

John

_______________________________________________
p4perl mailing list
p4perlperforce.com

http://maillist.perforce.com/mailman/listinfo/p4perl