Hi list,

Recent posts have lead me to look again at my FPC/Lazarus downloader/compiler fpcup [1] to see if I could get cross compiling going from win64 or win64 to Go32v2.

This works for me:
1) Setup:
Create directory c:\development
Get crosscompile binutils from
ftp://ftp.freepascal.org/pub/fpc/contrib/cross/mingw/binutils-2.20-win32-i386-go32v2.zip Place the binaries in c:\development\cross\bin\i386-go32v2

Binaries include
i386-go32v2-ar.exe
i386-go32v2-as.exe
i386-go32v2-ld.exe
i386-go32v2-objdump.exe
i386-go32v2-strip.exe

2) Let fpcup compile a new FPC and Lazarus:
fpcup

3) Then do a cross compile; note this does require the cross compilation binutils but fpcup will warn you if they're missing fpcup --cputarget=i386 --ostarget=go32v2

Fpcup will give a warning about missing support for LCL/Lazarus which is expected as there's no LCL for Go32V2.

4) Start the installed Lazarus, create a simple program/console program, in Project Options, set target OS to go32v2 and target CPU to i386. Compile.

5) Remember to distribute cwsdpmi.exe with your programs. http://homer.rice.edu/~sandmann/cwsdpmi/index.html download:
http://homer.rice.edu/~sandmann/cwsdpmi/csdpmi7b.zip Starting dosbox, running cwsdpmi and then a hello world .exe worked fine.

As usual: comments/suggestions welcome.

Thanks,
Reinier

[1]
https://bitbucket.org/reiniero/fpcup/downloads

On Fri, September 20, 2013 18:42, Reinier Olislagers wrote:

Hi Reinier,

Which FPC branch do you use, trunk or fixes? If it is trunk, it should be able to use not only the internal assembler but also internal linker and thus these binutils are not used at all (unless also using -Xe). If it is fixes, then I wonder what happens there because the linker included in the package above completely refuses object files created by FPC 2.6.2 (admittedly, I haven't tested a fixes snapshot, but I wouldn't expect major changes in this area merged to fixes) - the linker complains about unsupported section type and doesn't find the required symbols.

Tomas

Tomas Hajny wrote

On Fri, September 20, 2013 18:42, Reinier Olislagers wrote: Which FPC branch do you use, trunk or fixes? If it is trunk, it should be able to use not only the internal assembler but also internal linker and thus these binutils are not used at all (unless also using -Xe).

Hi Tomas,
Thanks a lot!

I've tested it with trunk. I've adapted fpcup to not error out if those binutils are not found. Instead it writes a warning about 2.6.x needing binutils.

Haven't tested on fixes yet.

Thanks again,
Reinier

In our previous episode, Reinier Olislagers said:

Note that despite internal assembler, one might still need GAS because of the startup code (Linux being a special case, having startup code in pascal)

True, that's a good point. Still, the linker from that package didn't work for me with the 2.6.2 compiler (I haven't tried it with trunk, but it might be broken there too).

Also, the linker included in the 2.15 build in contrib isn't compatible with the command line syntax used by our compiler for the GO32v2 target (as already mentioned in my yesterday's post). One possible option might be to change the compiler in order not to generate link.res unless using a DOS compiler or using -st option (assuming that this was a DJGPP extension due to limited length of DOS command line). Another possibility might be trying to get this option supported in standard binutils, but that would be certainly a task for someone else than me. Or is there possibly an option (e.g. some binutils Makefile directive) to get that ld option enabled, so that just rebuilding binutils with that option would be sufficient? Any thoughts?

Tomas