openjdk team mailing list archive

[sjgcit <1518741@xxxxxxxxxxxxxxxxxx>]

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 would not directly address the issue
of this bug, as those paths never was intended to provide the --cflags and
--libs information that is needed by developers.

So pkg-config with the paths it supplies linked via /etc/alternatives
"entries" would seem the logical way forward,


On Wed, Nov 25, 2015 at 11:42 AM, Tiago Stürmer Daitx <
1518741@xxxxxxxxxxxxxxxxxx> wrote:

> 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 <1518741@xxxxxxxxxxxxxxxxxx>
> 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 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
> >
> > To manage notifications about this bug go to:
> >
> https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1518741/+subscriptions
>
>
> --
> Tiago Stürmer Daitx
> Software Engineer
> tiago.daitx@xxxxxxxxxxxxx
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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 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
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1518741/+subscriptions
>

-- 
You received this bug notification because you are a member of OpenJDK,
which is subscribed to openjdk-7 in Ubuntu.
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 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1518741/+subscriptions