Closed jwt27 closed 4 years ago
Hi, I think its not a good idea because it will introduce the incompatibility with the upstream-packaged version: http://mirrors.fe.up.pt/pub/djgpp/rpms/djcross-gcc-8.2.0/
Interestingly, the djgpp packages for Arch (also maintained by Andris Pavenis) use target i686
: https://aur.archlinux.org/packages/djgpp-gcc/
Interesting. It seems it was submitted there by @fstirlitz, so maybe he knows the answer to this question.
The reason I set the target to i686 was because I adapted the PKGBUILD script from MinGW packages, which also used i686, so I left that part as-is for consistency. In hindsight, setting it to i386 may have been a wiser choice, given that a major reason for building software for DOS is to support older hardware.
Also note there is another set of packages (confusingly named dosbox-gcc
and the like) which targets the i586, created because DOSBox doesn't support i686 instructions. (I submitted a patch adding some of them, but upstream doesn't seem to want it.)
Use dosemu2 for the djgpp-compiled binaries, not dosbox. :) Anyway, if things will go this route, people will have to start using configure scripts to locate the proper name of djgpp... IMHO this is completely impractical, but it seems to be already happening.
Does the target name even have any effect on the compiler? I don't think it does, it's just a naming convention. GCC still produces 386 code by default, and you can change that behaviour using -march=
.
I still think i686
is the most sensible choice, given that it's the convention for most other 32-bit x86 toolchains (eg. i686-pc-linux
, i686-w64-mingw32
, etc). i386
is a good alternative, as it shows intent to build code for older systems. i586
always struck me as odd, there is nothing pentium-specific about djgpp. Even stranger, the official DOS binaries are built with target i786
- but in that case, it doesn't matter, as the long file name versions are never used.
Keep in mind this patch doesn't force the use of any particular target name, you can still change it by setting export TARGET=i586-pc-msdosdjgpp
before running the script.
The problem is not what target will be used. This is largely irrelevant (well, modulo dosbox fans). The problem is the different compiler name on different distros. How would you suggest to write a makefile for that? Using the autoconf detections? IMHO this will really trouble the life.
Of course a symlink can solve the problem. Use the name you like but create the compatibility symlink, and the problem solved.
Use dosemu2 for the djgpp-compiled binaries, not dosbox. :)
DOSBox is more stable, though. And portable. Just saying.
Does the target name even have any effect on the compiler? I don't think it does, it's just a naming convention. GCC still produces 386 code by default, and you can change that behaviour using
-march=
.
No, GCC produces i686 code on i686-pc-msdosdjgpp
, and the accompanying libc (which is always linked statically into the executable) is also compiled for the same architecture; which means -march=i386
isn't going to be of much help. (Otherwise the so-called 'DOSBox' toolchain would be truly superfluous.)
DOSBox is more stable, though.
For old games or for djgpp-compiled programs? If the later, then you are very much encouraged to fill in the bug, as this is not the intended situation.
I'm about to publish the Ubuntu PPA and I want to get this issue out of the way first. I've done some tests and it looks like i686-pc-msdosdjgpp-gcc
is incapable of producing 386 code, even with -march=i386
set.
Seeing as this toolchain is targeting older systems, I now propose changing the default to i386-pc-msdosdjgpp
.
Note that this only changes the default value, and you can still target i586 using ./build-djgpp.sh --prefix=i586-pc-msdosdjgpp
.
Is everyone okay with that?
If this will introduce the incompatibility with the upstream-packaged djgpp (rpm) then its not ok. People are not going to use autoconf to locate the djgpp binary.
How many projects have i586-pc-msdosdjgpp
hardcoded in their makefile? It would take two seconds to change it. The vast majority of djgpp code is written to be built on DOS where CC=gcc
, and make
is expected to run in command.com
with del
/ren
/copy
instead of rm
/mv
/cp
. That is a much bigger incompatibility.
You can't "change" it unless you also convince the upstream to package it the same way. Then the one can change the makefiles. But its a no go to have one name on fedora and another one on ubuntu.
I have no opinion on the name of the toolchain, but I do need the ability to target 386.
How about this: 4ea103b
This installs a script that links the i*86-*
binaries to i586-*
. If compatibility with other distributions is required, one can run: sudo i386-pc-msdosdjgpp-link-i586
to install these links.
If you run it in the post-install hook of your ubuntu package, then maybe.
That's fine, I can do that.
I'm running the script in the makefile now so the links end up compiled in the .deb. Pre-release debs available here: https://github.com/jwt27/build-gcc/actions/runs/38411143
If there are no further objections then I'll go ahead and merge this.
Yes, symlinks (either in a post-install hook or in an install target) are fine with me.
Thanks. Merging now.
This patch changes the default
TARGET
for the djgpp toolchain fromi586-pc-msdosdjgpp
toi686-pc-msdosdjgpp
, for consistency with other 32-bit x86 toolchains. If you use this script, let me know if you think this is a good idea or not.If no one responds, I will merge this when the next version of gcc is released.