• Laurentiu Pancescu <plaur crosswinds.net> Sep 15 2001
• "Walter" <walter digitalmars.com> Sep 15 2001
• Laurentiu Pancescu <plaur crosswinds.net> Sep 16 2001
• "Walter" <walter digitalmars.com> Sep 16 2001

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




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


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.