www.digitalmars.com         C & C++   DMDScript  

c++.command-line - Linker

reply Federico <Federico_member pathlink.com> writes:
Does anyone know how to make a linker different than OPTLINK work with DMC?
Thanks
Federico
Jul 30 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Federico" <Federico_member pathlink.com> wrote in message
news:ai6u1h$13c6$1 digitaldaemon.com...
 Does anyone know how to make a linker different than OPTLINK work with

 Thanks
 Federico

Any linker that works with standard omf files should work.
Jul 30 2002
parent reply Federico <Federico_member pathlink.com> writes:
In article <ai76ug$1i17$2 digitaldaemon.com>, Walter says...
Any linker that works with standard omf files should work.

I tried Borland Tlink 5.0, Blinker 5.1 and Alink 1.6. Each one complains or aborts with an error. Any idea? Federico
Jul 31 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Federico" <Federico_member pathlink.com> wrote in message
news:ai82eo$304b$1 digitaldaemon.com...
 In article <ai76ug$1i17$2 digitaldaemon.com>, Walter says...
Any linker that works with standard omf files should work.


 aborts with an error.

If optlink links the code successfully, I don't understand what the problem is. Optlink is far and away the best linker ever written.
Jul 31 2002
parent reply Federico <Federico_member pathlink.com> writes:
In article <ai84un$2s6$1 digitaldaemon.com>, Walter says...
If optlink links the code successfully, I don't understand what the problem
is. Optlink is far and away the best linker ever written.

I agree, but it fails as soon as the data declared at file scope exceed 40 MB total. As you maybe remember, we had this discussion a few months ago: DMC produces very fast executables, better then any competitor. However, if I use dynamic memory allocation, speed degrades by 30 percent. Still better than other compilers using dynamic allocation, but worse than other compiler on huge static data. I'm trying to find a way out of the problem. BTW. If I declare the big arrays 'static', Blinker does not complain anymore on the .obj, but has problems with SNN.LIB. The same happens with Borland Tlink. Any clue? Federico
Jul 31 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Federico" <Federico_member pathlink.com> wrote in message
news:ai9mrp$22dq$1 digitaldaemon.com...
 I agree, but it fails as soon as the data declared at file scope exceed 40

 total.

Ok, I remember now.
 As you maybe remember, we had this discussion a few months ago: DMC

 very fast executables, better then any competitor. However, if I use

 memory allocation, speed degrades by 30 percent. Still better than other
 compilers using dynamic allocation, but worse than other compiler on huge

 data.
 I'm trying to find a way out of the problem.

 BTW. If I declare the big arrays 'static', Blinker does not complain

 the .obj, but has problems with SNN.LIB. The same happens with Borland

What problems with snn?
Jul 31 2002
parent reply Federico <Federico_member pathlink.com> writes:
In article <ai9qud$27he$1 digitaldaemon.com>, Walter says...
What problems with snn?

