On Fri, Jun 21, 2019 at 10:29 AM Iain Sandoe <i...@sandoe.co.uk> wrote:
>
> Hi Christophe,
>
> we’ve been looking at some cases where Darwin tests fail or pass unexpectedly
> depending on
> options. It came as a surprise to see it failing a test for shared support
> (since it’s always
> supported shared libs).
>
> -----
>
> It’s a long time ago, but in r216117 you added this to target-supports.
>
> # Return 1 if -shared is supported, as in no warnings or errors
> # emitted, 0 otherwise.
>
> proc check_effective_target_shared { } {
> # Note that M68K has a multilib that supports -fpic but not
> # -fPIC, so we need to check both. We test with a program that
> # requires GOT references.
> return [check_no_compiler_messages shared executable {
> extern int foo (void); extern int bar;
> int baz (void) { return foo () + bar; }
> } "-shared -fpic”
> }
>
> ====
>
> The thing is that this is testing two things:
>
> 1) if the target consumes -shared -fpic without warning
>
> 2) assuming that those cause a shared lib to be made it also tests that
> the target will allow a link of that to complete with undefined symbols.
>
> So Darwin *does* support “-shared -fpic” and is very happy to make
> shared libraries. However, it doesn’t (by default) allow undefined symbols
> in the link.
AIX similarly does not allow undefined symbols in a link by default.
>
> So my question is really about the intent of the test:
>
> if the intent is to see if the target supports shared libs, then we should
> arrange for Darwin to pass - either by hardwiring it (since all Darwin
> versions do support shared) or by adding suitable options to suppress
> the error.
>
> if the intent is to check that the target supports linking a shared lib with
> undefined external symbols, then perhaps we need a different test for the
> “just supports shared libs”
Thanks, David
