jwt27 / build-gcc

Shell scripts to build various gcc cross-compilers (primarily djgpp)
https://jw.h4ck.me/debian/
GNU General Public License v3.0
41 stars 9 forks source link

Set default djgpp TARGET to i386-pc-msdosdjgpp. #1

Closed jwt27 closed 4 years ago

jwt27 commented 5 years ago

This patch changes the default TARGET for the djgpp toolchain from i586-pc-msdosdjgpp to i686-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.

stsp commented 5 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/

jwt27 commented 5 years ago

Interestingly, the djgpp packages for Arch (also maintained by Andris Pavenis) use target i686: https://aur.archlinux.org/packages/djgpp-gcc/

stsp commented 5 years ago

Interesting. It seems it was submitted there by @fstirlitz, so maybe he knows the answer to this question.

fstirlitz commented 5 years ago

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.)

stsp commented 5 years ago

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.

jwt27 commented 5 years ago

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.

stsp commented 5 years ago

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.

stsp commented 5 years ago

Of course a symlink can solve the problem. Use the name you like but create the compatibility symlink, and the problem solved.

fstirlitz commented 5 years ago

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.)

stsp commented 5 years ago

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.

jwt27 commented 4 years ago

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?

stsp commented 4 years ago

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.

jwt27 commented 4 years ago

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.

stsp commented 4 years ago

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.

jayschwa commented 4 years ago

I have no opinion on the name of the toolchain, but I do need the ability to target 386.

jwt27 commented 4 years ago

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.

stsp commented 4 years ago

If you run it in the post-install hook of your ubuntu package, then maybe.

jwt27 commented 4 years ago

That's fine, I can do that.

jwt27 commented 4 years ago

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.

stsp commented 4 years ago

Yes, symlinks (either in a post-install hook or in an install target) are fine with me.

jwt27 commented 4 years ago

Thanks. Merging now.