From: Al Viro <viro@ZenIV.linux.org.uk>
To: Richard Weinberger <richard@nod.at>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
user-mode-linux-devel@lists.sourceforge.net, jdike@addtoit.com
Subject: Re: [PATCH 8/9] um: fix strrchr problems
Date: Tue, 30 Aug 2011 13:48:05 +0100 [thread overview]
Message-ID: <20110830124805.GU2203@ZenIV.linux.org.uk> (raw)
In-Reply-To: <4E5CBC3F.9030006@nod.at>
On Tue, Aug 30, 2011 at 12:32:31PM +0200, Richard Weinberger wrote:
> defconfig + STATIC_LINK + UML_NET_VDE builds fine for me.
>
> Toolchain (openSUSE 11.4):
> glibc: 2.11.3
> vde2: 2.3.1
> gcc: 4.5.3
> binutils: 2.21.1
>
> Is my vde too new?
> BTW: Why is only strstr affected, what makes it so special?
What happens is that we end up with arch/um/drivers/vde.o having a reference
to rindex(). It comes from libvdeplug.a:libvdeplug.o and we don't have
rindex() in the kernel. In libc we *do* have it - as an alias for strrchr.
So libc.a:strrchr.o is pulled in by that and we end up with conflict since
now two object files picked by linker define the same symbol.
At a guess, newer vde stopped wanking with rindex(3) (perhaps switching
to strrchr(3), as recommended by POSIX these days) and that has eliminated
the problem.
So yes, probably it's your vde being newer. Until other distros pick that
version we are stuck with that problem, though... Alternative solution
would be to have rindex() in arch/um/drivers/vde_kern.c - that also works
and might be a bit saner. Defining it in lib/string.c is probably a bad
idea, since its use is not a good practice - it duplicates a standard C
equivalent (C89, at that) for no reason.
next prev parent reply other threads:[~2011-08-30 12:48 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-29 16:13 UML fixes for 3.1-rcX (2nd try) Richard Weinberger
2011-08-29 16:13 ` [PATCH 1/9] um: disable CMPXCHG_DOUBLE as it breaks UML build Richard Weinberger
2011-08-29 17:35 ` Christoph Lameter
2011-08-29 16:13 ` [PATCH 2/9] um: drivers/xterm.c: fix a file descriptor leak Richard Weinberger
2011-08-29 16:13 ` [PATCH 3/9] um: Save FPU registers between task switches Richard Weinberger
2011-08-29 16:13 ` [PATCH 4/9] um: fix oopsable race in line_close() Richard Weinberger
2011-08-29 16:13 ` [PATCH 5/9] um: winch_interrupt() can happen inside of free_winch() Richard Weinberger
2011-08-29 16:13 ` [PATCH 6/9] um: fix free_winch() mess Richard Weinberger
2011-08-29 16:13 ` [PATCH 7/9] um: PTRACE_[GS]ETFPXREGS had been wired on the wrong subarch Richard Weinberger
2011-08-29 16:13 ` [PATCH 8/9] um: fix strrchr problems Richard Weinberger
2011-08-29 21:27 ` Andrew Morton
2011-08-29 21:38 ` Richard Weinberger
2011-08-29 22:12 ` Al Viro
2011-08-29 22:15 ` Richard Weinberger
2011-08-29 22:19 ` Al Viro
2011-08-29 22:25 ` Richard Weinberger
2011-08-29 23:28 ` [uml-devel] " Boaz Harrosh
2011-08-30 0:23 ` Al Viro
2011-08-30 2:48 ` Al Viro
2011-08-30 10:32 ` Richard Weinberger
2011-08-30 12:48 ` Al Viro [this message]
2011-08-29 22:39 ` Arnaud Lacombe
2011-08-29 22:11 ` Al Viro
2011-08-30 3:41 ` [uml-devel] " Jeff Dike
2011-08-29 16:13 ` [PATCH 9/9] um: clean arch_ptrace() up a bit Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110830124805.GU2203@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=richard@nod.at \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox