[Linker Fatal Error] Fatal: Access violation. Link terminated.
Larry Griffiths
did a make.
I got the following linker message:
[Linker Fatal Error] Fatal: Access violation. Link terminated.
I have tried changing compiler and linker options but this message will not
go away and I do not have a clue to what causes the error.
I re-booted my PC but the linker error still occurs.
I closed all files and opened the project again but the linker error still
occurs.
I deleted all .tds, .exe, .lib. bpl and .bpi files but the linker error
still occurs.
I am currently doing a Build all to see if it fixes the problem.
I am wide open for any suggestions on how to get around this problem as it
leaves me dead in the water.
Larry Griffiths
Larry Griffiths
Larry Griffiths
We own multiple BDS2007 Rad studio that we have not migrated to yet.
Could I grab the ILINK32.EXE from BDS2007 and try it instead?
Is there a .DLL I would need to include with it also?
Larry Griffiths
Duane Hebert
"Larry Griffiths" <lgrif...@cox.net> wrote in message
news:472e54e7$1...@newsgroups.borland.com...
You may want to wait a bit. I got your first
post on my way out of the office on Friday and it's now
Sunday evening...
ANONYMOUS
If I were you, I would try it anway. As long as you keep your source
codes safe, there is no reason why you can't try it and see what
happens.
Hope this helps.
Larry Griffiths
I tried a full build but still get the linker error.
I removed all my source from the failing project directory and brought back
the files as they were before the link error occurred.
I made a mistake updateing all my CVS project directories and have to work
out some compile errors that are occuring because of submissions from other
members of my group.
I had to break away from this EDI project last month to work on a robotic
interface. This EDI project is a month or two behind schedule now so I
groaned when this linker error shows up. Murphy is at it again. The
business owner dropped by late Friday and asked me how the project was
going. I told him about the linker error and that searching the web did not
produce any solutions to this problem. I found that others had this error
in the past but they did not post any work-arounds for this problem and the
Codegear reports show that the problem could not be fixed because the techs
did not have enough information to solve the problem. It seems to me that
the linker could hold some "In Storage" trace information that it could
output when it catches this exception so that the techs would have some
clues to narrow it down. I get the feeling that the ILINK32 is a piece of
code that does not have an owner or someone who understands it. If someone
did understand the code enough to program in trace code then it seems that
intelligent information could be presented along with the "Fatal Linker
Error" message which would enable the techs to solve this issue. Searching
the web shows this error has been around for years and has not been resolved
yet.
If a trace does exist for the linker then someone please tell me how to use
it. If more detailed information can be presented from ILINK32 then I would
greatly appreciate know how to turn it on and where to look for log files,
etc.
Larry Griffiths
"ANONYMOUS" <ANON...@NEWSGROUPS.COM> wrote in message
news:472E5AB5...@NEWSGROUPS.COM...
Pavel Sobek
The linker from CRS2007 behaves the same as in BDS2006.
I have put this error to QC at least twice and other people have done the
same but to no avail.
I tried to explain to CodeGear that the basic problem is that the linker
does not leave any trace behind when it quits with that error - just as you
say - but my submission was criticized as "not helpful" .....
The only thing I can recommend to you is to make a "dynamic" link to make
the exe smaller, which worked in my case. The necessity to distribute all
that bpls instead of one "monolithic" exe is a nuisance however.
Codegear, do you listen ? Your linker is CRAP CRAP CRAPPY CRAPPY CRAP
.........
Regards,
Pavel
"Larry Griffiths" <lgrif...@cox.net> píše v diskusním příspěvku
news:472e...@newsgroups.borland.com...
Larry Griffiths
virtual void __fastcall OnGrid( TStringGrid *Grid, int Row,
TTableInterface *Ti );
[C++ Error] QueryListU.h(27): E2303 Type name expected
I appeared to be pointing at the *Ti.
I added a forward class reference in a header:
class TTableInterface;
and still got the error.
I removed the TTableInterface...
virtual void __fastcall OnGrid( TStringGrid *Grid, int Row );
//virtual void __fastcall OnGrid( TStringGrid *Grid, int Row,
TTableInterface *Ti );
and it compiled without errors.
I removed the forward class reference and went back to the original
condition.
virtual void __fastcall OnGrid( TStringGrid *Grid, int Row,
TTableInterface *Ti );
Now it compiles without an error. Adding and commenting statements and then
removing them makes the failing statement compile now?
Something has got to be really hosed somewhere...
Continuing with compiles.
Larry Griffiths
problem.
"Larry Griffiths" <nos...@nowhere.com> wrote in message
news:472f2c33$1...@newsgroups.borland.com...
Larry Griffiths
I will put back all of the files in the original failing project and see if
the linker fails again.
Larry Griffiths
originally.
CVS is showing differences between the .bdsproj file and its archived copy.
There are a couple minor changes to some source code in that directory that
I do not think would affect the linker.
I brought back the .bdsproj file from CVS and compiled the project again.
The Link works so the linker error appears to have something to do with
the diffrence between the two
project files.
I will make incremental changes to bring the original .bdsproj file to the
failing .bdsproj file and do a make after each change in an attempt to
isolate the problem.
Larry Griffiths
the .bdsproj file.
The addition of the dbexpress.lib causes the linker to get the fatal error.
This is as far as I can go as far as providing information to resolve this
problem. I will suspect the dbexpress.lib if I encounter this problem in
the future.
I have a work-around now.
This works...
<property category="build.node" name="libraries" value="bcbsmp.lib
tee.lib bdertl.lib vclx.lib vclactnband.lib xmlrtl.lib vcldb.lib dbrtl.lib
ProUser.lib vcl.lib rtl.lib"/>
<property category="build.node" name="sparelibs" value="rtl.lib
vcl.lib ProUser.lib dbrtl.lib vcldb.lib xmlrtl.lib vclactnband.lib vclx.lib
bdertl.lib tee.lib bcbsmp.lib"/>
This fails.
<property category="build.node" name="libraries" value="dbexpress.lib
bcbsmp.lib tee.lib bdertl.lib vclx.lib vclactnband.lib xmlrtl.lib vcldb.lib
dbrtl.lib ProUser.lib vcl.lib rtl.lib"/>
<property category="build.node" name="sparelibs" value="rtl.lib
vcl.lib ProUser.lib dbrtl.lib vcldb.lib xmlrtl.lib vclactnband.lib vclx.lib
bdertl.lib tee.lib bcbsmp.lib dbexpress.lib"/>
Larry Griffiths
Larry Griffiths
The link error only occurs when the "Debug" configuration is active. The
"Release" configuration links ok.
"Larry Griffiths" <nos...@nowhere.com> wrote in message
news:472f3fc6$1...@newsgroups.borland.com...
Larry Griffiths
project files are as follows.
Debug link fails:
<property category="build.config" name="active" value="0"/>
Release links ok:
<property category="build.config" name="active" value="1"/>
Larry Griffiths
to BDS\Bin\lib\debug for grins and giggles.
The link still fails.
.
Larry Griffiths
I got to a point where I got the following error but I do not know if it is
related to the fatal link error.
Access violation at address 20C31CD4 in module 'coreide100.bpl'. Read
address of 682E7377.
+ $25[20C31CD4]{coreide100.bpl}
EditorBuffer.EditorBuffer.FindEditWindowAndView (Line 5717,
"EditorBuffer.pas" + 8) + $25
+ $0[51F26B4B]{rtl100.bpl } System.System.@HandleAnyException (Line 9980,
"system.pas" + 13) + $0
+ $41[7C903786]{ntdll.dll } RtlConvertUlongToLargeInteger + $41
+ $9[7C90EAF5]{ntdll.dll } KiUserExceptionDispatcher + $9
+ $2[22BE2735]{bcbide100.bpl} CppReg.CppReg.TCompilerAdapter.Compile (Line
1314, "CppReg.pas" + 2) + $2
+ $40[22BBB546]{bcbide100.bpl} CppMgr.CppMgr.TCppProjectUpdater.DoCompile
(Line 4740, "CppMgr.pas" + 1) + $40
+ $1D[22BE30D8]{bcbide100.bpl} CppReg.CppReg.CompileProject (Line 1671,
"CppReg.pas" + 37) + $1D
+ $1B[22BBEB0D]{bcbide100.bpl}
CppMgr.CppMgr.TCppProjectUpdater.CompileProject (Line 5891, "CppMgr.pas" +
2) + $1B
+ $14[20BFD0C2]{coreide100.bpl}
ProjectGroup.ProjectGroup.TProjectGroup.CompileContainer (Line 642,
"ProjectGroup.pas" + 53) + $14
+ $B[20BFCAC4]{coreide100.bpl}
ProjectGroup.ProjectGroup.TProjectGroup.CompileActive (Line 519,
"ProjectGroup.pas" + 1) + $B
+ $2[20BD5B3E]{coreide100.bpl}
Containers.Containers.TStdProjectContainer.CommandHandler (Line 1934,
"Containers.pas" + 15) + $2
+ $6[20BD5BBA]{coreide100.bpl}
Containers.Containers.TStdProjectContainer.CommandHandler (Line 1942,
"Containers.pas" + 0) + $6
+ $5[5204F0F9]{vcl100.bpl } Menus.Menus.TPopupList.MainWndProc (Line 3374,
"Menus.pas" + 2) + $5
+ $0[51F60BC0]{rtl100.bpl } Classes.Classes.StdWndProc (Line 11572,
"classes.pas" + 8) + $0
+ $6A[7E418731]{USER32.dll } GetDC + $6A
+ $14A[7E418811]{USER32.dll } GetDC + $14A
+ $122[7E4189C8]{USER32.dll } GetWindowLongW + $122
+ $A[7E4196C2]{USER32.dll } DispatchMessageA + $A
Larry Griffiths
for C:\BDS\lib\release\dbexpress.lib.
If I build with "Release" activated then the link works ok.
If I build with "Debug" activated then the link fails.
I remove the library and add C:\BDS\lib\debug\dbexpress.lib.
If I build with "Release" activated then the link fails.
If I build with "Debug" activated then the link works ok..
I remove the library statement from the project.
If I build with "Release" activated then the link works ok.
If I build with "Debug" activated then the link works ok.
So in conclusion it would seem to be a bad think to include dbexpress.lib in
the project manager ( and maybe even other debug/release libraries ).
I am making an assumption that the "[Linker Fata Error] Fatal: Access
violation. Link Terminated" message might occur for any library that is
included in the project directory if it is a library in the C:\BDS\lib\debug
or the C:\BDS\lib\release directories and the active configuration is the
opposite of the library path in the project manager ( debug or release ).
Duane Hebert
>I started removing units from the project and doing builds.
>
>
> I got to a point where I got the following error but I do not know if it
> is related to the fatal link error.
>
> Access violation at address 20C31CD4 in module 'coreide100.bpl'. Read
> address of 682E7377.
Probably has nothing to do with anything but are you building with codeguard
in
your debug build?
Larry Griffiths
See if what I found might apply to your particular instance of the fatal
linker error message...
When I look at the Project Manager I see that the project contains a library
for C:\BDS\lib\release\dbexpress.lib.
If I build with "Release" activated then the link works ok.
If I build with "Debug" activated then the link fails.
I remove the library and add C:\BDS\lib\debug\dbexpress.lib.
If I build with "Release" activated then the link fails.
If I build with "Debug" activated then the link works ok..
I remove the library statement from the project.
If I build with "Release" activated then the link works ok.
If I build with "Debug" activated then the link works ok.
So in conclusion it would seem to be a bad think to include dbexpress.lib in
the project manager ( and maybe even other debug/release libraries ).
I am making an assumption that the "[Linker Fata Error] Fatal: Access
Larry Griffiths
Not a bad days work of playing "Is it bigger than a bread box", hehe.
Larry
"Duane Hebert" <sp...@flarn.com> wrote in message
news:472f8193$1...@newsgroups.borland.com...
Duane Hebert
I don't have BDS2007 handy but can't you include the debug lib in your
debug build and the release lib in your release build? I have 2006 explorer
at home and it seems that this should work, no? Maybe rename the
library to dbexpressD.lib for the debug one or something...
Though I'm not sure why including a release lib in a debug build would
cause link problems.
Duane Hebert
>I think I figured it out, Duane.
>
> Not a bad days work of playing "Is it bigger than a bread box", hehe.
Ok. I replied to your other post. But I'm REALLY hoping that if that's
the problem, there's a way around it. I mean in msvc I can specify
a debug lib in a debug project either by a different path or a different
library name.
I just sort of assumed that once Borland gave us debug/release
build capabilities that this would also be the case. Can you not
have different paths defined dependant on the build?
David Dean [CodeGear]
"Duane Hebert" <sp...@flarn.com> wrote:
> I just sort of assumed that once Borland gave us debug/release
> build capabilities that this would also be the case. Can you not
> have different paths defined dependant on the build?
It *is* possible to have different library paths for different build
configurations. This actually happens by default because there is a
$(BDS)\lib\release defined in the release configuration and a
$(BDS)\lib\debug defined in the debug configuration.
--
-David
Duane Hebert
"David Dean [CodeGear]" <david....@spam.codegear.com> wrote in message
news:david.dean.no-EA4...@killface.local...
Yes, now that I'm home, looking at the explorer version, this seems to be
the case. So
it seems that the solution for Larry is to put the libs in the proper
location
or specify new locations in the particular builds.
Larry Griffiths
the compile and link. One of persons on my team says he adds it to certain
projects. I did get some missing external references to
sqlexpr::methodnames when linking but they went away. What I need to figure
out is why the sqlexpr:: etern message appear. Adding dbexpress.lib to the
project manager is surely not the way to fix the extern errors during
linking when they occur.
"Duane Hebert" <sp...@flarn.com> wrote in message
news:472f8cb5$1...@newsgroups.borland.com...
Duane Hebert
>I removed the dbexpress.lib from the project manager It is not needed for
>the compile and link. One of persons on my team says he adds it to certain
>projects. I did get some missing external references to
>sqlexpr::methodnames when linking but they went away. What I need to
>figure out is why the sqlexpr:: etern message appear. Adding dbexpress.lib
>to the project manager is surely not the way to fix the extern errors
>during linking when they occur.
Not unless your code is using functions defined there of course <g>.
Sounds like you're close to getting it sorted out now. You should
be able to grep for the function names that are causing problems
and find out where they're used. Hopefully not in some other
library...
Larry Griffiths
so the linker cannot resolve the externs in the packages or the executable
that uses the packages. The executable project also uses TSqlQuery.
I see BDS2007 uses the Project manager for configuration activation verses
using the Project Options to activate configurations in BDS2006.
I tried to get the fatal access error to occur under BDS2007 but everything
appears to compile and link just fine. ( perhaps brashly spoken, heh ) knock
on wood. LOL
Larry.
"Duane Hebert" <sp...@flarn2.com> wrote in message
news:472fbeae$1...@newsgroups.borland.com...
Larry Griffiths
The more things change.... The more things change!
Who says we can't re-invent the wheel?
Pavel Sobek
it is nice you have been able to guess a workaround to your particular
situation, but it is hardly a solution. I am not using dbexpress.lib nor
mixing debug and release paths.
To me it seems the problem is related to the exe size : when linking with
"Build with runtime packages" on, it works (smaller exe), when it is off
(bigger exe), it fails. So it sort of works for now (although I must
distribute many bpls with my application which I hate) but what am I to do
if my application grows a bit and I will be unable to link it anymore ?????
So I am trying to explain to Codegear and to anybody that the linker is a
potential catastrophe but nobody seems to listen. Instead I am told nonsense
such as "we have not sufficient information" and blablabla. The point is
that the "Fatal : Link terminated" bug is really Mother-of-all-bugs because
it precludes anybody (both Codegear and users) from having any useful
information on what is going on.
I say once more : the ILINK32 linker is a piece of unbelievable,
unprofessional, sub-standard crap which should not be given to the users.
What we need NOW is a linker which is able to deliver information in case of
exception such as : stack trace, name of file and function being processed
when error occured. Then we would be able to distinguish between Codegear
errors and user errors and to find a suitable workaround until the linker is
fixed. Is it really so hard to understand ????
Regards,
Pavel
"Larry Griffiths" <nos...@nowhere.com> píše v diskusním příspěvku
news:472f8509$1...@newsgroups.borland.com...
Larry Griffiths
I meant to use first names.
David , Can you squeeze 10 pounds of
projects into a 5 pound bag and get some trace code in the linker?
Please! Pretty Please with brown sugar and honey on it. :)
Larry
"Larry Griffiths" <nos...@nowhere.com> wrote in message
news:47307963$1...@newsgroups.borland.com...
> Sound like a plan, Pavel.
>
> Maybe Dean can squeeze it in his todo list. Can you squeeze 10 pounds of
> projects into a 5 pound bag, Dean. :)
>
> Larry.
>
>
> "Pavel Sobek" <ony...@czn.cz> wrote in message
> news:472f...@newsgroups.borland.com...
Larry Griffiths
compiles and links just fine in release or debug mode.
There must still be an additional factor in our production project other
than just including the dbexpress library from the release or debug
directory in the ProjectManager.
"Larry Griffiths" <lgrif...@cox.net> wrote in message
news:472fc2a5$1...@newsgroups.borland.com...
Larry Griffiths
Maybe Dean can squeeze it in his todo list. Can you squeeze 10 pounds of
projects into a 5 pound bag, Dean. :)
Larry.
"Pavel Sobek" <ony...@czn.cz> wrote in message
news:472f...@newsgroups.borland.com...
>
Pavel Sobek
> There must still be an additional factor in our production project other
> than just including the dbexpress library from the release or debug
> directory in the ProjectManager.
>
Wind direction or air humidity perhaps ....
Larry Griffiths
"Pavel Sobek" <ony...@czn.cz> wrote in message
news:4730c896$1...@newsgroups.borland.com...
David Dean [CodeGear]
"Larry Griffiths" <nos...@nowhere.com> wrote:
> Maybe Dean can squeeze it in his todo list. Can you squeeze 10 pounds of
> projects into a 5 pound bag, Dean. :)
How about if I try and squeeze it onto someone else's to do list? ;)
--
David Dean (CodeGear)
Lead C++ QA Engineer
Larry Griffiths
and you still have the fatal linker error?
By the way, does anybody know what the ILINK32.EXE-03A80551.pf in the
\WINDOWS\Prefetch is all about?
I guess I should ask what CRS stands for ( besides can't remember stuff ).
Larry.
"Pavel Sobek" <ony...@czn.cz> wrote in message
news:472e...@newsgroups.borland.com...
> As far as I know, no trace from the linker exists.
> The linker from CRS2007 behaves the same as in BDS2006.
>
Larry Griffiths
So then, when do I start and when can I get the source code. LOL
Larry
"David Dean [CodeGear]" <david....@spam.codegear.com> wrote in message
news:david.dean.no-585...@n003-000-000-000.static.ge.com...
Pavel Sobek
me even worse.
Never heard about this ...pf file.
Pavel
"Larry Griffiths" <lgrif...@cox.net> píše v diskusním příspěvku
news:4730...@newsgroups.borland.com...
Larry Griffiths
project that I could fire off to CodeGear.
Larry
"Pavel Sobek" <ony...@czn.cz> wrote in message
news:4730c896$1...@newsgroups.borland.com...
Pavel Sobek
As for big projects, nobody is willing to send all projects with sources to
CodeGear to reproduce the problem.
Without the linker producing useful information such as stack trace, exact
location of the problem (name of file and function processed) etc., it is
really a no-go situation.
Pavel
"Larry Griffiths" <lgrif...@cox.net> píše v diskusním příspěvku
news:4732775f$1...@newsgroups.borland.com...
dhoke
>I am afraid this problem wouldn't manifest itself in a small project.
> As for big projects, nobody is willing to send all projects with sources
> to CodeGear to reproduce the problem.
But, if you're willing, you can produce a "linkset" consisting of the binary
objects and libraries that are used to perform the actual link, along with a
response file that drives it. (If the link is long enough, I have captured
the response file produced by the IDE before it deleted it. If not, then
you have to display commands, copy it out of the IDE log and massage it to
create a batch file or response file.)
I have done this, and it sounds like Eike has also done this.
David Dean can probably give Larry more info on doing this if Larry is
interested.
Pavel Sobek
"dhoke" <dhoke....@east-shore.com> píše v diskusním příspěvku
news:4733115a$1...@newsgroups.borland.com...
dhoke
> If you have done this, would you care to describe it in more detail ?
First obtain a link command line.
[bds2006 creates a file "resp" in the target output directory which it uses
to invoke the linker. If the link within the IDE takes long enough, it is
possible to literally copy [from a command line] the response file, while it
exists. I used something like "copy resp keep_response" on a command line
in the target output directory, and hit enter there as soon as the project
began linking. It may be necessary to edit out some items, as the IDE
appears to create temporary files for files that have been modified but not
saved, and thus includes arguments to the linker that apparently result in a
substitute of the "temporary" name for the "actual" name, where the actual
name is used later in the command - or something like that.
If you can't "catch" the resp file, then you can tell the IDE to display its
command lines, and after running a link, cut and paste the resulting link
command into a batch file.
Either way will get you the information - my recollection is that for some
reason it seemed I would have to do less editing with the resp file... not
sure if that was the case or not - or it may have simply been that I was
_sure_ that's what the linker was being fed, when I could re-execute it.
]
Then you need to capture all of the binary items that "fed" into that link
command line attempting to produce the resulting executable. This would
include all objects from your application project, any import (package?)
libraries, and any static libraries, and any resource (.res) files [what am
I forgetting?] that are needed - anything referenced as input. (Anything
provided by Borland/Codegear, they already have access to.)
To verify that I had what I needed, I created a zip file with the above
binary items, and the linker command file or response file, preserving path
names (without drive letter) from the root all the way down.
I then created a temporary directory, and used the command line level
"subst" command to assign a "drive" to that location. I changed to that
subst'd drive, (which was initially empty) and unarchived the entire
contents there.
I then positioned to the target output directory on that drive, and executed
the link command. Any missing items required an adjustment of the zipfile,
a cleaning of the subst'd drive, and a repeat of unarchive/link/review,
until the only errors I had were ones that should not be.
Hoping that it might add some clarity to the above description, below is the
"steps" to reproduce file that I provided:
(adjust appropriately for your environment and circumstances)
mkdir c:\temp\linkset
subst u: c:\temp\linkset
cd /d u:\
unzip c:\isolate\linkset2.zip
xcopy "c:\Program Files\Borland\bds\4.0\lib\*" "u:\Program
Files\Borland\BDS\4.0\lib\"
mkdir "u:\Documents and Settings\Administrator\My Documents\Borland Studio
Projects\Bpl"
xcopy "c:\Program Files\Borland\bds\4.0\lib\release\*" "u:\Program
Files\Borland\bds\4.0\lib\release\"
xcopy "c:\Program Files\Borland\bds\4.0\lib\obj\*" "u:\Program
Files\Borland\bds\4.0\lib\obj\"
cd u:\working\trunk1547\est\UIStations\LSTPStation\Release_Build
(the later attempts were again done with ilink32.exe from cb2007 trial, but
supporting
rlink32.dll and lnk....dll were from bds2006 - I have verified the prob.
exists both ways)
c:\isolate\ilink32 @u:\temp\keep_resp2_mod_u.txt
(errors) (no .exe generated)
cd ..
c:\isolate\ilink32 @u:\temp\keep_resp2_mod_u.txt
(NO errors) (.exe generated in .\Release_Build)
===========end of file===============
Pavel Sobek
Will try it as soon as I can.
Pavel
Bob Gonder
>If you can't "catch" the resp file, then you can tell the IDE to display its
>command lines, and after running a link, cut and paste the resulting link
>command into a batch file.
You could also write a program that saves its commandline, parses it for response
filenames, copies the response files, etc.
Name it ilink32.exe and temporarily replace the official \bin version.
I did this several years ago to capture TASM info.
dhoke
"Bob Gonder" <no...@notmindspring.invalid> wrote in message
news:a4j6j3lfit315k22l...@4ax.com...
>
> You could also write a program that saves its commandline, parses it for
> response
> filenames, copies the response files, etc.
> Name it ilink32.exe and temporarily replace the official \bin version.
>
> I did this several years ago to capture TASM info.
>
>
Maybe you'd like to dig it up and contribute it :) (perhaps to David D. for
provision on an as-needed basis).
Bob Gonder
>Maybe you'd like to dig it up and contribute it :)
TASM32.C
#define _WIN32_WINNT 0x0400
#include <windows.h>
#include <stdlib.h>
#include <mem.h>
void cputs(HANDLE stdout,char*str)
{ DWORD byteswritten;
WriteFile( stdout,str,lstrlen(str),&byteswritten,NULL);
}
/* 0 1 2 3 4*/
/*D:\RA7\LIBRARY\TASM32.EXE apply/D__CDECL__ /r/ml ,apply.obj ;*/
int main(int argc, char * argv[])
{ int i;
char from[80];
char*to;
char*r;
HANDLE stdout=GetStdHandle(STD_OUTPUT_HANDLE);
for( i=0;i<argc;i++)
{ cputs(stdout,argv[i]);cputs(stdout," ");
};
cputs(stdout,"\r\n");
to = &argv[3][1]; /* apply.obj */
lstrcpy(from,to); /* apply.obj */
r=memchr(from,'.',lstrlen(from));
r[0]=0; /* apply */
lstrcat(from,".asm"); /* apply.asm */
CopyFile( from, to, FALSE);
return 0;
}
Hmmm... some dangerous code in there, worked for me, maybe not for you.
For ilink32, I'd fill out this outline
int main(int argc, char * argv[])
{
char filename[MAX_PATH+1];
char* Rsp;
char* Command = GetCommandLine();
HANDLE Out = CreateFile(whatever);
cputs( Out, "Commandline:\r\n" );
cputs( Out, Command );
cputs( Out, "\r\n\n" );
Rsp = Command;
while( Rsp )
{ Rsp = strchr( Rsp, '@' );
if( Rsp )
{ ++Rsp;
/* add code to parse filename at Rsp */
cputs( Out, "Response file: " );
cputs( filename );
cputs( "\r\n" );
/* add code here to read/write response file */
cputs( Out, "\r\n\n" );
};
};
return 0;
}
Mike K
your post (wish I did).
I had this EXACT same problem with BCB5; in fact, I still do - with only
one project, and it does not do it every time I compile/run. When it
does, however, I do this:
save everything
close the IDE
delete the TDS file in the project folder
delete the RES file in the project folder
restart the IDE.
The IDE complains about rebuilding the resource file, then it
builds/compiles/runs fine. No one has any idea why, and I hope this
helps your problem with 6.
Mike
Larry Griffiths
Thanks for the information.
I deleted .TDS files but did not try the .res file. I will try it if the
error shows up again.
Larry Griffiths
"Mike K" <nos...@nospam.net> wrote in message
news:473B6639...@nospam.net...