Message-ID: <325F0F5D.627@cs.com> Date: Fri, 11 Oct 1996 20:24:13 -0700 From: "John M. Aldrich" Reply-To: fighteer AT cs DOT com Organization: Three pounds of chaos and a pinch of salt MIME-Version: 1.0 To: Robert Hoehne CC: Bill Currie , djgpp-workers AT delorie DOT com Subject: Re: Linker script (Was Re: binutils 2.7 questions) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Hoehne wrote: > > 1) The deafult target of ld is overwritten by the 'djgpp.djl' file. That > means, if you call ld through gcc, the output format is 'coff-go32', > the raw coff format. I assume this is the name of the new linker script file. :) > 2) The stubify.exe prepends to a coff image a hardcoded stub. That > means, the environment variable $(STUB), which was mentioned by DJ, > is used only by the binutils (including ld), when writing the > 'coff-go32-exe' format. Here comes my suggestion to DJ, to change > the stubify in that way, also to use that variable for determining > the stub. The problem here is that you'd have to completely rewrite stubify to use a user-defined stub. As it stands, the way the stub is hardcoded into stubify makes it very difficult to change. Besides, what exactly are the advantages of using a different stub program anyway? There should be no need for it unless you are writing a specialized program like djverify, and for that it's easier to rebuild stubify anyway. > 3) There is also an other misunderstanding. If you call gcc with > gcc -o foo foo.c > there is produced both, the coff image 'foo' and the exe 'foo.exe' > in the same way like in V 2.00. Remember, that the deafult target > of ld is used only, if not overwritten on command line or in the > linker script (which is in DJGPP the case) So what's your concern? This is exactly the point I was trying to make - if you use 'foo' instead of 'foo.exe' as your target, neither gcc NOR ld should produce 'foo.exe' by default. > 4) Until stubify is not changed to use the optional external stub, you > can use the following to build an exe file with your stub: > - create the stub (name it mystub or something else) > - set the environment variable STUB to point to this file > - link your program with gcc and outputfile without the exe suffix > - now use objcopy to create the exe (objcopy knows about the > STUB variable) > objcopy --output-target=coff-go32-exe foo foo.exe Is this a workable solution? I thought that stubify existed for a reason - if it is this easy to set up your own custom stub I don't see why we bother with a specialized program. There must be some sort of drawback here. Besides, why would we need all sorts of customized stub programs? On Unix systems you don't need a stub at all, and there is only one DOS. > > 1) If the user specifies an '.exe' as the output file, ld should call > > stubify and remove the image (current behavior). > > > > 2) If the user specifies a non-'.exe' as the output file, ld should > > produce the image, but not call stubify. > > > > 3) If the user doesn't specify an output file, ld should produce both > > a.out and a.exe (current behavior). > > > What you are missing? The only thing, which you want to change, is > in point 2) by not creating the exe file (in addition to the coff > image). That IS my point. I think the default behavior for 2 should be changed, as it is counter-intuitive. If the user wants foo.exe, he/she should have to say so explicitly. I think you missed the entire point of my post - I wasn't saying that I want to start appending all sorts of different custom stubs to my programs, I was saying that I should be able to compile and _only_ generate an image file. The djverify example is just that, an example. -- John M. Aldrich * Anything that happens, happens. * Anything that, in happening, causes something else to happen, causes something else to happen. * Anything that, in happening, causes itself to happen again, happens again. * It doesn't necessarily do it in chronological order, though. --- Douglas Adams