Summary: | multiple definition of `__fixdfdi' (and other floating point functions) | ||
---|---|---|---|
Product: | glibc | Reporter: | Chris Packham <judge.packham+glibc> |
Component: | build | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | carlos, judge.packham+glibc |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | 2.29 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Attachments: | Dockerfile to reproduce issue |
Description
Chris Packham
2019-09-04 22:00:26 UTC
You'll need to find why the soft-fp functions got built into glibc. Only sysdeps/powerpc/nofpu/Makefile and sysdeps/nios2/Makefile add them to the build, and there's no such thing as soft-float powerpc64, either endianness (see the list of supported glibc ABIs at <https://sourceware.org/glibc/wiki/ABIList>). So what went wrong with the configure tests distinguishing hard and soft float to cause inappropriate sysdeps directories to be used? Looks like 2.30 doesn't have the same problem. Skimming the history I don't see anything obvious. Somewhere along the line with_fp_cond gets set to 0 in the configure process. snippet from config.log configure:3865: checking for use of fpu sysdeps directories conftest.c:4:3: error: #error "no hardware floating point" # error "no hardware floating point" ^~~~~ configure:3884: result: no As Joseph said this should be true for powerpc64. sysdeps/powerpc/preconfigure only sets this in the 32-bit case. I wonder if one of the other preconfigure scripts is setting this to 0 unconditionally. I think the problem is actually due to a non-upstream patch that crosstool-NG is carrying for ARC. This ends up modifying with_fp_cond for all architectures (not just arc). I'm marking this as resolved/worksforme since the bug is actually due to a downstream patch. |