Red Hat Bugzilla – Bug 181868
gcc does not compile gmp with patches properly
Last modified: 2007-11-30 17:11:24 EST
Description of problem: I downloaded the source of gmp 4.1.4 and applied two of the offical patches to the source. Afterwards I compiled it and performed make check. Then I got some errors which I didn't get when I compiled it on a FC4 x86_64 system using gcc 4.0.0. Version-Release number of selected component (if applicable): Es werden eingebaute Spezifikationen verwendet. Ziel: x86_64-redhat-linux Konfiguriert mit: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread-Modell: posix gcc-Version 4.1.0 20060214 (Red Hat 4.1.0-0.27) How reproducible: Always Steps to Reproduce: 1. download the source of gmp 4.1.4 from http://ftp.sunet.se/pub/gnu/gmp/gmp-4.1.4.tar.bz2 2. unpack it 3. download the patches from http://people.freenet.de/juergen.bullinger/gmp/gmpPatch-4.1.4.tgz 5. unpack it in a separate new directory 6. do ./install pathToYourGmpRootDirectory in this new directory 7. only install toom3 and mpn_rootrem (say y when asked and n otherwise) 8. do cd pathToYourGmpRootDirectory 9. do ./configure 10. do make 11. do make check Actual results: Not all of the checks pass Expected results: They should pass as in earlier versions of gcc. In 4.0.0 for example it worked the same way. Additional info: This is most likely a bug in gcc and maybe not directly related to your package.
Can I install gcc parallel in different versions?
Far more often it is just a bug in the package, e.g. anything that relies on undefined behavior can work for years and be broken by a compiler upgrade that optimizes some more. If you think it is a gcc bug, you need to debug this yourself and prove it is a gcc bug, by distilling a small self-contained testcase. I really can't debug all packages just because somebody thinks it might be a gcc problem.
No it is not a bug in the package. As I said it ran on FC4 using gcc 4.0.0. I get another error in gcc if I use the genuine gmp source code and apply the genuine amd64 code enhancements. This also worked on FC4. I did it just some days ago. The source is exactly the same but now it doesn't work anymore.
Please reread what I said in #2. The fact that it worked in FC4 using gcc 4.0.x doesn't tell anything, still it is far more likely it is a gmp bug than a gcc bug (from my past experience). If you see the problem in gmp included in Fedora development, this should be reassigned to gmp, otherwise you need to come up with a small self-contained testcase. You can use binary search (compile some objects with gcc32, some with gcc) etc.
To reproduce it you can do the following: 1. download the original code from the official gmp homepage http://ftp.sunet.se/pub/gnu/gmp/gmp-4.1.4.tar.bz2 as well as the patch http://www.lix.polytechnique.fr/Labo/Pierrick.Gaudry/mpn_AMD64/mpn_amd64.tgz which is also directly linked from the official gmp homepage! 2. unzip both in two differenct directories 3. do ./install pathToYourGmpDir in the mpn_amd64 directory just created 4. perform the following sequence of commands in the gmp-4.1.4 directory you just created ./configure make make check As I said it surely is not a bug in the code. If you do the steps above on a x86_64 installation (AMD) you will get the following messages: lt-t-bswap: error while loading shared libraries: libgmp.so.3: cannot enable executable stack as shared object requires: Permission denied FAIL: t-bswap lt-t-constants: error while loading shared libraries: libgmp.so.3: cannot enable executable stack as shared object requires: Permission denied FAIL: t-constants lt-t-count_zeros: error while loading shared libraries: libgmp.so.3: cannot enable executable stack as shared object requires: Permission denied FAIL: t-count_zeros lt-t-gmpmax: error while loading shared libraries: libgmp.so.3: cannot enable executable stack as shared object requires: Permission denied FAIL: t-gmpmax lt-t-modlinv: error while loading shared libraries: libgmp.so.3: cannot enable executable stack as shared object requires: Permission denied FAIL: t-modlinv
If it is so, then it doesn't have anything to do with gcc. SELinux simply refuses to load libgmp.so.3, as it requires executable stack. You need to build it in a way that the library either doesn't request executable stack, or tell SELinux about it. GCC automatically does the right thing for .c/.C/etc. sources when compiling them, but when .s/.S is used, it is author's responsibility to make sure the right thing happens. Either by marking it in the assembly: #ifdef __linux__ .section .note.GNU-stack .previous #endif or by assembling with --noexecstack as option (if invoked through gcc driver, -Wa,--noexecstack), or by linking with -Wl,-z,noexecstack. E.g. FC5 gmp spec file handles this by: export CCAS="gcc -c -Wa,--noexecstack" before doing configure. This is nothing new btw, almost 3 years old thing. The only difference is that FC5 SELinux policy enforces this by default even for unconfined processes, unless told otherwise, while in FC5 and earlier it was enforced by default only for confined processes.
Thank you for this info. I'll tried it. It resolves the second problem. In the meantime I tried to compile the patch mentioned first using the gcc32 command as you suggested. I get the same problem. It says PASS: t-cmp /bin/sh: line 1: 8605 Speicherzugriffsfehler ${dir}$tst FAIL: t-mul PASS: t-mul_i /bin/sh: line 1: 8645 Speicherzugriffsfehler ${dir}$tst FAIL: t-tdiv PASS: t-tdiv_ui /bin/sh: line 1: 8686 Speicherzugriffsfehler ${dir}$tst FAIL: t-fdiv P Which means "Memory access violation"
I did some more analysis and found out that at lease one of the bugs happens after a function terminates and before the next statement in the calling function is executed. The verry last statement which is executed is a printf. I inserted it at the end of the function mpn_mul_n in file gmp-4.1.4/mpn/generic/mul_n.c. It should be around line some lines before 901 (i inserted some other printf lines so i can't say exactly). I also inserted printf statements before the call to this function and know exactly where it is called when the error happens. It happens right after the first call of function mpz_mul in gmp-4.1.4/tests/mpz/t-fdiv.c returns (about line 119 in the file). Could this be caused by improper stack handling?
Have you seen my latest comments? How can you explain this?
Please don't reopen this bug until you prove there is a GCC problem.
I already did a lot of analysis. Was this just a waste of time? I hope not. Sorry if I analize things which might be a problem for your distribution and you just close the messages for the sake of your statistics then I hope you really have good reasons.