Missing GLIBC_<version> tags on binaries

Missing GLIBC_<version> tags on binaries

[Otavio Salvador]

Hello,

I am fighting with an issue for last cuple of days and after checking
a lot of weird stuff it seems that the root cause of problem is a
linking issue.

I am having trouble with apps using semaphores. Those are lacking the
GLIBC_2.1 or similar tags and then doesn't work. I rebuilt the
application to check and it keep doing the linking wrong.

Any clue?

Distro: minimal
Machine: i586-generic

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Missing GLIBC_<version> tags on binaries

[Phil Blundell]

On Fri, 2011-02-25 at 19:03 +0000, Otavio Salvador wrote:
> I am fighting with an issue for last cuple of days and after checking
> a lot of weird stuff it seems that the root cause of problem is a
> linking issue.
> 
> I am having trouble with apps using semaphores. Those are lacking the
> GLIBC_2.1 or similar tags and then doesn't work. I rebuilt the
> application to check and it keep doing the linking wrong.
> 
> Any clue?
> 
> Distro: minimal
> Machine: i586-generic

Can you be more specific about what's going wrong?  I guess you are
saying that your libc lacks the GLIBC_2.1 version of some symbol, but
which one?  Does the problem show up during linking or at run time?
Which binaries in particular?

p.

Re: Missing GLIBC_<version> tags on binaries

[Otavio Salvador]

On Fri, Feb 25, 2011 at 20:00, Phil Blundell <philb@gnu.org> wrote:
> On Fri, 2011-02-25 at 19:03 +0000, Otavio Salvador wrote:
>> I am fighting with an issue for last cuple of days and after checking
>> a lot of weird stuff it seems that the root cause of problem is a
>> linking issue.
>>
>> I am having trouble with apps using semaphores. Those are lacking the
>> GLIBC_2.1 or similar tags and then doesn't work. I rebuilt the
>> application to check and it keep doing the linking wrong.
...
> Can you be more specific about what's going wrong?  I guess you are
> saying that your libc lacks the GLIBC_2.1 version of some symbol, but
> which one?  Does the problem show up during linking or at run time?
> Which binaries in particular?
...

It fails at runtime. The application I am compiling is freerdp and
sem_ symbols are not versioned, dunno why.

Cheers,

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Missing GLIBC_<version> tags on binaries

[Phil Blundell]

On Fri, 2011-02-25 at 20:14 +0000, Otavio Salvador wrote:
> It fails at runtime. The application I am compiling is freerdp and
> sem_ symbols are not versioned, dunno why.

Do you mean that the symbols aren't versioned at all, or that they are
versioned but your libc.so.6 doesn't provide the versions that the
binary is expecting?  If the latter, what versions does it have?

Is the libc in your sysroot the same binary (ie same md5sum) that you're
using at runtime?

p.

Re: Missing GLIBC_<version> tags on binaries

[Otavio Salvador]

On Fri, Feb 25, 2011 at 20:40, Phil Blundell <philb@gnu.org> wrote:
> On Fri, 2011-02-25 at 20:14 +0000, Otavio Salvador wrote:
>> It fails at runtime. The application I am compiling is freerdp and
>> sem_ symbols are not versioned, dunno why.
>
> Do you mean that the symbols aren't versioned at all, or that they are
> versioned but your libc.so.6 doesn't provide the versions that the
> binary is expecting?  If the latter, what versions does it have?

The binary lacks version for sem_post, for example. objdump -T show
the undefined symbol without the GLIBC_2.1 version. This happens only
with the sem_ methods.

> Is the libc in your sysroot the same binary (ie same md5sum) that you're
> using at runtime?

Yes the same ... in fact checking objdump of libpthread shows the
symbol with the version so I am lost about why it is not using the
version when linking.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Missing GLIBC_<version> tags on binaries

[Phil Blundell]

