Re: mips64el in testing

Aurelien Jarno <[email protected]> Wed, 25 May 2016 15:14:26 +0200

Newsgroups	gmane.linux.debian.ports.mips
Message-ID	<[email protected]>

On 2016-05-24 18:07, Ed Swierk wrote:
> On Saturday, March 5, 2016 at 4:30:03 PM UTC-8, Aurelien Jarno wrote:
> > The port itself is in a good shape, that said we are still lacking DSAed
> > build daemons (and thus autosigning). It is built mostly on 4 machines,
> > 3 hosted in China by Aron Xu and 1 hosted in Germany by Andi Barth. In
> > addition the mipsel build daemons also build mips64el packages as the
> > lowest priority. The porterbox etler.d.o has both mipsel and mips64el
> > chroots. We are waiting for Octeon III hardware sponsored by Imagination
> > Technologies that will be used for the 3 MIPS ports (they are able to
> > boot on both endianness). That is the last blocker on our side and that
> > is why we haven't requested to get mips64el into testing yet.
> 
> What is the current status of getting mips64el into stretch? As a
> relative Debian newbie, I can't tell from
> https://release.debian.org/stretch/arch_qualify.html exactly what's
> missing.

The status hasn't changed that much. We are still waiting for new
buildds from Imagination Technologies [1]. A few of them have arrived,
but not enough to build the mips64el port fully, so we still rely on
non-official build daemons, provided by Aron Xu.

We are also have toolchain issues preventing some packages to build:

- Lua doesn't work due to a compiler issue, causing the GNU libc to be
  miscompiled. A bug has been opened upstream, but without any progress
  so far [2]. Lua is needed as a build-dependency of many packages.
- ecj doesn't build to a bug in GIJ, while it builds fine with OpenJDK
  7 or OpenJDK 8. Given ecj has been imported from the original imgtec
  mips64el archive, and hasn't been rebuilt since them, it blocks the
  creation of the testing suite for mips64el. I have attached a small
  testcase to show the issue.

Any help to solve the above issues would be really welcome.

On the positive side, note that we now have debian-installer images
available to install unstable [3]. They have only been lightly tested
though.

Aurelien

[1] https://bits.debian.org/2016/05/imagination-64-bit-mips-cpus.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71155 
[3] https://d-i.debian.org/daily-images/mips64el/daily/

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
[email protected]                 http://www.aurel32.net

testcase.sh (application/x-sh, 727 B)

#!/bin/sh

# Note: this testcase relies on the following packages being installed:
# gcj-5-jre-headless libecj-java openjdk-8-jre-headless:mips64el

ARCH=$(dpkg-architecture -qDEB_HOST_ARCH)

echo
echo "Trying to compile with OpenJDK 8..."
CLASSPATH=/usr/share/java/eclipse-ecj.jar /usr/lib/jvm/java-8-openjdk-$ARCH/jre/bin/java org.eclipse.jdt.internal.compiler.batch.Main IntegerCache.java

echo
echo "Trying to compile with GIJ 5..."
CLASSPATH=/usr/share/java/eclipse-ecj.jar /usr/bin/gij-5 org.eclipse.jdt.internal.compiler.batch.Main IntegerCache.java
echo

echo
echo "Trying to compile with GIJ 6..."
CLASSPATH=/usr/share/java/eclipse-ecj.jar /usr/bin/gij-6 org.eclipse.jdt.internal.compiler.batch.Main IntegerCache.java

IntegerCache.java (text/x-java, 468 B)

package org.eclipse.jdt.internal.compiler.codegen;

public class IntegerCache {
	public int keyTable[];
	int elementSize;
	int t;
	int threshold2;
	int threshold3;
/**
 * Constructs a new, empty hashtable with the specified initial
 * capacity.
 * @param initialCapacity int
 *  the initial number of buckets
 */
public IntegerCache(int initialCapacity) {
	this.elementSize = 0;
	this.t = (int) (initialCapacity * 0.66);
	this.keyTable = new int[initialCapacity];
}
}

signature.asc (application/pgp-signature, 819 B)