Hi! Maybe someone has done this before and knows the answer; I'd very much appreciate the help.

When running the compiler (more specifically, the linker, "tlink32.exe" for Borland 4.5), I need to be able to specify exactly where the "linker executable", tlink32.exe, resides. Can this be done using the "-L" option, or is it even possible with any option? I am not using a .cfg file to specify anything about the linker, and am strictly using the command-line compiler in a rather complex "make" file.

Any help would be appreciated.

Use the .CFG file. Once set up, it's done.

The problem is, I'm using an automated build process which can't use a .cfg file. It has to work on a broad selection of machines, most of which won't have a .cfg file.

You are creating a build process that uses Borland Version 4.5 and tlink32.exe, etc. on various machines and the machines have not had a proper installation of the compiler suite? That is, they don't have the compiler and linker in their %path% environment? What do they have? And where?

As far as your first post: No, you can't tell bcc where to find the linker executable with a command-line argument.

The -L tells the linker where to find libraries. The executables (bcc and tlink) must be on the %path%. If they are not, then the command line must give the complete path to the corresponding executable.

You could compile separately (using the -c option to bcc), and then call tlink32 explicitly on the object files.

You still have to have one of the two following:

Either

1. The executables are on the path as defined by the %path% environment variable.

or

2. You give the complete path to each executable when invoking bcc and tlink32 on the command line.

All of these could be defined in a Makefile that could be created separately for each machine (of course, then you have to know the path to make.exe for each one and inside the Makefile you have to be able to put the path to the compiler and linker explicitly into the rules).

What is it that you are really trying to do? If the machines have bcc, then why weren't they set up properly to use the compiler, and how do you propose to fix that?

Note that if you have a .cfg file in the current directory (wherever it is from which the compiler/linker is/are invoked), it will work OK, but usually the .cfg file is in the same directory as the compiler and linker executable. In any case, you have to know where the executables are. Period. If there isn't a .cfg file, then the build process can make one and put it where the compiler can use it. I hate to repeat myself, but you (that is: the "build process") must know where the executables are located.



Regards,

Dave

Dave, thanks. I'm working in an environment where BCC is just one of many compilers being used, and its use has no special preference vs. any other, and you simply can't rely on any given machine having its .cfg environment properly set up. So maybe it looks like I'm going to have to use the -c option and do a separate link.

So I guess, based on what you've posted, I'll need to specify the complete path to tlink32; that was my original question anyway, do you know how to do that?

Thanks for all the help!

Then why are you trying to build on each machine? Why not just load the final executable on each machine? If you can't rely on a configuration, you can't rely on a build.

Guys, I have no choice in the matter. Its a formal build process, and the final executable HAS to be created on a machine whose environment I have no control over. Its best to assume there is no .cfg file available. That's just how it is. The finished executable is "embedded" on a 386 processor used on an aircraft avionics system. I don't know who will do the actual "build" of the executable, or what the environment on that machine will be like. Currently I'm creating a makefile which has to specify in minute detail how everything gets built.

OK, so I've figured out how to invoke the linker directly (haha, just compile with the -c option and RUN the linker, who would've guessed!). Thanks for that suggestion!

Now I can't get it to point to the right .obj files, libs, etc. (on to the NEXT problem).

Progress is slow, but at least I seem to be headed in the right direction.

So thanks, every little bit helps.

With a Borland makefile, something like:


This way, if you need to change the installation path, it's done at a single place.

The same kind of thing can be used for other compilers (with GNU make for example).

I gotta ask again: If you have no control over the environment and you don't know how the compiler suite was installed, then how the heck can you know where the Borland executables are located on the target system(s)? As far as that goes, I can't even imagine an embedded 386 system even having a Borland Compiler installed to allow compiling arbitrary programs in-flight. But that's my problem, not yours isn't it?

On the other hand, if a system has a Borland compiler installed, then it should have had everything installed to allow it to compile programs in a standard manner.



Regards,

Dave

Thanks Dave! That's pretty close to what the final result will be, I think. My earlier problem was just not including the -c option to force a separate link. Now I've just got to get all my .obj and libs paths taken care of.

The .c.obj rule probably should have been


And the CFLAGS stuff would be for Optimization levels or whatever other general flags you would use (typically -D for specific defines needed by the source files)

Regards,

Dave