Please, find below outputs of Alink, Blinker, Tlink. The latter gives no information, but the problem happens as soon as SNN.LIB is accessed. Moreover, if the big arrays at file scope are not declared static, both alink and blinker complains on the .obj generated from my source code. Maybe I'm stuck in a stupid problem, I apologize but I'm not an expert in linking under Win32. Federico -----------------Alink------------------------------ e:\eee\ramspeed\qq>alink -oPE -subsys con rs.obj USER32.LIB KERNEL32.LIB ALINK v1.6 (C) Copyright 1998-9 Anthony A.J. Williams. All Rights Reserved Loading file rs.obj Loading file USER32.LIB Loading file KERNEL32.LIB Loading file SNN.lib Error in file at 000000EE - unknown object module record type BC name count = 19 seg count = 8 extcount=10 grpcount=2 comcount=4 fixcount=18 impcount=0 expcount=0 e:\eee\ramspeed\qq> --------------------Blinker----------------------------- e:\eee\ramspeed\qq>blinker file rs.obj lib user32.lib lib kernel32.lib BLINKER : 1115 : SNN.LIB(BUILDENV) : '__IMP__MULTIBYTETOWIDECHAR 24' : unresolved external BLINKER : 1115 : SNN.LIB(CLOCK) : '__IMP__GETTICKCOUNT 0' : unresolved external BLINKER : 1115 : SNN.LIB(GETENV) : '__IMP__GETENVIRONMENTVARIABLEA 12' : unresolved external BLINKER : 1115 : SNN.LIB(ISATTY) : '__IMP__GETFILETYPE 4' : unresolved external BLINKER : 1115 : SNN.LIB(LOCTIME) : '__IMP__GETTIMEZONEINFORMATION 4' : unresolved external BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CLOSEHANDLE 4' : unresolved external BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CREATESEMAPHOREA 16' : unresolved external BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__WAITFORSINGLEOBJECT 8' : unresolved external BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__RELEASESEMAPHORE 12' : unresolved external BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETACP 0' : unresolved external BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETOEMCP 0' : unresolved external BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETCPINFO 8' : unresolved external BLINKER : 1115 : SNN.LIB(SETNTERR) : '__IMP__GETLASTERROR 0' : unresolved external BLINKER : 1115 : SNN.LIB(TIME) : '__IMP__GETLOCALTIME 4' : unresolved external BLINKER : 1115 : SNN.LIB(TOLOWER) : '__IMP__LCMAPSTRINGA 24' : unresolved external BLINKER : 1115 : SNN.LIB(XCFILTER) : '__IMP__UNHANDLEDEXCEPTIONFILTER 4' : unresolved external BLINKER : 1115 : SNN.LIB(WCTOMB) : '__IMP__WIDECHARTOMULTIBYTE 32' : unresolved external BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALALLOC 16' : unresolved external BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALFREE 12' : unresolved external BLINKER : 1115 : SNN.LIB(ISCTYPE) : '__IMP__GETSTRINGTYPEA 20' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGW 24' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGA 24' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOW 16' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOA 16' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETSTRINGTYPEW 16' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__LCMAPSTRINGW 24' : unresolved external BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDNEXTFILEA 8' : unresolved external BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDCLOSE 4' : unresolved external BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FILETIMETODOSDATETIME 12' : unresolved external BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDFIRSTFILEA 8' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETSTDHANDLE 4' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__CREATEFILEA 28' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__MOVEFILEA 8' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__DELETEFILEA 4' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETHANDLECOUNT 4' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETFILEPOINTER 16' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETFILEATTRIBUTESA 4' : unresolved external BLINKER : 1115 : SNN.LIB(SETARGV) : '__IMP__GETMODULEFILENAMEA 12' : unresolved external BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__WRITECONSOLEA 20' : unresolved external BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__MESSAGEBOXA 16' : unresolved external BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETMODULEHANDLEA 4' : unresolved external BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETCOMMANDLINEA 0' : unresolved external BLINKER : 0 Warning error(s), 42 Fatal error(s) RS.EXE (not created) (0.1 seconds) e:\eee\ramspeed\qq> -----------------------Tlink------------------------ e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib\ rs.obj,,,user32.lib+kernel32.lib Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland Warning: Unable to perform incremental link - performing full link... Fatal: Unable to open file 'SNN.OBJ' e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib rs.obj,,,snn.lib+user32.lib+kernel32.lib Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland Fatal: Error detected (IMP1807) Fatal: Access violation. Link terminated. Warning: Unable to perform incremental link - performing full link... Fatal: Error detected (IMP1807) Fatal: Access violation. Link terminated. e:\eee\ramspeed\qq>
Aug 01 2002
next sibling parent reply Jan Knepper <jan smartsoft.cc> writes:
What about the DM Linker???

It seems to me like you have to throw an option for blinker to prevent it from
capitalizing the function names, that might fix one problem.

Jan



Federico wrote:

 In article <ai9qud$27he$1 digitaldaemon.com>, Walter says...
What problems with snn?

