I want to use another linker with the dmc compiler, preferably microsoft's link. It automatically converts the omf files generated by dmc but it complains taht snn.lib is corrupt. What's more confusing is that none of alink or ilink32 are able to handle that file.

alink says:

ALINK v1.6 (C) Copyright 1998-9 Anthony A.J. Williams.
All Rights Reserved

Loading file test.obj
Loading file snn.lib
Loading file SNN.lib

Error in file at 000000F4 - unknown object module record type BC
name count = 19
seg count = 8
extcount=5
grpcount=2
comcount=3
fixcount=2
impcount=0
expcount=0
modcount=2
total segment size=0000002C

Was snn generated by dmc? Is it in a standard format? There must be something non-standard about the file if no other linker can handle it.

Thanks.

An update,

The dmc librarian seems to create the lib file in a way that is incompatible with most other linkers. I managed to extract an obj module from snn.lib and microsoft's link has seems able to handle it. Is there an easy way to tell the dmc librarian to extract all object modules from the library or do I have to list them all at the command line.

Thanks!


In article <c1acli$24t$1@digitaldaemon.com>, pgrammer says...
>
>I want to use another linker with the dmc compiler, preferably microsoft's link. It automatically converts the omf files generated by dmc but it complains taht snn.lib is corrupt. What's more confusing is that none of alink or ilink32 are able to handle that file.
>
>alink says:
>
>ALINK v1.6 (C) Copyright 1998-9 Anthony A.J. Williams.
>All Rights Reserved
>
>Loading file test.obj
>Loading file snn.lib
>Loading file SNN.lib
>
>Error in file at 000000F4 - unknown object module record type BC
>name count = 19
>seg count = 8
>extcount=5
>grpcount=2
>comcount=3
>fixcount=2
>impcount=0
>expcount=0
>modcount=2
>total segment size=0000002C
>
>Was snn generated by dmc? Is it in a standard format? There must be something non-standard about the file if no other linker can handle it.
>
>Thanks.
>
>

DigitalMars libs are in OMF, Microsoft libs are in COFF.

See: http://www.digitalmars.com/ctg/implib.html#coff2omf

Arjan

pgrammer wrote:
> An update,
> 
> The dmc librarian seems to create the lib file in a way that is incompatible
> with most other linkers. I managed to extract an obj module from snn.lib and
> microsoft's link has seems able to handle it. Is there an easy way to tell the
> dmc librarian to extract all object modules from the library or do I have to
> list them all at the command line.
> 
> Thanks!
> 
> 
> In article <c1acli$24t$1@digitaldaemon.com>, pgrammer says...
> 
>>I want to use another linker with the dmc compiler, preferably microsoft's link.
>>It automatically converts the omf files generated by dmc but it complains taht
>>snn.lib is corrupt. What's more confusing is that none of alink or ilink32 are
>>able to handle that file.
>>
>>alink says:
>>
>>ALINK v1.6 (C) Copyright 1998-9 Anthony A.J. Williams.
>>All Rights Reserved
>>
>>Loading file test.obj
>>Loading file snn.lib
>>Loading file SNN.lib
>>
>>Error in file at 000000F4 - unknown object module record type BC
>>name count = 19
>>seg count = 8
>>extcount=5
>>grpcount=2
>>comcount=3
>>fixcount=2
>>impcount=0
>>expcount=0
>>modcount=2
>>total segment size=0000002C
>>
>>Was snn generated by dmc? Is it in a standard format? There must be something
>>non-standard about the file if no other linker can handle it.
>>
>>Thanks.
>>
>>
> 
> 
> 

I know. If anything, I'd need omf2coff. However, I don't becuase the MS linker *converts* omf object files to coff format *automatically*. Unfortunately, it chokes on the very necessary snn.lib.

Anyway, don't worry about it. I think I have the workaround. As I said, the MS linker has no problem with the omf object files after I extract them from snn.lib using the dmc librarian.

Problem solved! :)

