c++.command-line - Linker
- Federico <Federico_member pathlink.com> Jul 30 2002
- "Walter" <walter digitalmars.com> Jul 30 2002
- Federico <Federico_member pathlink.com> Jul 31 2002
- "Walter" <walter digitalmars.com> Jul 31 2002
- Federico <Federico_member pathlink.com> Jul 31 2002
- "Walter" <walter digitalmars.com> Jul 31 2002
- Federico <Federico_member pathlink.com> Aug 01 2002
- Jan Knepper <jan smartsoft.cc> Aug 01 2002
- Federico <Federico_member pathlink.com> Aug 02 2002
- Jan Knepper <jan smartsoft.cc> Aug 02 2002
- Federico <Federico_member pathlink.com> Aug 03 2002
- Jan Knepper <jan smartsoft.cc> Aug 03 2002
- Federico <Federico_member pathlink.com> Aug 04 2002
- "Walter" <walter digitalmars.com> Aug 01 2002
- Federico <Federico_member pathlink.com> Aug 02 2002
- "Walter" <walter digitalmars.com> Aug 02 2002
- Federico <Federico_member pathlink.com> Aug 03 2002
- Jan Knepper <jan smartsoft.cc> Aug 03 2002
- Federico <Federico_member pathlink.com> Aug 04 2002
- Heinz Saathoff <hsaat bre.ipnet.de> Jul 31 2002
- Federico <Federico_member pathlink.com> Aug 01 2002
- Jan Knepper <jan smartsoft.cc> Aug 01 2002
- Federico <Federico_member pathlink.com> Aug 03 2002
- Federico <Federico_member pathlink.com> Aug 04 2002
- "Walter" <walter digitalmars.com> Aug 01 2002
- Heinz Saathoff <hsaat bre.ipnet.de> Aug 02 2002
- Federico <Federico_member pathlink.com> Aug 03 2002
Does anyone know how to make a linker different than OPTLINK work with DMC? Thanks Federico
Jul 30 2002
"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
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
"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
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
"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
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
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
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
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
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
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
Federico <Federico_member pathlink.com> 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
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
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
"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
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
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
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
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
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
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
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
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
"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
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
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