This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/15926] New: _itoa multiply defined with -static
- From: "baker at usgs dot gov" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 03 Sep 2013 07:51:30 +0000
- Subject: [Bug libc/15926] New: _itoa multiply defined with -static
- Auto-submitted: auto-generated
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.