If I use a static library with main() inside the library,
OPTLINK complains about "no start address", and also "no stack", in
case of console programs.  I used LIBUNRES, and the main module
is in the lib, and even extern __acrtused_con.  This also
happens with WinMain() instead of a library (I had this problem
with V GUI toolkit). For example:

// main.cpp
#include <iostream.h>
extern const char *about();

int main()
{
  cout << about() << endl; // BTW, I see a pointer here,
instead of the text!
  return 0;
}

// about.cpp
const char *about()
{
  return "DM LIB test";
}

Now, compile everything:
sc -c -mn -WA about.cpp
sc -c -mn -WA main.cpp
lib main.lib /c /noi main.obj
sc -omain.exe about.obj main.lib    // this fails
sc -omain.exe about.obj main.obj    // okay

Is there something that can be done about this?  Is it a linker bug?


Laurentiu

The problem is that there's no reference in about.obj to pull in main.obj from the library. The linker only pulls in modules from a .lib file that are referenced.

Pull main.obj out of the .lib file and link it in explicitly.

-Walter

Laurentiu Pancescu wrote in message <9nvbg7$uhr$1@digitaldaemon.com>...
>
>If I use a static library with main() inside the library,
>OPTLINK complains about "no start address", and also "no stack", in
>case of console programs.  I used LIBUNRES, and the main module
>is in the lib, and even extern __acrtused_con.  This also
>happens with WinMain() instead of a library (I had this problem
>with V GUI toolkit). For example:
>
>// main.cpp
>#include <iostream.h>
>extern const char *about();
>
>int main()
>{
>  cout << about() << endl; // BTW, I see a pointer here,
>instead of the text!
>  return 0;
>}
>
>// about.cpp
>const char *about()
>{
>  return "DM LIB test";
>}
>
>Now, compile everything:
>sc -c -mn -WA about.cpp
>sc -c -mn -WA main.cpp
>lib main.lib /c /noi main.obj
>sc -omain.exe about.obj main.lib    // this fails
>sc -omain.exe about.obj main.obj    // okay
>
>Is there something that can be done about this?  Is it a linker bug?
>
>
>Laurentiu
>

"Walter" <walter@digitalmars.com> wrote:

>The problem is that there's no reference in about.obj to pull in main.obj from the library. The linker only pulls in modules from a .lib file that are referenced.
>
>Pull main.obj out of the .lib file and link it in explicitly.
>
>-Walter

It works like this, what I was asking is why the acrtused is ignored from a lib.  The linking doesn't fail with "main not defined" (I added a "extern main" in about.cpp, but no change - main is found, but not marked as start point).

Various compilers seem to treat this differently: MinGW must
have the object file containing main() included first in the
library, otherwise it doesn't find main().


Laurentiu

Laurentiu Pancescu wrote in message <9o1scb$29m9$1@digitaldaemon.com>...
>"Walter" <walter@digitalmars.com> wrote:
>>The problem is that there's no reference in about.obj to pull in main.obj from the library. The linker only pulls in modules from a .lib file that
are
>>referenced.
>>Pull main.obj out of the .lib file and link it in explicitly.
>>-Walter
>It works like this, what I was asking is why the acrtused is
>ignored from a lib.  The linking doesn't fail with "main not
>defined" (I added a "extern main" in about.cpp, but no change -
>main is found, but not marked as start point).
>Various compilers seem to treat this differently: MinGW must
>have the object file containing main() included first in the
>library, otherwise it doesn't find main().


_acrtused is not ignored. A reference to _acrtused is placed in a .obj that contains a main() function, and it's purpose is to pull in the startup code. If there is no main() in your program, there is no reference to _acrtused.

An extern main(); is not sufficient to pull in main.obj, because you have to actually refer to it in the code. Run OBJ2ASM on your .obj file and you can see what is actually referenced.