Pelles C forum
C language => Beginner questions => Topic started by: mathguy on September 21, 2011, 06:40:10 PM
-
Okay, let me preface this by saying that I am no expert and may be asking a stupid question. For that, I'm sorry but I would really appreciate any help you can provide.
I am accustomed to and have been using Borland 4.5 IDE. I am considering a move to Pelles and am so far quite pleased with it. I am having problems making the transition with the following. I have two projects. One produces a DLL using the __stdcall convention. The other calls and tests the DLL. I have both projects set up in Pelles and have the DLL project compiling properly and, by all appearances, producing a valid DLL. In the other project, testdll.exe, I am getting the following build errors:
Unresolved external symbol '_DLLNAME@16'.
POLINK: error: Unresolved external symbol '_WinMain@16'.
I have searched the forum and have found some things but none of the things I've tried have resolved the issue. I am sure it is something quite simple but I cannot seem to figure it out. In the Borland compiler, I used a def file to import the external. That does not seem to work here. I know in VS you set the imports in the options dialogs. I don't see where I would do that in Pelles.
-
Post your code... lets see what's going on...
Also if you are using WinMain you should go into your project settings and turn on "Enable Microsoft Extensions"
I gather your testdll program is being compiled in GUI mode....
-
Okay. Here it is. Some of the names have been changed to protect the innocent. I have the Windows Extensions enabled. Thank you for your time!
// TestEngine.cpp : Defines the entry point for the console application.
//
#include <windows.h>
#include <stdio.h>
#include <process.h>
#include "data.h"
int far __stdcall DLL(struct buffer far *mcb,
struct buffer2 far *mcd,
struct buffer2 far *mce,
struct buffer2 far *mcf);
void load_buffer(struct buffer far *mcb)
{
data population routine
}
void test_component()
{
struct buffer mcb;
struct buffer2 mcd;
struct buffer2 mce;
struct buffer2 mcf;
load_buffer(&mcb);
DLL(&mcb, &mcd, &mce, &mcf);
}
int main()
{
printf("\ntesting started\n\n");
test_component();
printf("\ntesting complete\n\n");
return 0;
}
-
POLINK: error: Unresolved external symbol '_WinMain@16'
Change from menu Project -> Project options -> Linker tab -> Subsystem to Console.
Unresolved external symbol '_DLLNAME@16'.
Include your dll's import library to Library and object files.
-
timo,
Thank you! It compiles without complaint. Now I would like to debug it and I'm getting "The program can't start because pocrt.dll is missing from your computer. Try reinstalling the program to fix this problem." What would be the fix for this issue?
Thanks again!!!
-
Can you compile those with static libraries ?
EDIT:
Compiler option Single threaded (LIB) or Multithreaded (LIB)
for both projects.
-
Okay here's where you find out how little I know. I'm sorry but can you help me understand what you mean by your question?
-
timo,
Okay. I wasn't sure if that was what you meant. I did get it to compile and run. However, I don't think that it is making it into the DLL (where a significant amount of processing goes on). The debugger seems to be not as robust as I would like. Is there a way to step through code and into the library, etc.? If so, I'm not finding it. I like the IDE but a robust debugger is a must for what I'm working on.
Thanks for your help so far. I really appreciate it.
-
Is there a way to step through code and into the library, etc.?
Create Project Workspace and build both projects with debug info.
Insert breakpoints into the dll project where to stop.
"The program can't start because pocrt.dll is missing from your computer. Try reinstalling the program to fix this problem."
You can copy pocrt.dll into project folder if it isn't in the search path.
-
@mathguy... just one tiny hint here... don't use the .cpp file extension... use .c instead.
POIDE may have trouble classifying the .cpp ones.
-
timo and Tater,
Thank you both for your help. I've got it working the way I want to now. I still have some things to figure out and get used to but I think that it might just be what I'm looking for. And, you two helped prevent me from pounding my head against the wall. I truly appreciate your help and knowledge. Thank you!!!
-
My pleasure!
-
"The program can't start because pocrt.dll is missing from your computer. Try reinstalling the program to fix this problem."
You can copy pocrt.dll into project folder if it isn't in the search path.
Where can I get pocrt.dll? I don't see that on my install. I have pocrt64.dll but not pocrt.dll.
-
From 32-bit v.6.50 install.
-
Both should be in your PellesC\Bin folder...
As a rule it's better to build lib based programs...
Project -> Options -> Compiler -> Runttime Library...
Either "Single-threaded (LIB)" or "Multi-threaded (LIB)" depending if you are using mutliple threads or not...
The advantage is that you don't have to distribute pocrt*.dll with your programs.
They free stand and run without external support.
-
As a rule it's better to build lib based programs...
Project -> Options -> Compiler -> Runttime Library...
Either "Single-threaded (LIB)" or "Multi-threaded (LIB)" depending if you are using mutliple threads or not...
The advantage is that you don't have to distribute pocrt*.dll with your programs.
They free stand and run without external support.
Well, the advantage of a DLL in return is that you can change the logic and coding within and update the DLL on all distributed systems without having to replace\update the whole program. As long as exported symbols and parameters of course stay the same...
Ralf
-
(Grin) and in turn... it's just as easy to replace the program as the DLL... And then if changes to the DLL require changes to the program... you end up replacing both.
(Your turn)
-
(Grin) and in turn... it's just as easy to replace the program as the DLL... And then if changes to the DLL require changes to the program... you end up replacing both.
(Your turn)
Well, the former is not necessarily true. I have one application (not written in (Pelle's) C though, but that doesn't matter) where I can include a database related DLL depending on the database engine to be used.
For example, for a single user, I include one which internal works with a Sqlite database. If that user upgrades to a multi-user MySQL MariaDB setup, I just need to replace that specific DLL and it turns the application into a multi-user one. Or if someone moves from a dedicated MySQL database to a shared MS SQL Server or Oracle setup, it's again just a switch of the DLL and done.
Changes necessary to the interface of the DLL which would require a change in the program itself can easily be avoided by planning a bit ahead. Programming doesn't mean just hacking along at the source code... 8)
Ralf
-
LOL... I don't necessarily disagree with you... and you're preaching to the choir about programming being more than just typing source...
But it still remains that one could just as easily replace a 1 piece program as that DLL file...
Having written several addins and libraries for Pelles C... yes I do see the value in replaceable libraries... but on the question of which is easier to replace, I think it's a tie.
-
LOL... I don't necessarily disagree with you... and you're preaching to the choir about programming being more than just typing source...
I was very tempted the other day to post a reply to that dude that complained that Pelle's C is compiling so slow... ;-)
But it still remains that one could just as easily replace a 1 piece program as that DLL file...
Having written several addins and libraries for Pelles C... yes I do see the value in replaceable libraries... but on the question of which is easier to replace, I think it's a tie.
That certainly depends on the size/complexity of your projects... ;-)
And DLLs are easily usable across projects as well.
Ralf
-
Yep, it sure does hinge on both size and complexity.
I was talking strictly about the mechanics of replacing a file... it's as easy to drag and drop an executable as a DLL... Last time I looked they both weigh about the same.
Believe me... I get the whole DLL thing just fine and have used them in several of my projects.
Going back to my point to the OP... rather than distributing POCRT with my projects I prefer to link statically... Your point about it being replaceable is totally valid... but whenever possible I like keeping things nice and simple... One file, job done...
-
Okay...I think only one more question and I hope to have this wrapped up. In most IDEs, there is an option for Data Structure Alignment (/Zp#). I do not find that in Pelles C. Is it not there? Or, am I just missing it? If it isn't there, can I just modify the command line in the Compiler options window and add the /Zp# to it?
Thanks again, guys!
-
Look in your help files for the Command Line Tools -> POCC -> Command Line Options... if it ain't there, you can't use it.
Also look at the list of compiler pragmas... While it is mostly recommended that you leave the default alignment (4 on x86 or 8 for amd64) alone, on those rare occasions where raw data has to be transmitted from one machine to another you can use the #pragma pack(??) preprocessor to affect only what's needed.
#pragma pack (1)
typedef struct t_sendme
{ char name[100];
int values[43]; }
sendme, *psendme;
#pragma pack ()
I should warn you that I ran full blown bug on windshield into this issue some time back and you will find a couple of threads here where I struggled royally as the others did their best to help me out... Basically what I took from that rather sobering experience is that you just don't mess with stuff you don't need to mess with.
-
Well, it doesn't look like it's there. That sucks. And, I don't think that it is actually using 4-byte for x86. I am trying to call this DLL from a Visual Basic program. For that reason, the data structure that we use needs to be on a 4-byte alignment. When I use the pragma pack statement, we can call the DLL but get some gibberish midway through the data structure. This usually means that the alignment is not quite as expected. If we don't use the pragma statement, we get a stuck DLL (i.e. infinite loop) which means a dramatic alignment issue. My guess is that the pragma is working but maybe something else in this build isn't what it seems. I will dig. The frustrating thing is that a Borland 4.5 build of this same code works fine. Oh well, back to head scratching and sleuthing! Thanks, as always!
-
Most likely it's the padding that's causing you the problem... When you align on 4 byte boundaries the compiler has to insert extra bytes to make the struct a multiple of 4 bytes in size... Now WHERE it inserts those 4 bytes is something we won't necessarily know... we can make some educated guesses such as padding a string to align an int behind it, but we won't always know exactly where the extra bytes are inserted.
So along comes Visual Basic (another language that should never have reached the market) it expects padding at location x but Pelles C has used location y ... now the starting points for each variable in the rest of the struct are wrong, hense, garbage results.
Are you compiling your DLL as 32 bits or 64 bits... Windows has rules about this... a 32 bit program *cannot* load a 64bit DLL... a 64bit program *cannot* load a 32bit DLL ... this because of the differences in pointers addresses and, yes, alignment.
http://msdn.microsoft.com/en-us/library/aa384198(v=vs.85).aspx
-
Is it possible to test those structures between compilers with some code like this ?
#include <stddef.h>
#include <stdio.h>
struct foo {
char a;
short b;
long c;
int d;
};
int main(void)
{
int a, b, c, d;
a = offsetof(struct foo, a);
b = offsetof(struct foo, b);
c = offsetof(struct foo, c);
d = offsetof(struct foo, d);
printf("%d\n%d %d %d %d\n", sizeof(struct foo), a, b, c, d);
return 0;
}
-
Okay. I've actually got it all working! The pragma statement works and that's probably what I'm going with. However, I also think I can add the command line argument in the options. I'm looking at that now.
One thing that I forgot about Borland that was nice was that their resource compiler had a version number capability. Does the Pelles IDE offer this? I want to be able to tag the DLL with a version number that can be accessed by the Properties.
Guys, again, thank you so much for your help. I really appreciate it!
Tater,
Right? VB is a mess. Unfortunately, we were stuck with it at an early time by a less-than-skilled "programmer". We need to work toward a phase-out of it.
-
I figured out the Resource script to do versioning so my question has been answered. Sorry to gobble up board space on it.
-
This is just in case you did it the hard way...
You do know that Pelles C has a full suite of built in resource editors? Rather than using manual scripts...
Click... File -> New -> Resources ... this will produce a new page in the editor with "untitled" at the top left...
Right click -> New -> Version ... this will open the version editor. (Note there are several other useful editors there as well)
When done save the resource page, give it a name and click Yes when it asks if you want to add it.
-
PellesC IDE have add-in Buildver.dll (Increment build-number) for updating build-number.
-
Okay. Now I've really done it. I had it all working just fine. Now, all of the sudden when I'm debugging, the debugger just hangs at the DLL call. In the debug window it says that it's loading the DLL but nothing happens after that. If I put a breakpoint at the entrypoint of the DLL, of course, it never gets there. Yet the DLL produced by the build works just fine in production. I don't know what I did or why it is hanging. I swear that all is as it was before. Any ideas? I've been bangin' my head against the wall for a while now.
-
Still sleuthing this one. If I just run the debugger without trying to stop at or in the DLL, it runs and works. It's if I try to step over or into the DLL that the debugger freezes.
-
Can you select Debug -> Break and then F5 Continue ?
-
No, Break is greyed out!?
-
Is there debugging code in the DLL?
-
Yes, I believe so. When I build it, I have the debug set to Full. I see it writing the debug info too. Is it possible that it's not there? What should I check to see if it is? Also, would that make the debugger hang?
-
Yes, I believe so. When I build it, I have the debug set to Full. I see it writing the debug info too. Is it possible that it's not there? What should I check to see if it is? Also, would that make the debugger hang?
Don't forget that you have to turn on debugging info in both the compiler and the linker before the POIDE tool can give you source code level debugging.
If you look in the ADDINS forum you will find a tool rel-dbg-prf that switches the modes for you. It creates 3 little buttons on your project's toolbar ... just select the DLL project and click the dbg button... makes it real easy.
-
CT,
Yep, I have them all set and still it hangs at the DLL call in the test program if I step and it won't stop at any of the breakpoints within the DLL if I do a Run with a breakpoint after the call. It will stop at that breakpoint and I can tell the DLL ran fine. Stumped.
Thank you for the add-in tip. I will look at that.
-
You might try debugging the DLL project using your executable as a "helper" app...
Load the DLL project and make it the active one...
Project -> Project Options -> Executable Helper ... put in your program's name.
Then recompile with debugging turned on and Run...
-
CT,
Thank you. It executed but did not catch any of the breakpoints, etc. It sure is acting like there's no debug information but during the build I even get "Writing Debug Info" in the build window. Something is very puzzling here. I will keep digging.
Thank you for all of your help and attention on this. It is greatly appreciated!
-
CT,
Thank you. It executed but did not catch any of the breakpoints, etc. It sure is acting like there's no debug information but during the build I even get "Writing Debug Info" in the build window. Something is very puzzling here. I will keep digging.
Thank you for all of your help and attention on this. It is greatly appreciated!
DLL project...
Project -> Project options -> Compiler -> Debug Information -> Full
For 32 bit project...
Project -> Project options -> Linker -> Debug information -> CodeView & Coff
for 64 bit project
Project -> Project options -> Linker -> Debug information -> CodeView
Now run the DLL with it's executable helper...
If it's not stopping at the breakpoints... perhaps it's not actually reaching the breakpoints...