Minor complaint :not pick up SSFcc2A.obj when the pseudo op NAME has the same operand

When the pseudo op NAME has the same operand in two modules, only one of the objexts get to the library.

Well, I don't agree that this would be grounds for even a minor complaint.
This is a picture-perfect example case of the "Don't do that, then!" rule.

The object module name (as set by those NAME
directives) is the only name left to
a module sitting in a .lib, by definition of
the file format, so it's hardly surprising
if the library refuses to hold two modules
with the same name, is it?

The other name the object module had, it's
file name, simply isn't there any more,
because the lib doesn't contain files --- it
contains object modules. This is one of the
key differences between OMF-based .lib
libraries and, say, Unix-style .a archives.

When the pseudo op NAME has the same operand in two modules, only one of the objexts get to the library.

Well, I don't agree that this would be grounds for even a minor complaint.
This is a picture-perfect example case of the "Don't do that, then!" rule.

The object module name (as set by those NAME
directives) is the only name left to
a module sitting in a .lib, by definition of
the file format, so it's hardly surprising
if the library refuses to hold two modules
with the same name, is it?

The other name the object module had, it's
file name, simply isn't there any more,
because the lib doesn't contain files --- it
contains object modules. This is one of the
key differences between OMF-based .lib
libraries and, say, Unix-style .a archives.

Should the library generator not "complain" if it in the same run was presented with two modules with same "name".

I run into this one on a yearly basis becuase I quite often make "similar" modules by making a copy of another and modifying it. Since the selection of which module to include is vbery dynamic using library, this is exactly where such a goof should be caught. I would be satisfied with a library switch (Use filename not "NAME" operand)

Erik

What's ruling out the blazingly obvious option of simply not using NAME directives all over the place?

Should the library generator not "complain" if it in the same run was presented with two modules with same "name".

Which "library generator" would that be? It can't really be BL51 you're referring too, as that is not presented with two same-named in the same run: it's invoked several times, and asked to add an .obj file holding a module under some name, to an existing .lib which already contains a module of the same name.

And according to the docs, this should trigger an error message. But the way your batch file uses the trashbin, you'll never see that message. Your fault.

... can't really be BL51 you're...

Blast, a typo. Make that "can't really be LIB51 you're"

And according to the docs, this should trigger an error message. But the way your batch file uses the trashbin, you'll never see that message. Your fault
good point

Erik

continuation: When I have the time I'll try with all the blasted messages omming out and see what happens.

someone suggested I remove the NAME statement. If I remove the NAME statement will the filename be substituted or what?

Erik

Well, you really should look that up in the manual yourself, Erik, but yes, without NAME, the module name will default to be the base of the source file name (and thus the same as the default .obj file basename).

I would look it up myself except that some unknown person "reduced" my set of manuals so I do not have the assembler manual any more :(

Erik

So what? You should still have the electronic copy of the Assembler/Utilities manual (A51.pdf), right? Or did you manage to lose that one, too? That, and all Keil CDs you ever had?

just an old fashioned guy looking for a book :)

erik

So get A51.pdf to the nearest printer and turn it into a book ;->