linker problems with builtins on fedora11

linker problems with builtins on fedora11

Hi,

I'm trying to build openchange (http://www.openchange.org) with icc / icpc on a Fedora 11 box.

The build dies with:
libmapi.so.0.8: undefined reference to `__builtin_object_size'
libmapi.so.0.8: undefined reference to `__builtin___memset_chk'
libmapi.so.0.8: undefined reference to `__builtin___strcpy_chk'
libmapi.so.0.8: undefined reference to `__builtin___memcpy_chk'
libmapi.so.0.8: undefined reference to `__builtin___strncpy_chk'
libmapi.so.0.8: undefined reference to `__builtin_va_arg_pack'

when I try to link an executable.

I tried passing -fno-builtin (using CFLAGS, to the configure script), and doing a complete rebuild, but the results are unchanged.

I'm using
icc (ICC) 11.1 20090630
and
icpc (ICC) 11.1 20090630

If I comment-out the strcpy call, then __builtin___strcpy_chk disappears from the linker errors, but I'm still not sure how to address this problem.

11 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Quoting - Brad Hards
Hi,

I'm trying to build openchange (http://www.openchange.org) with icc / icpc on a Fedora 11 box.

The build dies with:
libmapi.so.0.8: undefined reference to `__builtin_object_size'
libmapi.so.0.8: undefined reference to `__builtin___memset_chk'
libmapi.so.0.8: undefined reference to `__builtin___strcpy_chk'
libmapi.so.0.8: undefined reference to `__builtin___memcpy_chk'
libmapi.so.0.8: undefined reference to `__builtin___strncpy_chk'
libmapi.so.0.8: undefined reference to `__builtin_va_arg_pack'

when I try to link an executable.

I tried passing -fno-builtin (using CFLAGS, to the configure script), and doing a complete rebuild, but the results are unchanged.

I'm using
icc (ICC) 11.1 20090630
and
icpc (ICC) 11.1 20090630

If I comment-out the strcpy call, then __builtin___strcpy_chk disappears from the linker errors, but I'm still not sure how to address this problem.

Hi
You having already success build with GNU compiler ?

Kind regards

Quoting - bustaf

You having already success build with GNU compiler ?

That's a fair question, as a problem could exist when the source code isn't compatible with the g++ you have active.

Quoting - tim18

Quoting - bustaf

You having already success build with GNU compiler ?

That's a fair question, as a problem could exist when the source code isn't compatible with the g++ you have active.

I have built (and rebuilt, from clean sources) with gcc/g++ (version 4.4.0).

