see https://help.github.com/articles/open-source-licensing

AFAIK your builds don't support threads, but there is a library called GNU pth that supports DOS (don't bother with FSU Pthreads, it's too old of an implementation, even though you can make it to compile). I'd like to see a build with pthreads support, so that std::thread would work.

It looks like short name binaries missed some of long name ones. size for example,
we have bin/i586-pc-msdosdjgpp-size, but have no i586-pc-msdosdjgpp/bin/size. So, I think it is better to link/copy them from long to short.

Hi there,

First of all, awesome project. This script really saves people a lot of time. 😃

The issue I'm reporting here is a minor one: by default, the script installs the cross-compiler and tools in /usr/local/djgpp/. However, on most systems, /usr/local/ is not writable for non-root users, so the script will have to be run with sudo privileges, unless an alternative DJGPP_PREFIX somewhere in the user's home folder is specified.

It might be helpful to clarify this in the README.md file.

Thanks and keep up the good work!

The problem is so well known, that I'm surprised it hasn't been fixed yet. You can compile anything:

gcc -std=c++1z -march=i386 -Ofast -g c.cpp -o c.exe
and you get a SIGILL in dosbox when you run the executable. If you disassemble the code, you get a plethora of cmov* instructions, which are from the i686 instruction set. Different optimization levels have no effect.

Recently [0], FreeDOS accepted some patches from Bart Oldeman to compile the FDKernel using gcc-ia16 [1][2]. So far, I'm only aware of people building this stuff as cross compilers of which you're particularly knowledgeable.

[0] PerditionC/fdkernel#25
[1] https://github.com/tkchia/gcc-ia16
[2] https://github.com/tkchia/build-ia16

So I tried to install this like specified, but it only installs the i586 version. I need the i686 version, and there are no instructions on how to do that.
There is an arch pkg build, but I can't get access to it because I am on fedora. Is there anything I could do?

Thank you.

Hi, thank you for these win32 cross-compilers. Makes it a lot easier to compile large projects, especially with new version of make.exe from MSYS to allow parallel building.

Your versions posted do not include DXE3. During compile it fails to find _dlsymresolver.

Thanks for your builds, and I look forward to using them full time on windows if this issue can be resolved.

setenv running in bash from the MSYS2 distribution provided with Git For Windows fails because of $0 being evaluated to /usr/bin/bash :

$ echo 'export DJDIR="$(cd "$(dirname "$0")"; pwd)"/i586-pc-msdosdjgpp ; echo $DJDIR' > test.sh
$ cat test.sh
export DJDIR="$(cd "$(dirname "$0")"; pwd)"/i586-pc-msdosdjgpp ; echo $DJDIR

$ ./test.sh
/h/devel/djgpp/i586-pc-msdosdjgpp

$ source ./test.sh
/usr/bin/i586-pc-msdosdjgpp

Using ${BASH_SOURCE[0]} instead of $0 fixes the problem.

Just noticed the script downloads and builds binutils version 2.24. I changed it to build the latest version (2.26) instead, and it seems to work fine as far as I can tell.
Any reason to prefer the old 2.24 version?

