I'm using bakefile to generate smake compliant makefiles for my project. The bakefile uses optlink as the linker. Before migrating to bakefile I used my own makefiles where I used dmc as the linker (of course I realize dmc is still invoking the linker for me, but with some differences which I'll get to).

What's interesting is that by using dmc as the linker, dmc generates DEF files for me for all of my DLLs which saves me quite a bit of work. When I run dmc for compiling a DLL and a seperate invocation of optlink, I don't get the DEF file. For this reason, my DLLs don't work (I get no output or crashes when linking an executable with the DLL).

How can I force DMC to generate a DEF file for me? I know it has this capability because I don't write DEF files but I do get them after compilation. Hmmm...now that I think of it, it may be optlink that generates the DEF. I'm pretty certain that I invoke dmc the same way so it can't be DMC generating the DEF files. In any case, I'm not writing them myself.

As it stands, I can't get my DLLs to work if I invoke the linker itself.

-Michael

Why not just create a .def file and include it as a source file in your build?

In article <deg7un$2m0e$2@digitaldaemon.com>, Walter says...
>
>Why not just create a .def file and include it as a source file in your build?
>

Unfortunately because bakefile has no provisions for providing a DEF file in it's linker command.

Bakefile has chosen to invoke optlink instead of dmc as it's linker, and by doing so I can't really use it to create working DLLs.

-Michael

Michael <Michael_member@pathlink.com> wrote in news:deggb5$22n$1@digitaldaemon.com:

> For this reason, my DLLs don't work (I get no output or crashes when linking an executable with the DLL).

I'm expect that optlink called directly can do all the same as dmc on top of it. So perhaps that there is just missing flag passed to optlink or additional step/command before/after optlink invocation. Or perhaps there is an error somewhere not catched. Definietly I need to know more about "don't work".

> Bakefile has chosen to invoke optlink instead of dmc as it's linker, and by doing so I can't really use it to create working DLLs.

I could optionally change that for future bakefiles as long as you could provide me replacement.

if you look into bakefile/rules/makefile_defs_dmars_common.bkl which defines dmars and dmars_smake formats it contains:

    <set var="__LINKER">link /NOLOGO /SILENT /NOI /DELEXECUTABLE</set>
    <set var="__LINKER_CC">$(__LINKER) /EXETYPE:NT</set>
    <set var="__LINKER_CXX">$(__LINKER) /EXETYPE:NT</set>
    <set var="__DLL_LINKER_CC">$(__LINKER)</set>
    <set var="__DLL_LINKER_CXX">$(__LINKER)</set>

and later in that file in <template id="__commands_templ"> there is linker command specified. Please tell me how could dmc-based command look.

Thanks!

ABX

dmc will create a default .def file if one is not specified on the command line. It looks like:

    static char ntdlldef[] =
        "LIBRARY \"%s.dll\"\n"
        "DESCRIPTION '%s as a DLL'\n"
        "EXETYPE NT\n"
        "SUBSYSTEM WINDOWS\n"
        "CODE SHARED EXECUTE\n"
        "DATA WRITE\n";

for windows dll's. %s is the dll name. Hope this helps.

>I could optionally change that for future bakefiles as long as you could provide me replacement.

I've since had to switch from Digital Mars to MingW because the DM linker frequently deadlocks when building on multiprocessor machines. It was just too much of a headache to wake up to find a build stalled the next day. :-( I know it's written in pure assembly, but the deadlock is a real problem. With chips going mulitcore, this will begin to become more and more a problem for DMC.

But I will suggest that bakefile use dmc as the linker. Walter gave us the code snippet of how dmc constructs the default DEF file. This really is necessary for building DLLs. I could not get a working DLL built with the standalone linker. I have the equivalent link command (to the default bakefile rule) written down somewhere. Ah...found it.

Here is the link command that dmc generates (or so the console says):

link Foo+Bar+Hello,MyDll.dll,,SomeLib+ws2_32+advapi32+kernel32,MyDll/noi/implib

Notice that /NOI and /IMPLIB are automatically generated by dmc and the format is a little different than from what bakefile produces. I'd get rid of the all uppercase option names too. I think they are harder on the eyes. There is no map file specified (unlike bakefile where you do name the map file in the linker rule). Note that this link command produces a default .DEF file (but only when invoked by dmc). I hope that helps.

-Michael

"Michael" <Michael_member@pathlink.com> wrote in message news:df5m3p$30l9$1@digitaldaemon.com...
> I've since had to switch from Digital Mars to MingW because the DM linker frequently deadlocks when building on multiprocessor machines. It was just
too
> much of a headache to wake up to find a build stalled the next day. :-( I
know
> it's written in pure assembly, but the deadlock is a real problem. With
chips
> going mulitcore, this will begin to become more and more a problem for
DMC.

Here's a workaround posted previously:
-------------------------------------------------------
I expect a workaround would be the same solution we used at work by setting the processor affinity.

There is a utility that will set it. It's not the one we used but it should do the job.

http://www.beyondlogic.org/solutions/processutil/processutil.htm (Scroll near the bottom for the download)

Basically, you can tell the program to select a particular combination of processors to run on using a bit mask. I've not tried it on hyperthreaded machines only on dual processor machines but I believe they appear the same to the OS so it should work.
-------------------------------------------------------------