From: jimsymolon (jsymolon01_at_attbi.com)
Date: 2003-05-29 15:09:15
Ullrich von Bassewitz wrote: >On Thu, May 29, 2003 at 06:28:53AM -0400, jimsymolon wrote: > > >>Right now I don't know where to start. It is the CFG file for the >>linker ? It is one of the programs not getting the right parameters ? >> >> > >Unfortunately you haven't given enough information for me to track down the >problem. Some things you say seem to contradict each other. One example is >that the EXEHDR segment is added in one situation and not in the other. This >is almost impossible. Why should the linker do that? Another thing I don't >understand is: if the non working code is being compiled and used on a Linux >system, how comes that your compile and link scripts are windows batch files? > >If you used the Linux system to just recompile the libraries and the final >application compile happened on a Windows system, one possible cause is that >you messed up the libraries/object files or the executable when transfering >them. Windows has a lot of old and quite illogical behaviours, one being that >there is a difference between text and binary files. Some tools apply >automatic conversions to files when transfering them between machines. A >binary file that gets transferred in text mode will get corrupted when doing >so. > >My suggestion would be to run the binary on the Linux system if you haven't >done so before. Development under Linux (or other Unices) is a lot easier and >straightforward than under Windows, and a lot of problems simply don't exist. > >If the above is *not* the cause of your problem I need more information about >what you did *exactly*. Which packages are you using? Which files/tools and >command lines were used for the original (working) binary and which were use >for the non working one? On which systems did each step happen and if more >than one system was involved, how did you transfer the files? Did you compare >the transfered files resp. output files byte by byte? If so, how do they >differ? If you didn't: Linux comes out of the box with tools that can do that >easily. If you're using Windows, things are worse, so see my suggestion above. > >Regards > > > Uz > > > > I'm sorry... lets try again. I've downloaded the windows binaries and compiled the helloworld example program. I've copied the helloworld program to a DOS3.3 disk and it runs on the emulator (apple2win) successfully. This is done completely on a windows machine. There is a tool called a2tools that will copy a binary file into a DOS3.3 file system "disk". This disk is then loaded into the emulator. This is using the pre-compiled binaries on the cc65 site. I want to add in ProDOS support so I downloaded the cc65 sources and compiled on the linux box. Using those binaries, I've recompiled the library sources (using the gcc.mak) and re-built the helloworld program (cc65 and ld from the shell). Copying that new program (through samba to the windows box and then using a2tools) to DOS3.3 and running in applewin - the program crashes. I'm running samba on the linux box, which provides the file support. Right now I'm concentrating on building the libraries on linux and generating code that will run in the DOS3.3 / apple emulator. The binary built on linux looks correct in the emulator but the function calls jump to the wrong place. For example: the zerobss call, on both binaries (the windows and the linux) the JSR is to EEB but that location is 4 bytes short it should be to EEE. Its almost like the EXEHDR is messing things up. It it 4 bytes long. Am I forgetting some type flag somewhere ?? Thanks Jim ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2003-05-29 15:20:34 CEST