Dynamically linked libjli for *BSD

[Bryan Everly]

Kurt,

I pulled down the latest change sets (thanks for tweaking the stuff I
submitted - much improved over what I did) and I applied your patch.
It got farther in the build process but then started trying to compile
a bunch of ALSA_Linix stuff. Clearly the NO_ALSA flag (don't recall
the exact name) didn't work the way I thought it would. Can you point
me to the right config file and I will get a patch together to get
psst this?  I was grep'ing and find'ing to no avail last night.

Thanks,
Bryan

> On May 17, 2015, at 11:30 AM, Christos Zoulas <christos at zoulas.com> wrote:
>
> On May 16,  3:06pm, kurt at intricatesoftware.com (Kurt Miller) wrote:
> -- Subject: Dynamically linked libjli for *BSD
>
> | Hi Greg, Christos,
> |
> | Currently building the jdk with debug symbols fails on OpenBSD and
> | I suspect at least FreeBSD (since it is disabled in the ports tree
> | java/openjdk8/Makefile too). This was determined to be caused by
> | libjli being statically linked on *BSD. [1]
> |
> | Statically linking libjli was a work-around introduced in 1.5 or 1.6
> | most likely due to the lack of rpath $ORIGIN support in our runtime
> | linkers. All of the BSD's have rpath $ORIGIN support for several
> | years now. I propose that we eliminate linking libjli statically and
> | remove another difference we have in the build when compared to
> | Linux and Solaris. Dynamically linking libjli fixes the build with
> | debug symbols.
> |
> | Please review/test this diff on FreeBSD and NetBSD and let me know if
> | you are okay with the change.
>
> Works on NetBSD. Just a note, $ORIGIN support is not fully implemented
> on NetBSD, there is a #ifdef notyet in kern_exec.c... But running java
> with a full path in $0 works. I'd say apply it if it works for others.
>
> christos
>