A pkg-config file is need for OpenJDK distributions

[sjgcit]

When developing using JNI ( either to start a JVM or to develop native support files for classes ), you need to compile and link against <jni.h> and libjvm.so.

The normal way for developers to do this on Linux systems is to use pkg-config to get the required paths for --cflags and --libs and avoid hardwiring paths into make and other build files.

However OpenJDK does not supply a pkg-config file, which is a shame as it's a very simple file to add to the package.

I would make three observations in this regards :

1. In practical terms libraries should be the normal search path for Linux libraries, so that they can be found by linkers ( ld ) without complex configurations. Having the Java libraries in a completely separate location is not ideal. However, failing the uatomatic installation of a symbolic link in e.g. /usr/lib to the Java runtime libraries, having them accessible via a standard mechanism like pkg-config would be some help.

2. While a pkg-config would be a big help, without libraries being installed on standard paths people distributing non-Java applications that wish to start their own JVM have problems ensuring the application will launch without knowledge of where on the system the Java runtime libraries are. A symbolic link or similar to the Java libs would be useful in it's own right

3. Any symbolic links should probably be made against /usr/lib/jvm/default-path and not the canonical path to the files proper. This allows more flexibility.

Thanks,

  Stephen Geary

[Tiago Stürmer Daitx (tdaitx)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

There has been a few discussions in the past about pkg-config on the OpenJDK mailing lists, the first one back from 2009 http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-July/006480.html

Another thread was started last year on two OpenJDK mailing lists, most messages are the same but a few have been sent only to one of those mailing lists:
http://mail.openjdk.java.net/pipermail/discuss/2014-August/003511.html
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-June/028371.html

again no consensus and no conclusion was reached, the thread either died down or continued in private.

One of those messages linked to a bug report which has an interesting comment from Omair:

"Basically, it's wrong for fedora packages to link against a specific JVM. We use alternatives and JAVA_HOME to allow users to select the right VM at runtime. Linking directly against a VM runs against this. Individual programs needs to be fixed to use dlopen() on the appropriate JVM and use that." @ https://bugzilla.redhat.com/show_bug.cgi?id=740762#c27

Petr's reply was "Which still leaves the burden of locating the shared library location on the application. If pkg-config is not suitable solution, another locator should be provided." - very reasonable, but no further discussion happened over what such locator or solution would look like.

If you believe this is not the case, please let us know or even forward this request upstream, possibly both to OpenJDK [1] and IcedTea [2].

[1] http://mail.openjdk.java.net/mailman/listinfo/discuss
[2] http://mail.openjdk.java.net/mailman/listinfo/distro-pkg-dev

[sjgcit (sg-euroapps)]

My view is that it is not an OpenJDK issue, but a package maintainer's issue.

I think whether other LInux distros want to include a pkg-config file is a matter for them to decide. My view is that it's easy to add to a distro, but no-one will do it unless someone starts. I don't think Ubuntu need follow anyone else's lead on this - they can take the lead, as a major distro.

Until someone actually does this, no one will. No consensus will form until it's already been done somewhere. I do not see any way for the OpenJDK people to maintain pkg-config files for distributions they do not ultimately control. So it's down to individual distros. I think the very long gestation time we've already had in the community shows it's won;t happen until someone takes the lead.

The whole point of a pkg-config is to be provide a method for accessing resources that is package independent. Where the package maintainers place files should be left to them. But the pkg-config files are so useful and simple it's hard to see a justification for omitting them. I might suggest they should be standard for practically all applications that have developer components, but that's beyond the scope of this bug.

Thanks.

[Tiago Stürmer Daitx (tdaitx)]

I am mostly a user of pkg-config, my experience as a developer using
it directly is somewhat limited. So please understand that I may be
lacking information on pkg-config's scope and usage.

That said, I understand your request (plus the requests made before on
those mailing lists) and what it is expected to achieve.

Previously I quoted a few comments on the other bug which seem to
indicate that pkg-config is not the right tool:

"Basically, it's wrong for fedora packages to link against a specific
JVM. We use alternatives and JAVA_HOME to allow users to select the
right VM at runtime. Linking directly against a VM runs against this.
Individual programs needs to be fixed to use dlopen() on the
appropriate JVM and use that."

"Which still leaves the burden of locating the shared library location
on the application. If pkg-config is not suitable solution, another
locator should be provided."
@ https://bugzilla.redhat.com/show_bug.cgi?id=740762#c27

On Ubuntu we also allow users to select their VM using alternatives,
thus linking directly against a VM through pkg-config will be
problematic as well. If you disagree, could you explain why and
provide some pointers so I can start looking?

Unless there is a way to use pkg-config such as it does not violate
this, we would required another solution. What this "locator" would be
or how it would work is unclear at the moment. Please let me know if
you might have a proposal for this.

On Wed, Nov 25, 2015 at 9:08 AM, sjgcit <email address hidden> wrote:
> My view is that it is not an OpenJDK issue, but a package maintainer's issue.
>
> I think whether other LInux distros want to include a pkg-config file is
> a matter for them to decide. My view is that it's easy to add to a
> distro, but no-one will do it unless someone starts. I don't think
> Ubuntu need follow anyone else's lead on this - they can take the lead,
> as a major distro.
>
> Until someone actually does this, no one will. No consensus will form
> until it's already been done somewhere. I do not see any way for the
> OpenJDK people to maintain pkg-config files for distributions they do
> not ultimately control. So it's down to individual distros. I think
> the very long gestation time we've already had in the community shows
> it's won;t happen until someone takes the lead.
>
> The whole point of a pkg-config is to be provide a method for accessing
> resources that is package independent. Where the package maintainers
> place files should be left to them. But the pkg-config files are so
> useful and simple it's hard to see a justification for omitting them. I
> might suggest they should be standard for practically all applications
> that have developer components, but that's beyond the scope of this bug.
>
> Thanks.
>
> --
> You received this bug notification because you are subscribed to
> openjdk-7 in Ubuntu.
> Matching subscriptions: all openjdk-7 bugs
> https://bugs.launchpad.net/bugs/1518741
>
> Title:
> A pkg-config file is need for OpenJDK distributions
>
> Status in openjdk-7 package in Ubuntu:
> New
>
> Bug description:
> When developing using JNI ( either to start a JVM or to develop native
> support files...

[sjgcit (sg-euroapps)]

I do not see pkg-config and /etc/alternatives are being in any way in
conflict.

pkg-config provides instructions for library linking, something
/etc/alternatives does not do, so it's a red herring for the provision of
that info, IMO. There's simply no practical way to use it like that.

pkg-config can certainly use paths defined to link **via**
/etc/alternatives and it's got t be a system independent method.

If Ubuntu want to "integrate" the pkg-config paths with /etc/alternatives
it simply boils down to adding a link to major folders ( especially "lib"
and "bin" stuff ) in the /etc/alternatives folder.

Note I am **not** suggesting individual links to e.g. every shared library,
but links to directories. Whether in practical terms links to library
files is something that /etc/alternatives should provide is outside the
scope of this bug, although I would say I can see an argument for that.

The paths is pkg-config files ( in general for any package ) could then use
/etc/alternatives to create system and platform independent paths for
developers to find. pkg-config users would be happy, /etc/alternative
users would be happy.

From Ubuntu maintainer's point of view it would make the /etc/alternative
paths be the "reference" to be used on Ubuntu platforms. Maintainers of
package would need to be told to use those paths and not hard-wire explicit
paths in to config files. I imagine that's already the case with Ubuntu
maintainers.

From pkg-config users it still provides then with what they need and they
don't even need to know about /etc/alternatives links, they simply get the
path they require.

One issue specific to Java is the naming and distribution of libraries in
OpenJDK. For example the path to find libjvm.so includes an explicit path
element of "jamvm". That's a problem in terms of platform path abstraction
simply because it's not. If you switch to another version of Java then the
name jamvm may become irrelevant. I do not think that such build-specific
paths should be used in OpenJDK at all. A better choice would be e.g. a
symbolic link called "vm" which could then act as an abstracted path
element for all distros.

However, even doing that is slightly problematic as OpenJDK defines **two**
libjvm.so files, one for server and one for non-server. This is well
outside of the scope of this bug, but I feel strongly that these should not
be named identically. I would suggest an explicit libjvm_server.so ( and
similar ) naming convention would make for safer dynamic linking friendly
scenarios. With the same names being shared you get the risk of search
paths getting confused. You're probably well aware that the server version
of libjvm.so is different to the non-server, so we're not talking about
hard-links to the same file, but physically different files.

But in regard to this bug ( I suppose feature enhancement is a better name
), I think pkg-config can be easily and painlessly made to use
/etc/alternatives with symbolic links in folders.

$JAVA_HOME has been tried. The biggest problem with it is that it was
never used consistently and ( as usual ) the broader Java community simply
never got it's act together. It also woul...