Bug 20721 - Cross-compiling glibc with CFLAGS option -march fails
Summary: Cross-compiling glibc with CFLAGS option -march fails
Status: RESOLVED INVALID
Alias: None
Product: glibc
Classification: Unclassified
Component: build (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-20 03:43 UTC by Nam-goo Lee
Modified: 2016-10-24 08:55 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
error message (683 bytes, text/plain)
2016-10-20 03:43 UTC, Nam-goo Lee
Details
config.log for failed build (7.96 KB, text/plain)
2016-10-21 03:36 UTC, Nam-goo Lee
Details
config.log for successful build (7.97 KB, text/plain)
2016-10-21 03:39 UTC, Nam-goo Lee
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nam-goo Lee 2016-10-20 03:43:57 UTC
Created attachment 9583 [details]
error message

Hi.

I'm trying to cross-compile glibc for an arm system.
After adding -march=armv7-a option to CFLAGS environment variable,
the build fails, with error messages such as :

"Error: selected processor does not support 'uxtb r1, r1' in ARM mode"

I've included the error messages as an attachment.

The following is the step I took:

1) export CC=arm-linux-gnueabi-gcc
2) export CFLAGS="-g -O2 -march=armv7-a"
3) CC=$CC ../glibc/configure --prefix=[some_directory_path] --host=arm-linux-gnueabi
4) make

* Build environment
- OS : Ubuntu 16.04
- Kernel : 4.4.0-43-generic
- compiler : arm-linux-gnueabi-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.1) 5.4.0 20160609

Looking at the "ARM Architecture Reference Manual, ARMv7-A and ARMv7-R edition", the instructions 'uxtb, ldrd, pld, uqsub8' are indeed supported in ARM mode.

I assume that the strchr.S file mentioned above (under sysdeps/arm/armv6) is intended to be compiled in Thumb mode, by NOT defining the NO_THUMB macro.

The directive ".thumb" should be added by codes in line 139~145 of sysdeps/arm/sysdep.h.

However, when compiling the strchr.S file in question, the include path order states that it looks into the directory sysdeps/unix/sysv/linux/arm before sysdeps/arm. Which results in including sysdeps/unix/sysv/linux/arm/sysdep.h, and not including sysdeps/arm/sysdep.h.

Thanks for reading my report.
Comment 1 Carlos O'Donell 2016-10-20 13:11:01 UTC
Can you attach your config.log so we can see what was actually configured?
Comment 2 joseph@codesourcery.com 2016-10-20 15:34:18 UTC
Please try putting -march in CC instead of CFLAGS, so that it gets used 
when building .S files as well as C code.
Comment 3 Nam-goo Lee 2016-10-21 03:33:24 UTC
Thanks for the replies.

Putting -march in CC instead of CFLAGS, as Joseph commented, did the job for me.

The following command lines resulted in a successful build:

1) export CC="arm-linux-gnueabi-gcc -march=armv7-a"
2) CC=$CC ../glibc/configure --prefix=[some_directory_path] --host=arm-linux-gnueabi
3) make

I've also attached config.log which Carlos asked for, just in case it might be of some use. (the config.log that failed to build glibc) 
I've also attached config.log for the successful build.
Comment 4 Nam-goo Lee 2016-10-21 03:36:32 UTC
Created attachment 9587 [details]
config.log for failed build
Comment 5 Nam-goo Lee 2016-10-21 03:39:17 UTC
Created attachment 9588 [details]
config.log for successful build
Comment 6 Carlos O'Donell 2016-10-21 18:42:01 UTC
(In reply to Nam-goo Lee from comment #3)
> Thanks for the replies.
> 
> Putting -march in CC instead of CFLAGS, as Joseph commented, did the job for
> me.
> 
> The following command lines resulted in a successful build:
> 
> 1) export CC="arm-linux-gnueabi-gcc -march=armv7-a"
> 2) CC=$CC ../glibc/configure --prefix=[some_directory_path]
> --host=arm-linux-gnueabi
> 3) make
> 
> I've also attached config.log which Carlos asked for, just in case it might
> be of some use. (the config.log that failed to build glibc) 
> I've also attached config.log for the successful build.

I'm glad to hear it worked and that it was something as simple as this.

The config.log's look fine, and they are here for posterity if anyone else thinks they have the same issue, but it turns out to be something else.