Please, find below outputs of Alink, Blinker, Tlink. The latter gives no information, but the problem happens as soon as SNN.LIB is accessed. Moreover, if the big arrays at file scope are not declared static, both alink and blinker complains on the .obj generated from my source code. Maybe I'm stuck in a stupid problem, I apologize but I'm not an expert in linking under Win32. Federico -----------------Alink------------------------------ e:\eee\ramspeed\qq>alink -oPE -subsys con rs.obj USER32.LIB KERNEL32.LIB ALINK v1.6 (C) Copyright 1998-9 Anthony A.J. Williams. All Rights Reserved Loading file rs.obj Loading file USER32.LIB Loading file KERNEL32.LIB Loading file SNN.lib Error in file at 000000EE - unknown object module record type BC name count = 19 seg count = 8 extcount=10 grpcount=2 comcount=4 fixcount=18 impcount=0 expcount=0 e:\eee\ramspeed\qq> --------------------Blinker----------------------------- e:\eee\ramspeed\qq>blinker file rs.obj lib user32.lib lib kernel32.lib BLINKER : 1115 : SNN.LIB(BUILDENV) : '__IMP__MULTIBYTETOWIDECHAR 24' : unresolved external BLINKER : 1115 : SNN.LIB(CLOCK) : '__IMP__GETTICKCOUNT 0' : unresolved external BLINKER : 1115 : SNN.LIB(GETENV) : '__IMP__GETENVIRONMENTVARIABLEA 12' : unresolved external BLINKER : 1115 : SNN.LIB(ISATTY) : '__IMP__GETFILETYPE 4' : unresolved external BLINKER : 1115 : SNN.LIB(LOCTIME) : '__IMP__GETTIMEZONEINFORMATION 4' : unresolved external BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CLOSEHANDLE 4' : unresolved external BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CREATESEMAPHOREA 16' : unresolved external BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__WAITFORSINGLEOBJECT 8' : unresolved external BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__RELEASESEMAPHORE 12' : unresolved external BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETACP 0' : unresolved external BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETOEMCP 0' : unresolved external BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETCPINFO 8' : unresolved external BLINKER : 1115 : SNN.LIB(SETNTERR) : '__IMP__GETLASTERROR 0' : unresolved external BLINKER : 1115 : SNN.LIB(TIME) : '__IMP__GETLOCALTIME 4' : unresolved external BLINKER : 1115 : SNN.LIB(TOLOWER) : '__IMP__LCMAPSTRINGA 24' : unresolved external BLINKER : 1115 : SNN.LIB(XCFILTER) : '__IMP__UNHANDLEDEXCEPTIONFILTER 4' : unresolved external BLINKER : 1115 : SNN.LIB(WCTOMB) : '__IMP__WIDECHARTOMULTIBYTE 32' : unresolved external BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALALLOC 16' : unresolved external BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALFREE 12' : unresolved external BLINKER : 1115 : SNN.LIB(ISCTYPE) : '__IMP__GETSTRINGTYPEA 20' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGW 24' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGA 24' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOW 16' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOA 16' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETSTRINGTYPEW 16' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__LCMAPSTRINGW 24' : unresolved external BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDNEXTFILEA 8' : unresolved external BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDCLOSE 4' : unresolved external BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FILETIMETODOSDATETIME 12' : unresolved external BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDFIRSTFILEA 8' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETSTDHANDLE 4' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__CREATEFILEA 28' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__MOVEFILEA 8' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__DELETEFILEA 4' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETHANDLECOUNT 4' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETFILEPOINTER 16' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETFILEATTRIBUTESA 4' : unresolved external BLINKER : 1115 : SNN.LIB(SETARGV) : '__IMP__GETMODULEFILENAMEA 12' : unresolved external BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__WRITECONSOLEA 20' : unresolved external BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__MESSAGEBOXA 16' : unresolved external BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETMODULEHANDLEA 4' : unresolved external BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETCOMMANDLINEA 0' : unresolved external BLINKER : 0 Warning error(s), 42 Fatal error(s) RS.EXE (not created) (0.1 seconds) e:\eee\ramspeed\qq> -----------------------Tlink------------------------ e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib\ rs.obj,,,user32.lib+kernel32.lib Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland Warning: Unable to perform incremental link - performing full link... Fatal: Unable to open file 'SNN.OBJ' e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib rs.obj,,,snn.lib+user32.lib+kernel32.lib Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland Fatal: Error detected (IMP1807) Fatal: Access violation. Link terminated. Warning: Unable to perform incremental link - performing full link... Fatal: Error detected (IMP1807) Fatal: Access violation. Link terminated. e:\eee\ramspeed\qq>

Aug 01 2002
parent reply Federico <Federico_member pathlink.com> writes:
In article <3D49ACB6.963DE854 smartsoft.cc>, Jan Knepper says...

What about the DM Linker???

Look at the other messages, it fails.
It seems to me like you have to throw an option for blinker to prevent it from
capitalizing the function names, that might fix one problem.

Thanks Jan, you are obviously write (and I'm a stupid :-( ). Your message prompted me to better study the horrible on line documentation of Blinker DEMO version, and I happened to write the correct script and definiton files to produce a Win32 executables, just to discover that: ----------------------------blinker ouput--------------------------- e:\eee\ramspeed\qq>blinker blrs __ __ (оп) (оп) BLINKER DOS Extender and Windows Linker 5.10  ___ Blink and you'll miss it !! Copyright (c) Assembler Software Manufacturers, Inc. 1990-99 All Rights Reserved * Demo * www.blinkinc.com 1-804-784-2347 BLINKER : 1000 : This demo version will not create 32 bit Windows programs --------------------------------------------------------------------- Maybe that explains Blinker complaints. Federico
Aug 02 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
What about the DM Linker???


I meant, the messages the linker gives you. You give a report for all the other linkers I can not help you with.
It seems to me like you have to throw an option for blinker to prevent it from
capitalizing the function names, that might fix one problem.

Thanks Jan, you are obviously write (and I'm a stupid :-( ). Your message prompted me to better study the horrible on line documentation of Blinker DEMO version, and I happened to write the correct script and definiton files to produce a Win32 executables, just to discover that: [ ... ]

Well, I guess that answers your question about blinker... Jan
Aug 02 2002
parent reply Federico <Federico_member pathlink.com> writes:
In article <3D4B044D.97C0BB2E smartsoft.cc>, Jan Knepper says...
What about the DM Linker???


I meant, the messages the linker gives you. You give a report for all the other linkers I can not help you with.

"Unexpected OPTLINK termination at EIP=0043E29C" The body contains a red circle with a white X in it, and says: "EAX=00000000 EBX=0046C7A0 ECX=00001000 EDX=000008DF ESI=00000000 EDI=00004056 EBP=006BFF78 ESP=006BFE10 First=00430000" Federico
Aug 03 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
Federico wrote:

 In article <3D4B044D.97C0BB2E smartsoft.cc>, Jan Knepper says...
What about the DM Linker???


I meant, the messages the linker gives you. You give a report for all the other linkers I can not help you with.

"Unexpected OPTLINK termination at EIP=0043E29C" The body contains a red circle with a white X in it, and says: "EAX=00000000 EBX=0046C7A0 ECX=00001000 EDX=000008DF ESI=00000000 EDI=00004056 EBP=006BFF78 ESP=006BFE10 First=00430000"

<g> That's all?! Jan
Aug 03 2002
parent Federico <Federico_member pathlink.com> writes:
In article <3D4C0358.45137DD6 smartsoft.cc>, Jan Knepper says...
<g>
That's all?!

Yes. I'm not used to hide information to people helping me... ;-) Walter said it is a problem in OPTLINK he cannot fix. BTW, I'm running WinME, but I had the same problem with different versions and on different systems. Federico
Aug 04 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
1) Record type BC is a COMDAT record - perfectly valid. Bug in Alink.
2) These externs should be defined in whatever operating system .lib file
you're linking with - not a problem with SNN.LIB.
3) Identifying the problem as being with SNN.OBJ (when the name of the file
is SNN.LIB) indicates a bug in ilink32, not SNN.
4) Access violations when ilink32 is run is a bug in the linker, not SNN.


