Bug 740762 - java.library.path is missing some paths
Summary: java.library.path is missing some paths
Keywords:
Status: CLOSED DUPLICATE of bug 449456
Alias: None
Product: Fedora
Classification: Fedora
Component: java-1.7.0-openjdk
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Omair Majid
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 740897
TreeView+ depends on / blocked
 
Reported: 2011-09-23 09:39 UTC by Stanislav Ochotnicky
Modified: 2016-05-11 22:40 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-30 00:34:29 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 449456 0 low ASSIGNED Make Java shared libraries like libjvm.so available for linking 2023-01-25 12:31:34 UTC
Red Hat Bugzilla 1112012 0 unspecified CLOSED java-1.8.0-openjdk on aarch64 returns the wrong path for -ljvm 2021-02-22 00:41:40 UTC

Internal Links: 449456 1112012

Description Stanislav Ochotnicky 2011-09-23 09:39:30 UTC
Description of problem:
Paths specified by java.library.path are missing some directories. Simple reproducer:

    class jlibpath
    {
       public static void main(String args[])
       {
          System.out.println(System.getProperty("java.library.path"));
       }
    }


Version-Release number of selected component (if applicable):
java-1.7.0-openjdk-1.7.0.0-0.1.20110803.fc17.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Compile above reproducer
2. Run: /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java testpath

  
Actual results:
/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

Expected results:
Something similar to java-1.6.0-openjdk output which is:
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

Additional info:

Comment 1 Stanislav Ochotnicky 2011-09-23 10:24:58 UTC
To be exact I expected something like this from openjdk 1.7.0:

/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

Comment 2 Andrew John Hughes 2011-09-23 16:19:11 UTC
The culprit is:

#define REG_DIR         "/usr/java/packages"

in src/os/linux/vm/os_linux.cpp.  The others have gone because library loading was cleaned up.

The obvious thing to do from my perspective is fix this to be the install path, making it configurable.  On Fedora, /usr/java/packages would be replaced with /usr/lib/jvm/java-1.7.0-openjdk for example.

Do we actually need all three i.e.

<install>/lib/amd64
<jre_install>/lib/amd64
<jre_install>/lib/amd64/server

Based on existing content, <jre_install>/jre/lib/amd64 seems sufficient.

Are some packages actually broken as a result of this change?

Comment 3 Petr Pisar 2011-09-26 08:03:20 UTC
This problem was spotted by me when searching a way how to get path to JDK shared libraries to be able to link them to my native C code (i.e. the `-L' option passed to gcc or ld). I found java.library.path as the best approach which does not work for openjdk-1.7 obviously. If you have no better way to get these paths, I would appreciate if all paths kept in the list. E.g. libjvm.so resides under `server' directory in openjdk-1.6.

Comment 4 Fedora Update System 2012-03-13 13:52:08 UTC
java-1.7.0-openjdk-1.7.0.3-2.1.fc16.2 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/java-1.7.0-openjdk-1.7.0.3-2.1.fc16.2

Comment 5 Fedora Update System 2012-03-13 13:53:04 UTC
java-1.7.0-openjdk-1.7.0.3-2.1.fc17.2 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/java-1.7.0-openjdk-1.7.0.3-2.1.fc17.2

Comment 6 Petr Pisar 2012-03-15 11:15:15 UTC
I'm sorry the returned path are still bad:

$ rpm -qf /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/bin/java 
java-1.7.0-openjdk-1.7.0.3-2.1.fc16.2.x86_64

$ /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/bin/java -version
java version "1.7.0_b147-icedtea"
OpenJDK Runtime Environment (fedora-2.1.fc16.2-x86_64)
OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)

$ /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/bin/java JavaConfig --libs-only-L
-L/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/lib/amd64 -L/usr/lib64 -L/lib64 -L/lib -L/usr/lib