seems like the number of mirrors is dwindling :(

I built with ENABLED_LANGUAGES=c, which seems reasonable: C++ doesn't seem to be widely used in DJGPP. The trouble is that the build script tests the compiler by building a C++ program. A simple fix would be to change to just a C program; or, build a C program, and then, if g++ was built, a C++ program.

Is it possible? I can't find any C++ cross-compiler for DOS that can run a modern Windows system.

the following lines need to be changed that current makeinfo can process the file - otherwise the build will not finish (make returned error 1):

-@tab General: @tex press@@gnu.org @end tex
+@tab General:
+@tex press@@gnu.org
+@end tex
 @item Free Software Foundation
-@tab Orders:  @tex sales@@gnu.org @end tex
+@tab Orders:
+@tex sales@@gnu.org
+@end tex

Notes:

• this likely applies to the some of the more current versions, too (just checked 7.2.0 and it doesn't occurs there)
• the texinfo sources still generate a bunch of warnings (but no further errors)
• the changes should be integrated in the patch applied to gcc sources
• older versions of makeinfo should work with this, too - but I didn't checked
• normally makeinfo shouldn't be called at all as the generated info files are normally part of the release tarballs - it is therefore likely a good idea to check this and try if running touch on it on the correct part of the build fixes the invocation completely

First I have to say "well done"! This is an amazing package. I was able to use my almost 20 years GNU-makefiles; just add a $(DJ_PREFIX) ahead of gcc and build. Try that with an old Microslut VS project file today.

The problem I have with generating a .map-file in the final link-stage. Like I'm used to in MinGW:

f:/gv/djgpp/bin/i586-pc-msdosdjgpp-gcc -o curl.exe  -Wl,--print-map,--sort-common \
 <lots of .o-files here> ../lib/libcurl.a  <some .a files here>  > curl.map
Warning: input file is neither COFF nor stubbed COFF
rename of curl.000 to curl.exe failed.
The error was: File exists

AFAICR from the old DOS-days, I had to use the redir command. Like:

$(DJDIR)/bin/redir -o $*.map $(CC) -Wl,--print-map,--sort-common ...

I this needed here or what's up?

Hi,

thanks a lot for your efforts. I have not finished downloading the zips but I expect your script to work fine :)
The slow download that allows me to write these lines before I could really assess the script is exactly the reason I am writing them. I have not checked the license but I guess one is allowed to distribute the zip files. In that case I think it would make sense to mirror them here (e.g. in the release directory) to get a faster build time.

I like modules.

The readme says that the standard build assumes the installation will be performed on /usr/local/djgpp. It also mentions the DJGPP_PREFIX variable, but it's not clear if that variable is used only at build time, or if the prebuilt binaries also honor it.

What I really want to know is if I can just take a prebuilt release, unzip it in any directory of my choice, and run it from there. If affirmative, should I set any env variables?

Thanks!!

djcrx is no longer available at Andris Pavenis' site, http://ap1.pp.fi/djgpp/djdev/djgpp/20140421/.

Trying to build 5.2.0 on mingw-w64, the following error occurs while compiling fixincl.c:

make[2]: Entering directory '/home/JW/build-djgpp/build/djcross-gcc-5.2.0/djcross/fixincludes'
gcc -c -g -O2 -D__USE_MINGW_ACCESS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wno-overlength-strings -pedantic -Wno-long-long   -DHAVE_CONFIG_H -I. -I../../gnu/gcc-5.20/fixincludes -I../include -I../../gnu/gcc-5.20/fixincludes/../include ../../gnu/gcc-5.20/fixincludes/fixincl.c
../../gnu/gcc-5.20/fixincludes/fixincl.c:29:22: fatal error: sys/wait.h: No such file or directory
 #include <sys/wait.h>
                      ^
compilation terminated.
Makefile:76: recipe for target 'fixincl.o' failed
make[2]: *** [fixincl.o] Error 1
make[2]: Leaving directory '/home/JW/build-djgpp/build/djcross-gcc-5.2.0/djcross/fixincludes'
Makefile:3504: recipe for target 'all-fixincludes' failed
make[1]: *** [all-fixincludes] Error 2
make[1]: Leaving directory '/home/JW/build-djgpp/build/djcross-gcc-5.2.0/djcross'
Makefile:876: recipe for target 'all' failed
make: *** [all] Error 2

This is probably not an issue with the build-djgpp script per se, most likely with mingw-w64, but I'm asking here since I wouldn't know where else to post it. I can find the missing file in /usr/include/sys, but adding /usr/include to C_INCLUDE_PATH causes even more errors.
How can I resolve this?

RE: FFMPEG_VERSION="4.4"
DJGPP Cross Compiler 12.2.0
link

"DJGPP Cross Compiler 12.2.0 Fails to Recognize Parameters in FFmpeg Source Code"
Hi,
I am using the DJGPP cross compiler 12.2.0, to build the FFmpeg source code, and it's failing to recognize certain parameters and the script I used to download and build FFmpeg source code follows:

`
#!/usr/bin/env bash

Path to DJGPP cross compiler

export DJGPP_PREFIX="/Users/owner/djcc"

export DJGPP_PREFIX=${DJGPP_PREFIX-/Users/owner/djcc}

export DJGPP_PREFIX2=${DJGPP_PREFIX2-/Users/owner/ffcc}

export

DJGPP_PREFIX3=${DJGPP_PREFIX3-/Users/owner/Documents/DOSBox/NET/watt}

system path

export PATH="$DJGPP_PREFIX/bin:$PATH"

Your cross compilation target

TARGET_ARCH="$DJGPP_PREFIX/bin/i586-pc-msdosdjgpp"

set C_INCLUDE_PATH environment variable

export C_INCLUDE_PATH="#DJGPP_PREFIX/i586-pc-msdosdjgpp/sys-include"

Download FFmpeg source code

FFMPEG_VERSION="4.4"
FFMPEG_ARCHIVE="https://ffmpeg.org/releases/ffmpeg-${FFMPEG_VERSION}.tar.gz"
FFMPEG_SOURCE_DIR="ffmpeg-${FFMPEG_VERSION}"

Download FFmpeg source

echo "Downloading FFmpeg source..."
wget -c "$FFMPEG_ARCHIVE" || exit 1
tar -xf "ffmpeg-${FFMPEG_VERSION}.tar.gz" || exit 1
cd "$FFMPEG_SOURCE_DIR" || exit 1

clean debri

gmake clean

Redirect both stdout and stderr to separate .err files

exec > >(tee -ia gcca.txt) 2> >(tee -ia gcc_err.err >&2)

Configure FFmpeg for cross-compilation

echo "Configuring FFmpeg for cross-compilation..."
./configure --enable-cross-compile
--prefix="$DJGPP_PREFIX2"
--target-os=ms-dos
--arch=i486
--cross-prefix="$TARGET_ARCH-"
--extra-cflags="-I$DJGPP_PREFIX/i586-pc-msdosdjgpp/sys-include -I$DJGPP_PREFIX/include -I$DJGPP_PREFIX3/inc2 -I$DJGPP_PREFIX3/inc3"
--extra-ldflags="-L$DJGPP_PREFIX/i586-pc-msdosdjgpp/lib -L$DJGPP_PREFIX/lib -L$DJGPP_PREFIX3/lib2 -L$DJGPP_PREFIX3/lib3"
--enable-debug
--disable-shared
--enable-static
--disable-doc
--disable-programs
|| exit 1

Compile a hello world program for testing

echo "Compiling hello world program for testing..."
cat > helloai.c <<EOF
#include <stdio.h>

int main() {
printf("Hello, world!\n");
return 0;
}
EOF

"$TARGET_ARCH-gcc" helloai.c -o helloai || exit 1

Compile FFmpeg

echo "Compiling FFmpeg..."
gmake CC="$DJGPP_PREFIX/bin/i586-pc-msdosdjgpp-gcc" || exit 1

gmake install || exit 1

echo "Compilation complete."
`

The following 36 issues surfaced compiling FFmpeg DJGPP 'make' cross compile, stating, "error: declaration for parameter 'XX_XXXX_XX_XXXX' but no such parameter:".

1. 'ff_log_net_error'

2. 'ff_socket'

3. 'ff_http_match_no_proxy'

4. 'ff_listen_connect'

5. 'ff_accept'

6. 'ff_listen'

7. 'ff_listen_bind'

8. 'ff_is_multicast_address'

9. 'ff_gai_strerror'

10)'ff_getnameinfo'

