Re: Compiling the GNU ada compiler on a new platform
22.08.2009 02:16, Joe Buck kirjoitti: On Fri, Aug 21, 2009 at 03:40:57PM -0700, Paul Smedley wrote: I'm wanting to update the GNU ADA compiler for OS/2... I'm currently building GCC 4.3.x and 4.4.x on OS/2 (C/C++/fortran) but for ADA configure complains about not finding gnat. The problem is that the only gnat compiled for OS/2 was years ago using a different toolchain so it's not suitable. I assume that at some point in time, ada didn't depend on an existing gnat, so if I could find that version, I could compile a version of gnat to get me started?? Otherwise it's a bit chicken and egg :( The alternative solution is to build gnat as a cross-compiler, so it runs on (say) GNU/Linux and produces gnat code for OS/2. I haven't done that for gnat, only for other languages, but perhaps someone can advise you on how to set that up. Then you can use the cross-compiler to build a native compiler. I tried for some last versions cross-native build for DJGPP under Linux. Not much success for Ada. About native build: If there was some port sometimes long ago, then one could do all in several steps: build for example gcc-3.something including Ada using existing port, after that move to some newer version. I do not thing that there will be many steps required. For DJGPP I initially used used some port I found somewhere when built first version which included Ada support. Also: when building Linux-to-DJGPP cross-compiler (C, C++, Fortran, Objective C, Objective C++, Ada) I had to bootstrap at first native compiler for Linux (C and Ada only) or otherwise I have got problems building libada with native system compiler under Linux. Andris
Re: Error making a cross-compiler
David Fernandez kirjoitti: Hi there, I don't know if this is the right place for questions about the gcc build/install process. Let me know the right place otherwise. I'm trying to compile a cross-compiler from gcc-4.0.2 sources. It is configured this way: /usr/src/redhat/BUILD/gcc-4.0.2/configure --prefix=/usr/local/gcc-msdos --with-local-prefix=/usr/local/gcc-msdos --enable-checking=release --disable-threads --disable-libunwind-exceptions --enable-target-optspace --with-system-zlib --enable-__cxa_atexit --enable-languages=c,c++ --host=i386-redhat-linux --target=i686-pc-msdosdjgpp I have source RPMS of GCC-4.0.2 cross-compiler for DJGPP target togethere with ones of needed tools at http://ap1.pp.fi/djgpp/gcc/cross-compiler/index.html Tested on Fedora Core 4, but all perhaps should be OK also for other versions Andris
Re: GCC 4.8.0 does not compile for DJGPP
On 03/24/2013 07:51 PM, Fabrizio Gennari wrote: Il 24/03/2013 18:48, Fabrizio Gennari ha scritto: Il 23/03/2013 18:07, DJ Delorie ha scritto: The DJGPP build of gcc 4.8.0 was just uploaded, it might have some patches that haven't been committed upstream yet. Thank you DJ. I downloaded beta/v2gnu/gcc480s.zip from a mirror, and that compiles. And, indeed, the file gcc/config/i386/djgpp.h is different from the one in the official gcc-4.8.0.tar.bz2, meaning that some DJGPP patches are not present upstream. I guess it would be easier to see changes from: ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-4.8.0/djcross-gcc-4.8.0.tar.bz2 Its much smaller and contains only DJGPP related patches and scripts for using them. Changes from subdirectory diff2 in that archive are not needed for building cross-compiler only ones from subdirectory diffs. One may also try SRPM from the same place: ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-4.8.0/djcross-gcc-4.8.0-1ap.src.rpm Forgot to say that I also had to apply this patch --- ../gcc-4.8.0/libbacktrace/alloc.c2013-01-14 19:17:30.0 +0100 +++ ../gcc-4.80/libbacktrace/alloc.c2013-03-24 18:07:11.995891959 +0100 @@ -34,6 +34,7 @@ #include #include +#include #include "backtrace.h" #include "internal.h" This fix is required for current stable version (2.03) of DJGPP only. I only built for development version 2.0.4 (really recent once from CVS) which does not need this fix. Native build for DJGPP v2.03 fails due to DJGPP own problems and was left out for that reason and because of DJGPP v2.03 is already too old. Andris
Re: GCC 4.8.0 does not compile for DJGPP
On 03/25/2013 08:02 PM, Fabrizio Gennari wrote: Il 25/03/2013 00:00, Ian Lance Taylor ha scritto: What failed without that patch? In file included from ../../../gcc-4.80/libbacktrace/alloc.c:39:0: ../../../gcc-4.80/libbacktrace/internal.h:141:11: error: unknown type name ‘off_t’ off_t offset, size_t size, ^ make[3]: *** [alloc.lo] Errore 1 make[3]: uscita dalla directory "/home/fabrizio/dev/djgpp/cross/gcc2/i586-pc-msdosdjgpp/libbacktrace" internal.h (included by libbacktrace/alloc.c) uses off_t, which is not declared unless sys/types.h is included BTW, I am using beta/v2/djcrx204.zip for basic DJGPP headers and libraries, so no version 2.03 involved That's also an ancient version. I have newer CVS version build at: http://ap1.pp.fi/djgpp/djdev/djgpp/20130306/ (2013-Mar-06 CVS version, built in Linux using cross-compiler). With version from beta/v2/djcrx204.zip one would run into next trouble when building libstdc++-v3: both time.h and xmintrin86.h included and time.h contains incompatible _rtdsc(). Fixed in later version by using gcc own _rdtsc with gcc-4.8+. Andris
Re: gcc-4.9: How to generate Makefile.in from a modified Makefile.am?
On 03/26/2014 05:22 PM, Jonathan Wakely wrote: On 26 March 2014 15:20, Andreas Schwab wrote: Svante Signell writes: autoconf 2.69: You must use autoconf 2.65, exactly. And as it sounds like you're been messing the tree up, undo all your local changes to the files that got touched by the wrong versions of autoconf and automake, then start again with the right versions. Because automake calls "autoconf" the right version must be in your PATH, it's not good enough to have "autoconf2.65" installed because automake won't invoke that version, it will use "autoconf" from your PATH. It is not so difficult to configure required versions of autoconf and automake to install in some arbitrary prefix (like /opt/foobar) and after that add /opt/foobar/bin to begin of the PATH. I'm regularly using this approach when building modified versions of gcc Andris
Re: GCC 4.7.3 Status Report (2012-09-20)
On 09/20/2012 06:33 PM, Jakub Jelinek wrote: Status == The GCC 4.7.2 release tarballs have been created and were uploaded to ftp.gnu.org. The GCC 4.7 branch is thus open again for regression and documentation fixes. Shouldn't be change http://gcc.gnu.org/viewcvs/trunk/gcc/gcc.c?r1=188102&r2=189918 Invoke GCC_DRIVER_HOST_INITIALIZATION after diagnostic_initialize * gcc.c (main): Move GCC_DRIVER_HOST_INITIALIZATION after diagnostic_initialize. backported to gcc-4.7 branch? Andris
Re: Deprecate i386 for GCC 4.8?
On 12/12/2012 11:07 PM, David Brown wrote: On 12/12/12 20:54, Robert Dewar wrote: On 12/12/2012 2:52 PM, Steven Bosscher wrote: And as usual: If you use an almost 30 years old architecture, why would you need the latest-and-greatest compiler technology? Seriously... Well the embedded folk often end up with precisely this dichotomy :-) True enough. But if no sign of 386 embedded chips, then reasonable to deprecate I agree. I believe it has been a very long time since any manufacturers made a pure 386 chip. While I've never used x86 devices in any of my embedded systems, I believe there are two main classes of x86 embedded systems - those that use DOS (these still exist!), and those that aim to be a small PC with more modern x86 OS's. For the DOS systems, gcc does not matter, because it is not used - It is used (http://www.delorie.com/djgpp/). However 386 is not really supported any more for DJGPP for rather long time. I do not have corresponding hardware to test on 386 already for a long time so I did not do any testing on 386 when I built recent GCC versions for DJGPP for DJ FTP server (last is gcc-4.7.2). As far as I remember read in mailing list 386 support no more work (at least C++ standard library). So I guess deprecating 386 could be not too large loss. compilers like OpenWatcom are far more common (ref. the FreeDOS website). And for people looking for "embedded PC's", the processor is always going to be a lot more modern than the 386 - otherwise they are not going to be able to run any current OS. Andris
Re: GCC 4.3 target deprecation proposals (about DJGPP)
Ben Elliston wrote: On Wed, 2008-01-23 at 12:02 -0500, DJ Delorie wrote: DJGPP, Please don't deprecate this. It's actively used, but the test harness doesn't run under DJGPP so testing it is difficult. I don't think we've *ever* run the testsuite for it. You can't cross-test, with DejaGnu running elsewhere? Theoretically it maybe could possibly be done, but the main problem is perhaps available manpower. I released DJGPP packages of GCC for long time up to version 4.2.2 (native compiler and for last versions also Linux to DJGPP cross-compiler RPM packages). I have also tried to build 4.3 snapshots as native compiler for DJGPP, but run into trouble with broken DJGPP port of BASH (latest we have is bash-2.0.5b), which prevented build to work for libstdc++-v3. I tried to fix it, but there were still problems. I don't know when I'll have time to fix them. Additionally there is rather large set of patches I need to apply for building GCC for DJGPP. I haven't had time get them in. Andris
Re: insn-attrtab.c long time to compile..
Jay wrote: 4.2.3 insn-attrtab.c takes "a long time" to compile on djgpp (build=host=target=i586-pc-msdosdjgpp, bootstrapping from 4.2.3) with the default -g -O2. It did not take "forever" to build it for me, but it takas some time (for the mentioned target). For DJGPP I had similar problems with gcc-4.3.0 due to O(n) behaviour of DJGPP-s v-2.04 free(), which I solved by using nmalloc() instead. One hint however: Make sure that the stack size set by stubify.exe is big enough. 1024Kb is OK. The default 512K is not. Andris
[Fwd: Libiberty problem in gcc-4.3 snapshots]
Original Message
Subject: Libiberty problem in gcc-4.3 snapshots
Date: Sun, 25 Nov 2007 17:14:47 -0500
From: Andris Pavenis <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Tried to build gcc-4.3-20071123 for DJGPP (native build). Run into a following
libiberty related
problem problem:
vasprintf() was not found when building gcc stage 1.
vasprintf() should be provided by libiberty as DJGPP does not have own.
Inspecting libiberty
Makefile and present object files however showed that none of procedures that
are missing in DJGPP
were included in built libiberty.a:
LIBOBJS =
For GCC-4.2.2 I had in libiberty Makefile:
LIBOBJS = ${LIBOBJDIR}./asprintf$U.o ${LIBOBJDIR}./mempcpy$U.o
${LIBOBJDIR}./mkstemps$U.o
${LIBOBJDIR}./sigsetmask$U.o ${LIBOBJDIR}./strndup$U.o
${LIBOBJDIR}./strverscmp$U.o
${LIBOBJDIR}./vasprintf$U.o
and as result no such problem.
As the difference between Makefile.ac versions contains DJGPP related stuff not
from me (see
attachment) , I'm sending this message at first to DJGPP related list
Andris
--- configure.ac.4.2.2 2007-11-25 15:59:52 +
+++ configure.ac 2007-07-17 17:52:28 +
@@ -109,30 +109,32 @@
AC_CHECK_TOOL(AR, ar)
AC_CHECK_TOOL(RANLIB, ranlib, :)
+dnl When switching to automake, replace the following with AM_ENABLE_MULTILIB.
+# Add --enable-multilib to configure.
+# Default to --enable-multilib
+AC_ARG_ENABLE(multilib,
+[ --enable-multilib build many library versions (default)],
+[case "$enableval" in
+ yes) multilib=yes ;;
+ no) multilib=no ;;
+ *) AC_MSG_ERROR([bad value $enableval for multilib option]) ;;
+ esac],
+ [multilib=yes])
+
+# Even if the default multilib is not a cross compilation,
+# it may be that some of the other multilibs are.
+if test $cross_compiling = no && test $multilib = yes \
+ && test "x${with_multisubdir}" != x ; then
+ cross_compiling=maybe
+fi
+
GCC_NO_EXECUTABLES
AC_PROG_CC
AC_PROG_CPP_WERROR
-# Warn C++ incompatibilities if supported.
-AC_CACHE_CHECK(
- [whether ${CC} accepts -Wc++-compat],
- [ac_cv_prog_cc_w_cxx_compat],
- [save_CFLAGS="$CFLAGS"
- CFLAGS="-Wc++-compat"
- AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])],
-[ac_cv_prog_cc_w_cxx_compat=yes],
-[ac_cv_prog_cc_w_cxx_compat=no])
- CFLAGS="$save_CFLAGS"
- ])
-
-
-if test x$GCC = xyes; then
- ac_libiberty_warn_cflags='-W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes'
-fi
-if test $ac_cv_prog_cc_w_cxx_compat = yes ; then
- ac_libiberty_warn_cflags="${ac_libiberty_warn_cflags} -Wc++-compat"
-fi
-AC_SUBST(ac_libiberty_warn_cflags)
+ACX_PROG_CC_WARNING_OPTS([-W -Wall -Wwrite-strings -Wc++-compat \
+ -Wstrict-prototypes], [ac_libiberty_warn_cflags])
+ACX_PROG_CC_WARNING_ALMOST_PEDANTIC([], [ac_libiberty_warn_cflags])
AC_PROG_CC_C_O
# autoconf is lame and doesn't give us any substitution variable for this.
@@ -545,6 +547,23 @@
setobjs=yes
;;
+ *-*-msdosdjgpp)
+for f in atexit basename bcmp bcopy bsearch bzero calloc clock ffs \
+ getcwd getpagesize getrusage gettimeofday \
+ index insque memchr memcmp memcpy memmove memset psignal \
+ putenv random rename rindex sbrk setenv stpcpy strcasecmp \
+ strchr strdup strerror strncasecmp strrchr strstr strtod \
+ strtol strtoul sysconf times tmpnam vfprintf vprintf \
+ vsprintf waitpid
+do
+ n=HAVE_`echo $f | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`
+ AC_DEFINE_UNQUOTED($n)
+done
+
+
+setobjs=yes
+;;
+
esac
fi