$ LANG=en stat /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/lib/amd64
stat: cannot stat `/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/lib/amd64': No such file or directory

Expected paths for this build are:

/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/lib/amd64/
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/lib/amd64/server/

So not only the correct paths are missing, also given path is invalid.

Comment 7 Deepak Bhole 2012-03-15 13:48:10 UTC
It is weird that the jre dir is not being added. It was doing so in the local builds I did. Sorry about that.

Do you also need the server/ patch by the way, or would /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/lib/amd64/ suffice?

Thanks for testing it. I will work on this and confirm with the build rpm before pushing again.

Comment 8 Petr Pisar 2012-03-15 14:14:19 UTC
Yes, I need the server path because it contains libjvm.so. I need all paths where JVM dynamic libraries reside to pass these paths to native linker.

Comment 9 Deepak Bhole 2012-03-21 17:34:55 UTC
Looking at what the OpenJDK6 had (hs20):

http://hg.openjdk.java.net/hsx/hsx20-gate/master/file/f0f676c5a2c6/src/os/linux/vm/os_linux.cpp

It seems like it too does not add $JAVA_HOME/jre/lib/... to the path.

I think the issue was that the launcher no longer sets LD_LIBRARY_PATH, due to this commit:
http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/de45eac5670e

Thus updating java.library.path seems to be incorrect, as the setting code has not changed. It is LD_LIBRARY_PATH that has changed.

Updating LD_LIBRARY_PATH is not a good idea IMO. I looked into your problem more and I think that a better solution is to use something like:


String libdir = System.getProperty("java.home") + "/lib/" + System.getProperty("os.arch");
String libjvmdir = System.getProperty("java.home") + "/lib/" + System.getProperty("os.arch") + "/server";

System.out.println(libdir);
System.out.println(libjvmdir);

I am going to mark this as WONTFIX, but please feel to re-open if you disagree.

Comment 10 Andrew John Hughes 2012-03-21 17:42:24 UTC
Yes, the LD_LIBRARY_PATH changes caused this change, as mentioned in comment #2.

I still think there's a case for changing /usr/java/packages to something we actually use, but that's a separate issue.

Comment 11 Deepak Bhole 2012-03-21 17:52:02 UTC
(In reply to comment #10)
> Yes, the LD_LIBRARY_PATH changes caused this change, as mentioned in comment
> #2.
> 
> I still think there's a case for changing /usr/java/packages to something we
> actually use, but that's a separate issue.

Ah sorry, I thought you had meant that loading was cleaned up in os_linux.cpp

Comment 12 Andrew John Hughes 2012-03-21 23:25:24 UTC
Yeah, sorry, it could have been clearer.  Thought this bug was long dead :-)

Comment 13 Petr Pisar 2012-03-22 08:51:05 UTC
(In reply to comment #9)
> Looking at what the OpenJDK6 had (hs20):
> 
> http://hg.openjdk.java.net/hsx/hsx20-gate/master/file/f0f676c5a2c6/src/os/linux/vm/os_linux.cpp
> 
> It seems like it too does not add $JAVA_HOME/jre/lib/... to the path.
> 
You have beautiful comment at os::init_system_properties_values():

  // The next steps are taken in the product version:
  //
  // Obtain the JAVA_HOME value from the location of libjvm[_g].so.
  // This library should be located at:
  // <JAVA_HOME>/jre/lib/<arch>/{client|server}/libjvm[_g].so.
  //
  // If "/jre/lib/" appears at the right place in the path, then we
  // assume libjvm[_g].so is installed in a JDK and we use this path.
  //
  // Otherwise exit with message: "Could not create the Java virtual machine."
  //
  // The following extra steps are taken in the debugging version:
  //
  // If "/jre/lib/" does NOT appear at the right place in the path
  // instead of exit check for $JAVA_HOME environment variable.
  //
  // If it is defined and we are able to locate $JAVA_HOME/jre/lib/<arch>,
  // then we append a fake suffix "hotspot/libjvm[_g].so" to this path so
  // it looks like libjvm[_g].so is installed there
  // <JAVA_HOME>/jre/lib/<arch>/hotspot/libjvm[_g].so.
  //
  // Otherwise exit.
  //
  // Important note: if the location of libjvm.so changes this
  // code needs to be changed accordingly.


> Updating LD_LIBRARY_PATH is not a good idea IMO. I looked into your problem
> more and I think that a better solution is to use something like:
> 
> String libdir = System.getProperty("java.home") + "/lib/" +
> System.getProperty("os.arch");
> String libjvmdir = System.getProperty("java.home") + "/lib/" +
> System.getProperty("os.arch") + "/server";
> 
> System.out.println(libdir);
> System.out.println(libjvmdir);
> 
So you suggest me to duplicate the hard-coded path mess from your code. This is exactly what I do not want. Especially because of last paragraph of the comment:

  // Important note: if the location of libjvm.so changes this
  // code needs to be changed accordingly.

> I am going to mark this as WONTFIX, but please feel to re-open if you disagree.

Can you guarantee the locations will not change and this layout is valid on all platforms?

Or could you provide better way how to get _all_ java library paths?

Comment 14 Petr Pisar 2012-03-22 08:55:03 UTC
And of course the java.library.path property (http://docs.oracle.com/javase/7/docs/api/java/lang/System.html#getProperties()) returns non-existent path on x86_64 now. So at least this is still broken.

Comment 15 Deepak Bhole 2012-03-22 13:23:00 UTC
It is not my code, it was written by Oracle/Sun folks.

java.library.path is meant to contain JNI libraries loaded *by the jvm*. What you are suggesting (adding the extra paths that 6 adds, so that you can link against Java) would be an incorrect use of it. The fact that 6 was appending those paths was a hack and that is why 7 no longer does it.

As for how to get all the library paths, the issue is that there is no pkg-config file for the JDK. I discussed this briefly with Omair Majid (on cc) and while adding one is easy enough, the problem there is that there is no generally accepted name that we can use for the .pc file that is common across all distros, which means we are back to patching dependent code in Fedora to use that specific .pc name.

Comment 16 Andrew John Hughes 2012-03-22 14:35:44 UTC
Can you explain how you'd foresee a pkg-config file for OpenJDK in more detail?  If we added such a thing to IcedTea (and possibly upstream to OpenJDK), it would make its way (with time) to all distros.  I don't see where the "we can only change Fedora" argument comes in at all.

Comment 17 Deepak Bhole 2012-03-22 14:53:31 UTC
Icedtea may be used by many distros, but it is still not guaranteed to be used by all. For upstream dependent projects to start using something, it has to be on most if not all.

That said, it is not impossible -- I just meant that it needs some more thought along those lines rather than just creating a dropping in a .pc file in the RPM as a quick fix.

As for the contents of it, I had roughly something like this in mind:

prefix=/usr/lib/jvm/java-1.7.0...
libdir=${prefix}/jre/lib/<arch>/server/
includedir=${prefix}/include/

Name: <name>
Description: ...
Version: 1.X.Y
Libs: -L${libdir} -ljvm
Cflags: -I${includedir}

Comment 18 Petr Pisar 2012-03-22 15:32:20 UTC
Deepak, thanks you explaining the java.library.path semantic. Once you put relevant value to the property (if there is standardized search path for JNI libraries, then that one; otherwise let it null or empty), you can close this bug report.

You can consider the pkg-config file as new feature and track it with different bug report. I'm not expert in calling JVM from native applications. I just like to see portable way how to compile such applications (to prevent from this: http://pkgs.fedoraproject.org/gitweb/?p=pl.git;a=blob;f=pl.spec;h=6323418356c6ccc3632828408a2bb3b4c6014bd6;hb=f9276e466f7d2124e9a6ef94dca6aef1abf509cb#l166). The upper sketch looks good. I'm not sure -ljvm is the only needed library. E.g. SWI Prolog links to -ljava -ljvm -lverify. If there are different use cases, you can create multiple pkg-config files or you can add more pkg-config variables that can queried by "pkg-config --variable".

Comment 19 Andrew John Hughes 2012-03-22 15:49:10 UTC
IcedTea (note capitalisation) is used by all the major distros, and it's at least a start (better than writing off the idea).  As I say, getting it into OpenJDK would be ideal, but harder.  

We already have a .desktop file being generated using similar data, so this doesn't look too hard to implement.  libdir would need more than just the one directory.  Can that field be a list?
I guess:

libdir=${prefix}/jre/lib/${arch}

Libs: -L${libdir} -L${libdir}/client -L${libdir}/server 

would be a start, though there are others in there too.

Comment 20 Deepak Bhole 2012-03-22 15:59:12 UTC
Ah, yes we will need libdir itself too, in addition to client/ or server/ . As for adding both, we always ship the server -- is there a case where we ship client only? if not, I don't know if we need the client in the -L path there

Comment 21 Omair Majid 2012-03-22 16:13:53 UTC
(In reply to comment #20)
> Ah, yes we will need libdir itself too, in addition to client/ or server/ . As
> for adding both, we always ship the server -- is there a case where we ship
> client only? if not, I don't know if we need the client in the -L path there

The path here determines which jvm the JNI programs will start up. Even if we (Fedora) never ship client/ only, do we always want JNI code to star the server vm? Also, I think the order in which -L${libdir}/client -L${libdir}/server matters.

As for IcedTea, it can get more complicated. With the --with-additional-vms= configure option, you can get zero/, jamvm/, cacao/ and (possibly) others.

Comment 22 Bill C. Riemers 2012-06-20 20:58:19 UTC
There is some interesting discussions about this in some of the mailing lists.  I'm not going to repeat them here, but I think someone should mention some of the key findings.  First off, it seems this bug causes severe problems in that it breaks common applications such as elluminate and javadjvu, because libraries such as libjawt are not loaded.  (Javadjvu is opensource, you can find it at http://javadjvu.foxtrottechnologies.com .  Versions of this applet are used on sights such as archive.org.)

Until this is fixed, a workaround is to use a wrapper script for javaws and java that add appropriate libraries into the LD_LIBRARY_PATH.

According to:

http://lwjgl.org/forum/index.php/topic,4085.msg22061.html#msg22061

Not loading the libraries was a deliberate update

According to Andrew Haley: (I am paraphasing below.)
> However, breaking awt was probably not intentional.  In particular Toolkit.getDefaultToolkit() should just work without a need to adjust library paths and such.)
>
> The patch says
>
> > All other required
> > + * libraries are loaded by the runtime linker, by virtue of the $ORIGIN paths
> > + * baked into the shared libraries, by the build infrastructure at compile time.
>
> which is not happening.


Bill

Comment 23 Omair Majid 2012-09-12 21:28:21 UTC
(In reply to comment #22)
> There is some interesting discussions about this in some of the mailing
> lists.  I'm not going to repeat them here, but I think someone should
> mention some of the key findings.  First off, it seems this bug causes
> severe problems in that it breaks common applications such as elluminate and
> javadjvu, because libraries such as libjawt are not loaded.  (Javadjvu is
> opensource, you can find it at http://javadjvu.foxtrottechnologies.com . 
> Versions of this applet are used on sights such as archive.org.)

Those are actually two separate issues.

The libjawt breakage has been fixed in OpenJDK:
http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f003387c33ad

More background about this bug is availabe at:
http://mail.openjdk.java.net/pipermail/build-dev/2012-July/006486.html

The Javadjvu applet not working was a (completely unrelated) bug in IcedTea-Web and fixed there:
http://icedtea.classpath.org/hg/icedtea-web/rev/924a83097ed7

Comment 24 Fedora End Of Life 2013-04-03 19:27:10 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 25 Omair Majid 2014-06-26 14:10:38 UTC
How about this pkg-config file?

jdk=@JDK@
jre=@JRE@
lib_arch=@JRE@/lib/@ARCH@

Name: java-1.8.0-openjdk
Description: OpenJDK 8
Version: @VERSION@
Cflags: -I${jdk}/include -I${jdk}/include/linux
Libs: -L${lib_arch} -L${lib_arch}/@VM@ -ljvm -ljava

When built, it will look something like this (on x86_64):

jdk=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5.x86_64
jre=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5.x86_64/jre
lib_arch=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5.x86_64/jre/lib/amd64

Name: java-1.8.0-openjdk
Description: OpenJDK 8
Version: 1.8.0.5
Cflags: -I${jdk}/include -I${jdk}/include/linux
Libs: -L${lib_arch} -L${lib_arch}/server -ljvm -ljava

Are there any additional features needed? If this looks okay, I will send it upstream for further discussion.

Comment 26 Petr Pisar 2014-06-26 14:29:53 UTC
That looks great.

Comment 27 Omair Majid 2014-06-26 17:44:10 UTC
I sent the pkg-config file upstream.

Then I talked to Mikolaj who pointed me to this:
https://bugzilla.redhat.com/show_bug.cgi?id=449456#c5

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.

I think this bug should be closed as WONTFIX.

Comment 28 Petr Pisar 2014-06-27 05:48:00 UTC
(In reply to Omair Majid from comment #27)
> I sent the pkg-config file upstream.
> 
> Then I talked to Mikolaj who pointed me to this:
> https://bugzilla.redhat.com/show_bug.cgi?id=449456#c5
> 
> Basically, it's wrong for fedora packages to link against a specific JVM. We
> use alternatives

Alternatives control files. pkg-config file is a file. 

> and JAVA_HOME to allow users to select the right VM at
> runtime.

Indeed?

$ type -a java
java je /bin/java
java je /usr/bin/java

$ readlink --canonicalize /usr/bin/java
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre/bin/java

$ cat /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre/bin/java
#!/bin/bash
if [ -e  /usr/lib64/libabrt-java-connector.so ] ; then
  exec -a java /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre-abrt/bin/java -agentpath:/usr/lib64/libabrt-java-connector.so=abrt=on "$@" 
else
  exec -a java /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre-abrt/bin/java "$@"
fi

$ file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre-abrt/bin/java
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre-abrt/bin/java: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=848e939f06a059e6b1b00be447c91d0a0effabbb, stripped

Where exactly is JAVA_HOME environment variable used when launching java? I cannot see that.

> 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.

All the bugs are about off-loading this tedious and always broken application-side implementations to one central place. Preferably to the JDK.

Comment 29 Fedora End Of Life 2015-01-09 21:53:00 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 30 Fedora End Of Life 2015-05-29 08:40:20 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 31 Fedora End Of Life 2015-06-30 00:34:29 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 32 Andrew John Hughes 2016-05-11 22:40:21 UTC

*** This bug has been marked as a duplicate of bug 449456 ***


Note You need to log in before you can comment on or make changes to this bug.