This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 05/13] powerpc64le: link tests against ld.so
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Sat, 7 Mar 2020 00:31:29 +0000
- Subject: Re: [PATCH 05/13] powerpc64le: link tests against ld.so
- Ironport-sdr: FTlehZi5FJqBbEEif6qR9KB/qG+aEyg/btcPgSKeUzAScIsT+n5wrMydZW4HFbQ5DoU+BExqBq op9UO0qyrncKnfnEjNDLO+SffycLNYRv6P1+Ta8NkVY8BokGZDdPm02yFSnDpsM1+LWHtKPXC/ GkTzipVAWue9n8ZRHW8ssP7uU7Dsba0GqrRZlpwFVJB2hGGzH5bCPaGUmiWpd9MmEDsKCCLwwY lzDteuu5mOGuFJL03nfONJeUFTCJdgjIkG73/hhxwuG7OmRm0TvP0PIqoboOrQnwRyXWfXXYWi cBs=
- Ironport-sdr: 02urEkGkAGyax3khlqQEiwjVarNyWWI/ZRc4A+qAmd+7X8q0zv7dG6yXps5QG71p/iO98qrw4K wwbq1HbOW1WcaNLFmpoHYzyjLPfzROZ8rlIsHhhY4mK6e4eGv8QLEqCdQamEaTmvEQ8h8ULC4q MrsSSyq6Z9ZH23HRvu2Mi5qisxZuJ8uayYsEYXbzWMFSa7vjE3p6MUq7k35PnursOQnnkmmTvg qaf2hTMR+FdhQVrZ7lt7YMvbXFZz3L9xM+UUAP0eWTdjooHuFGeYVibGUQmUp+6M9l3XMaG02W SvU=
- References: <20200306203721.15886-1-murphyp@linux.vnet.ibm.com> <20200306203721.15886-6-murphyp@linux.vnet.ibm.com>
On Fri, 6 Mar 2020, Paul E. Murphy wrote:
> In preparation for the transition of the format of long double - from
> IBM Extended Precision to IEEE 754 128-bits floating-point - on
> powerpc64le, this patch adds the linking of the loader to the tests for
> long double, since after the switch they will also depend on
> __parse_hwcap_and_convert_at_platform.
I'm afraid this patch looks unmaintainable.
It adds a duplicate list of libm tests, with no obvious logic for what
goes in that list, to an architecture-specific Makefile. That seems like
a recipe for patches that add a libm test, changing only
architecture-independent code, accidentally breaking the build for
powerpc64le.
Things should be designed in such a way that normal
architecture-independent changes, such as adding new libm tests, do not
require any knowledge of the existence of such a powerpc64le-specific
list.
As these are generally normal tests, not tests in tests-internal, I
presume they do not in fact use any internal glibc interfaces and so would
work fine when built with an installed compiler and glibc. So I think you
need to identify exactly what is different (to cause the problem this
patch is addressing) between normal builds of user code with installed
tools, and the build of tests as part of the glibc testsuite build, and
fix that difference (globally, not limited to these particular tests or
this particular architecture) in such a way that these tests just work
without a duplicate architecture-specific list of tests being needed.
--
Joseph S. Myers
joseph@codesourcery.com