GMP instructions (dev version) say to add ABI=32 to CFLAGS; should be separate variable

[drjones]

The instructions for compiling GMP 5.0.1 (section 6.13) in the LFS development version provide a note on compilation when the CFLAGS environment variable is set. The instructions say to "avoid this by adding ABI=32 to the CFLAGS variable for the duration of the configure command below, then remove it afterwards." It appears that ABI should be a separate environment variable, not part of the value assigned to CFLAGS. Configuration failed with ABI=32 added to CFLAGS. Configuration, compilation, and tests worked with ABI as a separate environment variable.

[bdubbs@…]

Looking back at the discussion that caused this note to be added, I'd agree that the line:

"Avoid this by adding ABI=32 to the CFLAGS variable for the duration of the configure command below, then remove it afterwards."

appears to be misleading. However it may have the desired effect, depending on how it is added to CFLAGS.

If we just say: "Avoid this by adding the environment variable ABI=32." it may be enough, but I suspect it may cause problems because it is not specific enough. Someone will probably want us to say "export ABI=32". Personally, I feel that if a user knows enough to set CFLAGS, they can set ABI too.

If the OS is 32-bit, I would doubt that leaving the environment variable set for the remainder of the chroot session would affect other packages.

I never use custom build variables, so I really can't check it.

Ken, you wrote the note in the book. Do you want to address this?

[ken@…]

I've been searching through my old scripts, but I can't find any references to ABI=32, except in my current script which hasn't necessarily been tested building 32-bit.

Looking at the thread in the archives, it appears the point made in this ticket is correct. I'll reword it.

[Gilles Espinasse]

IPCop build for 32 bits and we need ABI=32. You may need to add another instruction depending of the building machine and the machine where the code will run.

We have a generic CFLAGS for all package that contain -march=i486 -mtune=pentium

Even with this in CFLAGS, But we discover than libgmp contain sse2 instruction (thank to analyse-x86.sh) when building machine support that.

Adding --build=i686-linux to configure fixed that issue.

​http://marc.info/?l=ipcop-devel&m=127142650405003&w=2

[ken@…]

Sorry, I don't understand that. You say that libgmp has sse2 instructions for "-march=i486 -mtune=pentium" but NOT if you simulate an i686 cross-compilation ?

[Gilles Espinasse]

My mystake, the added instruction is --build=i486-linux

The diff of configure with and without build show at the start

-cd /usr/src/gmp-5.0.1 && ./configure --prefix=/usr --disable-static ABI=32 #--build=i486-linux
-checking build system type... athlon-pc-linux-gnu
-checking host system type... athlon-pc-linux-gnu
+cd /usr/src/gmp-5.0.1 && ./configure --prefix=/usr --disable-static ABI=32 --build=i486-linux
+checking build system type... i486-pc-linux-gnu
+checking host system type... i486-pc-linux-gnu
 checking for a BSD-compatible install... /usr/bin/install -c
 checking whether build environment is sane... yes
 checking for a thread-safe mkdir -p... /bin/mkdir -p
@@ -34,12 +34,11 @@
 checking for build system compiler math library... -lm
 checking for grep that handles long lines and -e... /bin/grep
 checking for egrep... /bin/grep -E
-checking if the assembler knows about MMX instructions... yes
 using ABI="32"
       CC="gcc -std=gnu99"
       CFLAGS="-Os -march=i486 -mtune=pentium -pipe -fomit-frame-pointer -D_FORTIFY_SOURCE=2 -fstack-protector-all -fPIE -Wl,-z,now"
       CPPFLAGS=""
-      MPN_PATH=" x86/k7/mmx x86/k7 x86 generic"
+      MPN_PATH=" x86/i486 x86 generic"
 checking for function prototypes... yes
 checking for ANSI C header files... yes
 checking for sys/types.h... yes
@@ -325,40 +324,41 @@
 config.status: creating config.h
 config.status: linking mpn/generic/add.c to mpn/add.c
 config.status: linking mpn/generic/add_1.c to mpn/add_1.c
-config.status: linking mpn/x86/k7/aors_n.asm to mpn/add_n.asm
+config.status: linking mpn/x86/aors_n.asm to mpn/add_n.asm

Our --build instruction is strange as there is no i486-pc-linux-gnu compiler. But looking in configure code, the reason why it is working is

    case $host_cpu in
      i386*)                path="x86" ;;
      i486*)                path="x86/i486 x86" ;;
      i586 | pentium)       path="x86/pentium x86" ;;
      pentiummmx)           path="x86/pentium/mmx x86/pentium x86" ;;
      i686 | pentiumpro)    path="x86/p6 x86" ;;
      pentium2)             path="x86/p6/mmx x86/p6 x86" ;;
      pentium3)             path="x86/p6/p3mmx x86/p6/mmx x86/p6 x86";;
      pentiumm | core2 | corei)
                            path="x86/p6/sse2 x86/p6/p3mmx x86/p6/mmx x86/p6 x86";;
      k6[23])             path="x86/k6/k62mmx x86/k6/mmx x86/k6 x86" ;;
      k6)                   path="x86/k6/mmx x86/k6 x86" ;;
      geode)                path="x86/k6/k62mmx x86/k6/mmx x86/k6 x86" ;;
      # we don't have any specific 32-bit code for athlon64/opteron, the
      # athlon code should be reasonable
      athlon | athlon64)    path="x86/k7/mmx x86/k7 x86" ;;
      i786 | pentium4)      path="x86/pentium4/sse2 x86/pentium4/mmx x86/pentium4 x86" ;;
      # VIA/Centaur processors, sold as CyrixIII and C3.
      viac32)               path="x86/p6/p3mmx x86/p6/mmx x86/p6 x86";;
      viac3*)               path="x86/pentium/mmx x86/pentium x86";;
      atom)                 path="x86/atom x86" ;;
      *)                    path="x86" ;;
    esac

[ken@…]

OK, I think I'm getting there. The original part of this ticket only happens if CFLAGS are set.

I'll categorise this second part as "building with wrong instructions". The host_cpu is picked up from config.sub, but can be overridden by --build. Depending on what flavour of x86 cpu this is, different code is used to get the most from the cpu.

If I read this correctly (line 4010 onwards, and 5046 onwards in 5.0.1/configure), configure identifies the cpu and then builds code to suit it, irrespective of whether CFLAGS are passed or not. Either we have a misidentified cpu (the c3 and suchlike used to cause problems in the past, but I would hope that they will be correctly identified by our temporary toolchain), or you have cases where you follow our instructions and hope to run on anything >= i486, but in this case a "common" build machine generates code for itself.

If it's the latter, I don't think LFS gives guarantees about compatability across different machines. The point is certainly worth noting, because some users will try this, but I think we can merely tell users in that situation to pass --build=[CPU]-linux to configure after choosing a value of [CPU] such as i486 from the x86 cpus listed under host_cpu in configure.

[ken@…]

Replying to ken@…:

OK, I think I'm getting there. The original part of this ticket only happens if CFLAGS are set.

And what I had overlooked is that the note dated from when LFS *only* built for 32-bit. If someone has a 64-bit capable x86 cpu, and has set CFLAGS, *and is building for 32-bit* then ABI=32 is required. The current phrase "the configure script will attempt to configure for 64-bits and fail" is incorrect for a 64-bit LFS build.

[ken@…]

Preview the altered NOTE at ​http://www.linuxfromscratch.org/~ken/tmp/chapter06/gmp.html - comments on lfs-dev please.

[ken@…]

The ABI part is fixed in r9287.