"Federico" <Federico_member pathlink.com> wrote in message
news:aic9qt$d1o$1 digitaldaemon.com...
 In article <ai9qud$27he$1 digitaldaemon.com>, Walter says...
What problems with snn?

Please, find below outputs of Alink, Blinker, Tlink. The latter gives no information, but the problem happens as soon as SNN.LIB is accessed. Moreover, if the big arrays at file scope are not declared static, both alink and blinker complains on the .obj generated from my source code. Maybe I'm stuck in a stupid problem, I apologize but I'm not an expert in linking under Win32. Federico -----------------Alink------------------------------ e:\eee\ramspeed\qq>alink -oPE -subsys con rs.obj USER32.LIB KERNEL32.LIB ALINK v1.6 (C) Copyright 1998-9 Anthony A.J. Williams. All Rights Reserved Loading file rs.obj Loading file USER32.LIB Loading file KERNEL32.LIB Loading file SNN.lib Error in file at 000000EE - unknown object module record type BC name count = 19 seg count = 8 extcount=10 grpcount=2 comcount=4 fixcount=18 impcount=0 expcount=0 e:\eee\ramspeed\qq> --------------------Blinker----------------------------- e:\eee\ramspeed\qq>blinker file rs.obj lib user32.lib lib kernel32.lib BLINKER : 1115 : SNN.LIB(BUILDENV) : '__IMP__MULTIBYTETOWIDECHAR 24' : unresolved external BLINKER : 1115 : SNN.LIB(CLOCK) : '__IMP__GETTICKCOUNT 0' : unresolved

 BLINKER : 1115 : SNN.LIB(GETENV) : '__IMP__GETENVIRONMENTVARIABLEA 12' :
 unresolved external
 BLINKER : 1115 : SNN.LIB(ISATTY) : '__IMP__GETFILETYPE 4' : unresolved

 BLINKER : 1115 : SNN.LIB(LOCTIME) : '__IMP__GETTIMEZONEINFORMATION 4' :
 unresolved external
 BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CLOSEHANDLE 4' : unresolved

 BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CREATESEMAPHOREA 16' :

 external
 BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__WAITFORSINGLEOBJECT 8' :

 external
 BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__RELEASESEMAPHORE 12' :

 external
 BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETACP 0' : unresolved

 BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETOEMCP 0' : unresolved

 BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETCPINFO 8' : unresolved

 BLINKER : 1115 : SNN.LIB(SETNTERR) : '__IMP__GETLASTERROR 0' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(TIME) : '__IMP__GETLOCALTIME 4' : unresolved

 BLINKER : 1115 : SNN.LIB(TOLOWER) : '__IMP__LCMAPSTRINGA 24' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(XCFILTER) : '__IMP__UNHANDLEDEXCEPTIONFILTER 4' :
 unresolved external
 BLINKER : 1115 : SNN.LIB(WCTOMB) : '__IMP__WIDECHARTOMULTIBYTE 32' :

 external
 BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALALLOC 16' : unresolved

 BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALFREE 12' : unresolved

 BLINKER : 1115 : SNN.LIB(ISCTYPE) : '__IMP__GETSTRINGTYPEA 20' :

 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGW 24' :

 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGA 24' :

 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOW 16' :

 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOA 16' :

 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETSTRINGTYPEW 16' :

 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__LCMAPSTRINGW 24' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDNEXTFILEA 8' : unresolved

 BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDCLOSE 4' : unresolved

 BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FILETIMETODOSDATETIME 12' :

 external
 BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDFIRSTFILEA 8' : unresolved

 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETSTDHANDLE 4' : unresolved

 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__CREATEFILEA 28' : unresolved

 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__MOVEFILEA 8' : unresolved external
 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__DELETEFILEA 4' : unresolved

 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETHANDLECOUNT 4' : unresolved

 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETFILEPOINTER 16' : unresolved

 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETFILEATTRIBUTESA 4' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(SETARGV) : '__IMP__GETMODULEFILENAMEA 12' :

 external
 BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__WRITECONSOLEA 20' :

 external
 BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__MESSAGEBOXA 16' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETMODULEHANDLEA 4' :

 external
 BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETCOMMANDLINEA 0' :

 external

 BLINKER : 0 Warning error(s), 42 Fatal error(s)

 RS.EXE (not created) (0.1 seconds)

 e:\eee\ramspeed\qq>

 -----------------------Tlink------------------------

 e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib\
 rs.obj,,,user32.lib+kernel32.lib
 Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland

 Warning: Unable to perform incremental link - performing full link...

 Fatal: Unable to open file 'SNN.OBJ'

 e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib
 rs.obj,,,snn.lib+user32.lib+kernel32.lib
 Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland

 Fatal: Error detected (IMP1807)

 Fatal: Access violation.  Link terminated.

 Warning: Unable to perform incremental link - performing full link...

 Fatal: Error detected (IMP1807)

 Fatal: Access violation.  Link terminated.


 e:\eee\ramspeed\qq>