On Fri, 2011-02-25 at 20:58 +0000, Otavio Salvador wrote:
> On Fri, Feb 25, 2011 at 20:40, Phil Blundell <philb@gnu.org> wrote:
> > On Fri, 2011-02-25 at 20:14 +0000, Otavio Salvador wrote:
> >> It fails at runtime. The application I am compiling is freerdp and
> >> sem_ symbols are not versioned, dunno why.
> >
> > Do you mean that the symbols aren't versioned at all, or that they are
> > versioned but your libc.so.6 doesn't provide the versions that the
> > binary is expecting?  If the latter, what versions does it have?
> 
> The binary lacks version for sem_post, for example. objdump -T show
> the undefined symbol without the GLIBC_2.1 version. This happens only
> with the sem_ methods.

Is it actually including -lpthread during final link?  Failing to do
that is the most obvious reason for not getting the right version
information.

p.

Re: Missing GLIBC_<version> tags on binaries

[Otavio Salvador]

On Fri, Feb 25, 2011 at 21:34, Phil Blundell <philb@gnu.org> wrote:
> Is it actually including -lpthread during final link?  Failing to do
> that is the most obvious reason for not getting the right version
> information.

It does -pthread that supposelly does it plus -D_REENTRANT IIRC.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Missing GLIBC_<version> tags on binaries

[Phil Blundell]

On Sat, 2011-02-26 at 13:43 +0000, Otavio Salvador wrote:
> On Fri, Feb 25, 2011 at 21:34, Phil Blundell <philb@gnu.org> wrote:
> > Is it actually including -lpthread during final link?  Failing to do
> > that is the most obvious reason for not getting the right version
> > information.
> 
> It does -pthread that supposelly does it plus -D_REENTRANT IIRC.

Yeah, it does seem to be doing the right thing there.  And indeed some
of the sem_ symbols are getting correctly versioned, it's just a couple
(sem_post and sem_wait I think) which are not.

It looks at first inspection as though this might be a linker bug,
though I can't immediately see anything very special about freerdp that
looks like it would be causing things to go wrong.  Some further
debugging needed, though it'd be interesting to know whether it works
any better with gold for example.

p.

Re: Missing GLIBC_<version> tags on binaries

[Otavio Salvador]

On Mon, Feb 28, 2011 at 15:08, Phil Blundell <philb@gnu.org> wrote:
...
> It looks at first inspection as though this might be a linker bug,
> though I can't immediately see anything very special about freerdp that
> looks like it would be causing things to go wrong.  Some further
> debugging needed, though it'd be interesting to know whether it works
> any better with gold for example.

