This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: inlining failed


Carlos O'Donell pÃÅe v So 29. 11. 2008 v 22:19 +0100:
> On Sat, Nov 29, 2008 at 10:53 AM, Dominik TÃborskà <bremby@seznam.cz> wrote:
> > This might be a stupid question, since I wasn't able to google the
> > answer. I'm sorry in that case.
> >
> > I have been trying to build Glibc 2.8.90 (20080505) and 2.9 (from
> > tarball, thanks Brett! ) for a few days now, trying to figure out the
> > compiler settings, mainly. I have overcome many problems, but I got
> > stuck on this, and can't move on:
> >
> > ../misc/syslog.c: In function '__vsyslog_chk':
> > ../misc/syslog.c:123: sorry, unimplemented: inlining failed in call to
> > 'syslog': function body not available
> > ../misc/syslog.c:155: sorry, unimplemented: called from here
> >
> >
> > My system is Ubuntu 8.10 with latest updates, gcc 4.3.2, CFLAGS se to
> > -O2 -mtune=i586 -funit-at-a-time.
> >
> > I think the -fno-stack-protector is also needed to compile glibc, but so
> > far, no matter how hard I've tried, how long I have been googling this,
> > I just can't get it compiled...
> >
> > Anyone's got ideas?
> 
> Yes. Turn off unit-at-a-time (-fno-unit-at-a-time) for this file.
> 
> The function syslog is actually __syslog, but the compiler doesn't
> seem to notice this, and when it tries to inline the function it fails
> to find the function body.
> 
> In practice the compiler *should* know, since ldbl_strong_alias is
> strong_alias and that uses the alias attribute, but apparently this
> doesn't work when doing unit-at-a-time.
> 
> This is probably a compiler bug, or an unimplemented feature.
> 
> Cheers,
> Carlos.

Actually, I am sure I tried turning unit-at-a-time off yesterday, but
didn't work.

Now I found something revealing - it seems to be Ubuntu-specific. In
Ubuntu-GCC man pages you can read a note about setting
-D_FORTIFY_SOURCE=2
when optimizing -O2. I turned it off by setting 
-U_FORTIFY_SOURCE
and I actually got further. 
Now the build ends up with multiple definitions and ld returns 1 exit
status.

_itoa.c:(.text+0xe0): multiple definition of `_itoa'
glibc-2.9-build/elf/dl-allobjs.os:(.text+0x130d0): first defined here
collect2: ld returned 1 exit status

Now I don't know how to get over this. 
It seems to me Glibc is not very secured when I have to turn off stack
protector and FORTIFY_SOURCE checks...

Thanks
Dominik


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]