Adding support to an ARM processor

[julien.puydt@…]

I tried to compile sage on my ARM-based notebook, and failed with the attached build log.

This is part of : trac.sagemath.org/sage_trac/ticket/10285
(I had to leave h t t p : / / out because it makes my report look too spamish)

[julien.puydt@…]

Log from the failed build

[julien.puydt@…]

Ok, here is another log where I forced the configure script to recognize my setup as "ARM-Linux" instead of "unknown". That still doesn't make the build ok, but it shows the real errors at least.

I don't want to sound too harsh, but I don't think it's really reasonable to have a configure script which tests for a closed list of configurations. The idea of having a configure script is to have a short list of must-have properties, so that when a system, whatever it is, meets those, then the sources build.

The impression I have is that the build system is fighting teeth and claws against me, instead of just doing its best to help.

[anonymous]

Sigh... it seems kernel/mod_raw.cc doesn't build a few things.

Why? Well, since configure got out of its way to try to put my system in a nice niche, then mod_raw.cc has to go out of its way to decide if said niche does have the ELF feature.

Solution : have the configure script detect if ELF is supported, and leave only the #ifdef for that in kernel/mod_raw.cc.

That still makes two good news :
(1) when I force mod_raw.cc to admit I have an ELF system, the build is a success ;
(2) I'm ready to work on a correct patch to make configure check for ELF directly, and remove the then-unneeded tests from mod_raw.cc.

I'm sorry if I sound harsh, but I'm quite used to using autotools, so the way they are used in singular just *aches*.

[julien.puydt@…]

Patch to directly detect ELF support

[anonymous]

That was even easier than I thought -- and the same trick of using #if defined(ELF) was used elsewhere in the code! I have attached a patch against current trunk.

With that patch, I only have to put:

ac_cv_singuname=ARM-Linux

in config.cache before running configure, and the configure script just doesn't realize it's on a so-terrible 'unknown' system... and singular builds!

[hannes]

Thanks for the patch, the the systems uname is also used at other places:
for example, please try combinations of HAVE_MULT_MOD/HAVE_GENERIC_ADD/HAVE_MULT_MOD/HAVE_DIV_MOD:
all variants shlould work everythere (i.e. autoconf cannot figure out any difference),
but the running times depend on the properties of the cpu (Tst/Old?/std1.tst may be used to test).

One additional remark to autotools: very nice tool, but there are thing it cannot figure out:
see above, or, for example: mmap is available on Mac OsX, and works a few times, but fails
if called some hundred times.....or times: available and working on MacOsX and Windows(Cygwin),
but returning nonsens (OsX) or 0 (some Windows versions).....

[julien.puydt@…]

Replying to hannes:

Thanks for the patch, the the systems uname is also used at other places:
for example, please try combinations of HAVE_MULT_MOD/HAVE_GENERIC_ADD/HAVE_MULT_MOD/HAVE_DIV_MOD:
all variants shlould work everythere (i.e. autoconf cannot figure out any difference),
but the running times depend on the properties of the cpu (Tst/Old?/std1.tst may be used to test).

One additional remark to autotools: very nice tool, but there are thing it cannot figure out:
see above, or, for example: mmap is available on Mac OsX, and works a few times, but fails
if called some hundred times.....or times: available and working on MacOsX and Windows(Cygwin),
but returning nonsens (OsX) or 0 (some Windows versions).....

The general philosophy is the following :

• the code should only use #ifdef HAS_FOO HAS_BAR, HAS_BAZ -- it shouldn't depend on the platform at all ;
• the configure script should decide if the particular target has feature FOO, feature BAR or feature BAZ -- and depending on what it finds, decide what to build -- or even *if* to build.

Instead of just breaking the compilation because the platform is unknown, the configure script should just do as good as possible -- in fact, the AC_MSG_ERROR about the unknown platform should probably become an AC_MSG_WARNING...

I'll try to have a look at the other #if defined(platform) that still lurk in the code, but if I can get it to compile, that will already be an improvement.

Did you apply the patch I gave to trunk? Will it appear in a forthcoming release soon?

[hannes]

see commit 13672, 13673: allow unknown architecures (with warning)

[julien.puydt@…]

Wonderful ; looks nice! When will 3-1-3 get out?

[julien.puydt@…]

I just checked the Singular-3-1-3-3 source files on my ARM box ; the result is that the build breaks for at least the following reasons :

• first, one of the makefiles adds "/unknown" to the paths I have given for libdir, includedir, etc... which breaks the build ;
• most objects are compiled without the "-fPIC" flag, so can't be put in a shared library ;
• last, in Singular/makefile for the install-libsingular target, the last linking step fails because of a lacking "-shared" switch (and even with it, the previous point is a problem).

I'm still trying to figure out exactly what goes wrong where, and I'll try to provide a patch, but if something more knowledgeable could see where the crux of the matter is just by that listing of symptoms, that will probably be faster.

I'm sorry I didn't retest sooner :-(

[anonymous]

In Singular/Makefile?.in, I changed:

#LIBSINGULAR_FLAGS = -export-dynamic 
LIBSINGULAR_LD = $(CXX)

to:

LIBSINGULAR_FLAGS = -shared
LIBSINGULAR_LD = $(CXX)

that made it build for sage (sage forces the -fPIC for the rest of the problem).

In fact, I'm convinced that the main issue with singular is the way the build is handled :

• a configure script tries to set things right ;
• after which the Makefiles break everything. They have lists of if(arch is ...), where they set things forcefully -- and if you're on an arch which isn't in that list, they put in bad default values.

Testing for arch-specific things to do should be done in the configure script only, and even there kept to a strict minimum.

Makefiles are there to make, not to configure.

[julien.puydt@…]

I gave a try to your git repository ; the terrible singuname.sh is still there, but there configure scripts have been worked on, and they rock! That repository definitely is more portable, and has as far as I can tell full support for ARM -- at least I had no problem compiling it, contrary to 3-1-3-3.

When will you release a version with that work?

[hannes]

Thanks for the arm patches.

See ​https://github.com/Singular/Sources/wiki/How-To-Contribute
The new branch "spielwiese" still does not pass our test suite
and there are still some things to be decided (directory layout, etc.).
And: while most of the interface is stable, some parts (which are used by sage)
changed: the clueing code must be revised/changed.
So a date is not fixed, and sage integration will take even longer.

[hannes]

fixed completely in spielwise (Singular 4-0-0), partially in 3-1-6/3-1-7