In article <c1aen2$5j2$1@digitaldaemon.com>, Arjan Knepper says...
>
>DigitalMars libs are in OMF, Microsoft libs are in COFF.
>
>See: http://www.digitalmars.com/ctg/implib.html#coff2omf
>
>Arjan
>
>pgrammer wrote:
>> An update,
>> 
>> The dmc librarian seems to create the lib file in a way that is incompatible with most other linkers. I managed to extract an obj module from snn.lib and microsoft's link has seems able to handle it. Is there an easy way to tell the dmc librarian to extract all object modules from the library or do I have to list them all at the command line.
>> 
>> Thanks!
>> 
>> 
>> In article <c1acli$24t$1@digitaldaemon.com>, pgrammer says...
>> 
>>>I want to use another linker with the dmc compiler, preferably microsoft's link. It automatically converts the omf files generated by dmc but it complains taht snn.lib is corrupt. What's more confusing is that none of alink or ilink32 are able to handle that file.
>>>
>>>alink says:
>>>
>>>ALINK v1.6 (C) Copyright 1998-9 Anthony A.J. Williams.
>>>All Rights Reserved
>>>
>>>Loading file test.obj
>>>Loading file snn.lib
>>>Loading file SNN.lib
>>>
>>>Error in file at 000000F4 - unknown object module record type BC
>>>name count = 19
>>>seg count = 8
>>>extcount=5
>>>grpcount=2
>>>comcount=3
>>>fixcount=2
>>>impcount=0
>>>expcount=0
>>>modcount=2
>>>total segment size=0000002C
>>>
>>>Was snn generated by dmc? Is it in a standard format? There must be something non-standard about the file if no other linker can handle it.
>>>
>>>Thanks.
>>>
>>>
>> 
>> 
>> 

I have only one problem now: unresolved external symbols __edata and __end from clearbss.obj. That is not dmc's problem. I get the error from another linker. I just need to know which object file defines those symbols so I can know which other file to feed to the linker. Nothing in snn.lib exports __edata or __end.

Anyone knows? Walter?

Thanks.

In article <c1ag4r$7tl$1@digitaldaemon.com>, pgrammer says...
>
>I know. If anything, I'd need omf2coff. However, I don't becuase the MS linker *converts* omf object files to coff format *automatically*. Unfortunately, it chokes on the very necessary snn.lib.
>
>Anyway, don't worry about it. I think I have the workaround. As I said, the MS linker has no problem with the omf object files after I extract them from snn.lib using the dmc librarian.
>
>Problem solved! :)
>
>In article <c1aen2$5j2$1@digitaldaemon.com>, Arjan Knepper says...
>>
>>DigitalMars libs are in OMF, Microsoft libs are in COFF.
>>
>>See: http://www.digitalmars.com/ctg/implib.html#coff2omf
>>
>>Arjan
>>
>>pgrammer wrote:
>>> An update,
>>> 
>>> The dmc librarian seems to create the lib file in a way that is incompatible with most other linkers. I managed to extract an obj module from snn.lib and microsoft's link has seems able to handle it. Is there an easy way to tell the dmc librarian to extract all object modules from the library or do I have to list them all at the command line.
>>> 
>>> Thanks!
>>> 
>>> 
>>> In article <c1acli$24t$1@digitaldaemon.com>, pgrammer says...
>>> 
>>>>I want to use another linker with the dmc compiler, preferably microsoft's link. It automatically converts the omf files generated by dmc but it complains taht snn.lib is corrupt. What's more confusing is that none of alink or ilink32 are able to handle that file.
>>>>
>>>>alink says:
>>>>
>>>>ALINK v1.6 (C) Copyright 1998-9 Anthony A.J. Williams.
>>>>All Rights Reserved
>>>>
>>>>Loading file test.obj
>>>>Loading file snn.lib
>>>>Loading file SNN.lib
>>>>
>>>>Error in file at 000000F4 - unknown object module record type BC
>>>>name count = 19
>>>>seg count = 8
>>>>extcount=5
>>>>grpcount=2
>>>>comcount=3
>>>>fixcount=2
>>>>impcount=0
>>>>expcount=0
>>>>modcount=2
>>>>total segment size=0000002C
>>>>
>>>>Was snn generated by dmc? Is it in a standard format? There must be something non-standard about the file if no other linker can handle it.
>>>>
>>>>Thanks.
>>>>
>>>>
>>> 
>>> 
>>> 
>
>

