| Summary: | Wrong dynamic loader because of missing -mfloat-abi=hard in LDFLAGS (in scons) | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Tasskjapp <tasskjapp> |
| Component: | devtools / tool chain | Assignee: | Richard Purdie <richard.purdie> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | benjamin.esquivel, meta.mr.watcher, meta.watcher |
| Version: | 1.8.1 | ||
| Target Milestone: | 2.3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Tasskjapp
2015-08-17 08:36:38 UTC
Isn't this something that the configuration should have picked up? I'm saying this because I recently fixed an issue in glibc where the config was picking up the wrong setting for hard-float ABI at the configure. Can you give more of an example of how you ended up linking a binary like this? I tried a test with beaglebone and the SDK locally and the environment file lists: CC="arm-poky-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 --sysroot=$SDKTARGETSYSROOT" so if you use $CC, you get the right option to gcc. You can't be using $LD since that wouldn't accept -mfloat-abi as an option. If you're not using $CC, you can't be getting the --sysroot or other important options. Basically, I need more information about how to reproduce this. Sorry for the late reply. Busy at work, so I haven't had a chance to look at this.
I use SCons. There you set up a build environment where you specify e.g. CC and LD and their flags. I took info from the environment setup and used the following flags.
# common (c/c++) flags
ccflags = [
'-march=armv7-a',
'-mthumb',
'-mthumb-interwork',
'-mfloat-abi=hard',
'-mfpu=neon',
'-mtune=cortex-a15',
'-pipe',
'-g',
'-feliminate-unused-debug-types',
'--sysroot=' + armsysroot]
# specific c, c++ flags
cflags = ['-std=gnu99', '-Wshadow']
cxxflags = ['-std=c++0x', '-Wno-psabi']
# link flags and paths
ldflags = [
'-pthread',
'-g3',
'-Wl,-O1',
'-Wl,--hash-style=gnu',
'-Wl,--as-needed',
'--sysroot=' + armsysroot]
My SCons build first compiles all the c/c++ files, and then links with LD. I had to add '-march=armv7-a' to the ldflags list to get a working binary.
I believe he has answered the question. Please put it back in NEEDINFO if that is not the case. (In reply to comment #3) > My SCons build first compiles all the c/c++ files, and then links with LD. I > had to add '-march=armv7-a' to the ldflags list to get a working binary. Sorry, I'm confused. You had to add '-mfloat-abi=hard' or '-march=armv7-a' or both? No wonder you're confused. I only added -mfloat-abi=hard, so my previous comment was wrong. Sorry. Sorry for the delay in getting back to this. I think the clue here is that your LDFLAGS contain -Wl options which mean that they're being passed to gcc as the driver to the linker, not caling ld directly. If you're using gcc as the driver to the linker, you also need to add CFLAGS to LDFLAGS as you've discovered. Most environments add in LDFLAGS to CFLAGS when linking, it appears scons doesn't and you therefore need to do that yourself. I'm not sure there is much we can do about this from the project side, the same LDFLAGS are what we use for building all our software and we can't really change that. I'm going to have to mark this as WONFIX buts more CANTFIX, sorry :( |