This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Do we care about binary compatibility of code produced by cross-compilers?


Paolo Carlini <paolo.carlini@oracle.com> writes:

>> In this specific case, because _Unwind_GetIPInfo is provided by the
>> compiler support libraries when it is present, it might be possible to
>> write a link test which works even if libc has not yet been built.
>> The idea would be something like this:
>>
>>   hold_LDFLAGS="$LDFLAGS"
>>   hold_LIBS="$LIBS"
>>   LDFLAGS="$LDFLAGS -nostdlib"
>>   LIBS="$LIBS -lgcc"
>>   AC_LINK_IFELSE([AC_LANG_PROGRAM([[extern void Unwind_GetIPInfo();]],
>>                                   [[Unwind_GetIPInfo();]])],
>>                  [gcc_cv_getipinfo=yes],
>>                  [gcc_cv_getipinfo=no])
>>   LDFLAGS="$hold_LDFLAGS"
>>   LIBS="$hold_LIBS"
>>   
> Thanks. Therefore you are suggesting changing the test itself, in
> /config along these ways, which would decouple it from libc, if I
> understand correctly. But it would remain a link-test, which would
> play bad with GCC_NO_EXECUTABLES in the libatsc++ configure.ac... What
> do you think?

You're right that GCC_NO_EXECUTABLES would break this, because of the
magic redefinition of AC_LINK_IFELSE.  However, I believe that this
test would in fact work, even if general linking did not work, if we
could get around the GCC_NO_EXECUTABLES problem somehow.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]