Opened 9 years ago

Closed 6 years ago

Last modified 6 years ago

#299 closed proposed feature (fixed)

Adding support to an ARM processor

Reported by: julien.puydt@… Owned by: hannes
Priority: minor Milestone: 3-1-3 and higher
Component: dontKnow Version: 3-1-1
Keywords: Cc:

Description

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)

Attachments (3)

build-singular.log (1.6 KB) - added by julien.puydt@… 9 years ago.
Log from the failed build
build-singular.2.log (17.4 KB) - added by anonymous 9 years ago.
singular.diff (2.4 KB) - added by julien.puydt@… 9 years ago.
Patch to directly detect ELF support

Download all attachments as: .zip

Change History (17)

Changed 9 years ago by julien.puydt@…

Log from the failed build

Changed 9 years ago by anonymous

comment:1 Changed 9 years ago by 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.

comment:2 Changed 9 years ago by 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*.

Changed 9 years ago by julien.puydt@…

Patch to directly detect ELF support

comment:3 Changed 9 years ago by 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!

comment:4 follow-up: Changed 9 years ago by 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).....

comment:5 in reply to: ↑ 4 Changed 9 years ago by 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?

comment:6 Changed 9 years ago by hannes

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

comment:7 Changed 9 years ago by hannes

  • Resolution set to fixed
  • Status changed from new to closed

comment:8 Changed 9 years ago by julien.puydt@…

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

comment:9 Changed 8 years ago by julien.puydt@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

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 :-(

comment:10 Changed 8 years ago by 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.

comment:11 Changed 8 years ago by 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?

comment:12 Changed 8 years ago by hannes

  • Owner changed from somebody to hannes
  • Status changed from reopened to new

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.

comment:13 Changed 6 years ago by hannes

  • Resolution set to fixed
  • Status changed from new to closed

comment:14 Changed 6 years ago by hannes

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

Note: See TracTickets for help on using tickets.