bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: inline problems on RHEL 5.8


From: Eric Blake
Subject: Re: inline problems on RHEL 5.8
Date: Mon, 31 Dec 2012 11:28:34 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 12/31/2012 09:57 AM, Eric Blake wrote:
> How do I go about debugging and fixing these errors?  I suspect they are
> more fallout from Paul's efforts to revamp how 'inline' works; these
> were reproduced by temporarily bumping m4 to the latest gnulib.git and
> compiling on a RHEL 5.8 machine (kernel 2.6.18, glibc 2.5, gcc 4.6.4):

It looks like the particular machine I tested on was using a non-default
gcc (stock RHEL 5 still ships with gcc 4.1.2); this may be a case of the
old headers and new compiler not being compatible with one another, and
therefore something we don't have to worry about by default.

> 
> gcc -std=gnu99   -g -O2   -o m4 m4.o builtin.o debug.o eval.o format.o
> freeze.o input.o macro.o output.o path.o symtab.o ../lib/libm4.a
> /usr/local/lib/libsigsegv.a -lc
> builtin.o: In function `stpncpy':
> /usr/include/bits/string3.h:156: multiple definition of `stpncpy'
> m4.o:/usr/include/bits/string3.h:156: first defined here
> 
> It's choking on this, and any other function, where older glibc uses the
> following style of declaration:
> 
> extern __always_inline char *
> __NTH (stpncpy (char *__dest, __const char *__src, size_t __n))

Looking at the preprocessor output, this expanded to:

extern __inline __attribute__ ((__always_inline__)) char *
__attribute__ ((__nothrow__)) stpncpy (char *__dest, __const char
*__src, size_t __n)

But comparing it to a machine with modern gcc _and_ modern glibc, I see
a more complex expansion to:

extern __inline __attribute__ ((__always_inline__)) __attribute__
((__gnu_inline__)) __attribute__ ((__artificial__)) char *
__attribute__ ((__nothrow__ , __leaf__)) stpncpy (char *__dest, const
char *__src, size_t __n)

So I wonder if it is worth trying to have gnulib fix the glibc
definition of __always_inline to include '__attribute__
((__gnu_inline__))' when appropriate.  But I'm not sure how easy that
would be to detect if the current gcc needs this attribute added to the
current glibc definition of the internal __always_inline macro.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]