Aug 01 2002
parent reply Federico <Federico_member pathlink.com> writes:
I never meant the problem was IN snn.lib, I said:

 BTW. If I declare the big arrays 'static', Blinker does not complain anymore
 on the .obj, but has problems with SNN.LIB. The same happens with Borland
 Tlink.

I never said "SNN.LIB causes problems". Federico In article <aicch8$ggd$1 digitaldaemon.com>, Walter says...
1) Record type BC is a COMDAT record - perfectly valid. Bug in Alink.
2) These externs should be defined in whatever operating system .lib file
you're linking with - not a problem with SNN.LIB.
3) Identifying the problem as being with SNN.OBJ (when the name of the file
is SNN.LIB) indicates a bug in ilink32, not SNN.
4) Access violations when ilink32 is run is a bug in the linker, not SNN.

Aug 02 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Federico" <Federico_member pathlink.com> wrote in message
news:aieu3p$5ki$1 digitaldaemon.com...
 I never said "SNN.LIB causes problems".

You're right, you did not. I apologize.
Aug 02 2002
parent reply Federico <Federico_member pathlink.com> writes:
Thanks to everyone who replied. Now that I solved the problem and I'm happy,I
have to make two comments:

1) the C standard and DMC docs state no limit on statically allocated areas.
I know form past interactiosn that the (wonderful!) linker is not in Walter's
control, but that problem is not nice at all;

2) before solving the problem, I anyhow ordered the DM CD: it's a wonderful
product, I love it more than I loved Symantec C++ in the past, it's worth
really more than 25 bucks!

Federico
Aug 03 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
Federico wrote:

 2) before solving the problem, I anyhow ordered the DM CD: it's a wonderful
 product, I love it more than I loved Symantec C++ in the past, it's worth
 really more than 25 bucks!

I thought it is currently being sold for $50??? Jan
Aug 03 2002
parent Federico <Federico_member pathlink.com> writes:
In article <3D4C0399.A6578C4C smartsoft.cc>, Jan Knepper says...
I thought it is currently being sold for $50???

I'd pay $50 as well, it's worth even more, however in those days of poor compilers available for free, and of people satisfied with those, keeping the price low could be a good approach. Federico
Aug 04 2002
prev sibling parent reply Heinz Saathoff <hsaat bre.ipnet.de> writes:
Federico schrieb...
 I agree, but it fails as soon as the data declared at file scope exceed 40 MB
 total.
 As you maybe remember, we had this discussion a few months ago: DMC produces
 very fast executables, better then any competitor. However, if I use dynamic
 memory allocation, speed degrades by 30 percent. Still better than other
 compilers using dynamic allocation, but worse than other compiler on huge
static
 data.
 I'm trying to find a way out of the problem.

Why not allocating a big buffer on startup? It shouldn't make much difference in access time if you change char big_buffer[big_size]; // doing something with big_buffer to char *big_buffer = new char[big_size]; // or malloc // doing somthing with big_buffer There is only one dynamic memory allocation in this case. The rest is nearly the same. Ok, the static buffer can be accessed with immediate addresses where the dynamic buffer pointer must first be loaded to a register and offset addressed. But I would expect that this isn't a big performance degradation. - Heinz
Jul 31 2002
parent reply Federico <Federico_member pathlink.com> writes:
In article <MPG.17b2f9f4a1b121699896ae news.digitalmars.com>, Heinz Saathoff
says...
Why not allocating a big buffer on startup? It shouldn't make much 
difference in access time if you change

