daly / axiom

Axiom is a free, open source computer algebra system

Home Page:http://axiom.axiom-developer.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Problems compiling/linking on opensuse

1ykos opened this issue · comments

I tried to compile the release version and a fresh git clone but both fail with mostly the same error.
gcc --version
gcc (SUSE Linux) 6.2.1 20161209 [gcc-6-branch revision 243481]
Do you know where the error could originate from? I very much would like to help fix it but do not know where to start.
gcc -Wl,-T ../unixport/gcl.script -o raw_pre_gcl /home/usr/axiom/obj/opensuse/lib/cfuns-c.o /home/usr/axiom/obj/opensuse/lib/sockio-c.o -L. -Wl,-Map raw_pre_gcl_map -lpre_gcl -lm -ldl -lgmp -lreadline -lc -lgclp /home/usr/axiom/obj/opensuse/lib/libspad.a
./libpre_gcl.a(alloc.o): In function m__gmpz_add': alloc.c:(.text+0x1130): multiple definition of m__gmpz_add'
...
...
...
num_sfun.c:(.text+0xb150): undefined reference to number_zero_expt' ./libpre_gcl.a(num_sfun.o):num_sfun.c:(.text+0xb61e): more undefined references to number_zero_expt' follow
collect2: error: ld returned 1 exit status
make[4]: *** [makefile:172: raw_pre_gcl_map] Error 1
make[4]: Leaving directory '/home/usr/axiom/lsp/gcl-2.6.12/unixport'
make[3]: *** [makefile:78: unixport/saved_pre_gcl] Error 2
rm h/mcompdefs.h
make[3]: Leaving directory '/home/usr/axiom/lsp/gcl-2.6.12'
/bin/sh: line 5: unixport/saved_gcl: No such file or directory
make[2]: *** [Makefile:18: gcldir] Error 127
make[2]: Leaving directory '/home/usr/axiom/lsp'
make[1]: *** [Makefile.opensuse:175: lspdir] Error 2
make[1]: Leaving directory '/home/usr/axiom'
make: *** [Makefile:148: all] Error 2

I'm getting the same error on Fedora. GCL doesn't compile with GCC 6.

Is there a dependency on a certain gcl version?
Should I first try a more recent gcl version or adding include guards to gcl ?

Yes, this is a known problem with GCC 6. It shows up with the lisp build but I have walked the system
back to prior lisps and it still fails.

The method of debuging this problem is to either use GDB or build an old working version of GCC
and apply patches until you find the failing patch. I started working on this problem but it is one of
many to be solved. If you find a solution please post a patch or a message to the list.

There are three possible workarounds until this gets solved, assuming you can't solve it:

  1. apt-get install axiom

  2. use the Docker version

  3. use a virtual machine with a different version of GCC

@daly I'd like to help fix this. Kindly tell me what the last known working GCC version was.

I think this problem can be solved with the right compilation parameters.
Similar to here:
https://gmplib.org/list-archives/gmp-discuss/2011-January/004490.html
That is what I am pursuing right now anyways.

GCL generally sets its own compiler parameters but these can probably be adjusted by autoconf. Since the problem occurs in GCL the least-complicated debugging path would be to check out a clean version, either from the Axiom zips subdirectory or from the hosting site at savannah.

Axiom builds with GCC --version = 4.8.2 which is what I normally use.

I wrote to the GCL mailinglist about the problem but have not recieved an answer, it seems the mailinglist ist dormand/dead.
I am pretty shure that the error is related to this:
stackoverflow:why-arent-my-comile-guards-preventing-multiple-definitions
Each sub library of GCL has its definition of m__gmpz_add and the other gmp functions and when linking they conflict.
just have a look at:
nm -s unixport/libpre_gcl.a
and note the multiplicity of gmp function definitions

re: GCL reply... The mailing list is alive. Remember that (a) this is open source maintained by one person, (b) the problem isn't trivial or (c) christmas is this week. It is highly likely that he is busy either with work or family or has not found a solution yet. Few people ever make the effort to debug a problem and contribute a patch. He might be working on a different bug report at the moment. Camm is an amazing programmer. Give him time.

