Bug 487995 - basename prototype mis-match between libiberty.h and string.h
basename prototype mis-match between libiberty.h and string.h
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: binutils (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Nick Clifton
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-01 23:32 EST by William Cohen
Modified: 2009-04-09 10:45 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-09 10:45:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
short program prototype mismatch (143 bytes, text/x-c++src)
2009-03-01 23:32 EST, William Cohen
no flags Details

  None (edit)
Description William Cohen 2009-03-01 23:32:29 EST
Created attachment 333680 [details]
short program prototype mismatch

Description of problem:

The declaration in /usr/include/libiberty.h from binutils-devel rpm for basename does not match the current declaration in /usr/include/string.h. When compiling oprofile got the following error:

g++ -DHAVE_CONFIG_H -I. -I..  -I ../libutil -I ../libop -I ../libpp  -W -Wall -fno-common -ftemplate-depth-50 -g -MT child_reader.o -MD -MP -MF .deps/child_reader.Tpo -c -o child_reader.o child_reader.cpp
In file included from ../libutil/op_libiberty.h:27,
                 from child_reader.cpp:22:
/usr/include/libiberty.h:105: error: new declaration ‘char* basename(const char*)’
/usr/include/string.h:599: error: ambiguates old declaration ‘const char* basename(const char*)’
make[3]: *** [child_reader.o] Error 1
make[3]: Leaving directory `/home/wcohen/rh-rpms/BUILD/oprofile-0.9.4/libutil++'
make[2]: *** [all-recursive] Error 1

Can see this problem in:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1186823

Version-Release number of selected component (if applicable):
binutils-devel-2.19.51.0.2-14.fc11.i586
glibc-headers-2.9.90-8.1.i586

How reproducible:

Every time. Can reproduce with simple program.

Attempt to build 


Steps to Reproduce:
1. have the needed rpms installed on machine
2. g++ -c b.cpp
  
Actual results:

Get the following error:

 g++ -c /tmp/b.cpp
In file included from /tmp/b.cpp:2:
/usr/include/libiberty.h:105: error: new declaration ‘char* basename(const char*)’
/usr/include/string.h:599: error: ambiguates old declaration ‘const char* basename(const char*)’
/tmp/b.cpp: In function ‘int main(int, char**)’:
/tmp/b.cpp:9: error: invalid conversion from ‘const char*’ to ‘char’



Expected results:

Compile without error.


Additional info:
Comment 1 Nick Clifton 2009-03-06 06:21:24 EST
Hi Will,

  First of all there is a small mistake in your example program (b.cpp).  Currently you are assigning the result of calling basename() into a char, hence the error message for line 9 in b.cpp.  Also the pointer returned by basename, according to string.h, is a const char *, so you have a type mismatch as well.  Hence I changed the source to:

  [...]
  const char *b;
  int main(int argc, char **argv)
  {
    b = basename("/usr/bin/xyz.sdf");
  [...]

Which just leaves the ambiguity between libiberty.h and string.h.  I do not really think that libiberty.h is at fault here, since it is following the XPG specifications for the basename function.  (Rather than the ISO C++ specification which is what is being used by string.h).  An easy workaround is to define HAVE_DECL_BASENAME to 1 before including libiberty.h, like this:

  #include <string.h>
  #define HAVE_DECL_BASENAME 1
  #include <libiberty.h>

Or use autoconf to test for basename and include config.h before libiberty.h.

Cheers
  Nick
Comment 2 William Cohen 2009-04-08 15:42:02 EDT
Added the following in the configure.in:

AC_CHECK_DECLS([basename], [], [], [[#include <libgen.h>]])

This produces the needed define in config.h and allows things to compile on f11.
Comment 3 William Cohen 2009-04-09 10:45:35 EDT
Have fix in oprofile-0.9.4-6.fc11.

Note You need to log in before you can comment on or make changes to this bug.