Sorry, it does. I was able to reduce the problem to a simple and stupid matrix multiplication of two NxN matrices into a third one (the original code is different and much more sophisticated, but exhibits the very same pathology). Please, look at those measures (dynamic means that memory is allocated once at the very beginning): N Allocation DMC 8.28 BC++ 5.5 500 static 2.45 s 2.70 s 500 dynamic 3.17 s 3.67 s 2000 static link failed! 141.13 s 2000 dynamic 166.31 s 196.81 s Not only is DMC better than other compiler in most respects (support of accurate floating point computation is wonderful), it produces faster executables too. However, performance degradations resulting from the switch from static to dynamic memory allocation are significant (actually deadly for my application).
nearly the same. Ok, the static buffer can be accessed with immediate 
addresses where the dynamic buffer pointer must first be loaded to a 
register and offset addressed. But I would expect that this isn't a big 
performance degradation.

No, this is not a problem. There is not much difference between accessing memory locations in an array and accessing memory locations in a malloc'ed area, not with a barely decent optimizing compiler. I can prove that easily, it is even more evident on RISC architectures and the progressive RISC-ification of x86 processors made this true for them as well. I had not time to look in detail to DMC generated assembler, but the one for the computational core is much more verbose and lenghty for the dinamic allocation version than for the static one. This usually comes from the optimizer being more aggressive with static data, as it can more easily check at compile time for aliasing problems, something cannot be done easily for dynamically allocated areas and pointers to them. With FORTRAN 77, which always assume no aliasing (if you don't use EQUIVALENCE, of course), there is no difference if you pass to a subroutine a static data area or a malloc'ed one. In FORTRAN 9X, which supports pointers, aliasing can be an issue, and performance can degrades. In FORTRAN 9X you can fine control the effect using the TARGET attribute (if the compiler takes advantage of the information), C99 introduced the restrict keyword with similar purposes, and using it can pay a lot with some compilers. To my surprise, using __restrict with DMC had no effect. Federico
Aug 01 2002
next sibling parent reply Jan Knepper <jan smartsoft.cc> writes:
Federico wrote:

 In article <MPG.17b2f9f4a1b121699896ae news.digitalmars.com>, Heinz Saathoff
 says...
Why not allocating a big buffer on startup? It shouldn't make much
difference in access time if you change

Sorry, it does. I was able to reduce the problem to a simple and stupid matrix multiplication of two NxN matrices into a third one (the original code is different and much more sophisticated, but exhibits the very same pathology).

Could you give an example in 'code' of what you are doing and how static v.s. dynamic makes such a difference? Jan
Aug 01 2002
parent reply Federico <Federico_member pathlink.com> writes:
In article <3D49AD77.20CE8DA7 smartsoft.cc>, Jan Knepper says...
Could you give an example in 'code' of what you are doing and how static v.s.
dynamic makes such a difference?

