- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
Link Copied
10 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - bustaf
You having already success build with GNU compiler ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 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([], [[#ifndef __INTEL_COMPILER choke me #endif ]])], [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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 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([], [[#ifndef __INTEL_COMPILER choke me #endif ]])], [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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is this still an issue with latest Intel compiler?
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page