#299 closed proposed feature (fixed)
Adding support to an ARM processor
Reported by: | 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)
Change History (17)
Changed 12 years ago by
Attachment: | build-singular.log added |
---|
Changed 12 years ago by
Attachment: | build-singular.2.log added |
---|
comment:1 Changed 12 years ago by
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 12 years ago by
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*.
comment:3 Changed 12 years ago by
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: 5 Changed 12 years ago by
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 Changed 12 years ago by
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 12 years ago by
see commit 13672, 13673: allow unknown architecures (with warning)
comment:7 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:9 Changed 11 years ago by
Resolution: | fixed |
---|---|
Status: | closed → 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 11 years ago by
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 11 years ago by
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 11 years ago by
Owner: | changed from somebody to hannes |
---|---|
Status: | reopened → 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 9 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:14 Changed 9 years ago by
fixed completely in spielwise (Singular 4-0-0), partially in 3-1-6/3-1-7
Log from the failed build