Well, today I had some time to look at generated assembler and I happened to solve the problem: now my code meets the deadline for the compuattion. The dynamic allocation version was a poor performer because the pointers to the data areas were allocated at file scope. If they are local to the function using them (temporary variables or formal parameters) the resulting code is more compact and faster as well (the codes are reported below, too bad that I'm not allowed to publish the real code, just a different one exhibiting the same problem). The files: rs.c the original one, arrays defined at file scope rsdyn.c pointers defined at file scope, malloc'ed memory areas rsdynb.c pointers defined at function scope, malloc'ed memory areas rsdynf.c pointers defined at file scope, malloc'ed memory areas passed as parameters to a function implementing the core computation rsdynbf.c pointers defined at function scope, malloc'ed memory areas passed as parameters to a function implementing the core computation The fact that defining pointers at function scope with respect to file scope makes such a difference is still puzzling to me, I'm not accustomed to that on RISC architectures and find it a little bit strange. Federico ---------------------------------rs.c------------------------------------ #include <math.h> #include <stdio.h> #include <stdlib.h> #include <time.h> #define N 2000 float a[N][N]; float b[N][N]; float derpo[N][N]; int main() { int i, j, k; float *pa, *pb, *pc; float tot = 0.0; clock_t start, stop; fprintf(stderr,"Using %f MB of memory.\n", 3.0*N*N*sizeof(float)/1048576.0); start = clock(); for(pa=a[0], pb=b[0], i=0; i<(N*N); ++i) *pa++ = rand(), *pb++ = rand(); for(i=0; i<N; ++i) { for(j=0; j<N; ++j) derpo[i][j] = 0.0; for(k=0; k<N; ++k) for(j=0; j<N; ++j) derpo[i][j] += a[i][k]*b[k][j]; } for(pc=derpo[0], i=0; i<(N*N); ++i) tot += *pc++; stop = clock(); fprintf(stderr,"Total: %f, time: %fs.\n", tot, (1.0*stop-start)/CLOCKS_PER_SEC); return 0; } ---------------------------------rsdyn.c--------------------------------- #include <math.h> #include <stdio.h> #include <stdlib.h> #include <time.h> #define N 2000 float (*a)[N]; float (*b)[N]; float (*derpo)[N]; int main() { int i, j, k; float *pa, *pb, *pc; float tot = 0.0; clock_t start, stop; a = malloc(N*N*sizeof(float)); b = malloc(N*N*sizeof(float)); derpo = malloc(N*N*sizeof(float)); if (!(a && b && derpo)) { fprintf(stderr, "Failed to allocate memory!\n"); exit(1); } fprintf(stderr,"Using %f MB of memory.\n", 3.0*N*N*sizeof(float)/1048576.0); start = clock(); for(pa=a[0], pb=b[0], i=0; i<(N*N); ++i) *pa++ = rand(), *pb++ = rand(); for(i=0; i<N; ++i) { for(j=0; j<N; ++j) derpo[i][j] = 0.0; for(k=0; k<N; ++k) for(j=0; j<N; ++j) derpo[i][j] += a[i][k]*b[k][j]; } for(pc=derpo[0], i=0; i<(N*N); ++i) tot += *pc++; stop = clock(); fprintf(stderr,"Total: %f, time: %fs.\n", tot, (1.0*stop-start)/CLOCKS_PER_SEC); return 0; } ---------------------------------rsdynb.c-------------------------------- #include <math.h> #include <stdio.h> #include <stdlib.h> #include <time.h> #define N 2000 int main() { int i, j, k; float (*a)[N]; float (*b)[N]; float (*derpo)[N]; float *pa, *pb, *pc; float tot = 0.0; clock_t start, stop; a = malloc(N*N*sizeof(float)); b = malloc(N*N*sizeof(float)); derpo = malloc(N*N*sizeof(float)); if (!(a && b && derpo)) { fprintf(stderr, "Failed to allocate memory!\n"); exit(1); } fprintf(stderr,"Using %f MB of memory.\n", 3.0*N*N*sizeof(float)/1048576.0); start = clock(); for(pa=a[0], pb=b[0], i=0; i<(N*N); ++i) *pa++ = rand(), *pb++ = rand(); for(i=0; i<N; ++i) { for(j=0; j<N; ++j) derpo[i][j] = 0.0; for(k=0; k<N; ++k) for(j=0; j<N; ++j) derpo[i][j] += a[i][k]*b[k][j]; } for(pc=derpo[0], i=0; i<(N*N); ++i) tot += *pc++; stop = clock(); fprintf(stderr,"Total: %f, time: %fs.\n", tot, (1.0*stop-start)/CLOCKS_PER_SEC); return 0; } ---------------------------------rsdynf.c-------------------------------- #include <math.h> #include <stdio.h> #include <stdlib.h> #include <time.h> #define N 2000 float (*a)[N]; float (*b)[N]; float (*derpo)[N]; void MatrixMul(float *A, float *B, float *C) { // multiply NxN matrix A*B resulting in C int i, j, k; float *b; for(i=0; i<N; ++i, C+=N, A+=N) { for(j=0; j<N; ++j) C[j] = 0.0; for(k=0, b=B; k<N; ++k, b+=N) for(j=0; j<N; ++j) C[j] += A[k]*b[j]; } } int main() { int i, j, k; float *pa, *pb, *pc; float tot = 0.0; clock_t start, stop; a = malloc(N*N*sizeof(float)); b = malloc(N*N*sizeof(float)); derpo = malloc(N*N*sizeof(float)); if (!(a && b && derpo)) { fprintf(stderr, "Failed to allocate memory!\n"); exit(1); } fprintf(stderr,"Using %f MB of memory.\n", 3.0*N*N*sizeof(float)/1048576.0); start = clock(); for(pa=a[0], pb=b[0], i=0; i<(N*N); ++i) *pa++ = rand(), *pb++ = rand(); MatrixMul((float *)a, (float *)b, (float *)derpo); for(pc=derpo[0], i=0; i<(N*N); ++i) tot += *pc++; stop = clock(); fprintf(stderr,"Total: %f, time: %fs.\n", tot, (1.0*stop-start)/CLOCKS_PER_SEC); return 0; } ---------------------------------rsdynbf.c------------------------------- #include <math.h> #include <stdio.h> #include <stdlib.h> #include <time.h> #define N 2000 void MatrixMul(float *A, float *B, float *C) { // multiply NxN matrix A*B resulting in C int i, j, k; float *b; for(i=0; i<N; ++i, C+=N, A+=N) { for(j=0; j<N; ++j) C[j] = 0.0; for(k=0, b=B; k<N; ++k, b+=N) for(j=0; j<N; ++j) C[j] += A[k]*b[j]; } } int main() { int i, j, k; float (*a)[N]; float (*b)[N]; float (*derpo)[N]; float *pa, *pb, *pc; float tot = 0.0; clock_t start, stop; a = malloc(N*N*sizeof(float)); b = malloc(N*N*sizeof(float)); derpo = malloc(N*N*sizeof(float)); if (!(a && b && derpo)) { fprintf(stderr, "Failed to allocate memory!\n"); exit(1); } fprintf(stderr,"Using %f MB of memory.\n", 3.0*N*N*sizeof(float)/1048576.0); start = clock(); for(pa=a[0], pb=b[0], i=0; i<(N*N); ++i) *pa++ = rand(), *pb++ = rand(); MatrixMul((float *)a, (float *)b, (float *)derpo); for(pc=derpo[0], i=0; i<(N*N); ++i) tot += *pc++; stop = clock(); fprintf(stderr,"Total: %f, time: %fs.\n", tot, (1.0*stop-start)/CLOCKS_PER_SEC); return 0; }
Aug 03 2002
parent Federico <Federico_member pathlink.com> writes:
In article <aigqms$2li6$1 digitaldaemon.com>, Federico says...
The files:
rs.c           the original one, arrays defined at file scope
rsdyn.c        pointers defined at file scope, malloc'ed memory areas
rsdynb.c       pointers defined at function scope, malloc'ed memory areas
rsdynf.c       pointers defined at file scope, malloc'ed memory areas passed
as parameters to a function implementing the core computation
rsdynbf.c      pointers defined at function scope, malloc'ed memory areas
passed as parameters to a function implementing the core
computation

Should someone be interested in, I forgot to mention compiler options. I used -WA -o+all -ff Federico
Aug 04 2002
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
"Federico" <Federico_member pathlink.com> wrote in message
news:aic9al$ceu$1 digitaldaemon.com...
 In FORTRAN 9X you can fine control the effect using the TARGET attribute

 the compiler takes advantage of the information), C99 introduced the

 keyword with similar purposes, and using it can pay a lot with some

 To my surprise, using __restrict with DMC had no effect.

