This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH roland/nptl-sparc] Move remaining SPARC code out of nptl/.
- From: David Miller <davem at davemloft dot net>
- To: roland at hack dot frob dot com
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 24 Jun 2014 16:00:02 -0700 (PDT)
- Subject: Re: [PATCH roland/nptl-sparc] Move remaining SPARC code out of nptl/.
- Authentication-results: sourceware.org; auth=none
- References: <20140624201458 dot D62112C39C4 at topped-with-meat dot com> <20140624 dot 132842 dot 1255651814055244349 dot davem at davemloft dot net> <20140624203452 dot A0FD52C3A10 at topped-with-meat dot com>
From: Roland McGrath <email@example.com>
Date: Tue, 24 Jun 2014 13:34:52 -0700 (PDT)
>> I will not have time to investigate this today, sorry.
> No problem. I will test the other builds that are easiest for me to do
> (ARM, and re-test x86 in case I flubbed my previous testing), and might
> find some general snafu that way. Then I'll see what I can do to
> investigate the sparc build myself if you haven't gotten there first.
> (I have some old pointers from you to log into a machine of yours,
> and in years past I've managed to find sparc boxes I could use via
> the Debian and/or GCC compile farms or maybe sourceforge.)
Your roland/nptl branch results in a new build error, the problem is
that sysdeps/sparc/sparc32/sparcv9/nptl/sem_trywait.c tries to include
the old location of the generic Linux sem_trywait.c file which of
course no longer works.
What's the best way to handle this? I tried:
but that still picks up sysdeps/sparc/sparc32/sparcv9/nptl/sem_trywait.c,
then I thought to try:
but that won't work because 1) it will generate a warning about using
include_next being used in a primary file and 2) it will end up using
sysdeps/sparc/sparc32/nptl/sem_trywait.c rather than what I want which