make confusion, help needed

[Stefan Schumann]

Hi there!
I have big trouble in understanding the make file.
I tried to write a simple DOS program using BGI.
With BGIOBJ.exe I created egevga.obj and put it to the project folder.
Now I would like to use the commanline-tools to make an exe file but
here is my problem.
The program is quite simple, it prints a sentence and draws a rectangle:
Note that it works, when I compile the project inside the IDE.

#include <stdio.h>
#include <graphics.h>

void main (void)
{
int gdriver = DETECT, gmode;
printf("Hello, here I am");
printf("%d",registerbgidriver(EGAVGA_driver));
initgraph(&gdriver, &gmode, "" );
rectangle(4, 6, 20, 50 );
}

Here is my makefile:
test3.exe : test3.obj
tlink -LE:\BC5\LIB -c -Tde -x test3.obj

test3.obj : test3.c
bcc -c -P- -IE:\BC5\INCLUDE test3.c

I tried to compile and link the Program with "make -ftest3.mak", but
then I get the following errors:

Error: Undefined symbol _rectangle in module test3.c
Error: Undefined symbol _initgraph in module test3.c
Error: Undefined symbol _printf in module test3.c
Error: Undefined symbol _registerbgidriver in module test3.c
Error: Undefined symbol _EGAVGA_driver in module test3.c
Fatal: No program entry point
** error 2 ** deleting test3.exe

Why are the symbols not included, allthough I name the correct include
and library paths, why is there no program entry point although there is
a main function?
Sure, I can create a makefile inside the IDE (which works but I tried to
understand it, without any success) but I need to work in DOS mode in
future so I would like to understand the main reasons for my problems.

Thanks in advance.

Stefan

[Ed Mulroy [TeamB]]

The compile and link command lines have problems.

The compile command line has redundant options and a serious
problem of no memory model specified.

- The compiler defaults to small model but with the BGI linked in
small model is at best only barely able to fit that. Use large
model, /ml or -ml on the command line for bcc.exe
- The -I option duplicates what the compiler already supplies.
- The -P- option tells the compiler to compile test3.c as a C
file, which it already was told to do by the ".c" at the end of
the file name.

The link command line has no startup code, no runtime libraries
and no output file name. It also does not mention the egavga.obj
that you seem to want to link in. What it does have is a redundant
-L option specifying a library path that duplicates that which it is
already configured to use.

The startup code for a DOS program is named c0?.obj (zero, not 'o')
where the '?' is the first letter of the memory model. Neither BGI
nor
floating point can work with tiny model so for this one of S, M, C, L
or H would be used. I suggest L for large model (avoid huge model
unless you have very special needs).

The runtime library for a DOS program is named c?.lib with the same
naming convention for the '?'.

A make file might look something like this:

--------------------------------------
.autodepend

test3.exe : test3.obj
tlink -c -Tde -x -v c0l test3 egavga,test3,,graphics cl

test3.obj : test3.c
bcc -c -v -ml test3.c
--------------------------------------

The linker command line has several fields separated by commas.
Because news readers wrap lines I'll show each on a separate line.
This is the syntax for calling the linker:

tlink {options} object files ,
output file name ,
map file name ,
libraries ,
module definition file name ,
resource file name

The command line is stopped at the end of the last field used so for
your DOS build you would just not put a comma after the libraries
since neither of a module definition file nor a resource file are used
for DOS programs.

It assumes object files will have .obj for an extension, that the
output file will have an .exe or .dll extension depending upon the
linker options, that the map file will have an extension of .map, that
the library files will have an extension of .lib, the module
definition files of .def and the resource files of .res

As an alternative for DOS programs you could use the compiler to call
the linker, relying on the compiler's knowledge of the need for
startup code and runtime libraries and its recognition of the .obj and
.lib file name extensions like this:
bcc -ml -v test3.obj egavga.obj graphics.lib

For Windows programming that ability is limited by its lack of
recognition of resource file names.

. Ed

> Stefan Schumann wrote in message
> news:4056fad3$1...@newsgroups.borland.com...

[Stefan Schumann]

Thank you, Ed,

it works, and now I understand a few more things.

Stefan

[ric...@gmail.com]

On Tuesday, March 16, 2004 6:10:00 AM UTC-7, Stefan Schumann wrote:
> Hi there!
> I have big trouble in understanding the make file.

o
o
o

> Fatal: No program entry point

I just had a similar issue and found this old thread was the best source on the topic. It does not look like Borland supplies a lot of information about how to build programs separately using bcc32 -c followed by tlink32. I ended up hacking to get the information.

What I did was to build a simple hello world program. I compiled to an object file, then used bcc32 to build the executable. I noticed that the compiler calls the linker to complete the process.

Here is the hack: I renamed the linker to tlink32.tmp, then substituted my own programs to report back the arguments bcc32 was passing to the linker. I had to go one further step as the argument passed was a response file that gets deleted immediately.

I compiled hello.c using:
bcc32 -c -ohellow.obj

Renamed TLINK32 and found that:
bcc32 hellow.obj

would then execute:
C:\BC45\BIN\tlink32.exe @turboc.$ln

Then I rewrote my dumping program to type out turboc.$ln and found it contained:
N:\BC45\LIB\c0x32.obj+
+
hellow.obj
hellow.exe
/c/x/ap/Tpe
N:\BC45\LIB\import32.lib+
N:\BC45\LIB\cw32.lib

Here is the code I used to make the dummy executable I substituted for TLINK32:

{CODE}
// RRC: Brain-dead program to dump the arguments to tlink32.
// Borland does an exceptional job of hiding what they do when you execute bcc32 and let them supply the libraries.
// Basically they put the commands in a file named turboc.$ln, then execute tlink32 @turboc.$ln.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[])
{
int ii;
char sDumpCommand[256];

for (ii=0; ii<argc; ii++)
{
printf("argv[%d] = '%s'\n", ii, argv[ii]);
}
printf("Dumping contents of argv[1] = '%s'\n", argv[1]);
strcpy(sDumpCommand, "type ");
strcat(sDumpCommand, argv[1]+1);
system(sDumpCommand);

return 0;
}
{CODE}