This is the mail archive of the mailing list for the GCC 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: Link tests after GCC_NO_EXECUTABLES

Bernd Schmidt wrote:

> "libstdc++-v3/" AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT ->
> which leads to
> checking for shl_load... configure: error: Link tests are not allowed
> 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
(650) 331-3385 x713

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