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?
View all questions in Keil forum