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.
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”
===
(note, also the comment doesn’t match what’s actually done, but that’s prob
a cut & pasto).
thanks
Iain
