PDCurses v2.8 in Visual C++ 2005: "fatal error LNK1104: cannot open file 'LIBC.lib' "
Aaron J. M.
I downloaded PDCurses, put pdcurses.lib and panel.lib in C:\Program
Files\Microsoft Visual Studio 8\VC\PlatformSDK\Lib, and put curses.h,
curspriv.h, panel.h, and term.h in C:\Program Files\Microsoft Visual
Studio 8\VC\PlatformSDK\Include. I right-clicked on my project and
selected Properties, went to Linker -> Input, and put "pdcurses.lib" in
Additional Dependencies.
Everything is fine if all I do is include curses.h. However, when I
call functions from the library and then compile I get "fatal error
LNK1104: cannot open file 'LIBC.lib.' "
Anyone else using Visual C++ and PDCurses ever had this problem?
William McBrine
previous free command-line tools package. I finally installed VC++ 2005
Express Edition the other day...) The link error you're seeing is due to
Microsoft having eliminated the single-threaded libraries.
So, you'd have to build it yourself. Normally, this wouldn't be a big
deal: Just download the source code package, open the "Visual Studio 2005
Command Prompt", and do an "nmake -f vcwin32.mak".
However, MS has thrown up some roadblocks. As you may know, they left the
SDK out of the "Express Edition" package; without it, you don't even have
windows.h. You might already have set up the SDK; but, if you followed the
usual instructions for doing so, it _still_ won't be available from the
command-line environment -- only in the IDE. I haven't seen a recommended
solution for that, but what I did was to find the file "vcvars.txt" (in
C:\Program Files\Microsoft Visual Studio 8\Common7\Tools), rename it
vcvars.cmd, and just run "vcvars" every time I open the command prompt.
Then, there's the problem that "__override", which is used as a function
name in panel.c, has apparently become a reserved word. I've renamed it in
the CVS version to get around this; you can do the same, or ignore it if
you don't care about the panel library.
And, if you try to build the DLL instead of the static library, the
"INITINSTANCE" keyword in curses.def causes an error. (Previously, it gave
a warning.) You can remove it with no ill effects. (It's gone in CVS.)
Finally, Microsoft had the bizarre notion to mark a lot of standard C
library functions as "deprecated". This doesn't prevent compilation, but
it does put up a lot of warnings for no good reason, obscuring any real
problems you might have. You can eliminate these by defining
_CRT_SECURE_NO_DEPRECATE (already done in PDCurses CVS).
Ido Yehieli
compatibility.
Why not just save yourself the trouble and use mingw (gcc for windows)?
Aaron J. M.
OK, I've dumped Visual Studio today.
I actually do have access to gcc (and more importanty, g++, since I'm
using C++) through ssh on my university account. I was just starting
on Visual Studio because
1) I wanted a nice GUI.
2) I already had Visual Studio at the time.
3) I'm trying to make my code as portable as possible. I know that
sounds strange for someone using Visual Studio, but I figured that if I
got my game compiling in VS (avoiding as much Windows-only code as
possible) then I'd transfer it to my university accout and compile it
there or fix the bugs that come up.
Anyway, I've now switched to Code::Blocks and the Borland C++ compiler.
Everything seems fine so far. Wish me luck.
On Jan 21, 12:13 am, William McBrine <wmcbr...@users.sf.net> wrote:
> Finally, Microsoft had the bizarre notion to mark a lot of standard C
> library functions as "deprecated". This doesn't prevent compilation, but
> it does put up a lot of warnings for no good reason, obscuring any real
> problems you might have.
Hm. I would argue that there are a few C functions that are
"depreciated," though gets() vs. fgets() is the only example I can
think of. Of course, whether Microsoft chose the right functions to
depreciate is another matter.
Sherm Pendley
> On Jan 21, 12:13 am, William McBrine <wmcbr...@users.sf.net> wrote:
>> Finally, Microsoft had the bizarre notion to mark a lot of standard C
>> library functions as "deprecated". This doesn't prevent compilation, but
>> it does put up a lot of warnings for no good reason, obscuring any real
>> problems you might have.
>
> Hm. I would argue that there are a few C functions that are
> "depreciated," though gets() vs. fgets() is the only example I can
> think of. Of course, whether Microsoft chose the right functions to
> depreciate is another matter.
Unless we're talking about taxes, William had it right - the word is
deprecated. :-)
Anyway, does it make a difference if you use a C-style "#include <stdio.h>"
vs. a C++-style "#include <cstdio>" to #include the headers?
I don't have VS installed right now to check it out, but maybe it's just
the old-style #include that's been deprecated, not the functions themselves.
Deprecating functions that are still part of the current standard would be
sillier than I'd expect even from MS.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Martin Read
>Deprecating functions that are still part of the current standard would be
>sillier than I'd expect even from MS.
And yet! It's exactly what they've done.
--
Martin Read - my opinions are my own. share them if you wish.
\_\/_/ http://www.chiark.greenend.org.uk/~mpread/dungeonbash/
\ / impending, adj. - Fatal to small demons.
\/
Corremn
I thought this was weird and if breaks backward compatability at lot.
I program in c++ but I am lazy and I use a some of the c string
functions a lot, like sprintf. Now I have to use sprintf_s to avoid
the warning? How is that supposed to compile on other systems? I
quickly learnt to use things like stringstream instead, so thankyou MS
for making me a better c++ programmer ;-P Hah, that last statement
even made me laugh.
Krice
> Studio 8\VC\PlatformSDK\Include. I right-clicked on my project and
> selected Properties, went to Linker -> Input, and put "pdcurses.lib" in
> Additional Dependencies.
With SDL you need to do following things:
Options -> Projects and solutions -> VC++ directories (add SDL
directories
for include and libraries)
Properties (of project) -> Configuration properties -> linker ->
command line
(add complete paths for libraries)
In example case of SDL:
"C:\Program Files\SDL\lib\SDL.lib"
"C:\Program Files\SDL\lib\SDLmain.lib"
You could try it this way and see if it works.
Andrew Patrick Schoonmaker
Sherm Pendley <spam...@dot-app.org> wrote:
>"Aaron J. M." <ajm...@ns.sympatico.ca> writes:
>> On Jan 21, 12:13 am, William McBrine <wmcbr...@users.sf.net> wrote:
>>> Finally, Microsoft had the bizarre notion to mark a lot of standard C
>>> library functions as "deprecated". This doesn't prevent compilation, but
>>> it does put up a lot of warnings for no good reason, obscuring any real
>>> problems you might have.
>>
>> Hm. I would argue that there are a few C functions that are
>> "depreciated," though gets() vs. fgets() is the only example I can
>> think of. Of course, whether Microsoft chose the right functions to
>> depreciate is another matter.
>
>Unless we're talking about taxes, William had it right - the word is
>deprecated. :-)
>
>Anyway, does it make a difference if you use a C-style "#include <stdio.h>"
>vs. a C++-style "#include <cstdio>" to #include the headers?
>
>I don't have VS installed right now to check it out, but maybe it's just
>the old-style #include that's been deprecated, not the functions themselves.
>Deprecating functions that are still part of the current standard would be
>sillier than I'd expect even from MS.
I think in many cases, it's just the buffer-overflow-prone versions of
things that give you this warning, with the recommended fix then being
to use the related function that explicitly states the relevant number
of characters (e.g. strcpy() is deprecated in favor of strncpy()).
Which generally results in a lot of heat and light with old C code, but
I can at least imagine the justification for.
-Andrew ()