There is no BC at or near offset F4 in snn.lib, so this is a most unhelpful error message from alink. As far as I know, standard .lib files are created by lib.

In article <c1ap20$nh4$1@digitaldaemon.com>, Walter says...
>
>There is no BC at or near offset F4 in snn.lib, so this is a most unhelpful error message from alink. As far as I know, standard .lib files are created by lib.
>
>

Thanks Walter. I've actually worked around that problem by extracting the object files and patching them back together as a COFF lib file. You see, I'm trying to use Microsoft's Link instead of optlink. My only problem now is the unresolved externals __edata and __end being referenced from clearbss.obj in snn.lib. That implies that I'm not linking to a necessary file. If you know which object file defines those symbols I'd be very grateful. How do they get defined in a ordinary optlink build?

Thanks in advance.

"pgrammer" <pgrammer_member@pathlink.com> wrote in message news:c1b3tv$1a5p$1@digitaldaemon.com...
> Thanks Walter. I've actually worked around that problem by extracting the
object
> files and patching them back together as a COFF lib file. You see, I'm
trying to
> use Microsoft's Link instead of optlink. My only problem now is the
unresolved
> externals __edata and __end being referenced from clearbss.obj in snn.lib.
That
> implies that I'm not linking to a necessary file. If you know which object
file
> defines those symbols I'd be very grateful. How do they get defined in a ordinary optlink build?

Those symbols are defined by the linker, and are used to bracket the bss data segment.

In article <c1bcr0$1pvk$1@digitaldaemon.com>, Walter says...
>
>
>"pgrammer" <pgrammer_member@pathlink.com> wrote in message news:c1b3tv$1a5p$1@digitaldaemon.com...
>> Thanks Walter. I've actually worked around that problem by extracting the
>object
>> files and patching them back together as a COFF lib file. You see, I'm
>trying to
>> use Microsoft's Link instead of optlink. My only problem now is the
>unresolved
>> externals __edata and __end being referenced from clearbss.obj in snn.lib.
>That
>> implies that I'm not linking to a necessary file. If you know which object
>file
>> defines those symbols I'd be very grateful. How do they get defined in a ordinary optlink build?
>
>Those symbols are defined by the linker, and are used to bracket the bss data segment.
>
>

Thanks.

I guess I'm stuck for the moment then if I'm not using optlink. Christoph Meerwald had some success replacing optlink with the openwatcom linker so I'll have to experiment a bit more to get Microsoft link to work.

"pgrammer" <pgrammer_member@pathlink.com> wrote in message news:c1bkts$26np$1@digitaldaemon.com...
> In article <c1bcr0$1pvk$1@digitaldaemon.com>, Walter says...
> >"pgrammer" <pgrammer_member@pathlink.com> wrote in message news:c1b3tv$1a5p$1@digitaldaemon.com...
> >> Thanks Walter. I've actually worked around that problem by extracting
the
> >object
> >> files and patching them back together as a COFF lib file. You see, I'm
> >trying to
> >> use Microsoft's Link instead of optlink. My only problem now is the
> >unresolved
> >> externals __edata and __end being referenced from clearbss.obj in
snn.lib.
> >That
> >> implies that I'm not linking to a necessary file. If you know which
object
> >file
> >> defines those symbols I'd be very grateful. How do they get defined in
a
> >> ordinary optlink build?
> >
> >Those symbols are defined by the linker, and are used to bracket the bss data segment.
> I guess I'm stuck for the moment then if I'm not using optlink.

Not really. Check out how VC clears the BSS, and modify the clearbss code accordingly.

> Christoph
> Meerwald had some success replacing optlink with the openwatcom linker so
I'll
> have to experiment a bit more to get Microsoft link to work.
>
>