I have an buildbot (continuous integration tool) set up (http://colo1.frogmouth.net:8010) that shows both gcc and icc builds.

Brad

Quoting - Brad Hards

I have built (and rebuilt, from clean sources) with gcc/g++ (version 4.4.0).

I have an buildbot (continuous integration tool) set up (http://colo1.frogmouth.net:8010) that shows both gcc and icc builds.

Brad

A bit more investigation shows that the problem might be related to use of -Wp,-D_FORTIFY_SOURCE=2 option on the command line. It looks like it builds OK without that option.

So a couple of options to work around this:
1. Can I provide extra builtins?
2. Is there an easy way to detect icc / icpc using autoconf so that I can vary the command line arguments?

Brad

Quoting - Brad Hards

Quoting - Brad Hards

I have built (and rebuilt, from clean sources) with gcc/g++ (version 4.4.0).

I have an buildbot (continuous integration tool) set up (http://colo1.frogmouth.net:8010) that shows both gcc and icc builds.

Brad

A bit more investigation shows that the problem might be related to use of -Wp,-D_FORTIFY_SOURCE=2 option on the command line. It looks like it builds OK without that option.

So a couple of options to work around this:
1. Can I provide extra builtins?
2. Is there an easy way to detect icc / icpc using autoconf so that I can vary the command line arguments?

Brad

Hi
Probably exact, -D_FORTIFY_SOURCE=2 can be problem
but i am surprise that g give success and icc false ...
(if contextual , are the two compiler in same machine O/S).
-D_FORTIFY_SOURCE=2 have made problem also already with compiler GNU
more old that last versions.

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html

About (autoscan, aclocal ,autoheader,autoconf,automake,i think well for two compiler (very similar). personal , I rectify manually as better ICC and remove not existing equivalence Icc in file Makefile result. (if required)
Probably would obtain better directly that have great practice this type utility...
(i using little this side)

Kind regards

Quoting - bustaf

Hi
Probably exact, -D_FORTIFY_SOURCE=2 can be problem
but i am surprise that g give success and icc false ...
(if contextual , are the two compiler in same machine O/S).
-D_FORTIFY_SOURCE=2 have made problem also already with compiler GNU
more old that last versions.

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html

About (autoscan, aclocal ,autoheader,autoconf,automake,i think well for two compiler (very similar). personal , I rectify manually as better ICC and remove not existing equivalence Icc in file Makefile result. (if required)
Probably would obtain better directly that have great practice this type utility...
(i using little this side)

I am having a bit of trouble following you. I guess:
1. you are asking if the two build environments are the same (they are - its the same machine)
2. that you are suggesting using the latest gcc / g++ (I am using gcc (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2), which is pretty recent)
3. that I hand-modify the output of autoconf (I did this to check the problem, but it isn't practical with a continuous integration tool, or in software that is only shipped as source)

Brad

Quoting - Brad Hards

Quoting - bustaf

Hi
Probably exact, -D_FORTIFY_SOURCE=2 can be problem
but i am surprise that g give success and icc false ...
(if contextual , are the two compiler in same machine O/S).
-D_FORTIFY_SOURCE=2 have made problem also already with compiler GNU
more old that last versions.

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html

About (autoscan, aclocal ,autoheader,autoconf,automake,i think well for two compiler (very similar). personal , I rectify manually as better ICC and remove not existing equivalence Icc in file Makefile result. (if required)
Probably would obtain better directly that have great practice this type utility...
(i using little this side)

I am having a bit of trouble following you. I guess:
1. you are asking if the two build environments are the same (they are - its the same machine)
2. that you are suggesting using the latest gcc / g++ (I am using gcc (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2), which is pretty recent)
3. that I hand-modify the output of autoconf (I did this to check the problem, but it isn't practical with a continuous integration tool, or in software that is only shipped as source)

Brad

Hi
I think if you take times to read and understand source that you want compile is easy to align correct parameter flag for GCC to ICC.
Some Lib major used by Icc more older last GCC.
Read the the number versions library required for install Icc before to add improbable or wrong parameters .
Use ldd utility over resulting GCC as reference for you compare.
you can also use last lib gcc with dummy link old to last for Icc , but warning can be occur others side problems.

Kind regards

Quoting - bustaf

Hi
I think if you take times to read and understand source that you want compile is easy to align correct parameter flag for GCC to ICC.
Some Lib major used by Icc more older last GCC.
Read the the number versions library required for install Icc before to add improbable or wrong parameters .
Use ldd utility over resulting GCC as reference for you compare.
you can also use last lib gcc with dummy link old to last for Icc , but warning can be occur others side problems.

Kind regards

I think I've read and understood the code - I wrote it, after all. After tryint to understand what you've written, I'm still not sure what you're trying to tell me.

I can say that I worked around the problem with autoconf:

[shell]dnl ###########################################################################
dnl _AC_LANG_COMPILER_ICC
dnl Check whether the compiler for the current language is really ICC.
dnl ###########################################################################
m4_define([AC_LANG_COMPILER_ICC],
[AC_CACHE_CHECK([whether we are really using the Intel _AC_LANG compiler],
                [ac_cv_[]_AC_LANG_ABBREV[]_compiler_icc],
[_AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], )],
                   [ac_compiler_icc=yes],
                   [ac_compiler_icc=no])
ac_cv_[]_AC_LANG_ABBREV[]_compiler_icc=$ac_compiler_icc
])])
[/shell]

and

[shell]dnl if it isn't icc, then use the gcc options
dnl otherwise suppress some noise from icc
if test x"$ac_cv_c_compiler_icc" != x"yes"; then
    CFLAGS="$CFLAGS -Wp,-D_FORTIFY_SOURCE=2"
else
    CFLAGS="$CFLAGS -wd2259,593,869,981,181,1419,2218"
fi
[/shell]

I think this is a limitation in icc that would be nice to have fixed in a future version.

Brad

Quoting - Brad Hards

Quoting - bustaf

Hi
I think if you take times to read and understand source that you want compile is easy to align correct parameter flag for GCC to ICC.
Some Lib major used by Icc more older last GCC.
Read the the number versions library required for install Icc before to add improbable or wrong parameters .
Use ldd utility over resulting GCC as reference for you compare.
you can also use last lib gcc with dummy link old to last for Icc , but warning can be occur others side problems.

Kind regards

I think I've read and understood the code - I wrote it, after all. After tryint to understand what you've written, I'm still not sure what you're trying to tell me.

I can say that I worked around the problem with autoconf:

[shell]dnl ###########################################################################
dnl _AC_LANG_COMPILER_ICC
dnl Check whether the compiler for the current language is really ICC.
dnl ###########################################################################
m4_define([AC_LANG_COMPILER_ICC],
[AC_CACHE_CHECK([whether we are really using the Intel _AC_LANG compiler],
                [ac_cv_[]_AC_LANG_ABBREV[]_compiler_icc],
[_AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], )],
                   [ac_compiler_icc=yes],
                   [ac_compiler_icc=no])
ac_cv_[]_AC_LANG_ABBREV[]_compiler_icc=$ac_compiler_icc
])])
[/shell]

and

[shell]dnl if it isn't icc, then use the gcc options
dnl otherwise suppress some noise from icc
if test x"$ac_cv_c_compiler_icc" != x"yes"; then
    CFLAGS="$CFLAGS -Wp,-D_FORTIFY_SOURCE=2"
else
    CFLAGS="$CFLAGS -wd2259,593,869,981,181,1419,2218"
fi
[/shell]

I think this is a limitation in icc that would be nice to have fixed in a future version.

Brad

Hi
Option -D_FORTIFY_SOURCE=2 with compiler 4.3.x also not working correctly
( greater problem, compile success (with warning) but program result running wrong.)
(tested (64)machine)
Is not limitation Icc is just probably partial or no compatibility Lib.
Just wait for last lib accorded with futures new version Icc for probably result perfectly
compatibility.
Better as can working correctly, but i have some doubt about vulnerability reality
in this side , to see is an side , to make with is is an other problem.....
Proportional probability leak secure system
(same you add secure windows house that probably have not the door).
It's well that you have discover this problem compatibility and show problem for all users ICC and older Gnu compiler.
Kind regards

Is this still an issue with latest Intel compiler?

Login to leave a comment.