Bug 835292 - Why is iso99_sscanf function genererated by default on RH 6.2
Why is iso99_sscanf function genererated by default on RH 6.2
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc (Show other bugs)
6.2
x86_64 Linux
unspecified Severity urgent
: rc
: ---
Assigned To: Carlos O'Donell
qe-baseos-tools
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-25 17:05 EDT by Arvind Amin
Modified: 2016-11-24 11:03 EST (History)
5 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Arvind Amin 2012-06-25 17:05:11 EDT
Description of problem:
During a link under Red Hat 6.2 I get undefined reference error shown here:

undefined reference to `__isoc99_sscanf'

No such error on Red Hat 5.5.
This is rooted in the difference in stdio.h between RH 5.x and RH 6.x.

Version-Release number of selected component (if applicable):

Red Hat 6.2

How reproducible:

See the difference in stdio.h header file between RH 5.5 and RH 6.2.

Steps to Reproduce:
1.
2.
3.
  
Actual results:



Expected results:


Additional info:
Comment 1 yawei Li 2012-07-09 06:08:09 EDT
would you please confirm you are raising bug for bugzilla? Maybe you want to raise bug for RH6.2?

As I have double checked bugzilla link can be displayed successfully on RHEL 6.2.
Comment 2 Arvind Amin 2012-07-09 08:40:42 EDT
I am reporting the bug for RH 6.2. I don't know enough about the differences between bugzilla and Red Hat. Please focus on the stdio.h header file differences between RH 5.5 and RH 6.2.

Thanks.

Arvind
Comment 3 yawei Li 2012-07-10 02:41:00 EDT
move this bug to RHEL 6 and version 6.2, but not sure the component.
Comment 6 Jakub Jelinek 2012-08-27 07:35:16 EDT
The default feature test macros are different between the two glibc releases, __isoc99_* are the alternative entry points that ensure ISO C99 standard compliance.
Comment 7 Jeff Law 2012-08-27 11:58:09 EDT
isoc99_sscanf (and other related functions) were introduced in 2007 for compliance with the C99 standard.  As part of the introduction of the C99 support, "sscanf" is redirected to "__isoc99_sscanf" by way of a #define in /usr/include/stdio.h.

That #define does not exist on RHEL 5.


Arvind, what we need from you is a reproducible testcase so that we can investigate why the linker was unable to resolve this symbol.
Comment 9 Jeff Law 2013-04-08 14:39:17 EDT
Arvind, per comment #7, we need a testcase which shows this problem so that we can analyze and take appropriate action.  Without a testcase there really isn't anything we can do at this time.
Comment 11 Arvind Amin 2013-04-08 19:29:44 EDT
I am including a small test. I have compiled this test on RH 5.3 and RH 6.5 to show the difference in the scanf function code generation. As I mentioned, there is a change in the header files which causes this issue. See the undefined scanf function name difference show in the output of nm command.
[aamin@cthor-jkt2 dds3]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.3 (Santiago)
[aamin@cthor-jkt2 dds3]$ cat scanf_test.c
#include <string.h>
#include <stdio.h>
double cdds_scale(
   const char *out,
   const char *in)
{

        static char c_rcs_ver[] = " $Revision: 120.3 $ ";
   char str[8];
   float scale_out, scale_in;
   double scale;
   if(! strcmp(out, "sec")) {
      if(! strcmp(in, "sec")) {
         scale = 1.;
      } else if(2 == sscanf(in, "%f%7s", &scale_in, str) &&
         ! strcmp(str, "sec")) {
         scale = scale_in;
      } else {
         scale = 0.;
      }
}
return(scale);
}
[aamin@cthor-jkt2 dds3]$ gcc -c scanf_test.c
[aamin@cthor-jkt2 dds3]$ nm scanf_test.o
                 U __isoc99_sscanf
0000000000000000 d c_rcs_ver.2219
0000000000000000 T cdds_scale
                 U strcmp
[aamin@cthor-jkt2 dds3]$
[aamin@cthor-aa ~]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
[aamin@cthor-aa ~]$ cat scanf_test.c
#include <string.h>
#include <stdio.h>
double cdds_scale(
   const char *out,
   const char *in)
{

        static char c_rcs_ver[] = " $Revision: 120.3 $ ";
   char str[8];
   float scale_out, scale_in;
   double scale;
   if(! strcmp(out, "sec")) {
      if(! strcmp(in, "sec")) {
         scale = 1.;
      } else if(2 == sscanf(in, "%f%7s", &scale_in, str) &&
         ! strcmp(str, "sec")) {
         scale = scale_in;
      } else {
         scale = 0.;
      }
}
return(scale);
}
[aamin@cthor-aa ~]$ gcc -c scanf_test.c
[aamin@cthor-aa ~]$ nm scanf_test.o
0000000000000000 d c_rcs_ver.2251
0000000000000000 T cdds_scale
                 U sscanf
[aamin@cthor-aa ~]$
Comment 12 Jeff Law 2013-04-11 17:36:28 EDT
Avind,

As I mentioned in comment #7, it is expected that sscanf gets remapped to __isoc99_sscanf to conform to the ISO standards.

Thus the nm output you showed with:

                 U __isoc99_sscanf

On RHEL 6 is normal and expected.

The __isoc99_sscanf symbol is satisfied by the C library.

[law@localhost ~]$ nm /lib64/libc.so.6 | grep scanf | grep __isoc99_scanf
0000000000063b70 T __isoc99_scanf


In your original problem description you indicated you were receiving a link failure.  I need a testcase showing that link failure.  If I take the testcase from your most recent command and add a main() function, it links fine.

[law@localhost ~]$ more j.c
#include <string.h>
#include <stdio.h>
double cdds_scale(
   const char *out,
   const char *in)
{

        static char c_rcs_ver[] = " $Revision: 120.3 $ ";
   char str[8];
   float scale_out, scale_in;
   double scale;
   if(! strcmp(out, "sec")) {
      if(! strcmp(in, "sec")) {
         scale = 1.;
      } else if(2 == sscanf(in, "%f%7s", &scale_in, str) &&
         ! strcmp(str, "sec")) {
         scale = scale_in;
      } else {
         scale = 0.;
      }
}
return(scale);
}
main(){}
[law@localhost ~]$ !2
gcc -c j.c
[law@localhost ~]$ !3
nm j.o
                 U __isoc99_sscanf
0000000000000000 d c_rcs_ver.2219
0000000000000000 T cdds_scale
00000000000000b5 T main
                 U strcmp
[law@localhost ~]$ !4
gcc j.o
[law@localhost ~]$
Comment 13 Arvind Amin 2013-04-11 19:56:57 EDT
The link problem is with -static option. Also, if I use -D_GNU_SOURCE option for compilation the sscanf function generates the old symbol and the problem is resolved. It appears that the lack of static link on the recent RH 6.x release is causing these issues. If you like you can close the case. However, it will be great if such issues are widely documented.

Thanks for the follow up.
Comment 14 Jeff Law 2013-04-12 01:03:11 EDT
The link can (and does) succeed with -static:

#include <string.h>
#include <stdio.h>
double cdds_scale(
   const char *out,
   const char *in)
{

        static char c_rcs_ver[] = " $Revision: 120.3 $ ";
   char str[8];
   float scale_out, scale_in;
   double scale;
   if(! strcmp(out, "sec")) {
      if(! strcmp(in, "sec")) {
         scale = 1.;
      } else if(2 == sscanf(in, "%f%7s", &scale_in, str) &&
         ! strcmp(str, "sec")) {
         scale = scale_in;
      } else {
         scale = 0.;
      }
}
return(scale);
}
main(){}
[law@localhost ~]$ gcc -static j.c
[law@localhost ~]$ gcc -c j.c
[law@localhost ~]$ nm j.o
                 U __isoc99_sscanf
0000000000000000 d c_rcs_ver.2219
0000000000000000 T cdds_scale
00000000000000b5 T main
                 U strcmp
[law@localhost ~]$ gcc -static j.o
[law@localhost ~]$ rpm -qa | grep glibc
glibc-headers-2.12-1.80.el6.x86_64
glibc-common-2.12-1.80.el6.x86_64
glibc-static-2.12-1.80.el6.x86_64
glibc-devel-2.12-1.80.el6.x86_64
glibc-2.12-1.80.el6.x86_64


The behaviour with -D_GNU_SOURCE is as expected; when _GNU_SOURCE is defined the definition which redirects sscanf to isoc99_sscanf is disabled.

At this point I don't see a bug in the behaviour of any of the tools.  Could you please show me the actual failing testcase, compilation line, nm symbols, link line, output from failed link, output from rpm -qa.
Comment 15 Arvind Amin 2013-04-12 07:22:23 EDT
I am including the original link error which happened almost a year ago. We used the work around and moved on. I no longer have the original app environment available since it was a customer project. As I said, it may be a documentation need.

[aamin@cthor-jkt2 async]$ ifort  -static -Wl,--allow-multiple-definition  -openmp -o bin/Linux/2.6/x86_64/ffdmig Linux/2.6/x86_64/Intel-12/*.o  -L/home1/aamin/cfs/mde125/lib/Linux/2.6/x86_64/Intel-13  -lfft -ldds_r3 -L/home1/aamin/cfs/mde125/lib/cm -lcmiog -lgenlib -lgio -lfhost -Wl,--start-group -L/opt/intel/impi/4.0.3.008/intel64/lib  -lmpi_mt -lmpigf -lmpigi -Wl,--end-group  -Wl,--start-group -lmkl_intel_lp64 -lmkl_core -lmkl_intel_thread -Wl,--end-group  -L/usr/lib/x86_64-redhat-linux5E/lib64 -lirc -lifcoremt -lifport -liomp5 -limf -lirc -lsvml -lstdc++ -lippac_l -lippi_l -lippcc_l -lipps_l -lippch_l -lippj_l -lippvc_l -lippcv_l -lippm_l -lippvm_l -lippdc_l -lippr_l -lippdi_l -lippsc_l -lippcore_l
/home1/aamin/cfs/mde125/lib/Linux/2.6/x86_64/Intel-13/libdds_r3.a(dicttmp.o): In function `ddsDictTmp':
../dicttmp.c:(.text+0x39): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
/opt/intel/impi/4.0.3.008/intel64/lib/libmpi_mt.a(dapl_util.o): In function `MPID_nem_dapl_util_get_ia_addr':
../../dapl_util.c:(.text+0xc4): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/opt/intel/impi/4.0.3.008/intel64/lib/libmpi_mt.a(tcp_init.o): In function `MPID_nem_tcp_get_business_card':
../../tcp_init.c:(.text+0x8ae): warning: Using 'gethostbyaddr' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/opt/intel/impi/4.0.3.008/intel64/lib/libmpi_mt.a(simple_pmi.o): In function `iPMI_Init':
../../simple_pmi.c:(.text+0x54ec): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/opt/intel/impi/4.0.3.008/intel64/lib/libmpi_mt.a(ofa_init.o): In function `load_ibv_library':
../../ofa_init.c:(.text+0x7fb): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home1/aamin/cfs/mde125/lib/Linux/2.6/x86_64/Intel-13/libdds_r3.a(dictinit.o): In function `ddsDictInit':
../dictinit.c:(.text+0x5dc): undefined reference to `__isoc99_sscanf'
/home1/aamin/cfs/mde125/lib/Linux/2.6/x86_64/Intel-13/libdds_r3.a(dictfd.o): In function `ddsDictFd':
../dictfd.c:(.text+0x29): undefined reference to `__isoc99_sscanf'
/home1/aamin/cfs/mde125/lib/Linux/2.6/x86_64/Intel-13/libdds_r3.a(mde_c_print.o): In function `Closepr':
../mde_c_print.c:(.text+0x166b): undefined reference to `__isoc99_sscanf'
../mde_c_print.c:(.text+0x1708): undefined reference to `__isoc99_sscanf'
../mde_c_print.c:(.text+0x1d4e): undefined reference to `__isoc99_sscanf'
/home1/aamin/cfs/mde125/lib/Linux/2.6/x86_64/Intel-13/libdds_r3.a(mde_c_print.o):../mde_c_print.c:(.text+0x2542): more undefined references to `__isoc99_sscanf' follow
/home1/aamin/cfs/mde125/lib/Linux/2.6/x86_64/Intel-13/libdds_r3.a(mediaunload.o): In function `ddsMediaUnload':
../mediaunload.c:(.text+0x78): undefined reference to `__isoc99_fscanf'
/home1/aamin/cfs/mde125/lib/Linux/2.6/x86_64/Intel-13/libdds_r3.a(symexpr2c.o): In function `ddsSymExpr2C':
../symexpr2c.c:(.text+0x146): undefined reference to `__isoc99_sscanf'
/home1/aamin/cfs/mde125/lib/Linux/2.6/x86_64/Intel-13/libdds_r3.a(c_scale.o): In function `cdds_scale':
../c_scale.c:(.text+0x1ce): undefined reference to `__isoc99_sscanf'
../c_scale.c:(.text+0x32b): undefined reference to `__isoc99_sscanf'
../c_scale.c:(.text+0x488): undefined reference to `__isoc99_sscanf'
../c_scale.c:(.text+0x5e5): undefined reference to `__isoc99_sscanf'
/home1/aamin/cfs/mde125/lib/Linux/2.6/x86_64/Intel-13/libdds_r3.a(c_scale.o):../c_scale.c:(.text+0x60b): more undefined references to `__isoc99_sscanf' follow
Comment 16 Jeff Law 2013-04-12 10:02:35 EDT
Thanks Arvind, those logs I think point the way to the problem.

Note in the arguments to ifort this link path:

L/usr/lib/x86_64-redhat-linux5E/lib64

That's the link path to the compat-glibc libraries.  Those libraries provide a glibc with a RHEL 5 symbol set and as you know, the mapping from sscanf to isoc99_sscanif does not exist in RHEL 5. 


If you're going to use the compat-glibc libraries for linking you must use the compat-glibc headers when you compile your code.  Otherwise you're compiling for RHEL6, but linking against a RHEL 5 symbol table -- that clearly will not work and is not supported.

The compat-glibc-headers package provides the RHEL 5 headers in /usr/lib/x86_64-redhat-linux5E/include.
Comment 17 Arvind Amin 2013-04-12 10:07:50 EDT
Unfortunately, I cannot reconstruct the problem. Note, I had user app libraries built under RH 5.5 which may have necessitate that particular library. The point is that we broke the compatibility when moving to RH 6.0. Anyway, we have a work around solution. No reason to rehash this at this point. Thanks for looking into the problem.

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