11. 'ff_freeaddrinfo'

12. 'ff_getaddrinfo'

13. 'sockaddr_union'

14. 'ff_network_sleep_interruptible'

15. 'ff_network_wait_fd_timeout'

16. 'ff_network_wait_fd'

17. 'ff_tls_deinit'

18. 'ff_tls_init'

19. 'ff_network_close'

20. 'ff_network_init'

21. 'ff_socket_nonblock'

22. 'ff_connect_parallel'

23. 'ff_log_net_error'

24. 'ff_socket'

25. 'ff_http_match_no_proxy'

26. 'ff_listen_connect'

27. 'ff_accept'

28. 'ff_listen'

29)'ff_listen_bind'

30. 'ff_is_multicast_address'

31. 'ff_gai_strerror'

32. 'ff_getnameinfo'

33. 'ff_freeaddrinfo'

34. 'ff_getaddrinfo'

35. 'sockaddr_union'

36. 'ff_network_sleep_interruptible'

The 'no such parameter', observed in 'libavformat/network.h', has now shown up in
'/libavformat/avio.c':

libavformat/avio.c:57:23: error: declaration for parameter 'options' but no such parameter

libavformat/avio.c:64:15: error: declaration for parameter 'ffurl_context_class' but no such parameter

Therefore, please explain the root cause, since it appears unique to DJGPP cross compiler . . .