I looked at your link. The odd thing is that this code compiles under earlier versions of GCC. I have looked at http://snapshot.debian.org/package/?cat=g to get prior snapshots of GCC to test. So if the problem is related to includes then something in GCC changed but I don't know which GCC version changed it. Unfortunately I'm also pushing on another dozen threads of effort so I haven't built a machine to run tests yet.

One thought is to modify the GCL build to skip using GMP. Or perhaps there is a version issue where GMP autoconf version tests are wrong? (see https://gmplib.org/manual/Autoconf.html). Again, these are possible threads to follow to debug it but, time, time, time...

@daly: If you dont have the time to investigate yourself thats fine, I will just report on my progress and you can comment. I am not trying to wear you down until you fix the bug, I want to fix it myself but am gratefull for any advice.

In h/gmp.h there is a section that seems to be concerned with the exact problem we are facing.

/* C++ always has "inline" and since it's a normal feature the linker should
   discard duplicate non-inlined copies, or if it doesn't then that's a
   problem for everyone, not just GMP.  */
#if defined (__cplusplus) && ! defined (__GMP_EXTERN_INLINE)
#define __GMP_EXTERN_INLINE  inline
#endif

/* Don't do any inlining within a configure run, since if the compiler ends
   up emitting copies of the code into the object file it can end up
   demanding the various support routines (like mpn_popcount) for linking,
   making the "alloca" test and perhaps others fail.  And on hppa ia64 a
   pre-release gcc 3.2 was seen not respecting the "extern" in "extern
   __inline__", triggering this problem too.  */
#if defined (__GMP_WITHIN_CONFIGURE) && ! __GMP_WITHIN_CONFIGURE_INLINE
#undef __GMP_EXTERN_INLINE
#endif

Considering that gcc has changed the default c standard from gnu89 to gnu11 starting from gcc 5 and the c11 standard handles inline differently:
porting to gcc5
The easy solution would be to use gcc -std=gnu90 which I will test right away.

And indeed adding -std=gnu89 to the configure script of GCL allowes compilation with gcc-6 again, how should I proceed? Making the code c11 compatible or just finding the line where I need to add gnu89 to the compilation of axiom?

Excellent! Create a file with the change and send me a diff -Naur patch. (e.g. if the file is foo.c):

cp foo.c foonew.c

(make the change in foonew.c)

diff -Naur foo.c foonew.c >foo.c.patch

I will apply the patch, test it on my various branches, and add it to the distribution.
Also, include your full name in the email so I can add you to the credits list.

I really appreciate you taking the time to solve this. Please also post your reply to the GCL mailing list.

I built a machine with the latest OpenSUSE 45.2 (Leap). Axiom fails to build with or without the -std switch. Either I'm doing it wrong or I don't understand the problem. It's late. I'll look at it in detail tomorrow.

I have not successfully built axiom either, but GCL can be built with -std=gnu89 which previously could not. I will first submit the patches to GCL and then try to build axiom again.

OpenSUSE ships with gcc version 4.8.5 on the latest release. How did you get gcc 6?

I am on opensuse tumbleweed.

I can get certain versions of gcl (including Version_2_6_13pre ) to compile with -std=gnu89 .
I cannot figure out how to add different compiler options to libtool which is apparently used in axiom to compile gcl as opposed to the configure/make combination used by gcl to compile gcl.
It should definitely be possible to compile gcl within axiom with gcc 5+ using -std=gnu89 but for now I cannot find the appropriate config file.
The patches for gcl to compile with gcc 5+ have been accepted in the gcl mailing list.

Hmmm.... Upgrading to 13pre is a fair amount of work. GCL versions are cached in the zips
subdirectory to make sure that Axiom will build with a given version. Otherwise upstream
changes can cause build failures that should never reach the user.

I will look into moving to 13pre. So far all of my linux distributions (even OpenSUSE) use GCC <= 4.8. Hopefully 13pre will work with prior GCC versions. That will need to be tested.

I appreciate you taking the time and effort to track this down and pushing a fix upstream.

BTW Wolfgang, your name has been added to the credits for Axiom. It appears in the )credits command in Axiom, in the readme file, and in the preamble of each of the Axiom volumes.

Axiom has moved to GCL 13pre. I believe this has resolved all of the Linux build issues.

@daly Can you please provide the source tarball link for GCL 13pre where Axiom builds fine?