[Bug libc/15926] New: _itoa multiply defined with -static

["baker at usgs dot gov" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=15926

            Bug ID: 15926
           Summary: _itoa multiply defined with -static
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: baker at usgs dot gov
                CC: drepper.fsp at gmail dot com

I am trying to port an application to an embedded ARMV5TE SoC.  I am
cross-compiling using the Yocto Project tool kit.  One of the libraries in the
application defines its own _itoa() function if the platform is not Windows. 
When linking normally (shared), there is no problem.  When linking -static, I
cannot get rid of the multiply defined link errors for the collision with
_itoa.c from libc.a.  -static linking does work when I comment out the private
_itoa().  But, if I then remove the -static option from the link, it fails with
an undefined reference to _itoa().

There seems to be a mixup with the visibility of _itoa() between the libc.a and
libc.so libraries.  Maybe it is being brought in from libc.a as part of a
module which is needed for a different entry point.  I hope there is some kind
of weak attribute that can be applied to _atoi() in that case so libc.a behaves
like libc.so.

I actually don't care which way you go -- I just need it to be the same with
either libc.a and libc.so.  Or, tell me how to get GCC to quit looking in
libc.a for a symbol that is already defined.

Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.