if not exist as.lib goto usliex del as.lib :usliex c:\tools\keil\c51\bin\lib51 c as.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a Sacode.obj to as.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a Sccode.obj to as.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a SSF881C.obj to as.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a SSF882C.obj to as.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a SSF882M.obj to as.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a SSFcc1C.obj to as.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a SSFcc2A.obj to as.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a SSF901C.obj to as.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a Scrout.obj to as.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a Sarout.obj to as.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a Sfmtbs.obj to as.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a Sfmtbm.obj to as.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a Sssgchar.obj to as.lib >..\trash\trashbin c:\tools\keil\c51\bin\lib51 a Sssbmap.obj to as.lib >..\trash\trashbin REM if "%MUSTYP%"=="a" goto lnkac REM c:\tools\keil\c51\bin\bl51 SSLstart.obj, SSLisr.obj, SSLiic.obj, Smain.obj, Sxdata.obj, as.lib, c51s.lib TO as.omf RS(256) IX >protl.log REM goto lnkdn REM REM :lnkac REM c:\tools\keil\c51\bin\bl51 Sstart.obj, Sisr.obj, Siic.obj, Smain.obj, SSFcc2A.obj, Sxdata.obj, as.lib, c51s.lib TO as.omf RS(256) IX >protl.log c:\tools\keil\c51\bin\bl51 Sstart.obj, Sisr.obj, Siic.obj, Smain.obj, Sxdata.obj, as.lib, c51s.lib TO as.omf RS(256) IX >protl.log
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 ;->