specifying the entry point when linking .lib files

[allynm]

Hi folks,

Here is yet another novice question.  Sorry.

I am trying to link a simple obj file for the calling program with a lib file (happens to contain an invoke of MessageBox).  I haven't had much experience in these matters.  The system is telling me that I have to specify an entry point. 

The code in my makefile that generates the error message is:

c:\masm32\bin\link.exe mbox.lib testlib.obj

The problem may actually be from an incorrect lib.exe call.  I say this because when I try to create mbox.lib with the lib.exe call, the system doesn't come back with a prompt.  It does however create a file called mbox.lib.

Thanks as always,

Mark Allyn

[Ossa]

In your main asm file that generates the OBJ make sure that you have your entry point quoted on the same line after the end statement:

Code Select Expand


.386

...

.code
your_entry_point_label:

...


end your_entry_point_label


It would be helpful if you posted the code - it is very difficult to know if I have correctly identified the problem without being able to test it.

Ossa

[Ossa]

The problem may actually be from an incorrect lib.exe call.  I say this because when I try to create mbox.lib with the lib.exe call, the system doesn't come back with a prompt.  It does however create a file called mbox.lib.

This is a known issue, you can use link -lib blah.obj blah2.obj instead of lib blah.obj blah2.obj and it will not hang. See this thread. Regardless of which you do, though, the .lib file will be generated correctly.

Ossa

[allynm]

Hi Ossa,

I checked on the "end" statement in my calling program.  It properly conforms to what you suggest.  I also tried using the link.exe with the -lib switch and it behaves just like you said it would:  doesn't hang, and creates the .lib file.  Thanks much--I probably never would have found this on my own.

However, I am still getting the message that there is an unresolved external symbol _mainCRTStartup when I try to link with the calling program obj file. 

Regards,
Mark Allyn

[Ossa]

Mark,

without seeing the code, I'm not sure that I can suggest anything else. The _mainCRTStartup symbol is the default for the linker - basically, if no OBJ file indicates that it has an entry point then it looks for that symbol, however any OBJ file with one will override that - there are also ways to override this with the linker command line by using the link /entry:myentrypointlabel switch but this should not be necessary. Could you please post the source code?

Ossa

[hutch--]

Mark,

That error message usually means you don't have your startup code done correctly, just show us the start setup code and the end code, we can probably help you from there.

It sould look something like this,

Code Select Expand


      .486                      ; create 32 bit code
      .model flat, stdcall      ; 32 bit memory model
      option casemap :none      ; case sensitive


It is usually conveniant to put your include files, prototypes and anything else you need as constants here before any of the sections.

Next you have things like the initialised data section

Code Select Expand


.data
  myitem dd 1234


If you need UNinitialised data,

Code Select Expand


.data?
  myvar dd ?


Then you start your CODE section.

Code Select Expand


.code
  your_start_label:

  ; all of your code here

  end your_start_label


The start label and the END startlabel must be the same name.

[allynm]

Hi Ossa & Hutch-

I couldn't get on to the Forum yesterday because it was down or otherwise occupied, so wasn't able to help out by submitting the code.  I should have done that from the git-go because you would have seen immediately what I was doing wrong. 

I did finally track the problem down-- actually, there were two.  First, I had mistakenly put an "end" statement at the end of the "inc" file where I had put the prototype for the library proc.  That was a killer.  I had also thrown the keyword "far" into the prototype.

Ossa was right about using the -lib switch in the link.exe rather than lib.exe Without the forum I would never have found that out.

Thanks much,

Mark Allyn

[hutch--]

Mark,

Pleased you got a good result, one note, win32 FLAT memory model always uses NEAR by default. It is possible to write an OS using FAR addressing but as far as I know no-one has done that although some earlier versions of Microsoft Advanced Server 2000 could address more than 4 gig but I think it was done by some form of memory remapping.

Bottom line is NEVER use FAR in win32.

[allynm]

Hi Hutch:

I have been really confused by the NEAR / FAR distance distinction.  Probably because I never programmed in real mode.  Thanks for the advice on this point.

Regards
Mark

[GregL]

Mark,

You can leave out the NEAR too since it is the default.

[allynm]

Greg-

Thanks for the reminder.  I noticed this when I was going thru the Prgmmrs Guide yesterday.  Like a lot of things, it is pretty buried in the fine print, but it is there.

Mark