How could I make it to use gold? I am stuck on that issue since it is
block us to advance on the development of a product :-(

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Missing GLIBC_<version> tags on binaries

[Phil Blundell]

On Mon, 2011-02-28 at 16:49 +0000, Otavio Salvador wrote:
> On Mon, Feb 28, 2011 at 15:08, Phil Blundell <philb@gnu.org> wrote:
> ...
> > It looks at first inspection as though this might be a linker bug,
> > though I can't immediately see anything very special about freerdp that
> > looks like it would be causing things to go wrong.  Some further
> > debugging needed, though it'd be interesting to know whether it works
> > any better with gold for example.
> 
> How could I make it to use gold? I am stuck on that issue since it is
> block us to advance on the development of a product :-(

Good question.  For local testing, I think it might be sufficient to
add:

EXTRA_OECONF += "--enable-gold=default"

to your binutils-cross recipe.  You can verify whether it's worked by
running "i586-oe-linux-ld --version" and checking to see whether it
claims to be gold or not.

That's definitely not a patch that you ought to check in, though.  For
wider consumption I guess there ought to be some kind of knob that
DISTROs can tweak to select the linker of their choice.  As far as I
know there isn't any such mechanism at present.

p.

Kernel Module Compilation

[Nick Lee]

I'm compiling a kernel module under openembedded, and it inherits from 
module and update-rc.d.  I want to pass a preprocessor directive, 
TESTFLAG, to my module source code.  I've tried setting -DTESTFLAG in 
CFLAGS, KERNEL_CFLAGS and EXTRA_CFLAGS in my recipe and in the Makefile 
for my module.  In none of these cases do I get TESTFLAG defined in my 
module code.  The best I can get is a helpful suggestion to use 
EXTRA_CFLAGS, which doesn't work.

What on earth am I doing wrong?  It doesn't seem like a particularly 
unusual thing to want to do!  I've spent most of a day trawling the 
internet and openembedded archives for a solution to this problem, and 
have found nothing.  Maybe it shows a lack of google skills on my part...

Nick

Re: Missing GLIBC_<version> tags on binaries

[Otavio Salvador]

On Mon, Feb 28, 2011 at 17:17, Phil Blundell <philb@gnu.org> wrote:
...
> That's definitely not a patch that you ought to check in, though.  For
> wider consumption I guess there ought to be some kind of knob that
> DISTROs can tweak to select the linker of their choice.  As far as I
> know there isn't any such mechanism at present.

One interesting way to "fix" the issue is to explicitly link against
-lpthread however it seems *wrong*.

It seems to be a gcc bug since -pthread is suppose to handle all the
needed background for it to work and seems to be doing it wrong.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Missing GLIBC_<version> tags on binaries

[Khem Raj]

On Mon, Feb 28, 2011 at 11:33 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Mon, Feb 28, 2011 at 17:17, Phil Blundell <philb@gnu.org> wrote:
> ...
>> That's definitely not a patch that you ought to check in, though.  For
>> wider consumption I guess there ought to be some kind of knob that
>> DISTROs can tweak to select the linker of their choice.  As far as I
>> know there isn't any such mechanism at present.
>
> One interesting way to "fix" the issue is to explicitly link against
> -lpthread however it seems *wrong*.
>
> It seems to be a gcc bug since -pthread is suppose to handle all the
> needed background for it to work and seems to be doing it wrong.
>

Does -pthread get passed to linking step too or not. if it does then
it might the order at which libpthread appears and linker picks the
symbols from.

> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Missing GLIBC_<version> tags on binaries

[Otavio Salvador]

On Mon, Feb 28, 2011 at 22:19, Khem Raj <raj.khem@gmail.com> wrote:
...
> Does -pthread get passed to linking step too or not. if it does then
> it might the order at which libpthread appears and linker picks the
> symbols from.

It is done as suggested by gcc docs. It is passed on CFLAGS and
supposely gcc ought to take care of adding it to linking flags
automatically. No?

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Missing GLIBC_<version> tags on binaries

[Khem Raj]

On Mon, Feb 28, 2011 at 2:27 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Mon, Feb 28, 2011 at 22:19, Khem Raj <raj.khem@gmail.com> wrote:
> ...
>> Does -pthread get passed to linking step too or not. if it does then
>> it might the order at which libpthread appears and linker picks the
>> symbols from.
>
> It is done as suggested by gcc docs. It is passed on CFLAGS and
> supposely gcc ought to take care of adding it to linking flags
> automatically. No?

gcc could be used for linking too and then it should consider the LDFLAGS
CFLAGS are for compiling.

>
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
>

Re: Missing GLIBC_<version> tags on binaries

[Otavio Salvador]

On Mon, Feb 28, 2011 at 22:43, Khem Raj <raj.khem@gmail.com> wrote:
> On Mon, Feb 28, 2011 at 2:27 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Mon, Feb 28, 2011 at 22:19, Khem Raj <raj.khem@gmail.com> wrote:
>> ...
>>> Does -pthread get passed to linking step too or not. if it does then
>>> it might the order at which libpthread appears and linker picks the
>>> symbols from.
>>
>> It is done as suggested by gcc docs. It is passed on CFLAGS and
>> supposely gcc ought to take care of adding it to linking flags
>> automatically. No?
>
> gcc could be used for linking too and then it should consider the LDFLAGS
> CFLAGS are for compiling.

From gcc manpage:

       -pthread
           Adds support for multithreading with the pthreads library.
This option sets flags for both the preprocessor and linker.

It seems to me that it sets both automatically, in this case.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Missing GLIBC_<version> tags on binaries

[Phil Blundell]

On Mon, 2011-02-28 at 19:33 +0000, Otavio Salvador wrote:
> On Mon, Feb 28, 2011 at 17:17, Phil Blundell <philb@gnu.org> wrote:
> ...
> > That's definitely not a patch that you ought to check in, though.  For
> > wider consumption I guess there ought to be some kind of knob that
> > DISTROs can tweak to select the linker of their choice.  As far as I
> > know there isn't any such mechanism at present.
> 
> One interesting way to "fix" the issue is to explicitly link against
> -lpthread however it seems *wrong*.
> 
> It seems to be a gcc bug since -pthread is suppose to handle all the
> needed background for it to work and seems to be doing it wrong.

I just tried linking xfreerdp by hand with gold and the resulting binary
seemed to come out fine.  So I think this is indeed a bug in GNU ld.

It does seem to be sensitive to the order in which things are mentioned
in the command line: if you put -lpthread first then GNU ld gets it
right.  But if -lpthread is at the end then it seems to fail to pick up
the versioning information for symbols which are also mentioned (even as
SHT_UNDEF) in other objects.  Clearly that can't be the whole story
though because if it was that simple then it would be failing with
everything.  I guess you need to either debug this further or switch to
using gold for your own builds.

p.

Re: Missing GLIBC_<version> tags on binaries

[Otavio Salvador]

On Tue, Mar 1, 2011 at 11:35, Phil Blundell <philb@gnu.org> wrote:
> On Mon, 2011-02-28 at 19:33 +0000, Otavio Salvador wrote:
>> On Mon, Feb 28, 2011 at 17:17, Phil Blundell <philb@gnu.org> wrote:
> I just tried linking xfreerdp by hand with gold and the resulting binary
> seemed to come out fine.  So I think this is indeed a bug in GNU ld.

Personally I think we need to trace it down (we as project) since it
can lead to broken and difficult to trace behaviour. It took 3 days
until I managed to identify the symbol failure.

I am far from an expert on linking and GNU ld. For debugging it I'd
need guidance.

> It does seem to be sensitive to the order in which things are mentioned
> in the command line: if you put -lpthread first then GNU ld gets it
> right.  But if -lpthread is at the end then it seems to fail to pick up
> the versioning information for symbols which are also mentioned (even as
> SHT_UNDEF) in other objects.  Clearly that can't be the whole story
> though because if it was that simple then it would be failing with
> everything.  I guess you need to either debug this further or switch to
> using gold for your own builds.

For now, I did:

+do_configure_prepend() {
+       # workaround gcc linking bug
+       find ${S} -name 'Makefile.am' | xargs -n 1 sed
's,-pthread,-lpthread -D_REENTRANT,g' -i
+}

This fixes the issue for me, but it is clearly a workaround.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Missing GLIBC_<version> tags on binaries

[Phil Blundell]

On Tue, 2011-03-01 at 11:47 +0000, Otavio Salvador wrote:
> On Tue, Mar 1, 2011 at 11:35, Phil Blundell <philb@gnu.org> wrote:
> > On Mon, 2011-02-28 at 19:33 +0000, Otavio Salvador wrote:
> >> On Mon, Feb 28, 2011 at 17:17, Phil Blundell <philb@gnu.org> wrote:
> > I just tried linking xfreerdp by hand with gold and the resulting binary
> > seemed to come out fine.  So I think this is indeed a bug in GNU ld.
> 
> Personally I think we need to trace it down (we as project) since it
> can lead to broken and difficult to trace behaviour. It took 3 days
> until I managed to identify the symbol failure.

Yeah, that might be true.  Or we could maybe just switch the default
linker to be gold, at least on targets that it supports. 

> I am far from an expert on linking and GNU ld. For debugging it I'd
> need guidance.

I think the place to start looking would be _bfd_elf_merge_symbol(),
which is in bfd/elflink.c.  This gets called by
elf_link_add_object_symbols() to record the syms that it finds and I
suspect that one or other of those functions is probably doing the wrong
thing.

Or, if you don't want to debug it yourself, you could try to create a
testcase that shows the problem and then file a bug report with binutils
upstream.

p.

Re: Missing GLIBC_<version> tags on binaries

[Khem Raj]

On (02/03/11 15:41), Phil Blundell wrote:
> On Tue, 2011-03-01 at 11:47 +0000, Otavio Salvador wrote:
> > On Tue, Mar 1, 2011 at 11:35, Phil Blundell <philb@gnu.org> wrote:
> > > On Mon, 2011-02-28 at 19:33 +0000, Otavio Salvador wrote:
> > >> On Mon, Feb 28, 2011 at 17:17, Phil Blundell <philb@gnu.org> wrote:
> > > I just tried linking xfreerdp by hand with gold and the resulting binary
> > > seemed to come out fine.  So I think this is indeed a bug in GNU ld.
> > 
> > Personally I think we need to trace it down (we as project) since it
> > can lead to broken and difficult to trace behaviour. It took 3 days
> > until I managed to identify the symbol failure.
> 
> Yeah, that might be true.  Or we could maybe just switch the default
> linker to be gold, at least on targets that it supports. 

Yes I have been doing this slowly for ARM. but probably it will be
better with gcc 4.6 where linker will be selectable with options

> 
> > I am far from an expert on linking and GNU ld. For debugging it I'd
> > need guidance.
> 
> I think the place to start looking would be _bfd_elf_merge_symbol(),
> which is in bfd/elflink.c.  This gets called by
> elf_link_add_object_symbols() to record the syms that it finds and I
> suspect that one or other of those functions is probably doing the wrong
> thing.
> 
> Or, if you don't want to debug it yourself, you could try to create a
> testcase that shows the problem and then file a bug report with binutils
> upstream.
> 
> p.
> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

-- 
-Khem

Re: Missing GLIBC_<version> tags on binaries

[Phil Blundell]

On Wed, 2011-03-02 at 20:18 -0800, Khem Raj wrote:
> On (02/03/11 15:41), Phil Blundell wrote:
> > Yeah, that might be true.  Or we could maybe just switch the default
> > linker to be gold, at least on targets that it supports. 
> 
> Yes I have been doing this slowly for ARM. but probably it will be
> better with gcc 4.6 where linker will be selectable with options

I'm not quite sure I understand what you're saying there.  Can you
clarify?

p.

Re: Missing GLIBC_<version> tags on binaries

[Khem Raj]

On 3/4/2011 8:09 AM, Phil Blundell wrote:
> On Wed, 2011-03-02 at 20:18 -0800, Khem Raj wrote:
>> On (02/03/11 15:41), Phil Blundell wrote:
>>> Yeah, that might be true.  Or we could maybe just switch the default
>>> linker to be gold, at least on targets that it supports.
>>
>> Yes I have been doing this slowly for ARM. but probably it will be
>> better with gcc 4.6 where linker will be selectable with options
>
> I'm not quite sure I understand what you're saying there.  Can you
> clarify?
>

I am talking about --with-linker option

> p.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Missing GLIBC_<version> tags on binaries

[Phil Blundell]

On Fri, 2011-03-04 at 08:54 -0800, Khem Raj wrote:
> I am talking about --with-linker option

Does that make much of a difference here?  I would have thought that any
given DISTRO would probably want to use either gold or ld.bfd as the
default and they could manage that by just configuring binutils
appropriately, and/or by installing a wrapper script for ld.  It's not
totally obvious to me that --with-linker solves any significant problem.

p.

Re: Missing GLIBC_<version> tags on binaries

[Khem Raj]

On Fri, Mar 4, 2011 at 1:47 PM, Phil Blundell <philb@gnu.org> wrote:
> On Fri, 2011-03-04 at 08:54 -0800, Khem Raj wrote:
>> I am talking about --with-linker option
>
> Does that make much of a difference here?  I would have thought that any
> given DISTRO would probably want to use either gold or ld.bfd as the
> default and they could manage that by just configuring binutils
> appropriately, and/or by installing a wrapper script for ld.  It's not
> totally obvious to me that --with-linker solves any significant problem.
>

I think there is more to integration of gold in 4.6 since in local
setups I have got trunk/4.6 working well with gold but not 4.5
since trunk worked for me I really did not dig deeper why it would not
work on 4.5

> p.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>