[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New compiler tools release: cris-dist-1.13



There's a new release of the compiler tools available as a
source SRPM, a binary RPM and sources as gzipped tar-balls.
The binary RPM is suitable for i386-type host machines
(i[3456]86-pc-linux-gnu) running Red Hat Linux release 6.2
to 7.1.  For Debian systems there has been reports of successful
conversion of the RPM to .deb using the "alien" converter.  The
SRPM and RPM are available at
<URL:ftp://ftp.axis.se/pub/axis/tools/cris/compiler-kit/cris-dist-1.13-1.src.rpm>
and
<URL:ftp://ftp.axis.se/pub/axis/tools/cris/compiler-kit/cris-dist-1.13-1.i386.rpm>.

The corresponding source is in four parts at
<URL:ftp://ftp.axis.se/pub/axis/tools/cris/compiler-kit/cris-dist-1.13.tar.gz>
<URL:ftp://ftp.axis.se/pub/axis/tools/cris/compiler-kit/cris-dist-elinux-headers-1.13.tar.gz>
<URL:ftp://ftp.axis.se/pub/axis/tools/cris/compiler-kit/cris-dist-linux-headers-1.13.tar.gz>
<URL:ftp://ftp.axis.se/pub/axis/tools/cris/compiler-kit/cris-dist-glibc-1.13.tar.gz>
If you need to install from these sources, first unpack the
cris-dist-1.13.tar.gz tar-ball, then "cd cris-dist-1.13" and
unpack the latter three tar-balls in that directory.  Further
installation instructions are available in the file README.

Most differences to the previous public release, cris-dist-1.11,
and some implications for devboard and elinux development can be
summarised as:

* There is now support for dynamic linking for Linux/CRIS
  (-mlinux).  This works just as for a standard GNU/Linux
  system, though all objects in a dynamic library must be
  compiled with -fPIC or -fpic.

* A port of recent glibc CVS (about 2.2.3, early April) to
  Linux/CRIS is now dropped in and installed with a standard
  installation, reachable with the -mlinux option.

* Support for posix threads, pthreads, is compiled in for
  Linux/CRIS.  Use the "-pthread" compiler option when compiling
  threaded applications.

* Users of the devboard_lx-R1_0_0 package can use this release
  as a drop-in replacement for cris-dist-1.11.  Note that this
  will not take advantage of dynamic linking and glibc; a newer
  devboard_lx-release will do that.  Users of devboard-R1_0_2
  can not use cris-dist-1.13 as-is, but will want to wait for a
  new devboard-release.

* There's no glibc installed for elinux any more (on Etrax 100;
  as opposed to Linux/CRIS on Etrax 100 LX).  The new glibc does
  not have support for elinux.

* GNU make is now a prerequisite to compile from source, while
  previously a POSIX compliant make-program may have been
  sufficient.  Note that you need GNU make 3.79 or newer to
  compile glibc.

Some bugs that have been fixed:

* Installation:

  - A trailing "/" on the directory for the binaries would cause
    problems if that directory was a parent directory of the
    libraries directory.  For example, "/usr/local/cris/" and
    "/usr/local/cris/lib/gcc-lib/cris/2.96".

  - A previous partial (aborted) installation was not detected
    correctly, but caused the new installation to fail.

  - Build problems building from source with
    "CC=gcc -O2 -static" on Solaris.  (Note that installing
    glibc on Solaris does not work; this was without glibc.)

* Linker:

  - The linker would abort rather than emit an error message when
    doing relocatable linking "-r" with mismatching object
    formats for input and output files (like not specifying the
    correct non-default format when linking elinux a.out files).

  - For elinux, linking dynamically with a library called e.g. libx.a
    and specified as just "libx.a" on the command line could cause the
    library to not be found at runtime.

* GCC:

  - Incorrect code would be generated when compiling the package
    OpenSSL 0.9.6 (local to using the DSA crypto, which is not
    enabled by default in that package).

  - GCC would abort when compiling the Linux kernel with IrDA
    enabled.

  - Adding a constant in the range -32768 .. -1 to a 64-bit
    number (long long) would give incorrect code.

  - Use of __builtin_expect on large programs would give
    spurious failures.

  - Some external (ELF, non-Linux) tool programs expected the
    linker-generated symbol __Stext to be present even though it
    wasn't referred to in the compiled program.  Furthermore, if
    it was defined, it had the wrong value.

brgds, H-P