`
// libavformat/avio.c
#include "libavutil/avstring.h"
#include "libavutil/dict.h"
#include "libavutil/opt.h"
#include "libavutil/time.h"
#include "libavutil/avassert.h"
#include "os_support.h"
#include "avformat.h"
#include "internal.h"
#if CONFIG_NETWORK
#include "network.h"
#endif
#include "url.h"

/** @name Logging context. /
/@{*/
static const char *urlcontext_to_name(void *ptr)
{
URLContext *h = (URLContext *)ptr;
if (h->prot)
return h->prot->name;
else
return "NULL";
}

static void *urlcontext_child_next(void *obj, void *prev)
{
URLContext *h = obj;
if (!prev && h->priv_data && h->prot->priv_data_class)
return h->priv_data;
return NULL;
}

#define OFFSET(x) offsetof(URLContext,x)
#define E AV_OPT_FLAG_ENCODING_PARAM
#define D AV_OPT_FLAG_DECODING_PARAM
static const AVOption options[] = { // L57:23
{"protocol_whitelist", "List of protocols that are allowed to be used", OFFSET(protocol_whitelist), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D },
{"protocol_blacklist", "List of protocols that are not allowed to be used", OFFSET(protocol_blacklist), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D },
{"rw_timeout", "Timeout for IO operations (in microseconds)", offsetof(URLContext, rw_timeout), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, AV_OPT_FLAG_ENCODING_PARAM | AV_OPT_FLAG_DECODING_PARAM },
{ NULL }
};

const AVClass ffurl_context_class = { // L64:15
.class_name = "URLContext",
.item_name = urlcontext_to_name,
.option = options,
.version = LIBAVUTIL_VERSION_INT,
.child_next = urlcontext_child_next,
#if FF_API_CHILD_CLASS_NEXT
.child_class_next = ff_urlcontext_child_class_next,
#endif
.child_class_iterate = ff_urlcontext_child_class_iterate,
};
/@}/
`

It seems like the declarations for the ffurl_context_class variable are consistent across multiple files in the libavformat library. The declarations specify that ffurl_context_class is defined externally in url.h, and then it's implemented in avio.c and referenced in aviobuf.c.

Given that the code compiles without issues using the macOS Monterey clang compiler, but encounters problems with the DJGPP cross compiler, giving credence to this post, THX!

It seems as though std::regex_search always returns false, and even the simplest regular expressions, such as [0-9]+ or even \d+, throw invalid character exceptions.

Please add support for DJGPP 2.0.5 and gcc 5.1.0.

./build-djgpp.sh 5.1.0 fails with:

In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/stl_algobase.h:64,
from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/char_traits.h:39,
from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/string:40,
from ../../gnu/gcc-5.10/gcc/system.h:201,
from ../../gnu/gcc-5.10/gcc/genpreds.c:24:
/usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/stl_pair.h:211:12: note: ‘struct std::pair<unsigned int, const char*>’ declared here
211 | struct pair
| ^~~~
make[2]: *** [Makefile:2422: build/genpreds.o] Error 1

It's finally here! :)

When i run the build script, it fails to download the DJGPP sources.

$ DJGPP_PREFIX=/home/ben/local/cross-djgpp ./build-djgpp.sh 7.2.0
Building version : 7.2.0
Download source files...
Download http://www.delorie.com/pub/djgpp/deleted/v2gnu/bnu229s.zip ...
Command : curl -f http://www.delorie.com/pub/djgpp/deleted/v2gnu/bnu229s.zip -L -o bnu229s.zip
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0
curl: (22) The requested URL returned error: 404 Not Found
rm: cannot remove 'bnu229s.zip': No such file or directory
Download http://www.delorie.com/pub/djgpp/deleted/v2gnu/bnu229s.zip failed.

