Weird error when building a debug DLL

Where did you get your PSDK? Maybe try using forward slashes in that PSDK line I had you change since all the other lines use / instead of \.
 
Maybe try using forward slashes in that PSDK line I had you change since all the other lines use / instead of \.

:lol:
I tried to build a debug DLL, but got still the same error. Again, I'll try to rebuild it.

Where did you get your PSDK?
I'm not sure anymore. It was somewhere here CivFanatics. I'll try to look them if i would remember.

EDIT: I'm quite sure, even it was long time ago, that I got all my files from here
 
If you build the "Final_Release" instead of "Debug" profile, it works from the command-line?
 
Did you try doing a Debug build of the unmodified BTS sources? It's always good to verify the simplest case before moving on to something tougher.
 
Ok, just tested it. Crashed like all other tries. Are the files I got from the link in post 42 correct? I used those files but refar's guide, and makefile to BTS 3.19 which i got from an attachment somewhere.
 
Where did you get the makefile from?

I don't remember anymore. It was attached to a post somewhere. I was looking for it because I couldn't build DLLs anymore when I patched to 3.19. I heard you need a new makefile to it and one day, BANG, it was there. I downloaded it fast. It might be gone now, 'cos people usually delete their attachment when they don't need them anymore...

Is it possible to get my projects to build debug DLL?
 
I would search for glider1's makefile. I think he has the latest "good" makefile for 3.19. However, it really doesn't seem like the makefile is the culprit. I think instead you have something else installed that's getting in the way or something missing. Given that all you need is the PSDK and VC++ 2003 Toolkit, there's not much to be missing.

I'm stumped. :(
 
NotSoGood,

When you compiled my source code, did you compile a Final Release or Debug version? If you didn't try a debug version, try it again. If you did, and it succeeded here's my not-so optimal solution:

Remove my source code and put your own in, merge any differences in the makefile and compile.

If you get an error compiling my debug dll, well.... I'm stumped too.
 
I still think it's the missing sal.h file that is causing trouble. I had the same issue and I know from atleast one other person who had the same problem.
 
NotSoGood,

When you compiled my source code, did you compile a Final Release or Debug version? If you didn't try a debug version, try it again. If you did, and it succeeded here's my not-so optimal solution:

Remove my source code and put your own in, merge any differences in the makefile and compile.

If you get an error compiling my debug dll, well.... I'm stumped too.

I compiled a debug DLL with your source code. I tried your idea and in the mean time, when VC was building it with my source, I managed to find glider1's makefile and downloaded it. I checked in the WinMerge what is different there. There were four or five differences with glider1's and mine. And one that interested me was this (do you still remember what was the file that crashed in building the debug DLL)
mine
Code:
Debug/CyMapInterface.obj: CyMapInterface.cpp
	$(Debug_CPP) /nologo $(Debug_CFLAGS) $(Debug_INCS) /c CyMapInterface.cpp /FoDebug/CyMapInterface.obj
glider's
Code:
Debug/CyMapInterface.obj: CyMapInterface.cpp
	$(Debug_CPP) /nologo $(Debug_SAFE_CFLAGS) $(Debug_INCS) /c CyMapInterface.cpp /FoDebug/CyMapInterface.obj
and now when using glider's makefile I managed to build properly a debug DLL. [party] [party] :hammer2: :beer:
I'll have to test if it does work though.

Thank you for your great ideas and awesome help. :worship: :worship: :worship: :worship::worship:
Now I can try to find the reason why my mod crashes so much. :D
 
What does the line that starts like this say?

Code:
Debug_SAFE_CFLAGS=[I][COLOR="Orange"]<what-goes-here?>[/COLOR][/I]
 
What does the line that starts like this say?

Code:
Debug_SAFE_CFLAGS=[I][COLOR="Orange"]<what-goes-here?>[/COLOR][/I]

Code:
Debug_SAFE_CFLAGS= $(Debug_PROJECT_CFLAGS) /MD /GR /Od /W3 /EHsc /DWIN32 /D_DEBUG /D_WINDOWS /D_USRDLL /DCVGAMECOREDLL_EXPORTS /nologo /Gd /TP $(Debug_GLOBAL_CFLAGS)
Also in glider's makefile the PSDK didn't point to Microsoft Platform SDK but C:/Program Files/Microsoft SDKs/Windows/v6.0A like mine did before I changed it. Does it matter what I use?
 
I see two differences between that makefile and BULL's for the CL.EXE command's options: glider1's specifies /Od and /TP.

/Od: Disable all optimizations. BULL uses /O2 (optimize for speed). This should only affect compilation speed and not stop it from building.

/TP: Force all source files to be treated as C++ even if they don't have a .cpp extension. Shouldn't matter for normal SDK code, but might affect BULL due to the xImage .c files. Of course, they are C files--not C++, and I have no trouble building BULL without that flag.

Long story short: I don't see how this would make a difference.
 
I've just read this whole thread because I'm getting essentially exactly the same problems that NoSoGood was facing.

I was using glider's makefile all along, and I also have my SDK on a different partition.

At post 54, NotSoGood seems to have gotten something working when I haven't.

I'm trying to get the standard BtS 3.19 files to compile but getting that u1077 error.

Anyway, since I will be merging in BULL, I thought it best to stop at this point and ask what way to proceed. I've probably asked you about the same thing before EF but I had to re-install all of this software.

I have all of the source files, .cpp and .h for PIG Mod but no working makefile (I used codeblocks for each build).

Another thing which might be a problem is I installed "Microsoft Platform SDK for Windows Server 2003 R2" for the SDK under the assumption it would work just as well as the PSDK. Is this obviously a mistake?
 
Just so we're on the same page here:

  1. You have compiled a DLL on your old system.
  2. You have compiled a debug DLL on your old system.
  3. You can't get your DLL to build on your new system, Final_Release or Debug.
  4. Can you get the unmodified 3.19 DLL to build on your new system?
While I would expect that PSDK to work just as well as the other PSDK, the first thing I do when I cannot solve a problem is remove all variables. Install the "normal" PSDK and give it a shot. Make sure to update the paths in your makefile.
 
1. I've compiled the DLL many times on my old system using codeblocks, but back then it was with the PSDK.
2. I haven't compiled any debug DLLs successfully.
3. Can't get the DLL to compile on the new system, either of the two. Note I have not tried codeblocks yet - only visual c++ studio 2008 express. I also tried the commandline method from the previous page, getting the same sort of errors again as NotSoGood.
4. No. I'm trying to build the unmodified DLL. I assume by unmodified you mean BtS 3.19.

Part of the reason I used the Server 2003 sdk is that I found an offline way to install it. Is there anywhere I can get an offline installer (or instructions) for the PSDK? It tried to download about 94MB or so which is not easy on the internet connection I have at the moment. I am assuming whatever it downloads from doesn't support download resuming.
 
Top Bottom