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.