FYI, i can still find that file on the DJGPP FTP site.

ftp://ftp.delorie.com/pub/djgpp/deleted/v2gnu/bnu229s.zip

Any suggestions? Thanks!

Hi!

Would it be possible to add objc to --enable-languages? I'd like to use it for CI for https://github.com/ObjFW/ObjFW.

Got that first trying to build 12.2.0 on Fedora 39 (beta):

config.status: creating t/wrap/automake-1.15
  GEN      bin/automake
  GEN      bin/aclocal
  GEN      t/ax/shell-no-trail-bslash
  GEN      t/ax/cc-no-c-o
  GEN      runtest
  GEN      doc/aclocal.1
  GEN      doc/automake.1
  GEN      lib/Automake/Config.pm
  GEN      doc/aclocal-1.15.1
help2man: can't get `--help' info from aclocal-1.15
Try `--no-discard-stderr' if option outputs to stderr
make: *** [Makefile:3687: doc/aclocal-1.15.1] Error 2

Now trying to install help2man that was not installed.

When attempting to compile a program, I get the following error:

$ ./gcc /path/to/lines.c -o /path/to/lines.exe
gcc: error trying to exec 'cc1': execvp: No such file or directory

This is on Mac OS X 10.10.3, with DJGPP 5.2.0 installed through the script. Am I missing a dependency or is there some other problem?

Strangely enough, the build script managed to make hello.exe and hello-cpp.exe which both work in DOS, though the regular Unix executables do not run. So that would indicate first and foremost that it's probably an environment problem on my end.

Edit: Ah, figured out why the hello world programs compiled. It seems to work fine when I invoke /usr/local/djgpp/bin/i586-pc-msdosdjgpp-gcc but not when I invoke /usr/local/djgpp/i586-pc-msdosdjgpp/bin/gcc. The latter is broken.

Hi Andrew, thanks for all your hard work with the cross-compiler packages over the years!

I have a project that runs a bit faster in 3.4.6 versus 5.10. Is it possible for you to make an updated release with GCC v3.4.6, DJ2.05 and DXE3? Been logging into a Linux VM to do it which is quite annoying.

Thanks a lot!

basically its a gcc problem but the djgpp doesn't build under a muslc environment (and therefore alpine linux)

I had to include this patch for it to build correctly

https://gitweb.gentoo.org/proj/gcc-patches.git/tree/12.1.0/musl/50_all_calloc_libgccjit.patch?id=caa4485a49e1064181e7ac2df2c5476fbb6e9cf5

side note- I also prefer to use clang even though I'm not in a freebsd environment. The build script overrides both CC and CXX even if I pass it in as an environment variable.

the patches below remove the freebsd check and just override the script to use clang and clang++, this is obviously not necessary but it conforms to my usecase

this is the patch set I use to get it to compile correctly under alpine:

/tmp/patches/djgcc/0001-Add-calloc-patch-to-build-script.patch

diff --git a/script/12.1.0 b/script/12.1.0
index 834e0c2..3d94495 100755
--- a/script/12.1.0
+++ b/script/12.1.0
@@ -36,14 +36,10 @@ AUTOMAKE_VERSION=1.15.1
 CC=gcc
 CXX=g++

-# use gmake under FreeBSD
-if [ `uname` = "FreeBSD" ]; then
-  MAKE=gmake
+# use clang on alpine
   CC=clang
   CXX=clang++
-else
   MAKE=make
-fi
 #CFLAGS="-O2 -g $CFLAGS -std=gnu11"

 export CC CXX CFLAGS MAKE
@@ -288,6 +284,10 @@ if uname|grep "^MINGW32" > /dev/null; then
   (cd $BUILDDIR && patch -p0 < $BUILDDIR/../../patch/patch-gcc12-mingw.txt) || exit 1
 fi

+cp /tmp/patches/djgcc/0002-Fix-attempt-to-use-poisoned-calloc-error-in-libgccji.patch $BUILDDIR/../../patch/
+echo "Patch GCC for alpine"
+(cd $BUILDDIR && patch -p0 < $BUILDDIR/../../patch/0002-Fix-attempt-to-use-poisoned-calloc-error-in-libgccji.patch) || exit 1
+
 # patch gnu/gcc-X.XX/gcc/doc/gcc.texi
 echo "Patch gcc/doc/gcc.texi"
 cd gnu/gcc-*/gcc/doc || exit 1

/tmp/patches/djgcc/0002-Fix-attempt-to-use-poisoned-calloc-error-in-libgccji.patch

https://git.alpinelinux.org/aports/plain/main/gcc/0042-Fix-attempt-to-use-poisoned-calloc-error-in-libgccji.patch
https://bugs.gentoo.org/828580
https://gcc.gnu.org/bugzillgnu-orig/gcc-12.10/show_bug.cgi?id=104799 (additional two hunks thrown in from here for 12)

From 72f32e3383129ad139df76d9a063fac9b03079b1 Mon Sep 17 00:00:00 2001
From: Alex McGrath <[email protected]>
Date: Wed, 13 Oct 2021 23:24:27 +0100
Subject: [PATCH] Fix attempt to use poisoned calloc error in libgccjit

This moves usages of pthread.h to above any usage of system.h as it
included #pragma GCC poison calloc
--- gnu-orig/gcc-12.10/gcc/jit/jit-playback.cc
+++ gnu/gcc-12.10/gcc/jit/jit-playback.cc
@@ -18,6 +18,8 @@ You should have received a copy of the GNU General Public License
 along with GCC; see the file COPYING3.  If not see
 <http://www.gnu.org/licenses/>.  */
 
+#include <pthread.h>
+
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
@@ -41,8 +43,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "diagnostic.h"
 #include "stmt.h"
 
-#include <pthread.h>
-
 #include "jit-playback.h"
 #include "jit-result.h"
 #include "jit-builtins.h"
--- gnu-orig/gcc-12.10/gcc/jit/jit-recording.cc
+++ gnu/gcc-12.10/gcc/jit/jit-recording.cc
@@ -18,6 +18,8 @@ You should have received a copy of the GNU General Public License
 along with GCC; see the file COPYING3.  If not see
 <http://www.gnu.org/licenses/>.  */
 
+#include <pthread.h>
+
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
@@ -25,8 +27,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "pretty-print.h"
 #include "toplev.h"
 
-#include <pthread.h>
-
 #include "jit-builtins.h"
 #include "jit-recording.h"
 #include "jit-playback.h"
--- gnu-orig/gcc-12.10/gcc/jit/libgccjit.cc
+++ gnu/gcc-12.10/gcc/jit/libgccjit.cc
@@ -18,13 +18,14 @@ You should have received a copy of the GNU General Public License
 along with GCC; see the file COPYING3.  If not see
 <http://www.gnu.org/licenses/>.  */
 
+#include <pthread.h>
+
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
 #include "timevar.h"
 #include "typed-splay-tree.h"
 #include "cppbuiltin.h"
-#include <pthread.h>
 
 #include "libgccjit.h"
 #include "jit-recording.h"
--- gnu-orig/gcc-12.10/libcc1/libcc1plugin.cc
+++ gnu/gcc-12.10/libcc1/libcc1plugin.cc
@@ -17,6 +17,7 @@
    along with GCC; see the file COPYING3.  If not see
    <http://www.gnu.org/licenses/>.  */
 
+#include <pthread.h>
 #include <cc1plugin-config.h>
 
 #undef PACKAGE_NAME
--- gnu-orig/gcc-12.10/libcc1/libcp1plugin.cc
+++ gnu/gcc-12.10/libcc1/libcp1plugin.cc
@@ -18,6 +18,7 @@
    along with GCC; see the file COPYING3.  If not see
    <http://www.gnu.org/licenses/>.  */
 
+#include <pthread.h>
 #include <cc1plugin-config.h>
 
 #undef PACKAGE_NAME

--- gnu-orig/gcc-12.10/gcc/cp/mapper-client.cc
+++ gnu/gcc-12.10/gcc/cp/mapper-client.cc
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3.  If not see
 #define INCLUDE_STRING
 #define INCLUDE_VECTOR
 #define INCLUDE_MAP
+#include <pthread.h>
 #include "system.h"
 
 #include "line-map.h"
--- gnu-orig/gcc-12.10/gcc/cp/module.cc
+++ gnu/gcc-12.10/gcc/cp/module.cc
@@ -204,6 +204,7 @@ Classes used:
 #include "config.h"
 #define INCLUDE_STRING
 #define INCLUDE_VECTOR
+#include <pthread.h>
 #include "system.h"
 #include "coretypes.h"
 #include "cp-tree.h"
--- gnu-orig/gcc-12.10/gcc/cp/mapper-resolver.cc
+++ gnu/gcc-12.10/gcc/cp/mapper-resolver.cc
@@ -25,6 +25,7 @@ along with GCC; see the file COPYING3.  If not see
 #define INCLUDE_VECTOR
 #define INCLUDE_ALGORITHM
 #define INCLUDE_MAP
+#include <pthread.h>
 #include "system.h"
 
 // We don't want or need to be aware of networking

/usr/bin/ccache i586-pc-msdosdjgpp-g++ -c src/builtins.cc -O0 -std=c++17 -Wall -Wextra -Werror -pedantic -ggdb -fms-extensions -DYSL_VERSION='"a73d29d96a432a528691399ea41dee5288de0f02"' -o bin/builtins.o
In file included from /usr/lib/gcc/i586-pc-msdosdjgpp/12.1.0/include/c++/cmath:47,
                 from /usr/lib/gcc/i586-pc-msdosdjgpp/12.1.0/include/c++/math.h:36,
                 from src/_components.hh:5,
                 from src/builtins.hh:4,
                 from src/builtins.cc:1:
/usr/lib/gcc/i586-pc-msdosdjgpp/12.1.0/include/c++/bits/std_abs.h:38:15: fatal error: stdlib.h: No such file or directory
   38 | #include_next <stdlib.h>
      |               ^~~~~~~~~~
compilation terminated.

code:

#include <map>

i ran the setenv script in the linux64 release before doing this

The current trunk version of build-djgpp does not allow to build GCC 4.8.5 under FreeBSD 9-stable.
This patch seems to make it possible.
I am submitting it here so that you can review it and integrate it, if you wish.

The patch brings the following changes:

• use gmake instead of make (that is: GNU Make instead of BSD Make);
• use the standard Clang compiler instead of the standard GCC (by "standard" I mean that they are both available in the base distribution of FreeBSD);
• remove the --verbose option from the patch invocations inside unpack-gcc.sh (BSD Patch does not support that option).

All the above only happens on FreeBSD systems (identified by the uname command).

I am not sure whether there are any ``cleaner'' ways to fix the problems. I can only tell that I could successfully build gcc 4.8.5 after applying that patch on my system:

$ uname
FreeBSD myhost 9.3-STABLE FreeBSD 9.3-STABLE #140 r293654M: Mon Jan 11 09:55:00 CET 2016     root@myhost:/usr/obj/usr/src/sys/GENERIC  i386

If you wish, I can prepare similar patches for the other scripts in the script directory. Before starting, I would like to hear if you have any remarks about this patch (code style etc).
I am of course open to your suggestions on this topic.

I am using the pre-built djgpp package (gcc 7.1.0, Linux Mint 32-bit).
As far as I can see, there is a complete, up-to-date standard library coming with it, just as I expected, but somehow I cannot access most of it.

test.cpp:

#include <string>
int main()
{
std::string s;
std::wstring w;
return 0;
}

Result of g++ test.cpp:

test.cpp: In function 'int main()':
test.cpp:5:6: error: 'wstring' is not a member of 'std'
 std::wstring w;
      ^~~~~~~
test.cpp:5:6: note: suggested alternative: 'isprint'
 std::wstring w;
      ^~~~~~~
      isprint

Running cc1plus -v shows that, as far as I can tell, all relevant include paths from the downloaded package are listed.

Is this a known issue? What am I doing wrong?

unpack-gcc.sh collects the output of cd in lines like these:

orig_dir_name=`(cd gnu && ls -d gcc* | sed 1q; )`

If CDPATH is set in the environment, this may well result in cd printing its new current directory (specifically, if CDPATH contains "."), which will then be collected by the backticks and added inappropriately to the output. Hence, unset CDPATH should be added to the top of the script.