__restrict is simply ignored by DMC at the moment, which is allowable behavior under C99. Nevertheless, it can be made use of to generate better code, and a future version of DMC may do this.
Aug 01 2002
prev sibling parent reply Heinz Saathoff <hsaat bre.ipnet.de> writes:
Federico schrieb...
Why not allocating a big buffer on startup? It shouldn't make much 
difference in access time if you change

Sorry, it does. I was able to reduce the problem to a simple and stupid matrix multiplication of two NxN matrices into a third one (the original code is different and much more sophisticated, but exhibits the very same pathology).

Do you do the matrix multiply in a function taking the matrices as 'pointer to double' parameters like void MatrixMul(int N, double *A, double *B, double *C) { // multiply NxN matrix A*B resulting in C } and call this with static allocated matrix in one case and dynamic one in the other case? This should not result in different performance as the generated code for MatrixMul would be the same. What would make a difference is simulating a 2D array with pointers as in double **A = new double*[N]; for(int i=0; i<N; ++i) A[i] = new double[N]; // same for B and C and writing MatrixMul as void MatrixMul(int N, double **A, double **B, double **C) { // do the multiply } This would indeed involve a overhead. Another point could be different alignment of static array and dynamic allocated array. We had this discussion in the group that 8-byte aligned doubles are faster than 4-byte aligned doubles.
 I had not time to look in detail to DMC generated assembler, but the one for
 the computational core is much more verbose and lenghty for the dinamic
 allocation version than for the static one.
 This usually comes from the optimizer being more aggressive with static data,
 as it can more easily check at compile time for aliasing problems, something
 cannot be done easily for dynamically allocated areas and pointers to them.

IMO this can only happen when the routines directly access the global static buffer and not taking the arguments as parameters. But, as Jan said, a small example code for static and dynamic version may help to clarify where the difference is. - Heinz
Aug 02 2002
parent Federico <Federico_member pathlink.com> writes:
In article <MPG.17b457435bb5f6899896af news.digitalmars.com>, Heinz Saathoff
says...
Do you do the matrix multiply in a function taking the matrices as 
'pointer to double' parameters like

   void MatrixMul(int N, double *A, double *B, double *C)

Look at the codes I sent, please.
What would make a difference is simulating a 2D array with pointers as 
in

  double **A = new double*[N];

I'm not so stupid or ignorant to do that.
Another point could be different alignment of static array and dynamic 
allocated array. We had this discussion in the group that 8-byte aligned 
doubles are faster than 4-byte aligned doubles.

That's obvious stuff I dind't mentioned, I'm using floats.
IMO this can only happen when the routines directly access the global 
static buffer and not taking the arguments as parameters.

This is the same conclusion I came to looking at assembly language compiler output. However, this is only true for DMC, try with BC++, or a compiler for RISC architectures anf you'll find that this makes no difference (as it should be...) Federico
Aug 03 2002