gcc 4.9.2 on rhel5

[Ricardo Telichevesky]

Mikhail, Jonathan,

     Thanks so much for your reply, Mikhail's suggestion of -fgnu89-inline works like a charm!
I'll try to play with the other suggestion Mikhail suggested, I'll report if makes any kind of impact in terms of inlining and code performance.

     Thanks again so much for your help,
     Ricardo

On 7/27/15 1:01 PM, Mikhail Maltsev wrote:
> On 07/27/2015 09:12 PM, Jonathan Wakely wrote:
>> On 27 July 2015 at 19:03, Ricardo Telichevesky wrote:
>>> Hello,
>>>
>>> Trying to compile gcc 4.9.2 on rhel5. Eventually got it compiled. Not sure
>>> what I did wrong, but in certain cases when using
>>> gcc -c ... the compiler "sticks"  some unwanted  symbols like:
>>>
>>> _strcspn_c1
>>> _strcpsn_c2
>>> _strspn_c1
>>>
>>> that obviously cause troubles when linking because each .o has this pesky
>>> stuff on it. Does it ring any bell? Anyone would know what triggers the
>>> compiler to automagically stick those symbols as globals in the code?
>> No idea. How did you configure gcc? ('gcc -v' will tell you).
>>
> Though I don't have an RHEL box, I think CentOS 5 should have somewhat similar
> package versions, and I remember having similar problems with that distro. The
> problem is caused by glibc headers (version 2.5-123.el5_11.1):
>
> /usr/include/bits/string2.h:
>
> [snip]
>
> #ifndef __STRING_INLINE
> # ifdef __cplusplus
> #  define __STRING_INLINE inline
> # else
> #  define __STRING_INLINE extern __inline
> # endif
> #endif
>
> [snip]
>
> __STRING_INLINE size_t __strcspn_c1 (__const char *__s, int __reject);
> __STRING_INLINE size_t
> __strcspn_c1 (__const char *__s, int __reject)
> {
>    register size_t __result = 0;
>    while (__s[__result] != '\0' && __s[__result] != __reject)
>      ++__result;
>    return __result;
> }
>
> Because of C99 inline semantics, out-of-line __strcspn_c1 will be defined with
> external linkage. In CentOS 6 (glibc 2.12-1.149.el6_6.9) this was fixed like this:
>
> #ifndef __STRING_INLINE
> # ifdef __cplusplus
> #  define __STRING_INLINE inline
> # else
> #  define __STRING_INLINE __extern_inline
> # endif
> #endif
>
> And __extern_inline is defined in /usr/include/sys/cdefs.h:
>
> #  define __extern_inline extern __inline __attribute__ ((__gnu_inline__))
>
> One possible workaround (which worked OK for me) is to use -fgnu89-inline flag.
> Though I think there is a better solution.
> Probably defining __STRING_INLINE to something appropriate (like "extern __inline
> __attribute__ ((__gnu_inline__))") before including glibc headers will help.
>