Bernd Schmidt wrote: > "libstdc++-v3/configure.ac" AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT -> > _LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF > > which leads to > checking for shl_load... configure: error: Link tests are not allowed > after GCC_NO_EXECUTABLES. > make[1]: *** [configure-target-libstdc++-v3] Error 1
Thanks. Perhaps the difference here is that <dlfcn.h> isn't available for MIPS/Power ELF, but is available in your configuration because you're building with uClibc as your C library? If so, I think there are ways that we can solve this problem that don't involve adding -msim. (I haven't looked at Jie's approach, so I can't comment on that.) > Jie had a patch for that, but I decided to fix it by just making things > link, since I've seen other occurrences of this problem over the years. > It just seems more robust not to require the configure scripts to avoid > linking. I disagree. Since the preferred bare-metal setup is that linking not work without -msim (or a -T option), we don't want configure tests that detect any properties that might depend on what happens when you link. We want to make sure that detected properties are a property only of the parts that a user isn't going to change. In any case, I think this is something that ought to be decided as a global policy for GCC and its run-time libraries, not something that differs between ports. In particular, if run-time libraries are allowed to depend on linking in their configure tests, that's something everyone should know. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
