Support for different compilers

[Martin Buchholz]

Sure, the real world is very messy, and in practice one often ends up
writing tests that looks like "are we using gcc on macosx?" but the goal is
to have an overall portable codebase, one that has a chance of building out
of the box on a system you've never seen before.  When one day the
Security-Hardened-BeOS-on-s390 team sends you an email that the openjdk
build "Just Works", then you can retire.


On Tue, Feb 4, 2014 at 1:22 AM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

>
> On 2014-02-04 04:49, Martin Buchholz wrote:
>
>> I'll concede that when determining default compiler flags, those are
>> highly dependent on something like a "compiler family" and cannot be done
>> in the C/C++ sources themselves.  But even then, for many of the compiler
>> flags there should be feature based autoconf tests instead of relying on
>> guessing based on compiler family, e.g. does -Wl,-rpath work?
>>
>
> I object strongly to this. From time to time, "feature based tests" is
> popped into the discussion. While it might sound good in theory, let's look
> at what that actually mean in practice.
>
> Let's take your example, "does -Wl,-rpath work?" What do you mean by
> "work"?
> * That the compiler accept the argument without failing? Sure, that's not
> so hard to test, but what does it tell you?
> * That it produces output with certain characterstics? How do you
> determine if that is the case? Analyze the resulting binary with a tool?
> Does that tool work properly? How do you test *that*, if you don't trust
> anything? Otherwise you're just shifting your assumption from how the
> compiler works to how the tool works.
>
> And the complexity! Let's go real life. Look at the value of
> $SET_SHARED_LIBRARY_ORIGIN. It's ...
> for gcc on macosx:
> '-Xlinker -rpath -Xlinker @loader_path/.'
> for gcc on linux:
> '-Xlinker -z -Xlinker origin -Xlinker -rpath -Xlinker \$$$$ORIGIN[$]1'
> for oracle solaris studio:
> '-R\$$$$ORIGIN[$]1'
>
> Now, how would you go along to arrive at that by feature based testing? I
> can't even start to imagine.
>
> Secondly, we *do* have some "feature based tests". But I'd rather get rid
> of them, because they behave (and typically are) more like workarounds.
> Look at this code, for instance.
>
>   # Check for broken SuSE 'ld' for which 'Only anonymous version tag is
> allowed in executable.'
>   USING_BROKEN_SUSE_LD=no
>   if test "x$OPENJDK_TARGET_OS" = xlinux && test "x$GCC" = xyes; then
>     AC_MSG_CHECKING([for broken SuSE 'ld' which only understands anonymous
> version tags in executables])
>     echo "SUNWprivate_1.1 { local: *; };" > version-script.map
>     echo "int main() { }" > main.c
>     if $CXX -Xlinker -version-script=version-script.map main.c
> 2>&AS_MESSAGE_LOG_FD >&AS_MESSAGE_LOG_FD; then
>       AC_MSG_RESULT(no)
>       USING_BROKEN_SUSE_LD=no
>     else
>       AC_MSG_RESULT(yes)
>       USING_BROKEN_SUSE_LD=yes
>     fi
>     rm -rf version-script.map main.c
>   fi
>   AC_SUBST(USING_BROKEN_SUSE_LD)
>
>
> It's probably a very good example of what feature based tests would look
> like. I'd be horrified if we were do that for all flags. The build system
> would blow up tenfold in size and complexity, for no or little gain.
>
> /Magnus
>