Building the library for 32-bit architectures

[gnzlbg]

I am trying to build the library for i686-apple-darwin and i686-unknown-linux-gnu targets (generic 32-bit apple and linux targets).

The "Environment support matrix" says that 32-bit linux is supported, yet I cannot find a 32-bit linux travis or jenkins buildbot on CI (maybe this one https://github.com/shibatch/sleef/blob/master/Jenkinsfile#L70 ?) to see the steps involved.

The usual way to do this on Linux is to use a gcc-multilib package that comes with 32-bit libraries, and passing -march=i686, -m32, etc. to the compiler via CFLAGS, or in this case, CMAKE_C_FLAGS, but for some reason CMAKE_C_FLAGS appears to be completely ignored by the build system :/

Any ideas of what I am doing wrong?

[gnzlbg]

A reproducer is to just pass CMAKE_C_FLAGS="-m32" to the build. On all platforms where I've tried, the build configures fine, and starts building, but no compiler invocations contain -m32. Trying then to link the library to a 32-bit binary will fail.

[fpetrogalli]

A reproducer is to just pass CMAKE_C_FLAGS="-m32" to the build. On all platforms where I've tried, the build configures fine, and starts building, but no compiler invocations contain -m32. Trying then to link the library to a 32-bit binary will fail.

I suspect this might be due to a bug in our cmake files, we might have reset CMAKE_C_FLAGS somewhere instead of appending it to what is passed from command line when invoking make. You could also try invoking cmake as follows?

$> CFLAGS="-m32” cmake path/to/sleef 

[gnzlbg]

You could also try invoking cmake as follows?

$> CFLAGS="-m32” cmake path/to/sleef

Same issue :/

IIRC cmake gets the CFLAGS and puts them into CMAKE_C_FLAGS automatically, which is what it then uses to set the flags of the C compiler.

I've managed to get the CMAKE_TOOLCHAIN_FILE working in other architectures, but I kind of wish that it was possible to do all this without such a file. I haven't tried to use a CMAKE_TOOLCHAIN_FILE for 32-bit architectures though, although that might work (IIRC the "list" variables there are "special", but I haven't used CMake in a long time).

--

That is, I'd expect that setting the usual suspects (CC, CFLAGS, LD, AR, HOST, TARGET, etc.) should be enough to properly cross-compile the library to any target without having to use a toolchain file, although using one should also be possible and supported.

[fpetrogalli]

Same issue :/

Yep, I just verified the same on my machine.

IIRC cmake gets the CFLAGS and puts them into CMAKE_C_FLAGS automatically, which is what it then uses to set the flags of the C compiler.

Yes, this is how it is supposed to work. The thing is that most of the project use the same CFLAGS all though the projects, while for SLEEF we have to set them for each target, so they are kinda hardcoded in the configuration.

I've managed to get the CMAKE_TOOLCHAIN_FILE working in other architectures, but I kind of wish that it was possible to do all this without such a file. I haven't tried to use a CMAKE_TOOLCHAIN_FILE for 32-bit architectures though, although that might work (IIRC the "list" variables there are "special", but I haven't used CMake in a long time).

I don’t think there is a need to cross-compile here. I think that you should set COMMON_TARGET_PROPERTIES to concat anything that is passed also at command line. That should make the trick, because COMMON_TARGET_PROPERTIES carries things like -fPIC.

At the end, you should invoke cmake as

$> cmake -DCOMMON_TARGET_PROPERTIES=“-m32"

If you submit a patch to implement this, I’ll happily review it.

[gnzlbg]

while for SLEEF we have to set them for each target, so they are kinda hardcoded in the configuration.

The thing I don't yet understand is, why doesn't SLEEF append these to CMAKE_C_FLAGS ? Or the otherway around, append CMAKE_C_FLAGS to these while building the SLEEF binaries?

[fpetrogalli]

The thing I don't yet understand is, why doesn't SLEEF append these to CMAKE_C_FLAGS ?

I think you just exposed a design flaw of our build system. There are multiple places where we simply reset CMAKE_C_FLAGS, see for example:

src/libm/CMakeLists.txt:5:set(CMAKE_C_FLAGS ORG_CMAKE_C_FLAGS)

In fact, if I run CFLAGS=“-m32’ make path/to/sleef, the configuration gets written correctly in the build folder, it is only that lines like the previous are just ignoring it.

We should in fact do a better use of this variable, so that it adheres to the original design it has in cmake, which is to pick up the CFLAGS passed at command line by the user.

Feel free to file an issue, and of course, you are more than welcome to fix the problem! :)

[gnzlbg]

I hope I'll fix this tomorrow morning, now that the issue is confirmed, it shouldn't be too hard :)

[gnzlbg]

So I think I fixed this already, but then SLEEF fails to build on i686-apple-darwin because... it does not define __SSE__, which seems to be a clang bug: https://bugs.llvm.org/show_bug.cgi?id=38594

So the configure should probably detect that target, and just error until a clang version is released with a fix...

[fpetrogalli]

@gnzlbg , do you have a patch showing the problem? I would like to reproduce it on my mac.

[shibatch]

I am going to add testing for 32-bit x86 and FreeBSD.

[gnzlbg]

https://github.com/gnzlbg/sleef/commit/b42e92cd4f0d21dcdae4514d1e821c6fc6d8738a

I’m travelling till Sunday but that commit is enough to reproduce on macOS’s. The problem is that the i686 clang target doesn’t aims for a CPU with SSE.

I haven’t finished setting CI for i686-unknown-Linux-gnu yet, will try to do so sunday.

I’ve reported the clang bug

https://bugs.llvm.org/show_bug.cgi?id=38594

And the Rust Lang one

https://github.com/rust-lang/rust/issues/53423